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