as it seems to be a hot subject, my additionnal 2cents:
pd is a graphical language, so a nice gui isn't a luxury. it provide good readability, which improve the developpement time and even more the maintenance time.
to have a good readability allow you to understand what you have done when you come back way later, allows other people to understand your work.
in textual language readability is known to be important for years. some textual language have a poor readibility and are qualified of 'write only' language.
is it possible to improve puredata gui ? well look at max/MSP one, i think they did a better job. not mandatorily the one we want to copy but a better one according to me.
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.
to have a good readability allow you to understand what you have done when you come back way later, allows other people to understand your work.
'nice' doesn't mean readable. Having patcher elements look like Max/MSP will not allow you to understand patches any better. I have seen (and done) max patches that were totally messy and unreadable without moving things around and trying to figure out what's what. Readability can be achieved with style: abstracting and commenting.
in textual language readability is known to be important for years. some textual language have a poor readibility and are qualified of 'write only' language.
in many cases it's a matter of preference and fuel for 'language wars'. perl is considered unreadable but many people swear by it. Go figure.
cheers -- ./MiS _ __ __ (_)___ Michal Seta / / \ _/^ _| / V |_ \ @creazone.32k.org (___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
Hallo, Michal Seta hat gesagt: // Michal Seta wrote:
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.
All these alternatives don't profit (much) from graph on parent, which I think was one of the major features in recent Pd history.
ciao
Frank Barknecht _ ______footils.org__
On Sunday 23 November 2003 04:41, Frank Barknecht wrote:
All these alternatives don't profit (much) from graph on parent, which I think was one of the major features in recent Pd history.
ciao
This is so beautifull. Thanks for spelling out "Graph On Parent".
I'm almost at the point of kill-filing anyone who sends a certain three letters in a row.
Larry
in textual language readability is known to be important for years. some textual language have a poor readibility and are qualified of 'write only' language.
that's interesting, which ones ??
we usually can decipher more languages than using some to express ourselves ( i'm fighting hard with spanish ) ///
well, way [OT]
cheers, sevy
On Sat, Nov 22, 2003 at 11:52:36PM -0500, Michal Seta wrote:
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.
One feature I really miss from Max is hiding objects and cords in execution mode. Max segmented patch cords are dangerous, because people use this feature to tie connections together in order to create an impression of clarity. Usually, more cosmetic features available to beginners allow them to hide more messy code. I prefer straight connection lines like in PD because it forces to write and organise patches that are easier to understand.
Readability can be achieved with style: abstracting and commenting.
This is true with any programming languages, graphical and textual.
Marc
I would almost say that the situation is the other way around. I find that the lack of segmented patch cords can make small recursive patches a spaghetti nightmare in Pd.
Whereas I see the ability to hide objects/cords in Max as the sole reason behind such messy patch design. Max users will create a nightmare of a patch and then just hide everything. Blech.
I used to think that not having the ability to hide was a huge burden in Pd, but now I realise that it's just taught me cleaner patch aesthetics.
David . . David McCallum . Music wants to be free . http://mentalfloss.ca/sintheta .
Marc Lavallée wrote:
On Sat, Nov 22, 2003 at 11:52:36PM -0500, Michal Seta wrote: One feature I really miss from Max is hiding objects and cords in execution mode. Max segmented patch cords are dangerous, because people use this feature to tie connections together in order to create an impression of clarity. Usually, more cosmetic features available to beginners allow them to hide more messy code. I prefer straight connection lines like in PD because it forces to write and organise patches that are easier to understand.
On Saturday 22 November 2003 19:46, Jerome Etienne wrote:
as it seems to be a hot subject, my additionnal 2cents:
pd is a graphical language, so a nice gui isn't a luxury. it provide good readability, which improve the developpement time and even more the maintenance time.
I'd be very surprised if that were true. Can you site an example of a case where something in PD would be more readable if were more nicely rendered?
Or studies comparing artistically pleasing GUIs, to ugly ones?
Larry
-
David NG McCallum -
Frank Barknecht -
Jerome Etienne -
Larry Troxler -
Marc Lavallée -
Michal Seta -
Yves Degoyon