routeOSC: how to distinguish messages addressed to a node from messages addressed to any descendant
Hi,
Suppose that in an OSC tree I have a node called "foo" (child of the / root node) which has a few child nodes.
So I place a [routeOSC /foo] object to get all messages that are addressed to /foo or to its child nodes.
This will catch all of the following messages:
/foo 123 /foo/bar 123 /foo/etc 123
Now, how can I discriminate messages like the first one from messages like the others? I.e., messages directed to the /foo node and not to any descendant?
I don't think I can accomplish this with [routeOSC], or can I?
Indeed I think that [routeOSC /] should match any message that doesn't start with an address, or alternatively, matching messages output by the first outlet of a [routeOSC /something] should start with "/ " if the pattern address matches the whole input address. However I understand this would break existing patches.
Or is there another way to discriminate the above?
Thanks m.
On 2011-05-21 13:58, Matteo Sisti Sette wrote:
Hi,
Suppose that in an OSC tree I have a node called "foo" (child of the / root node) which has a few child nodes.
So I place a [routeOSC /foo] object to get all messages that are addressed to /foo or to its child nodes.
This will catch all of the following messages:
/foo 123 /foo/bar 123 /foo/etc 123
Now, how can I discriminate messages like the first one from messages like the others? I.e., messages directed to the /foo node and not to any descendant?
I don't think I can accomplish this with [routeOSC], or can I?
Try [routeOSC /foo] | [routeOSC /*]
Martin
On 05/21/2011 08:46 PM, Martin Peach wrote:
Try [routeOSC /foo] | [routeOSC /*]
Hi,
I didn't know about the wildcard.
However, this still can't handle messages other than mere floats addressed to /foo.
For example:
/foo 1 2 3
You get only "1" out of the right outlet of your second routeOSC.
Also, messages like this:
/foo somesymbol 1 2 3
(which btw are valid osc messages, or aren't they? this is dubt, not sarchasm)
although they produce the desired output ("somesymbol 1 2 3") from the right outlet of your second routeOSC, will cause an error to be printed to the console:
error: * routeOSC: invalid message pattern somesymbol does not begin with /
what about [routeOSC /foo/* /foo] ?
Le 21/05/2011 21:40, Matteo Sisti Sette a écrit :
On 05/21/2011 08:46 PM, Martin Peach wrote:
Try [routeOSC /foo] | [routeOSC /*]
Hi,
I didn't know about the wildcard.
However, this still can't handle messages other than mere floats addressed to /foo.
For example:
/foo 1 2 3
You get only "1" out of the right outlet of your second routeOSC.
Also, messages like this:
/foo somesymbol 1 2 3
(which btw are valid osc messages, or aren't they? this is dubt, not sarchasm)
although they produce the desired output ("somesymbol 1 2 3") from the right outlet of your second routeOSC, will cause an error to be printed to the console:
error: * routeOSC: invalid message pattern somesymbol does not begin with /
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/21/2011 10:39 PM, cyrille henry wrote:
what about [routeOSC /foo/* /foo] ?
That won't work. RouteOSC only matches "one level at a time", meaning that [routeOSC /foo/bar] will never match anything (indeed it should issue a warning at creation time). That applies also to /foo/*, I've just tried it.
Even if it worked, you wouldn't be able to distinguish /foo/bar from /foo/etc after that, because routeOSC strips the address that matches * (just as it strips the address that matches anything).
I don't see any way out of this, until [routeOSC] will consider a message without an address as equivalent to a message addressed to "/".
That would be consistent with the convention that "/" means "the root". Any node is the root of its own subtree, so any message addressed to /foo is addressed to the root of the /foo subtree. After "routing" a message addressed to /foo through [routeOSC /foo] you obtain a message that is addressed to the root (of the current subtree), so it should be considered equivalent to a messaged addressed to / by any cascaded [routeOSC]. In my opinion.
On 05/22/2011 12:10 AM, Matteo Sisti Sette wrote:
I don't see any way out of this, until [routeOSC] will consider a message without an address as equivalent to a message addressed to "/".
Well yes there is a simple though not elegant solution, without a second routeOSC; see attached patch. It is probably incomplete, as I'm not discriminating between lists and other messages but I think routeOSC doesn't either.
By the way is there a particular reason why mrpeach's externals are not added to the objectclass path in Pd Extended while most other externals are?
Thanks m.
On 2011-05-21 18:10, Matteo Sisti Sette wrote:
On 05/21/2011 10:39 PM, cyrille henry wrote:
what about [routeOSC /foo/* /foo] ?
That won't work. RouteOSC only matches "one level at a time", meaning that [routeOSC /foo/bar] will never match anything (indeed it should issue a warning at creation time). That applies also to /foo/*, I've just tried it.
The latest version of [routeOSC] matches multiple levels, but the wildcard seems to be broken for multiple levels.
Even if it worked, you wouldn't be able to distinguish /foo/bar from /foo/etc after that, because routeOSC strips the address that matches * (just as it strips the address that matches anything).
You can do [routeOSC /foo /foo/bar /foo/etc] if you can stand getting multiple output.
I don't see any way out of this, until [routeOSC] will consider a message without an address as equivalent to a message addressed to "/".
Yes I think that makes sense. But I think [routeOSC] should simply prefix an outgoing message with '/' if there is no more path.
Martin
On 05/22/2011 12:44 AM, Martin Peach wrote:
until [routeOSC] will consider a message without an address as equivalent to a message addressed to "/".
Yes I think that makes sense. But I think [routeOSC] should simply prefix an outgoing message with '/' if there is no more path.
I agree that would be a more consistent solution, but I think it would break more existing patches. Indeed it would break almost _any_ existing patch using routeOSC, while having non-addressed messages match "/" would break only those patches which rely on [routeOSC] to discard such messages through the right outlet, which should not be a common practice, considering that most message are not handled properly by touchOSC used that way (only floats are; lists of floats are truncated after the first element and any other message issues an error).
On 2011-05-21 19:21, Matteo Sisti Sette wrote:
On 05/22/2011 12:44 AM, Martin Peach wrote:
until [routeOSC] will consider a message without an address as equivalent to a message addressed to "/".
Yes I think that makes sense. But I think [routeOSC] should simply prefix an outgoing message with '/' if there is no more path.
I agree that would be a more consistent solution, but I think it would break more existing patches.
Yes after thinking about it a few more minutes I agree...
Indeed it would break almost _any_ existing patch using routeOSC, while having non-addressed messages match "/" would break only those patches which rely on [routeOSC] to discard such messages through the right outlet, which should not be a common practice, considering that most message are not handled properly by touchOSC used that way (only floats are; lists of floats are truncated after the first element and any other message issues an error).
Lists arriving at a [routeOSC] are currently handled depending on the first element. If the first element is a float then only that float gets output (a bug!). If it's a symbol then the symbol is taken to be the OSC path, which causes an error message if it doesn't start with '/'.
So I propose to change it so that any input that doesn't start with a symbol that begins with '/' will have its path silently set to '/' by [routeOSC]. This will also mean that any unmatched message with no path leaving the rightmost outlet will have '/' set as its path.
The only snag I foresee is if the first element of an incoming OSC is a string beginning with the character '/'. In that case it will be mistaken for a path.
And also the wildcard code needs fixing up... Thanks for pointing out these issues.
Martin
-
cyrille henry -
Martin Peach -
Matteo Sisti Sette