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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
