This is interesting stuff about the innards of GEM. > the new processing can continue an old process if you use gemlist info object > (to recall last iteration position). (i should have an exemple somwhere > if you wish).
Cyrille, would you please send that patch? It would help my understanding of the discussion tremendously. ~Kyle On 2/28/07, cyrille henry <[EMAIL PROTECTED]> wrote: > hello, > > One solution i see to this generic problem is to run 2 pd : 1 for audio and 1 > for Gem. this "could" gives better result, but it will not be perfect. > an other solution would be to wait until gem run in it's own thread, but i > don't think this will be possible in a near future. > > last thing i can see is to use buffer 0. > you could then bang gemhead when you want. you can't use the any object to > delay the end of a processing, but you can start a new one whenever you want. > the new processing can continue an old process if you use gemlist info object > (to recall last iteration position). (i should have an exemple somwhere > if you wish). > but with this technique, you will see the image while it's drawing. > in order to clear the image, you will need to draw somthing black over the > windows, and clear the Z buffer in order to be able to draw anything else > (with GEMglClearDepth) > > > > anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) > the only thing you need is a good graphic card. > > > > don't forget you can optimized your patch with GEMglGenList / GEMglNewList > etc in order to create a display list so that you patch could resume in : > > repeat 1000 > [ > GEMglCallList > > > cyrille > > Roman Haefeli a écrit : > > 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. > > > > 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. > > > > how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come > > along with that? are there other ways to optimize? > > > > roman > > > > On Wed, 2007-02-28 at 00:43 +0100, cyrille henry wrote: > >> to store gem pointer, you can use the any object. > >> but if you want to render primitive when gem does not expect it (like > >> sprend in the 50ms as you explain), you can't expect it to render anything. > >> in the better case, it will not crash. > >> > >> cyrille > >> > >> > >> Roman Haefeli a écrit : > >>> hi all > >>> > >>> it's a known trick to use [repeat] from zexy in a gem render chain to > >>> produce funny effects and to multiply the rendering of the attached > >>> objects. > >>> the problem i have here, is that i use a [repeat] with a very high > >>> iteration number (>1000). after the [repeat 1000] some stuff is > >>> calculated and read from tables and then sent to gem-objects on each > >>> iteration. this works well, but on each render-cycle i get a short > >>> dropout. i use the default framerate of 20, that should make 50ms per > >>> frame, but with [realtime] i measure around 70ms. i could live with > >>> that, but i thought that this could be optimized. > >>> it's the concept of pd, that when a message is triggered, it gets > >>> completely processed in the same dsp-cycle. but when working with gem, > >>> this makes absolutely no sense, since the time between each render cycle > >>> is much higher (50ms in my case). that's why i wanted to build a slow > >>> repeat with [until] and [list], so that i can spread the 1000 iterations > >>> over the whole 50ms. unfortunately it is not possible to store a gem > >>> pointer with [list]. when i connect a [gemhead] to the right inlet of a > >>> [list] and turn rendering on, pd immediately crashes (at least here, i > >>> didn't test on other computers). > >>> i tried also to bang 'manually' the [gemhead] instead, but then the > >>> iterations don't have any effect (no objects are multiplied). > >>> > >>> is there any way to store a gem pointer? or is there another way of > >>> producing slow repeats of a gem pointer? > >>> > >>> any help appreciated! > >>> > >>> roman > >>> > >>> > >>> > >>> > >>> > >>> > >>> ___________________________________________________________ > >>> Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: > >>> http://mail.yahoo.de > >>> > >>> > >>> > >>> > >>> ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> PD-list@iem.at mailing list > >>> UNSUBSCRIBE and account-management -> > >>> http://lists.puredata.info/listinfo/pd-list > >> _______________________________________________ > >> PD-list@iem.at mailing list > >> UNSUBSCRIBE and account-management -> > >> http://lists.puredata.info/listinfo/pd-list > > > > > > > > ___________________________________________________________ > > 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 > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- http://theradioproject.com http://perhapsidid.blogspot.com (((())))(()()((((((((()())))()(((((((())()()())()))) (())))))(()))))))))))))(((((((((((()()))))))))((()))) ))(((((((((((())))())))))))))))))))__________ _____())))))(((((((((((((()))))))))))_______ ((((((())))))))))))((((((((000)))oOOOOOO _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list