-
Notifications
You must be signed in to change notification settings - Fork 52
SSR IP OSC interface
[UPDATE (2021): There is still no OSC interface (but there is an unfinished PR: #122). However, two additional protocols have been added: WebSocket and FUDI, see https://ssr.readthedocs.io/en/latest/network.html]
There are good reasons to include an OSC interface into the SSR. One is for example to be able to exchange existing ISONO renderer in cave environments with the SSR. Those renderer are informed by OSC commands about changes in source positions and so on. At the moment the SSR can process instructions using XML commands, which are send over a network interface. Have a look at the network interface documentation for details on the instructions that can be send.
The easiest solution is most probably a standalone program, converting OSC <-> XML. Here, one of the following might work:
- There exist a SSR client for puredata, written in Lua. There it might be easy to just add the OSC-part.
- It could be implemented in python by writing two classes for OSC and XML, which are then connected by a app. The following python modules might be helpful to realize this for the network part and the OSC part.
The best solution in the long term might be to expand the SSR network interface, this could include:
- Support different protocols like XML, OSC, WebSockets.
- Allow parallel usage of different protocols.
- Add a subscribe mechanism for clients to allow for the selection of the data that should be sent to them.
- Combine the expansion of the network protocol with 3D support to avoid additional work later on.
There was a start on this general solution with the goal to support XML and WebSocket at https://github.com/SoundScapeRenderer/SSR-Network, but it was not finished.
Publish/subscribe system (including 3D support) was implemented in https://github.com/SoundScapeRenderer/ssr/pull/127
- With the current network interface it can happen that the SSR is not able to perform changes as expected, if the commands are send in very short time intervals. This could be solved by the subscription mechanism explained above or by adding a rate limitation.