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 > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ > [email protected] 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
