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