[PD] Re: PD-list digest, Vol 1 #789 - 3 msgs

tzahm at punkass.com tzahm at punkass.com
Sun Nov 23 11:50:40 CET 2003


I also think that segmented patch cords and a way to know what each 
inlet/outlet stands for should have a higher priority than moving to 
another gui toolkit. Adding the option to group-assign color to 
message/object/number  boxes should not be too difficult and probably 
would help readability.

::: sam  :::

> Date: Sat, 22 Nov 2003 23:52:36 -0500
> From: Michal Seta <mis at creazone.32k.org>
> Subject: Re: [PD] about pd's gui
> To: pd-list at iem.at
>
> On Sat, 2003-11-22 at 19:46, Jerome Etienne wrote:
>
>> pd is a graphical language, so a nice gui isn't a luxury.
>
> Isn't adding 'niceties' to existing, working products a luxury?
>
>> it provide good readability, which improve the developpement
>> time and even more the maintenance time.
>
> I don't think that 'nice' will accomplish the above.  But I would opt
> for more functional.  Segmented patch cords would be welcome (although 
> I
> have learnt to live with the way they are now) and inlet/outlet hints
> would be a nice aid.  I don't see the need to put a lot effort into
> porting the gui into some fashionable graphical toolkit.  Adding some
> resources should probably be easier and more intelligent.
>
> As per GUI frontends to patches, the possibilities are already there:
> GriPD, python extern (and through python you can use wxWindows, QT, 
> GTK,
> SDL, tk, etc), and, of course, writing a separate frontend in _any_
> language and communicating via tcp/ip or OSC, or MIDI.






More information about the Pd-list mailing list