[PD] spread Gem-computation over several dsp-cycles (?)

[cyrille henry]

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 at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>> _______________________________________________
>> PD-list at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list