> On Feb 22, 2016, at 2:09 PM, pd-list-requ...@lists.iem.at wrote: > > From: Eugene Lazarchik <evgenius.lazarc...@gmail.com > <mailto:evgenius.lazarc...@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/>
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
