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

cyrille henry cyrille.henry at la-kitchen.fr
Wed Feb 28 17:15:32 CET 2007



cyrille henry a écrit :
> hello,
> 

> 
> anyway, if you wish to draw 1000 primitive,( with a well optimized patch,) the only thing you need is a good graphic card.
> 

btw.
http://nusmuk.free.fr/fleur/
some of those got more than 200 000 cube, (render at 1 fps for the slower).

patch to make this is almost the LS demo patch i send to this list few time ago.

ok, i don't make sound with those, but a good graphic card really improve processing speed.

cyrille

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




More information about the Pd-list mailing list