[PD-dev] Some OSC suggestions

[Roman Haefeli]

Hi Martin

I've been working with the mrpeach/osc objectclasses lately and had some
ideas that possibly would help to improve the usability of those (not to
mention that they are already very useful now!).


* Settable [routeOSC]
---------------------
Since Pd version 0.43 the [route] objectclass allows to override its
argument. This would be very practical for [routeOSC] as well. 


* A way to retrieve a single field of the OSC address
-----------------------------------------------------
Often it could be useful to extract the name of a certain field of the
OSC address name space. In cases where the number of possible values is
changed dynamically, it could be important to be able to extract the
field name instead of routing the message by that field name.
This is currently not possible by using mrpeach/osc classes only, though
it could be done by using [zexy/symbol2list /], for instance. However,
it'd be nice to have that in the library. 
Don't know if that is a good idea, but I imagine this could be done with
[routeOSC] by adding a middle outlet, that outputs the field name that
was matched for.

Example:

  [/one/two 3( 
  |
  [routeOSC /o*]

  * left outlet would give: '/two 3' 
  * middle outlet would give 'one'


* Allow to match more than one address field at once
----------------------------------------------------
It's a common patching idiom to use a global send/receive pair across
many levels of abstractions and heavily exploit [route] to gather the
messages interesting for a certain part of the patch.

By using OSC this idea could even be refined by using addresses with the
same depth as the abstraction nesting depth.
 
Let's consider the following structure of a typical abstraction
hierarchy:

[somesynth /somesynth]        listens on /somesynth
  |
  +-[voice $1/voice1]         listens on /somesynth/voice1
     |
     +-[oscil $1/freq1]       listens on /somesynth/voice1/freq1

Let's assume  that in each of those levels we find something like:

[r COM] <- global receive
|
[routeOSC $1]

In [somesynth] the [routeOSC $1] would receive all messages
to /somesynth, which is what we actually want. In the [voice]
abstraction, however, the $1 would resolve to '/somesynth/voice1'.
Unfortunately, the [routeOSC /somesynth/voice1] does not receive any
messages sent to '/somesynth/voice1', since only one field of the
address space is matched. 

Allowing [routeOSC] to match many fields at once would make it easy to
insert abstractions at any nesting level without the need to know
beforehand at which nesting level we currently are. One could simply
create a [partial $1/part2] into [oscil] and the [routeOSC $1] therein
would automatically listen on '/somesynth/voice1/freq1/part2'.


What do you think?

Cheers
Roman