Hi *,
AFAIK, there is no standard yet how MIDI is mapped within OSC. But does anybody know if there are already some suggestions that I could use for my OSC2MIDI bridge? Or does everybody make his own suggestions?
TIA, Holger
Osc has little or no standardisation and it seems to be roll your own. I’ve head people express frustration because one user will use 100 as full vol for instance whilst others use 255 or 65535.
We probably would benefit from defining our own but it becomes a standards plus one problem
Thanks @riban. Seems to be used by TouchOSC if you add the MIDI message flag.
But for the OSC tree everyone seems to make its own implementation. My idea is the following:
/midi/cc/<channel#>/<cc#>
/midi/noteon/<channel#>/<note#>
/midi/noteoff/<channel#>/<note#>
/midi/sysex/<channel#>/<var#>
This is easy to parse and enough for my simple TouchOSC bridge.
Regards, Holger
@C0d3man, what exactly are you trying to do? Is this a standalone box with OSC via WiFi and physical MIDI connections? Is it to interface other (non-Zynthian) devices?
If it is to control Zynthian, what elements do you want to control? Many are already exposed via MIDI and OSC.
Regarding OSC paths, this will always be wrong even when it is right 
. You may wish to start with message type or with channel, etc. The OSC client will have to handle these paths appropriately. Depending on the message or use case, one path syntax may be better than another… I would probably divide the messages as the MIDI standard does, i.e. Channel voice messages, Channel mode messages, System common messages, System Real-Time Messages. (I haven’t given it much thought though.)
The main challenge I have found with OSC is it’s asynchronous nature. It is common to use unidirectional UDP as the transport. There isn’t an established / consistent method of registering for feedback, e.g. a remote control device can send OSC to a target it has configured but that target device does not know where or when to send values so the remote control device does not know the current values of the target device (which may change due to local changes, e.g. selecting new preset). It is an unreasonable overhead to have to configure the target to know about each remote device. The target could infer the remote device from initial OSC connection but it does not know what values to send or if the remote device persists (is still turned on). We can use a registration mechanism, i.e. remote device sends an OSC message requesting specific values - this adds to the complexity of remote clients and is not likely to be implemented in any off-the-shelf software. Availability of remote devices could be checked with a heartbeat mechanism - again a bespoke implementation. I feel both of these mechanisms should be implemented and should be detailed in OSC protocol to allow interpretability.
For Zynthian I think we should implement a consistent OSC interface for all access with registration and heartbeat mechanisms. We should publish the OSC implementation allowing third party software provides to interface fully. We should (find a community member to) provide control apps for popular platforms, e.g. Android. Such apps may include plugins e.g. VST plugin to allow control of Zynthian from DAWs.
Can’t you use Zynthian as a TouchOSC bridge?
Can we make make an lv2 zynthian? 
or could we make such an entity a zynthian controller?
We could then do zynthians all the way down We would not need to design the gui, it’s already done and it wouldn’t half refine the OSC comms channel(s) . . .
Exactly: I want to use TouchOSC (or other OSC software) via WiFi to send MIDI data. So I can control parameters of my Zynthian (or other) synths. Now I have all parts together to build such a bridge:
- Simple MIDI-I/O to TTL interface (easy to build by yourself, but it was faster to buy a module)
- ESP8266 as AP/WiFi client and gateway
- 5V->3.3V step-down converter for powering via USB
Yes and no. For example, I would like to control the ZynMixer (or without ZynMixer the levels of the individual synths). If the ZynMixer might not get the “mixer design” later on, I could build my own using TouchOSC. Also I can directly reach every CC# via TouchOSC. Perhaps I can also achieve to send SYSEX, so a Dexed-Editor via TouchOSC may be possible.
Yes - I now have read much about different approaches for setting those pathes. I think I have to build the paths in a way that suits my application best - the same way others do it. Unfortunately it is not that easy with the compatibility, but that is the way it is.
Right, that’s a big problem. Another point where I can only think about my application for the time being and I will implement the following (as said before: The goal is to control synths via TouchOSC - even several TouchOSCs) via MIDI)
The brigde must remember the IP addresses of its clients and broadcast changed values (both OSC and MIDI) to all clients. So changes on one TouchOSC-client will be shown on the synth as well as on other TouchOSC clients. When changing the synth parameter (and the change on the synth is send via CC#) also all TouchOSC clients should get this information.
But the main way is TouchOSC->MIDI.
That would be very cool - and much work. Perhaps I will learn something more when finisheing my “small” brindge project.
Perhaps. But how should I build a simple 16-MIDI-Channel-Volume Mixer with only four encoders?
I need a flexible way to control parameters of (MIDI-)Synths from a controller. For this I find the solution to connect TouchOSC via a bridge to MIDI both cost effective and very flexible (regarding the arrangement of the controllers). But I have just finished a prototype. Let’s see how far I can get and what of it can be taken over in Zynthian - or what has to be built into the bridge to make it work well together later on.
Regards, Holger
… and here is a first simple test:
A newer one…
… and here is a first simple test:
A newer one…
Currently there are some bugs I have to fix. After fixing, sysex support for programming synths (MicroDexed) will be added and perhaps also some CC-LFOs…
You don’t need to use all of the internal logic and make your own programmer/controller/mixer. I am using TouchOSC but you can use every OSC software.
Pathes are like this:
/midi/cc/<channel#>/<cc#>/<value>
/midi/cc/<channel#>/<cc1#>/<value1>/<cc2#>/<value2> // for X/Y controller
/midi/mute/<channel#>
/midi/solo/<channel#>
/ping
… and later
/midi/note/<channel#>/<velocity>/<value>
/midi/sysex/<param#>/<value>
Regards, Holger
2 Likes