Okee, here's the first small wooden building for the storage of two-wheeled mechanical contraptions which we must design, architect and finally apply an agreed-upon shade of thin colored acrylic.
Ratification 1: Separators in Send/Receive/Value names
Synopsis: When writing send and receive names, two situations arise in which one might like to separate components of a name.
The characters under consideration are: _, -, ., / (and, camelCasing)
Examples: Separators after a dollarsym, like $0-send. Separators when writing a multi-word name, like my-long-send-name. Separators when writing a hierarchical name to be used within Pd, like drumkit.snare.noise.amount.
Possible confusion: Writing a hierarchical name to be used with OSC, like /drumkit/snare/noise-component, and when writing a namespaced pd object name, like [mapping/upsample]
Questions: Should we separate dollarsyms with the hierarchical separator, or the space separator? (i.e., if space is "-" and hierarchy is ".", should it be $0.my-send or $0-my-send?)
Should we reserve the /, the most obvious choice for a hierarchical separator, for use in OSC names and namespaces, using "." as a 'Pd-hierarchy-separator', or adopt the / for Pd name hierarchies as well?
Now, my thoughts on this: I think we should adopt "-" for spaces, since it's the most prevalent style I've encountered. And, I think whatever we decide on as the hierarchical separator should be used to separate $0, $1 etc from the name itself. When creating a hierarchy in a send/receive, one usually gloms together keys from parent abstractions, e.g. start with /bigsynth, then inside pass $1/filter to a child abstraction, then inside that use $1/cutoff to get /bigsynth/filter/cutoff. I see $0 as no different; it means (or, is used to mean) "this-instance"/cutoff, and thus should be separated accordingly.
And, I have a slight leaning towards "." over "/" as the send/receive hierarchical separator since it provides a distinction from OSC addresses and namespaces.
Best Luke
On 13/08/2008, at 9.27, Luke Iannini wrote:
I think we should adopt "-" for spaces, since it's the most prevalent style I've encountered.
I personal don't care if it's dash or underscore or camelCase.
And, I think whatever we decide on as the hierarchical separator should be used to separate $0, $1 etc from the name itself. When creating a hierarchy in a send/receive, one usually gloms together keys from parent abstractions, e.g. start with /bigsynth, then inside pass $1/filter to a child abstraction, then inside that use $1/cutoff to get /bigsynth/filter/cutoff. I see $0 as no different; it means (or, is used to mean) "this-instance"/cutoff, and thus should be separated accordingly.
I agree.
And, I have a slight leaning towards "." over "/" as the send/receive hierarchical separator since it provides a distinction from OSC addresses and namespaces.
I would be cool if you/someone could cook up some use case examples
of this to makes things more clear in a practical way and less
theoretical/bikeshedcolor-like. I think Frank suggested similar
earlier on.
Ps. I think it's very cool that you attempt this work, and also
honorable (though i hate that word) that you follow up on it and
organize peoples opinions into a wiki-page. Maillists are such a
terrible structured kind of "documentation".
On Wed, Aug 13, 2008 at 12:52 AM, Steffen Juul stffn@dibidut.dk wrote:
On 13/08/2008, at 9.27, Luke Iannini wrote:
I think we should adopt "-" for spaces, since it's the most prevalent style I've encountered.
I personal don't care if it's dash or underscore or camelCase.
And, I think whatever we decide on as the hierarchical separator should be used to separate $0, $1 etc from the name itself. When creating a hierarchy in a send/receive, one usually gloms together keys from parent abstractions, e.g. start with /bigsynth, then inside pass $1/filter to a child abstraction, then inside that use $1/cutoff to get /bigsynth/filter/cutoff. I see $0 as no different; it means (or, is used to mean) "this-instance"/cutoff, and thus should be separated accordingly.
I agree.
And, I have a slight leaning towards "." over "/" as the send/receive hierarchical separator since it provides a distinction from OSC addresses and namespaces.
I would be cool if you/someone could cook up some use case examples of this to makes things more clear in a practical way and less theoretical/bikeshedcolor-like. I think Frank suggested similar earlier on.
This is a good suggestion, as actually putting this into practice revealed at least one issue, which is when using a set of nested abstractions that you also want to use with OSC, as in Memento and my in-progress OSC-enabled SSSAD.
I still like the idea of having a "Pd-style" for hierarchies to distinguish them from OSC, as I personally think it's a bit confusing to, e.g., have a [routeOSC /synth/filter/resonance] and an [r /synth/filter/resonance] in the same patch.
I'm going to work with the idea in practice for a while so I can try to figure out a solution to this... I made a special [routeOSC] that can accept a "Pd-style hierarchy" and convert it to an OSC address as a first stab, but maybe that ends up causing just as much confusion?
So, this is another reason to have some other people's perspectives on all this, as I'm not sure how much "convenience when using OSC" should factor into a Pd style.
I am interested in deciding this issue first as I think, as Enrique said, there is no real precedent in place, and, because this is the most critical component for having patches talk to each other. That's why I'd like to define a syntax that has enough flexibility to cover most cases (e.g. NetPd/PdMTL/s-abstractions/DIYlib and so on). That way, patch collections could speak to one another without worrying.about whoUses which-syntax for_which_abstractions.
Best Luke
Ps. I think it's very cool that you attempt this work, and also honorable (though i hate that word) that you follow up on it and organize peoples opinions into a wiki-page. Maillists are such a terrible structured kind of "documentation".
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list