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