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

Roman Haefeli reduzierer at yahoo.de
Wed Feb 28 23:36:08 CET 2007

hi IOhannes

On Wed, 2007-02-28 at 14:46 +0100, IOhannes m zmoelnig wrote:
> Roman Haefeli wrote:
> > 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.
> this is not a question of the design of Gem but of openGL.
> for most objects (but the pix_ stuff), Gem directly communicates with
> the underlying openGL-infrastructure.
> for this to work, one must get hold of the openGL context.
> using delayed gem-messages, the openGL-context will most likely be
> grabbed by another application.
> > 
> > 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. 
> on the long run i have plans to put the rendering into a separate
> thread. however, don't expect it too soon.

hm... i am bit unsure now. chris clepper said in his previous mail, that
gem rendering is not bound to the dsp-ticks. but when you say, that
threading would help in this case, does that mean, the rendering _is_
bound to the dsp-ticks? do i understand something wrong?

> > how do you 'gem-cracks' (cyrille, IOhannes, chris clepper, a.o.) come
> > along with that? are there other ways to optimize?
> 2 ways:
> - use longer audio buffers (e.g. 100ms)

for some reason, it doesn't help here. it's not the audio i care about,
but that timing is lost and the desired frameperiod grows to 70ms. and
what is most surprising here, sometimes i close the patch i am working
on and open it again and start rendering and for some unexplainable
reason: frameperiod is 50ms. this is with the same patch with the same
gem-objects in gemwin.

> - use 2 instances of pd: one for audio and one for video; one of them
> (or a third one) is "master" and controls the rest.

yeah, when i want to do audio at the same time, i'll do that. 


Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

More information about the Pd-list mailing list