Le 2012-02-12 à 18:10:00, Hans-Christoph Steiner a écrit :
- 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 ?
- 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