[PD] Why I don't like the new automagic
IOhannes m zmoelnig
zmoelnig at iem.at
Thu Jan 29 09:44:29 CET 2009
Mathieu Bouchard wrote:
> On Wed, 28 Jan 2009, Andy Farnell wrote:
>> I remember you explaining this before Mathieu, and it was with great
>> dismay that I realised DesireData was not to be an alternative to
>> pd-gui, but a complete rewrite of the whole show.
> Well it was way too late to realise that, I rewrote much of the C code
> of IEMGUI back in the spring of 2004. DesireData didn't really start in
> mid-2005, it was a revival of an older project.
>> It seems there is a necessary intermediate step by which Pd is
>> properly separated into two truly independent GUI client and sound
>> server code sets. From this position, it opens the door to all kinds
>> of alternative GUIs, so long as clear protocols are established for
>> exchange between pd and pd-gui.
> Well, it may look like that when you don't mess with the code, but I ask
> you to ask yourself: what kind of protocol will that be between the
> client and the server? If you don't touch the server at all, you will
> have to have clients that accept to be told things in the words that the
> server is willing to feed them. Would all the clients have to accept Tcl
> commands from the server, and furthermore, would they all have to accept
> the same details that the server usually feeds to the client, such as
> how to draw each piece of each gui object on the canvas?... and that's
> just the display; the keyboard/mouse is similarly handled much more by
> the server than by the client.
well i guess this is the main problem with how Pd does it right now.
i am all in favour of using tcl/tk for drawing the GUI, but not using
tcl/tk commands over the wire. i would rather have "Pd-ish" commands.
it's gonna be a long road till miller might accept something like this.
that's the reason why i personally am not such a big fan of how the new
pd-devel goes: i think it eventually progresses to fast and might end up
very similar to desire-data. (being a cool project where people have
invested tons of time, but which unfortunately never made it)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
More information about the Pd-list