[PD] [Style Guide] 1. Separators in Send/Receive/Value names

[Luke Iannini]

On Wed, Aug 13, 2008 at 12:52 AM, Steffen Juul <stffn at 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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>