Luke,

I like some of your ideas, but I'd offer the following:

...

...

Style:

• If giving $0 as an argument to an abstraction, it is always first in

the argument list [1]

I often put it last (and it's specified to be that way e.g. in Memento)

My reasoning here is that $0 is probably the most common thing to pass to an abstraction, but abstractions have varying numbers of arguments, so $0 will sometimes be $3, sometimes $2, sometimes $7, and that swings my brain around. Putting it in the first slot means that $1 gains a sort of second meaning as "my parent's $0", which I think is handy.

Why should we assume anything about an abstraction's parent? It seems to me a lot has to be assumed about the general purpose of abstractions for one to say that a child's $1 should usually be the parent's $0... I tend not to hierarchize my abstractions to quite this extent, and prefer to allow abstractions to be relatively agnostic about their surroundings when possible. There's one style of patching which suggests that abstractions should operate as closely as possible to built-in objects, which (in vanilla at least) are usually also basically unaware of their surroundings (save for [block~] and other canvas-local settings, or send-receive type bindings, which granted depend a lot upon $0 but not usually explicitly as a single argument passed to objects)... Though, I suppose I agree that when $0 *does* need to be passed, it could go first. I can think of many situations where it would want to go last, though -- for instance an abstraction which takes mandatory arguments and optional arguments, of which one of the latter is a number to prepend to a symbol to designate, say, the send symbol of a group of instances within a parent abstraction which might be used e.g. for error cleanup, and which otherwise should be set to that instance's (not the parent's) $0 when not in the presence of a parent that knows what to do with the error message (so it isn't sent anywhere at all).

A related topic is: in general, if there's an adequate solution with an abstraction, should one use it rather than an external? Does this change in pedagogical situations where a student might profit in learning from a rather sparse set of unit generators? Does this change when performance is required above all? etc. etc.

Another related topic -- for GOP abstractions, is it bad form to cover the abstraction name and arguments with a canvas? What if these things are printed as labels on canvases?

...

...

• When prepending $0 to a symbol, only add a "-" to separate it from

another number, like [r $0-1stSend]. Otherwise the symbol should immediately follow, like [r $0mySend].

I always seperate $0 with a $0-dash. $0myGod is easy to misunderstand.

That's all cool, and I think you are in the majority on that. I think I just took camelCase because it reminded me of Smalltalk and Cocoa, which remind me of Pd : ).

Smalltalk and Cocoa remind me more of supercollider (y/n?), which isn't a bad thing at all. Still, I prefer the hyphen after $0 in general, as it can apply to all cases. As an aside, I also prefer $0 at the beginning of a symbol whenever possible to ensure backwards compatibility with <0.40 -- and a [makefilename %d] trick with $0 to allow things like pd-$0-edge_of_now (I suppose I prefer underscores to camelCase... meh - I'm not sure this is vital to "proper" patching, but it does remind me of the C-style the objects themselves are written in).

...

...

• When working with stereo, Left and Right pairs are written with Le

and Ri appended (to distinguish them from an R denoting "receive", above)

I think it's better to remain completely neutral with regard to the numbering of channels. Stereo should not stand out as a preferred case... many other more general nomenclatures could apply, e.g. ch1 ch2 ch3 ch4 (or ch0 ch1, etc. for channel array lovers), or just the numbers, or something else. This might allow code from a stereo garden to be plucked and implemented in a multichannel space in the future, with little worry. Also, actual pairing of loudspeaker to channel number should not, in general, be codified. There are too many "standard" and acceptable configurations by now to anoint some over others.

I guess I second Frank's suggestion and say let's see what patching styles abound and let people be creative -- but when there's codification, let it be generalizable to as many situations as possible.

Thanks for the great suggestion about a style guide, though -- it would be especially helpful to newcomers and students. Things like "decouple number boxes and bangs used for debugging from the workings of the patch" I feel are almost essential examples of efficient and "proper" pd patching. And early, strong, and repetitive grounding in [trigger].

Matt