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

[Kyle Klipowicz]

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 at 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 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
>


-- 

http://theradioproject.com
http://perhapsidid.blogspot.com

(((())))(()()((((((((()())))()(((((((())()()())())))
(())))))(()))))))))))))(((((((((((()()))))))))((())))
))(((((((((((())))())))))))))))))))__________
_____())))))(((((((((((((()))))))))))_______
((((((())))))))))))((((((((000)))oOOOOOO