RPC tends to be slow. It does depend on implementation but where we have seen this implemented, e.g. recent changes to Pianoteq have often used a slow (e.g. 50ms) processing loop which can add significant latency to messages and actions. It is a matter of choosing the right protocol based on requirements. I have done a lot of control and monitoring programming and development of various systems. There is often conflicting requirements: you want low latency control and monitoring, sometimes to a large quantity of clients (not necessarily an issue here) with high reliability with handling of delayed and out-of-order messages, e.g. you may not want to set a value if the message arrives seconds later! The reliability comes from some form of handshaking which adds to the complexity of messaging, especially in a large, distributed system. As I say, that is less of an issue with Zynthian and similar systems. OSC is a high-level protocol that may be carried on any suitable (or unsuitable) transport layer. The only transport I have seen
used is UDP/IP unicast. This works well to deliver messages promptly to a small quantity of clients but does not have handshaking. I have heard this coined as send and pray. There are other delivery protocols that provide reliable delivery, e.g. TCP/IP which has a massive overhead and undefined latency. There is a protocol that provides some of the TCP reliability over UDP with guaranteed reliability and latency figures that I was looking at for another project. (I can’t recall just now but might be DCM.) Anyway - the low-level transport is a consideration that is kinda separate from the high-level protocol. I quite like OSC because it is targeted at our use-case (control and monitoring of audio devices), is simple and extensible, has open source libraries and is already in use in Zynthian. It has relatively low latency and on a small, closed network is quite reliable. (Most/all unicast packets will reach their destination if the transport remains intact. Wifi may disappear randomly but the OS generally buffers messages during temporary loss of connection.)
Check out this post for discussion on API (high-level stuff). I am currently mostly concerned with shaping the core architecture to allow such a high-level API to access core elements. I defer decision on low-level transport until later but for now (for test and current stable operation) use OSC over unicast UDP/IP. It is working well enough and that is what we want. (No need to over engineer a solution. Pragmatism is king. Let’s deliver something that works rather than not deliver something that works too well!!!)
We use tinyOSC which is a cool and simple implementation of OSC over UDP/IP. We could send tallies (feedback) via broadcasts or multicasts but there are issues there which I am happy to describe, but not now… other things to do!