On Sat, 8 Sep 2018, David Runge wrote:
On 2018-09-05 14:40:19 (+0200), Daniel Swärd wrote:
- Start defining a standard for communicating midi messages via OSC.
Hmmmmmm, aren't there some projects doing this already (somehow)? Has
someone gathered background info on that?
OSC really needs a governing body. The OSC home page is pretty much a
mess. The OSC 1.1 spec was not only not finalized but is now "Page not
found". There is (was?) at least a proposal for midi over osc however all
the links on
http://opensoundcontrol.org/wrapping-other-protocols-inside-osc are dead.
There are applications/utilities that do midi/osc conversions which means
there is at least one (probably more) protocol out there. However,
creating a standard is not useful in the slightest if there is no
governing body to give an approval stamp.
These two projects use the same syntax:
https://github.com/jstutters/MidiOSC
https://github.com/rrbone/midioscar
Also look at things like:
https://github.com/fabb/SynOSCopy/wiki
Which is an OSC only synth protocol (not a standard really). It should
really be a super set of what midi is. That is, it contains the
information that midi does but also more and with greater accuracy. Being
able to convert from here to midi and back may make sense... with some
exceptions. The exceptions are all applications that use midi for things
it is not designed for... like controling mixers for example where a note
on is used as mute and several channels of pitch are used as faders. Such
cases would be better off with /midi/event_type/channel params style of
things so the events are exact in and out.
Should a governing body get set up and OSC move forward, I would like to
see that bundles are handled by the osc libs out there... that is bundle
arrives, lib presents bundle's messages to application as single messages
all with the same time stamp unless the application tells it not to. Why?
because in most cases, even if the lib has methods for dealing with
bundles, the application developer ignores them and udp is easy to over
run with lots of small packets. I would note that many application
developers only allow one parameter per message as well. Those that do
allow more than one parameter expect all parameters to apply to one knob
or switch (or note).
OSC's greatest plus is that it is incredibly flexible... this seems to be
it's greatest downfall as well. OSC 1.0 is all there is, until someone is
willing to take over the website and goverance, OSC is stuck there and can
not move on.
I am sorry, but I will not be able to attend... unless someone sends me
plane tickets :)
I would be willing to help with a govering body if there are others so
inclined.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
