It's just that the presence of those features makes it much easier not to care, and many users just don't care, and it makes things worse for those of us who have to use that patch elsewhere.

Short story: I'm not going to write the code to implement segmented cords, and I don't think anyone else is, either.  But if someone wants to I'll certainly have a look.

Long story: Non-segmented patch cords suggest a flow chart.  Segmented patch cords-- when used sensibly-- suggest a circuit board.  The difference IMO is nobody in their right mind would suggest circuit boards are an especially readable and friendly way to elucidate a program's logic to human beings.  That's the starting premise of every "flow based" language, though, and I've never seen much evidence to back it up.

All those awful-looking yet functional Pd and Max patches get that way because of the strength of the approach, IMO-- that is, a physical motion with visual animated feedback creates the flow of data.  It's the drawing of the patch matters, not the engraving. For example, imagine that Pd tracked Dan's eye movement on the first version of his patch.  Those objects and wires that he hasn't looked at for awhile fade more and more into the background, unless he tries to focus on one of them and then they return.  I think that's a pretty decent description of how we actually create those write-only patches.  Throw in whatever the opposite of MVC is (e.g., where a toggle can appear smack dab in the model), and you have an environment that's well suited to quick prototyping. Of course that mental model has a short shelf-life, so there's the separate issue of how to turn that into a readable patch.  There are certainly patterns to follow there, and ways to minimize the spaghetti in the first place.  But I think that potential to draw big ugly lines across the whole damn thing is what drives the speed and elegance of developing in the language.  If it weren't then Pd would be like brainfuck, and none of those spaghetti patches would be able to deliver any functionality to speak of.

So for those users who don't care about taking their patches (or, hopefully, small abstractions or subpatches) from "draw-time ugly-mode" to "presentable-to-other-humans mode", I don't think segmented cords matter much.  For the ones who do, I guess I'd rather look at a flow chart than a circuit board.  But given the choice I'd rather watch little gremlins carry buckets of water up a hill, or robots shooting lasers at drones.  Or at least see the data "pumping" through all those boring control wires that seem to always obscure the text I'm trying to read... -Jonathan

On Monday, February 22, 2016 5:20 PM, Matt Barber brbrofsvl@gmail.com wrote:

Hi all, Forcing good practice is not something I'm interested in. Every programming language can be abused horribly (they even have a prize for best/worst abuse of C -- look through some of these http://www.ioccc.org/years.html ). My point was not that avoiding segmented and hideable patch cords fixes these problems. It's just that the presence of those features makes it much easier not to care, and many users just don't care, and it makes things worse for those of us who have to use that patch elsewhere. We did have a long list discussion about best practices, actually, collected here: https://puredata.info/docs/style-guide/PrimordialStyleGuide/

There are other style guides too. On Mon, Feb 22, 2016 at 4:29 PM, Dan Wilcox danomatika@gmail.com wrote:

2016-02-22 17:25 GMT-03:00 Matt Barber brbrofsvl@gmail.com:

I've said this before, but I think there are very good reasons not to ever include segmented patch cords (although hideable patch cords would be even worse). These two features are responsible for some of the very worst patching habits in Max/MSP. Have you ever been called on to run someone's patch, and you need to tweak something for your specific audio setup or fix a bug or whatever, and when you open it you get something that looks like this (one of the first "max patch" results on google image search): http://www.letatoubleu.com/OLcomposer_files/image001.jpg

I agree, and I laugh when people say, this is hard to understand in Max, because of all the cords, I can't imagine how ugly it'd be in Pd.

The solution is the same in both environments: good use of encapsulation via subpatches & judicious use of send/recvs when necessary. Example from robotcowboy:

• one of my first performance patches: https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/* and the second version using subpatches & send/recvs: https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/

This approach led to using GOP and modularizing things between separate patches & a main control patch: https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/ To segment or not to segment is moot, you can create both well designed as well as spaghetti patches in either environment just as you can create well-written or spaghetti code in any textual language. I agree that the environments are not at fault here.

Dan Wilcox @danomatika danomatika.com robotcowboy.com

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Here's a radical idea that I've sometimes pondered: what if we could create left-inlets and right-outlets as well as the standard top- and bottom- ones? Part of the problem that I have with making my patches readable is that PD is always forcing me to go down, when sometimes I want to go sideways. Of course I can always just move the objects over, but then things start to look messy. Allowing me the option of adopting a second dimension might really help to simplify the workflow of the patch. Flow charts are rarely one-dimensional, after all.

Of course I can see the downsides as well: they could only be used in subpatches or abstractions, and it would probably just end up adding to the spaghetti unless it was used judiciously. But it's still something I'd love to see implemented, or at least considered.

Date: Mon, 22 Feb 2016 23:17:24 +0000 To: brbrofsvl@gmail.com; danomatika@gmail.com CC: pd-list@lists.iem.at Subject: Re: [PD] How's Pd limited? From: pd-list@lists.iem.at

It's just that the presence of those features makes it much easier not

to care, and many users just don't care, and it makes things worse for those of us who have to use that patch elsewhere.Short story: I'm not going to write the code to implement segmented cords, and I don't think anyone else is, either. But if someone wants to I'll certainly have a look. Long story:Non-segmented patch cords suggest a flow chart. Segmented patch cords-- when used sensibly-- suggest a circuit board. The difference IMO is nobody in their right mind would suggest circuit boards are an especially readable and friendly way to elucidate a program's logic to human beings. That's the starting premise of every "flow based" language, though, and I've never seen much evidence to back it up.All those awful-looking yet functional Pd and Max patches get that way because of the strength of the approach, IMO-- that is, a physical motion with visual animated feedback creates the flow of data. It's the drawing of the patch matters, not the engraving.For example, imagine that Pd tracked Dan's eye movement on the first version of his patch. Those objects and wires that he hasn't looked at for awhile fade more and more into the background, unless he tries to focus on one of them and then they return. I think that's a pretty decent description of how we actually create those write-only patches. Throw in whatever the opposite of MVC is (e.g., where a toggle can appear smack dab in the model), and you have an environment that's well suited to quick prototyping.Of course that mental model has a short shelf-life, so there's the separate issue of how to turn that into a readable patch. There are certainly patterns to follow there, and ways to minimize the spaghetti in the first place. But I think that potential to draw big ugly lines across the whole damn thing is what drives the speed and elegance of developing in the language. If it weren't then Pd would be like brainfuck, and none of those spaghetti patches would be able to deliver any functionality to speak of. So for those users who don't care about taking their patches (or, hopefully, small abstractions or subpatches) from "draw-time ugly-mode" to "presentable-to-other-humans mode", I don't think segmented cords matter much. For the ones who do, I guess I'd rather look at a flow chart than a circuit board. But given the choice I'd rather watch little gremlins carry buckets of water up a hill, or robots shooting lasers at drones. Or at least see the data "pumping" through all those boring control wires that seem to always obscure the text I'm trying to read...-Jonathan

On Monday, February 22, 2016 5:20 PM, Matt Barber brbrofsvl@gmail.com wrote: Hi all,Forcing good practice is not something I'm interested in. Every programming language can be abused horribly (they even have a prize for best/worst abuse of C -- look through some of these http://www.ioccc.org/years.html ).My point was not that avoiding segmented and hideable patch cords fixes these problems. It's just that the presence of those features makes it much easier not to care, and many users just don't care, and it makes things worse for those of us who have to use that patch elsewhere.We did have a long list discussion about best practices, actually, collected here:https://puredata.info/docs/style-guide/PrimordialStyleGuide/There are other style guides too.On Mon, Feb 22, 2016 at 4:29 PM, Dan Wilcox danomatika@gmail.com wrote:2016-02-22 17:25 GMT-03:00 Matt Barber brbrofsvl@gmail.com:I've said this before, but I think there are very good reasons not to ever include segmented patch cords (although hideable patch cords would be even worse). These two features are responsible for some of the very worst patching habits in Max/MSP. Have you ever been called on to run someone's patch, and you need to tweak something for your specific audio setup or fix a bug or whatever, and when you open it you get something that looks like this (one of the first "max patch" results on google image search):http://www.letatoubleu.com/OLcomposer_files/image001.jpgI agree, and I laugh when people say, this is hard to understand in Max, because of all the cords, I can't imagine how ugly it'd be in Pd.The solution is the same in both environments: good use of encapsulation via subpatches & judicious use of send/recvs when necessary.Example from robotcowboy:* one of my first performance patches: https://www.flickr.com/photos/danomatika/25082084442/in/datetaken-public/* and the second version using subpatches & send/recvs: https://www.flickr.com/photos/danomatika/24573539133/in/datetaken-public/Thi... approach led to using GOP and modularizing things between separate patches & a main control patch: https://www.flickr.com/photos/danomatika/25107115651/in/datetaken-public/To segment or not to segment is moot, you can create both well designed as well as spaghetti patches in either environment just as you can create well-written or spaghetti code in any textual language. I agree that the environments are not at fault here.--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com_______________________________________________Pd-list@lists.iem.at mailing listUNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list