[PD] GUI and DSP

[Mathieu Bouchard]

Le 2012-02-12 à 18:10:00, Hans-Christoph Steiner a écrit :

>> 1) pd completely removed redrawing logic from the c code and migrated 
>> it into tcl (which is what you may have done in great part already 
>> inside desire-data)

The big problems with (1) is that not only you need to copy all the 
visible settings of the c object into tcl so that the tcl side has direct 
access to the info it needs to have, you also to have to sync those 
things between the two copies. E.g. what happens when you move an object 
while the patch changes its displayed value, or its background colour ?

>> 2) pd used a different toolkit that allowed for more intelligent 
>> addressing of individual gui components (again, JUCE IMO comes at the 
>> very top here)

Ok, this needs something like step (1) above, but also note that if 
you are going to use a GUI toolkit that can't be used from Tcl, you either 
have to port it to Tcl, or stop depending on Tcl, which itself means 
either use a Tcl parser written in a language supported by JUCE, or use a 
different syntax that doesn't refer to Tcl (such as a binary protocol).

> I agree.  I think a lot of this can be done incrementally.

It's not just that it can : it ought to be incremental. An example of 
something not done incrementally is DesireData, and see where it did lead.

> Basically, take a chunk of logic and refactor it so that Tcl/Tk handles 
> the GUI stuff and pd sends pd messages rather than lines of Tcl.

Sending Pd messages fixes the Tcl dependency problem. You could even run 
Pd in the server.

But note that client and server could be merged, so that you don't have to 
serialise and deserialise every thing that the client might need. Then 
pd-gui would become an extra thread in the server.

More client-server separation is more work, and the amount of sync-work 
required is greater than what it is in Pd now. I don't know how that 
compares to the amount of sync-work that would be done by a threaded 
model.

But basically, there are problems that are fundamental problems, and if 
you avoid solving things with multithread because mutexes are troublesome, 
then you'll solve those problems using processes that have to tell each 
other « ok, done, I'm ready » all of the time and it can grow to similar 
levels of complexity. For each situation, one or the other might be 
easier, but it's not very obvious in advance. What's obvious is that 
people can get into ideologies, and DesireData's design partially had to 
do with a threads-are-evil ideology.

OTOH, just because the possibility of multi-client pd and remote-client pd 
are not exploited by many people, doesn't really mean that they're not 
things worth pursuing... Johannes' multi-client pd involved inserting an 
extra process between the client and the server so that there can be 
several clients. Any kind of insertion like that is much harder (or 
impossible) in a threaded design.

  ______________________________________________________________________
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC