[PD] spread Gem-computation over several dsp-cycles (?)
IOhannes m zmoelnig
zmoelnig at iem.at
Wed Feb 28 14:46:22 CET 2007
Roman Haefeli wrote:
> hello cyrille
>
> thank you. [any] was what i was looking for. it can store a gem-pointer.
> but as you mentioned it doesn't work when delayed.
>
> putting this in the render chain works and gives the expected result:
>
> [t b b a]
> | / /
> [any ]
>
> but this makes pd/gem completely stuck:
>
> [t b b a]
> | | |
> | [del 10] |
> | / /
> [any ]
>
> as you said, this is obviously the wrong approach. but my problem
> persists. unfortunately i can't see the design of gem behind the
> objects. so i wonder if there is still a solution.
this is not a question of the design of Gem but of openGL.
for most objects (but the pix_ stuff), Gem directly communicates with
the underlying openGL-infrastructure.
for this to work, one must get hold of the openGL context.
using delayed gem-messages, the openGL-context will most likely be
grabbed by another application.
>
> i might be wrong but in my eyes it doesn't make sense to do all the work
> that could be done in 50ms in only 1.45ms. the problem i have with my
> gem patch (and probably other gem-patches have as well) is that during
> one dsp-cycle the cpu is hopelessly overloaded, whereas for the next 33
> dsp-cycle there is no work to be done.
on the long run i have plans to put the rendering into a separate
thread. however, don't expect it too soon.
>
> how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come
> along with that? are there other ways to optimize?
2 ways:
- use longer audio buffers (e.g. 100ms)
- use 2 instances of pd: one for audio and one for video; one of them
(or a third one) is "master" and controls the rest.
mfg.asdr
IOhannes
More information about the Pd-list
mailing list