[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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090129/77e70b20/attachment.bin>

More information about the Pd-list mailing list