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 cyrille.henry@la-kitchen.fr 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