Hi !
New topic from an idea discussed in the SooperLooper/ Pedal thread.
What OSC messages are used in interne like for SooperLooper ? And why for these innovations engines specifically? (For SooperLooper I guess it is to avoid the GUI, but then why avoid the GUI ?)
We can use osc messages to trigger CUIA commands.
Is it possible to have and osc router ? To have “things” that talk to Zynthian with port 1370 and then translate (or follow) theses messages to other ports ?
Please note that as I have not a single clue on how to program or understand coding, theses questions are pure questions. Is it easy or hard to do is an other question, and I think it’s an interesting one but well, I guess you have already a super high to-do-list
Sooperlooper runs as a headless service to which it’s GUI connects using OSC commands. There is no advantage nor any practicable way to programmatically drive the native SL GUI. Zynthian starts an instance of SL then drives it with OSC commands, hence zynthian becomes the UI for SL. SL can accept multiple client connections so you can run up an instance of sl-gui to control it in parallel to zynthian’s control and most (all?) commands should tally in the other UI, e.g. start recording in zynthian and the native GUI shows recording, and vice versa.
There are other engines that are similarly controlled and monitored using OSC, e.g. ZynAddSubFx. This is just the internal mechanism used to control and monitor each engine. Other engines used different mechanisms such as CLI, etc. zynthian kind of abstracts the low level interface to give the higher level UI a consistent interface.
There is a mechanism in the zynthian to bind (learn) OSC commands to actions although I think that might be deprecated or broken. I fully think anyone has liked at it for many years.
CUIA is a kind of API to the zynthian UI. We plan to build a more robust and full API to the backend. I expect CUIA to split to maintain the UI API and provide the backend API… but there is work to be done there. It has been a topic for several years (search this forum) and one that I am very enthusiastic to complete. Indeed, Oram brings many (but not all) changes to facilitate this.
I don’t think we need OSC routing. Any process can make an OSC connection to an engine to control and monitor it. A process can make multiple OSC connections, allowing simultaneous control & monitoring of zynthian CUIA and direct connection to engines.
I would encourage developers to avoid direct OSC connections and instead to use CUIA, reporting and limitations. I s it suspect many such limitations will best be resolved in the future API.
We try to implement as many features of each engine as we can (or feels appropriate). SL is very flexible and there are some features that I have purposely not implemented because they don’t serve any workflow that I envisage. The idea is to make SL work within zynthian as a fully featured and flexible looper but not necessarily provide every feature available, e.g. we artificially limit to 6 tracks because that seems enough for most users and it simplifies the UI.
Direct connection should be possible. You should be able to make an OSC connection from another client directly to SL. This can be proved by running slgui -H zynthian_ip on a remote machine with sooperlooper installed. It will only run the GUI on the remote machine and connect to SL running on zynthian (assuming you have it in a chain on zynthian).
