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.
cheers tom