OSCQueryProposal
OSCQueryProposal copied to clipboard
Vidvox
Listen to ALL server value updates
Hey, thanks for this reference ! I guess a common case would be to just want to listen to any value change from the server, not only from external OSC control (as stated here https://github.com/Vidvox/OSCQueryProposal#optional-bi-directional-communication ), but also from internal modification those values (autonomous behaviours and whatnot). I didn't see anything mentioning this possibility, only the LISTEN method but that only support listening to a particular path, and not sure the good way to send one message for ALL parameters :)
Thank you !
Hi!
I too currently depend on LISTEN to subscribe to updates on the Server's state.
I'm not sure a method to listen to ALL would be useful with real-world large media software. In my current use-case, I want to record all the received messages, and then allow editing these and playing them back.
However, many messages are such that the software might be transmitting them, but would react badly if it received the same stream back verbatim. Resolume's "current time in clip" comes to mind for example (albeit Resolume doesn't use OSC Query). When I record and play back streams from Resolume, it really doesn't like getting that value back the way it had sent it.
So what I in this case need is the subset of messages that a server not only can transmit, but also would want to receive back just the way it sent them out. I guess that would mean the set of all messages with ACCESS that is both GET and SET, for example.
While I'm a bit uncomfortable creating potentially thousands of callbacks (if using libossia...) to listen to every single parameter with LISTEN, some way of specifying a subset is still needed, and if I have to iterate over all parameters anyway to see which I do and do not want, I think LISTEN is fit for purpose.
Best, Ilias B. (www.thewizardofosc.com)
At least in terms of "user API", maybe it could be possible to enable support for OSC 1.1 wildcard pattern over LISTEN queries as a possible extension ? This will save the need for sending 2000000 LISTEN messages if one just wants to listen to a whole tree or subtree - e.g. if I'm not mistaken, //is a magic address that matches every OSC node recursively.
OSC wildcards are extremely powerful indeed.
I rarely see them used, and am yet to support them, I really should.
I think what you propose is a great solution, a straight forward API, very powerful, concise and consistent with the standard!
That seems the best outcome for this issue indeed simplicity and coherence together :)
if I'm not mistaken, //is a magic address that matches every OSC node recursively.
I guess that would be //* isn’t it ?
```//```` is just doing path-traversal and still needs an address after, IIRC
Hello, any update on that ? I'm implementing LISTEN on Chataigne's side and it would be super good to have a listen at least for a hierarchy (like /myGroup/* )