hi IOhannes On Wed, 2007-02-28 at 14:46 +0100, IOhannes m zmoelnig wrote: > 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.
hm... i am bit unsure now. chris clepper said in his previous mail, that gem rendering is not bound to the dsp-ticks. but when you say, that threading would help in this case, does that mean, the rendering _is_ bound to the dsp-ticks? do i understand something wrong? > > 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) for some reason, it doesn't help here. it's not the audio i care about, but that timing is lost and the desired frameperiod grows to 70ms. and what is most surprising here, sometimes i close the patch i am working on and open it again and start rendering and for some unexplainable reason: frameperiod is 50ms. this is with the same patch with the same gem-objects in gemwin. > - 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. yeah, when i want to do audio at the same time, i'll do that. roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list