[PD] spread Gem-computation over several dsp-cycles (?) (was: [Gem]: gem-pointer and [list] OR slow [repeat])

[Roman Haefeli]

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