On Feb 22, 2016, at 2:09 PM, pd-list-request@lists.iem.at wrote:

From: Eugene Lazarchik <evgenius.lazarchik@gmail.com mailto:evgenius.lazarchik@gmail.com>

I consider sends and receives evil. They're similar to global variables or goto statements in general purpose programming languages.

However they are extremely useful when used well, especially in conjunction with $0. I don’t quite get the goto comparison here. Goto is a low level execution construct while send/receives is a higher level abstraction. I tech them as “named, invisible patch cords”.

When you see a receive object, it's not obvious where all corresponding sends may be. As opposed to simply following where the cords go.

The find menu is your friend here but of course one shouldn’t use send/receives for *everything*. I prefer to use patch chords as much as possible but their are times, especially when using GOP where send/receives make things not only more readable but *easier* to understand IMO. This, of course, is a style preference.

Also, libpd and both PdParty & PdDroidParty *rely* on send/receives for both inter app communication as well as their UI implementations.

Also, consider a subpatch (or abstraction), with certain cords connected to it. In a way the inlets and outlets describe how this object can be used: it can receive certain messages through inlets and then send output to the outlets. But if there's sends and receives inside, it becomes much harder to track what the object may do.

That’s a patching design issue and not a problem in the language/environment. If sends & receives are not used willy nilly, including ridiculous fanouts, there’s generally not too much of a problem, especially if a patch is documented.

In regards to the screenshot: it could be simplified by putting stuff into subpatches. However, even when there's only a couple of objects on a subpatch, the cords can still cross the objects if there's no way to segment them. Typical reasons include long objects ([pd $0-descriptive-name-of-the-subpatch], or [t a a a a a a a a] or [route this and that], etc.). Also it's hard to avoid a mess without segmenting if there's a lot of feedback connections (when A's output is connected to B but also B's output is connected to A).

This is usually fixed by arranging things in a good order underneath the [t a a a a a a a a] and subpatching and/or fanning things out. Not impossible to make things easy to understand without overlapping lines.

I’ve picked up quite a few tricks by looking at patches made by a number of people on this list. Maybe what we need is a wiki pages with examples of good patching practice?

Also, simple segmenting can be accomplished via using [t a] objects when desired.

Also, moving functionality in a subpatch usually should only be done when there's something common between the objects inside and they implement a relatively siloed functionality. Otherwise it may be hard to understand what the subpatch is doing and the reader will have to constantly switch between the parent and the subpatch to understand how they work together.

Again, this is a patching design issue. I agree that subpatches should only encapsulate common actions but not implementing things this way is a fault of the person who made the patch.

I have been using the method of adding descriptions to my subpatch as well as inlet/outlet objects as they aren’t used by help in documenting what’s going on:

[pd bass synth]

[inlet midi note vel pair]

[outlet~ pitched down audio]

etc

Dan Wilcox @danomatika https://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/