[PD] [GEM]: multiple gemwin

Tom Schouten doelie at zzz.kotnet.org
Thu Sep 9 19:26:05 CEST 2004

On Thu, Sep 09, 2004 at 12:46:20PM +0100, Ivan Franco wrote:
> Ok, just another general comment: 
> I personally think that one thing to keep in mind, concerning 
> architecture/implementation on all of 
> PD's visual externals, would be to have a nice performance of both 
> visuals and audio 
> running in the same PD patch. The most interesting thing about having 
> both 
> visuals and audio in the same app is to be able to drive both in 
> parallel. 
> It's just a bit frustrating when you have this beautiful Gem patch and 
> then you throw some simple synthesis in and "click, drop, glitch"! 
> Ugh....   
> This is a problem with all packages and I don't know the implications 
> on 
> the developing side. Just thinking out loud! :) 

it's because it is one of those invisible hard problems :)

because of the architecture of pd, there is no real way to solve this.
i still think this is a very good thing, actually. pd's serial nature
makes it simpler than a parallel approach.

you can solve this with threads, but then you somehow need to introduce
the concept 'dropped frame' or similar and other synchronization methods.

when you run 2 pd's and try to get things working, you'll see some things
are not 'real-time' any more, because there is a round trip delay between
the 2 pd's, that is not predictable. that's about the problem you need
to solve when adding a processing thread to pd.

not that it's not possible, it's just not so easy to do right.
pdp has this (procqueue), but it's not actually working very well.

wvvw has this, and i think there it's working better. i'm still looking
for the 'correct' approach.


More information about the Pd-list mailing list