# MCU/Mackie Control Support for Zynthian

**URL:** <https://discourse.zynthian.org/t/mcu-mackie-control-support-for-zynthian/7569>\
**Category:** Development\
**Tags:** diy-midi-control\
**Created:** [December 19, 2022, 5:08pm UTC](https://discourse.zynthian.org/t/mcu-mackie-control-support-for-zynthian/7569 "2022-12-19T17:08:41Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**Author:** ![riban](https://discourse.zynthian.org/user_avatar/discourse.zynthian.org/riban/32/2331_2.png) [@riban](https://discourse.zynthian.org/u/riban)\
**Post date:** [January 4, 2023, 11:29pm UTC](https://discourse.zynthian.org/t/mcu-mackie-control-support-for-zynthian/7569/7 "2023-01-04T23:29:33Z")

</div>

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](https://discourse.zynthian.org/t/api-proposal/6481) 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](https://github.com/mhroth/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!

---

_[View the full topic](https://discourse.zynthian.org/t/mcu-mackie-control-support-for-zynthian/7569)._