I’m expecting OSC messages (or bundles) with a path like /FREQ/ and then a number. Example would be something like /FREQ/1. According to the documentation of SuperCollider and OSC, I should be able to match such a path like this: /FREQ/*. This doesn’t seem to be working. I can confirm that the messages are being received using OSCFunc.trace(true);. Where am I going wrong?
o = OSCFunc.newMatching({
arg msg;
msg.postln;
},"FREQ/*", recvPort: 5005);
Unfortunately it’s the other way around: you can send /FREQ/* and it will match responders that you’ve registered for /FREQ/1, /FREQ/2, etc.
We’ve taken this question to the OSC designers and they disagree with the use case you’re asking for.
So I’m sorry to report that the ways to do it are:
Create a different OSCFunc for every incoming string.
Or, use http://doc.sccode.org/Classes/Main.html#-addOSCRecvFunc and parse the incoming command string.
FWIW I would be happy to see wildcard matching working the way you specify, but we can’t do that without breaking the OSC spec.
hjh
Thanks for the explanation. Perhaps I’m treating my OSC paths a but too much like REST endpoints… I’ll look into addOSCRecvFunc, it looks useful for this situation. Cheers!
James McCartney substantially disagreed with the OSC design. SC implements OSC in quite an idiosyncratic fashion, with flattened spaces, and quite a few other details covered in that presentation, e.g. no nested bundles. Basically turns it from a path-based protocol (itself openly inspired from XPath in that regard) to a more traditional RPC of the verb + argument-list kind, at lest in the typical SC client-sever exchanges. To steal the most relevant slide:
As a result, the SC OSC client library is a bit of a strange beast, with some minimal path matching still done, but also with argument matching templates that sort-of imitate the XPath at argument level.