[OSC_dev] [PD] MIDI and opensoundcontrol: type m for OSC ?

[IOhannes m zmoelnig]

on the Pd-list a question about MIDI-over-OSC was raised, which i would

Is anybody aware of any other (relevant) soft- or hardware which uses the type
'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

gfsd dr
IOhannes

[Winfried Ritsch]

Hello,

[...]

Is anybody aware of any other (relevant) soft- or hardware which uses the
type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]

MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.

Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
protocol not with a type 'm' in REST-style (even MIDI is stateful):

"/midi" ",iii" status data1 data2

or shorter 12 bytes instead of 28 bytes:

"/m" ",i" (status<<16 + data1<<8 + data2)

and for sysex to be complete:
"/midi/sysex" ",b" [n*data]
short:
"/ms" ",b" [n*data]


The goal is to implement this for Pd and Escher micro-controller, to play my
robotic piano player Rhea_ using OSC.

( see http://algo.mur.at/projects/autoklavierspieler )

Addendum:

a) Why MIDI is better than OSC is stated here ?-)

https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc

b) There is on midi.org a lot of specifications and recommendations for a
various set of transport of MIDI data:

Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI

but none for OSC, we should propose something like this to MIDI association.

mfG
Winfried

[Angelo Fraietta]

OSC is a protocol, however, it does not encompass the bottom layers of OSI
model. Have a read of NIME paper below for detailed description

http://www.nime.org/proceedings/2008/nime2008_019.pdf

Post by Winfried Ritsch
Hello,
[...]

Is anybody aware of any other (relevant) soft- or hardware which uses

the

type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]
MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.
Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
"/midi" ",iii" status data1 data2
"/m" ",i" (status<<16 + data1<<8 + data2)
"/midi/sysex" ",b" [n*data]
"/ms" ",b" [n*data]
The goal is to implement this for Pd and Escher micro-controller, to play my
robotic piano player Rhea_ using OSC.
( see http://algo.mur.at/projects/autoklavierspieler )
a) Why MIDI is better than OSC is stated here ?-)
https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
b) There is on midi.org a lot of specifications and recommendations for a
Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI
but none for OSC, we should propose something like this to MIDI association.
mfG
Winfried
--
---
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing.
Institut 17 Elektronische Musik und Akustik
8010 Graz, Inffeldgasse 10/III
Homepage http://iem.at/ritsch
Mobil ++436642439369
---
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Winfried Ritsch]

Post by Angelo Fraietta
OSC is a protocol, however, it does not encompass the bottom layers of OSI
model. Have a read of NIME paper below for detailed description
http://www.nime.org/proceedings/2008/nime2008_019.pdf

Sorry,

I did not want to offense OSC not being a protocol, but "media format". I
read "Best pratice OSC..." [1] from the originators of OSC and in 1.1:

"Open Sound Control (OSC) is a digital media
content format for streams of real-time audio
control messages"

[1] http://opensoundcontrol.org/files/osc-best-practices-final.pdf

So I thought it is a format no protocol, more exact no "communication
protocol", since this should have a syntax and semantic and others, but it
seems there is a need to define semantics for special usages as protocols with
the OSC syntax, see TUIO protocol [2].

[2] http://www.tuio.org/

Anyway, protocol or media format, i did not find a OSC-midi protocol so far.

mfg
winfried

Post by Angelo Fraietta

Post by Winfried Ritsch
Hello,
[...]

Is anybody aware of any other (relevant) soft- or hardware which uses

the

type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]
MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.
Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
"/midi" ",iii" status data1 data2
"/m" ",i" (status<<16 + data1<<8 + data2)
"/midi/sysex" ",b" [n*data]
"/ms" ",b" [n*data]
The goal is to implement this for Pd and Escher micro-controller, to play my
robotic piano player Rhea_ using OSC.
( see http://algo.mur.at/projects/autoklavierspieler )
a) Why MIDI is better than OSC is stated here ?-)
https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
b) There is on midi.org a lot of specifications and recommendations for a
Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI
but none for OSC, we should propose something like this to MIDI association.
mfG
Winfried
--
---
Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing.
Institut 17 Elektronische Musik und Akustik
8010 Graz, Inffeldgasse 10/III
Homepage http://iem.at/ritsch
Mobil ++436642439369
---
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Hanspeter Portner]

Post by Winfried Ritsch
Hello,
[...]

Is anybody aware of any other (relevant) soft- or hardware which uses the
type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]
MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.
Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
"/midi" ",iii" status data1 data2
"/m" ",i" (status<<16 + data1<<8 + data2)
"/midi/sysex" ",b" [n*data]
"/ms" ",b" [n*data]
The goal is to implement this for Pd and Escher micro-controller, to play my
robotic piano player Rhea_ using OSC.
( see http://algo.mur.at/projects/autoklavierspieler )
a) Why MIDI is better than OSC is stated here ?-)
https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
b) There is on midi.org a lot of specifications and recommendations for a
Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI
but none for OSC, we should propose something like this to MIDI association.
mfG
Winfried

Hi Winfried

renoise uses a similar OSC/MIDI API as you're proposing [1].

I've hit the same wall in the past. The 'm' argument is not widely supported.
The chimaera [2] by default sends TUIO, but can also send raw MIDI via OSC,
either with the 'm' argument or individual bytes packed into an int32 [3].

I had implemented packing midi bytes into an int32 to build OSC-MIDI bridges
in PD [4] and renoise [5], as both PD and renoise did not support the 'm'
argument.

I consider it a hack, though (packing MIDI bytes into an int32). How do you
stuff the MIDI bytes into the int32, most/least significant byte first?
Do you add any padding? What about 2-byte messages? There are numerous ways
to pack 2-3 bytes into an int32, so it's quite ambiguous and thus prone to
implementation errors.

I dislike the 'm' argument likewise, as it can only hold 3-byte messages
at max (e.g. no sysex possible). It also does not hold any information about
the message size (e.g. there are 2-byte MIDI messages), which forces
implementers to discover that for themeselves even if they may only want
to route it to a responder.

It would be much more straight-forward to simply pack normalized MIDI
(e.g. no running status) into the 'b' argument for all MIDI message types,
not only for sysex.

/midi ,b (normalized MIDI)

Seems to be the simplest, most portable and most unambigous way to
transport MIDI via OSC without custom argument types and with support
for arbitrary message lengths, IMHO.

/bye ,s hanspeter

[1] http://tutorials.renoise.com/wiki/Open_Sound_Control#The_Default_OSC_Implementation_of_Renoise
[2] https://open-music-kontrollers.ch/chimaera
[3] https://open-music-kontrollers.ch/chimaera/usage#oscmidi
[4] https://github.com/OpenMusicKontrollers/chimaera_pd
[5] https://open-music-kontrollers.ch/patchaweek/2014_36/

[Winfried Ritsch]

Thank you very much for this report, it is really interesting, i agree, type
"m" is not realy convincing, also since simple OSC implementation are allowed
not to handle it [OSC-1.0]:

[...]
"Some OSC applications communicate among instances of themselves with
additional, nonstandard argument types beyond those specified above. OSC
applications are not required to recognize these types; an OSC application
should discard any message whose OSC Type Tag String contains any unrecognized
OSC Type Tags..."
[...]

also not in OSC 1.1 required types, see [OSC-1.1] in 3.5.2


So:

[...]

Post by Hanspeter Portner
/midi ,b (normalized MIDI)

[...]

seems realy a good alternative, maybe
"/m" ,b [n*normalized MIDI]

to be as short as possible (4 bytes less).

Since slow microcontroller can just compare with a 16-bit integer the first
two bytes ad then the zeros and the format as a second match with zeros, to
read mididata afterwards.
Anyhow the bundle and timestamps needs to be handled (ignored or processed).

[OSC-1.0] http://opensoundcontrol.org/spec-1_0

[OSC-1.1] http://opensoundcontrol.org/spec-1_1


mfg
winfried

Post by Hanspeter Portner

Post by Winfried Ritsch
Hello,
[...]

Is anybody aware of any other (relevant) soft- or hardware which uses the
type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]
MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.
Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
"/midi" ",iii" status data1 data2
"/m" ",i" (status<<16 + data1<<8 + data2)
"/midi/sysex" ",b" [n*data]
"/ms" ",b" [n*data]
The goal is to implement this for Pd and Escher micro-controller, to play
my robotic piano player Rhea_ using OSC.
( see http://algo.mur.at/projects/autoklavierspieler )
a) Why MIDI is better than OSC is stated here ?-)
https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
b) There is on midi.org a lot of specifications and recommendations for a
Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI
but none for OSC, we should propose something like this to MIDI association.
mfG
Winfried

Hi Winfried
renoise uses a similar OSC/MIDI API as you're proposing [1].
I've hit the same wall in the past. The 'm' argument is not widely
supported. The chimaera [2] by default sends TUIO, but can also send raw
MIDI via OSC, either with the 'm' argument or individual bytes packed into
an int32 [3].
I had implemented packing midi bytes into an int32 to build OSC-MIDI bridges
in PD [4] and renoise [5], as both PD and renoise did not support the 'm'
argument.
I consider it a hack, though (packing MIDI bytes into an int32). How do you
stuff the MIDI bytes into the int32, most/least significant byte first?
Do you add any padding? What about 2-byte messages? There are numerous ways
to pack 2-3 bytes into an int32, so it's quite ambiguous and thus prone to
implementation errors.
I dislike the 'm' argument likewise, as it can only hold 3-byte messages
at max (e.g. no sysex possible). It also does not hold any information about
the message size (e.g. there are 2-byte MIDI messages), which forces
implementers to discover that for themeselves even if they may only want to
route it to a responder.
It would be much more straight-forward to simply pack normalized MIDI
(e.g. no running status) into the 'b' argument for all MIDI message types,
not only for sysex.
/midi ,b (normalized MIDI)
Seems to be the simplest, most portable and most unambigous way to
transport MIDI via OSC without custom argument types and with support
for arbitrary message lengths, IMHO.
/bye ,s hanspeter
[1]
http://tutorials.renoise.com/wiki/Open_Sound_Control#The_Default_OSC_Implem
entation_of_Renoise [2] https://open-music-kontrollers.ch/chimaera
[3] https://open-music-kontrollers.ch/chimaera/usage#oscmidi
[4] https://github.com/OpenMusicKontrollers/chimaera_pd
[5] https://open-music-kontrollers.ch/patchaweek/2014_36/
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[IOhannes m zmölnig]

Post by Winfried Ritsch
[...]

Post by Hanspeter Portner
/midi ,b (normalized MIDI)

[...]
seems realy a good alternative,

to the contrary.
OSC specs carefully avoid suggesting *any* path for a specific data
type. so why do you think it a good idea to randomly introduce some?
(you are of course free to use whatever path you want for a proprietary
solution; but we are talking about the OSC standard)

Post by Winfried Ritsch
maybe
"/m" ,b [n*normalized MIDI]

which of course is even worse.

Post by Winfried Ritsch
to be as short as possible (4 bytes less).
Since slow microcontroller

i understand the need speed in your specific case, but this can hardly
be the reason why we (the OSC community) should adapt a an arbitrary
one-character path for something that is seldom used (at least this is
what i suspect, judging from the lack of reference applications and
response).

probably OSC is the wrong tool in this case anyhow - have you checked
RTP-MIDI?

gfards
IOhannes

[Thomas Brand]

Post by Winfried Ritsch

Post by Hanspeter Portner
/midi ,b (normalized MIDI)

seems realy a good alternative,

to the contrary. OSC specs carefully avoid suggesting *any* path for a
specific data type. so why do you think it a good idea to randomly
introduce some? (you are of course free to use whatever path you want for
a proprietary solution; but we are talking about the OSC standard)

Post by Winfried Ritsch
maybe "/m" ,b [n*normalized MIDI]

which of course is even worse.

The freedoms that OSC as a data container offers for context specific
syntax and semantics can be challenging.

For MIDI, there is 'm' (which oscsend tells it's 4 bytes). Using that
typetag is using what the standard foresees. However as said it's not
widely used and not part of the previous OSC standards.

The freedom to implement a custom (not using the standard's 'm') way to
transmit MIDI as OSC messages can range from /m, b to /midi/note/on, i.
One way of looking at is is what are the requirements a) sender-wise:
create an 'm' might be too difficult, compared to sending a couple of
ints. b) receiver-wise: parsing a 'b' as a MIDI events could be too
difficult c) performance-wise: using long path and waste bytes with too
long datatypes can, but must not be, an issue.

I personally look at MIDI simply as a bytestream that can be parsed
relatively easy if it's normalized. My preference is thus what Hanspeter
is proposing, i think less as a standard, but more as a direct and
reasonable way how to send (MIDI) byte arrays.
Using the blob datatype allows to send an arbitrary number of MIDI events,
even mixed with sysex. The syntax and semantics of MIDI are then
off-loaded to parts that are well understood and working over many
decades.

For every type of content, characterizing what's inside the generic 'b'
type is easy. All infrastructure to add context and metadata is in place.

Greetings
Thomas

[Brian Willoughby]

In my opinion, it's usually more important to ask "why" before asking "how."

In this case, what would be gained by transferring MIDI over OSC?

MIDI usually flows over its own custom interface, but can also be transferred over USB or Ethernet. OSC does not define any physical interface, so there really is no advantage to putting MIDI on OSC. MIDI can already be transferred directly over any physical interface that could carry OSC, so why add the middle man?

Hopefully these considerations will make their way back to the original Pd thread.

Brian

Post by IOhannes m zmölnig
probably OSC is the wrong tool in this case anyhow - have you checked
RTP-MIDI?
gfards
IOhannes
OSC is a protocol, however, it does not encompass the bottom layers of OSI model. Have a read of NIME paper below for detailed description
http://www.nime.org/proceedings/2008/nime2008_019.pdf

[Angelo Fraietta]

Post by Brian Willoughby
In my opinion, it's usually more important to ask "why" before asking "how."
In this case, what would be gained by transferring MIDI over OSC?
MIDI usually flows over its own custom interface, but can also be
transferred over USB or Ethernet. OSC does not define any physical
interface, so there really is no advantage to putting MIDI on OSC.

A very real advantage of doing this was by making a device driver that
looked like a MIDI device in your Mac / PC / linux and sending it OSC
messages. This means any application would then be able to receive OSC
messages and appear as MIDI without having to support OSC in that app.
There are plenty of music programs that do not support OSC, but would now
be able to without any implementation from the music app.

Post by Brian Willoughby

Post by IOhannes m zmölnig
probably OSC is the wrong tool in this case anyhow - have you checked
RTP-MIDI?
gfards
IOhannes

On Jul 13, 2016, at 2:04 AM, Angelo Fraietta <

Post by IOhannes m zmölnig
OSC is a protocol, however, it does not encompass the bottom layers of

OSI model. Have a read of NIME paper below for detailed description

Post by IOhannes m zmölnig
http://www.nime.org/proceedings/2008/nime2008_019.pdf

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Camille Troillard]

Hi Angelo,

There are plenty of music programs that do not support OSC, but would now be able to without any implementation from the music app.

I believe this claim is valid only if you choose to ignore the vast impedance mismatch existing between OSC and MIDI.

OSC is a message format, and has none of the semantics that MIDI defines. Therefore you are pushing the problem of handling the MIDI logic to the pure OSC apps, i.e. no problem is solved.


All the best,
Cam

[Angelo Fraietta]

Post by Camille Troillard
I believe this claim is valid only if you choose to ignore the vast
impedance mismatch existing between OSC and MIDI.
What does that mean? You will really need to define what you mean by

"impedance" because I don't understand what you mean.

Post by Camille Troillard
OSC is a message format, and has none of the semantics that MIDI defines.

Basically, in both protocols, you are sending an instruction to another
machine. In OSC, you can give an instruction to turn a sound on or off, or
change a controller, or whatever. It is basically the same principle.

Post by Camille Troillard
Therefore you are pushing the problem of handling the MIDI logic to the
pure OSC apps, i.e. no problem is solved.
I proposing that OSC can be used to control MIDI software or devices,

without requiring the MIDI devices to do anything. People can now use their
MIDI gear and control it via OSC and they do not need to modify their
software or hardware. That is a big problem solved.

Post by Camille Troillard
All the best,
Cam
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Camille Troillard]

Post by Camille Troillard
I believe this claim is valid only if you choose to ignore the vast impedance mismatch existing between OSC and MIDI.
What does that mean? You will really need to define what you mean by "impedance" because I don't understand what you mean.

It is a technical metaphor meaning two domains (here MIDI and OSC) have a wrong fit. They appear to be compatible, when in fact they are not. See http://english.stackexchange.com/questions/187873/appropriate-contexts-for-the-phrase-impedance-mismatch <http://english.stackexchange.com/questions/187873/appropriate-contexts-for-the-phrase-impedance-mismatch> if you want more details.

Post by Camille Troillard
OSC is a message format, and has none of the semantics that MIDI defines.
Basically, in both protocols, you are sending an instruction to another machine. In OSC, you can give an instruction to turn a sound on or off, or change a controller, or whatever. It is basically the same principle.

No, OSC does not define anything more than a message format.

MIDI on the other hand has definitions for a Note On message, Note Off message, and plenty of other concept (Control Change, Program Change, etc.).

The MIDI specification defines the protocol down to the wire. OSC has no such recommandation, it is agnostic of any transport layer.

Post by Camille Troillard
Therefore you are pushing the problem of handling the MIDI logic to the pure OSC apps, i.e. no problem is solved.
I proposing that OSC can be used to control MIDI software or devices, without requiring the MIDI devices to do anything. People can now use their MIDI gear and control it via OSC and they do not need to modify their software or hardware. That is a big problem solved.

Angelo, think about it: your OSC programs will have to “speak” MIDI flluently for this to work.
You need to define a common ground for most common functions in OSC. You can’t just pipe MIDI through OSC and pretend it is OSC, when in fact it is still 100% MIDI inside :)


Cam

[Angelo Fraietta]

Post by Camille Troillard
I believe this claim is valid only if you choose to ignore the vast

Post by Camille Troillard
impedance mismatch existing between OSC and MIDI.
What does that mean? You will really need to define what you mean by

"impedance" because I don't understand what you mean.
It is a technical metaphor meaning two domains (here MIDI and OSC) have a
wrong fit. They appear to be compatible, when in fact they are not. See
http://english.stackexchange.com/questions/187873/appropriate-contexts-for-the-phrase-impedance-mismatch if
you want more details.

I read the exchange and I disagree. Impedance is a word being used to say
mismatch and that is not what it means. It like saying light and sound
don't match because they have an impedance mismatch. I think it is a poor
term to use.

OSC is a message format, and has none of the semantics that MIDI defines.

Post by Camille Troillard
Basically, in both protocols, you are sending an instruction to another
machine. In OSC, you can give an instruction to turn a sound on or off, or
change a controller, or whatever. It is basically the same principle.
No, OSC does not define anything more than a message format.

At the lower ISO layers - yes, but at the application layer it does

Post by Camille Troillard
MIDI on the other hand has definitions for a Note On message, Note Off
message, and plenty of other concept (Control Change, Program Change, etc.).

That is only in General MIDI. You can do what you wast in MIDI - you just
put it in your MIDI implementation chart.

Post by Camille Troillard
The MIDI specification defines the protocol down to the wire. OSC has no
such recommandation, it is agnostic of any transport layer.
That was one of the major points in the NIME paper. That it why the

statement "OSC is faster than MIDI" is false. Speed is outside the domain
of OSC in the same way weight does not exist outside of gravity. However,
saying that OSC is agnostic of any of the lower ISO layers is not really
any sort of "out" because the message has to get from point A to B through
them. You can pretend they don't exist, but in reality, when you go to
implementation, they do exists and you need to account for them.

Post by Camille Troillard

Post by Camille Troillard
Therefore you are pushing the problem of handling the MIDI logic to the
pure OSC apps, i.e. no problem is solved.
I proposing that OSC can be used to control MIDI software or devices,

without requiring the MIDI devices to do anything. People can now use their
MIDI gear and control it via OSC and they do not need to modify their
software or hardware. That is a big problem solved.
Angelo, think about it: your OSC programs will have to “speak” MIDI
flluently for this to work.
You need to define a common ground for most common functions in OSC. You
can’t just pipe MIDI through OSC and pretend it is OSC, when in fact it is
still 100% MIDI inside :)

I can see the point you are making. I don't believe that you can have a
standard MIDI mapping in OSC, but the reason is namespace pollution, and
the coupling required between the two.
Namespace, in that once you use "/midi", what do you do when you want
another device. One of the best things about OSC is that you can easily
expand by increasing the namespace. Bind it to something like "/midi" and
you immediately put an undesirable limit on it. Then there is all the
wastage of making what was one byte equal four by converting it to OSC.
However, looking at http://opensoundcontrol.org/spec-1_0, it appears to me
that there is already a data type for MIDI using type tag m
m 4 byte MIDI message. Bytes from MSB to LSB are: port id, status byte,
data1, data2

Why not just use that and use whatever OSC address you want? You just need
to get the device that is converting your OSC back to MIDI to respond to
that address.

This then bring the problem of coupling, in that the OSC app needs to know
how to turn its application layer function into a MIDI message - so you
have made the coupling between the two devices too high. That is why OSC
addressing scheme is so good in that you reduce that coupling. The problem,
however, is that it is very inefficient, as outlined in the NIME paper.

So basically, you need something like Max or PD to read the OSC message,
decode what you are expecting, and send it as MIDI to your MIDI device.

[Brian Willoughby]

Post by Camille Troillard
Hi Angelo,

There are plenty of music programs that do not support OSC, but would now be able to without any implementation from the music app.

I believe this claim is valid only if you choose to ignore the vast impedance mismatch existing between OSC and MIDI.
OSC is a message format, and has none of the semantics that MIDI defines. Therefore you are pushing the problem of handling the MIDI logic to the pure OSC apps, i.e. no problem is solved.

I agree, Cam.

On this topic, I think it's important to realize that "MIDI over OSC" is very different from "translating OSC messages of one flavor or another to MIDI at the remote end for applications that only support MIDI."

There are many OSC "note" standards. The monome flavor does not have velocity, and is organized in a two-dimension X/Y grid. The Soundplane flavor (t3d) has X, Y, and Z with real-time updates on all three parameters. Neither of these translates directly to MIDI, although MIDI is perfectly capable of handling the general idea in each case. Sending either of these flavors to a MIDI-only requires that the sender understand MIDI and organize the messages differently. But, once that is handled, there's no advantage to sending the MIDI messages over OSC. They might as well be sent over standard MIDI transports like ethernet. This is basically what the Soundplane client application does - it has an OSC output in t3d format, and a MIDI output that uses a standard MIDI transport. The MIDI output uses one channel per touch, mapping X to note and pitch bend, Y to a continuous controller, and Z to channel aftertouch or similar. The translation from raw data to OSC or MIDI is highly speci
fic, and wouldn't work without thorough knowledge of both t3d and MIDI. I can't see the MIDI option working any better by reworking it to transmit the MIDI byte stream inside an OSC link.

"MIDI over OSC" requires that both ends understand MIDI *and* OSC. Even if there is a MIDI-over-OSC to plain MIDI driver at the receiving end, the sender must still understand both MIDI and OSC, as Cam points out.

Brian Willoughby

[Winfried Ritsch]

Hello


Here my use-case:

I am building robtotic piano player as open hardware and my escher-
microcontroller have a Ethernet interface but no MIDI, since it is also to
slow as serial device, but also no USB:

Since I sent a proprietary Protocol to my machine, I wanted to change it to
OSC, so everybody can easily play it.
Most piano pieces are stored in MIDI-Files, so MIDI is native for playing
piano, therefore I want a roughly accepted protocol which sends MIDI, to my
device in various situations. Anyhow UDP mixes streams so multiple devices can
send MIDI to my device on the same time over Ethernet, (as far as timestamps
are synced time accurate).

Post by Angelo Fraietta

Post by Brian Willoughby
In my opinion, it's usually more important to ask "why" before asking "how."
In this case, what would be gained by transferring MIDI over OSC?
MIDI usually flows over its own custom interface, but can also be
transferred over USB or Ethernet. OSC does not define any physical
interface, so there really is no advantage to putting MIDI on OSC.

A very real advantage of doing this was by making a device driver that
looked like a MIDI device in your Mac / PC / linux and sending it OSC
messages. This means any application would then be able to receive OSC
messages and appear as MIDI without having to support OSC in that app.
There are plenty of music programs that do not support OSC, but would now
be able to without any implementation from the music app.

This is really an interesting feature especially I mostly use Linux. Anyhow
internal MIDI implementation in various OS-es support patching and MIDI is
more easily recorded and especially displayed in Sequencers than OSC.

Post by Angelo Fraietta

Post by Brian Willoughby

Post by IOhannes m zmölnig
probably OSC is the wrong tool in this case anyhow - have you checked
RTP-MIDI?

Thanks for the hint I will have a look at that.

mfg
winfried

Post by Angelo Fraietta

Post by Brian Willoughby

Post by IOhannes m zmölnig
gfards
IOhannes

On Jul 13, 2016, at 2:04 AM, Angelo Fraietta <

Post by IOhannes m zmölnig
OSC is a protocol, however, it does not encompass the bottom layers of

OSI model. Have a read of NIME paper below for detailed description

Post by IOhannes m zmölnig
http://www.nime.org/proceedings/2008/nime2008_019.pdf

_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Brian Willoughby]

Winfried,

In your use-case, I'd recommend keeping the OSC feature, but implement MIDI separately as RTP-MIDI. Since RTP-MIDI works over your Ethernet interface, there won't be any problem with missing classic MIDI or USB ports. The advantage of RTP-MIDI is that it will work with most sequencing software without any special drivers.

Meanwhile, your OSC implementation can implement whatever communication flavors you like, e.g., monome, t3d, etc.

Brian Willoughby

Post by Winfried Ritsch
I am building robtotic piano player as open hardware and my escher-
microcontroller have a Ethernet interface but no MIDI, since it is also to
Since I sent a proprietary Protocol to my machine, I wanted to change it to
OSC, so everybody can easily play it.
Most piano pieces are stored in MIDI-Files, so MIDI is native for playing
piano, therefore I want a roughly accepted protocol which sends MIDI, to my
device in various situations. Anyhow UDP mixes streams so multiple devices can
send MIDI to my device on the same time over Ethernet, (as far as timestamps
are synced time accurate).

Post by Angelo Fraietta

Post by Brian Willoughby
In my opinion, it's usually more important to ask "why" before asking "how."
In this case, what would be gained by transferring MIDI over OSC?
MIDI usually flows over its own custom interface, but can also be
transferred over USB or Ethernet. OSC does not define any physical
interface, so there really is no advantage to putting MIDI on OSC.

A very real advantage of doing this was by making a device driver that
looked like a MIDI device in your Mac / PC / linux and sending it OSC
messages. This means any application would then be able to receive OSC
messages and appear as MIDI without having to support OSC in that app.
There are plenty of music programs that do not support OSC, but would now
be able to without any implementation from the music app.

This is really an interesting feature especially I mostly use Linux. Anyhow
internal MIDI implementation in various OS-es support patching and MIDI is
more easily recorded and especially displayed in Sequencers than OSC.

Post by Angelo Fraietta

Post by Brian Willoughby

Post by IOhannes m zmölnig
probably OSC is the wrong tool in this case anyhow - have you checked
RTP-MIDI?

Thanks for the hint I will have a look at that.
mfg
winfried

[IOhannes m zmoelnig]

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as RTP-MIDI.

while i suggested something similar, you also have to be aware of the
drawback: now your receiver on a limited-ressources microcontroller must
speak 2 protocols (OSC and RTP-MIDI), which both can do similar
non-trivial things (scheduling events at timestamps).

fg
asmdr
IOhannes

[Hanspeter Portner]

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as RTP-MIDI.

Also take into consideration that RTP-MIDI is really exotic outside of the Apple
world, e.g. there are no (maintained) free RTP-MIDI implementations for GNU/Linux
et al. that I'd know of. So, if you really want to make your piano bot be accessible
for *everyone*, RTP-MIDI may just not be ideal. And it'll be more complicated to
implement than OSC (especially if you care about journaling), I'm afraid.

/bye ,s hanspeter

[Brian Willoughby]

Post by Hanspeter Portner

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as RTP-MIDI.

Also take into consideration that RTP-MIDI is really exotic outside of the Apple
world, e.g. there are no (maintained) free RTP-MIDI implementations for GNU/Linux
et al. that I'd know of. So, if you really want to make your piano bot be accessible
for *everyone*, RTP-MIDI may just not be ideal. And it'll be more complicated to
implement than OSC (especially if you care about journaling), I'm afraid.

See Linux, particularly Raspberry Pi, MIDIKit, and Ubuntu (Scenic software). The Wikipedia article for RTP-MIDI should bring you up to date on what's available.

See also: Arduino, MIDIBox, and Axoloti hardware platforms for their implementations.

Brian

[Winfried Ritsch]

Hello,

Post by Brian Willoughby

Post by Hanspeter Portner

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as
RTP-MIDI.>

Also take into consideration that RTP-MIDI is really exotic outside of the
Apple world, e.g. there are no (maintained) free RTP-MIDI implementations
for GNU/Linux et al. that I'd know of. So, if you really want to make
your piano bot be accessible for *everyone*, RTP-MIDI may just not be
ideal. And it'll be more complicated to implement than OSC (especially if
you care about journaling), I'm afraid.

See Linux, particularly Raspberry Pi, MIDIKit, and Ubuntu (Scenic software).
The Wikipedia article for RTP-MIDI should bring you up to date on what's
available.
See also: Arduino, MIDIBox, and Axoloti hardware platforms for their implementations.

I just found for Linux the thread:

http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-March/104446.html

meaning, there is nothing really easily or a rough consensus to use for Linux,
so it is no option for me.

Also the question is, if the Apple Session management added to rtp-midi ?
this will explode the code for microcontroller to use.


mfg
winfried

Post by Brian Willoughby
Brian
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Brian Willoughby]

Post by Winfried Ritsch

Post by Brian Willoughby

Post by Hanspeter Portner

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as
RTP-MIDI.>

Also take into consideration that RTP-MIDI is really exotic outside of the
Apple world, e.g. there are no (maintained) free RTP-MIDI implementations
for GNU/Linux et al. that I'd know of. So, if you really want to make
your piano bot be accessible for *everyone*, RTP-MIDI may just not be
ideal. And it'll be more complicated to implement than OSC (especially if
you care about journaling), I'm afraid.

See Linux, particularly Raspberry Pi, MIDIKit, and Ubuntu (Scenic software).
The Wikipedia article for RTP-MIDI should bring you up to date on what's
available.
See also: Arduino, MIDIBox, and Axoloti hardware platforms for their implementations.

http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-March/104446.html
meaning, there is nothing really easily or a rough consensus to use for Linux,
so it is no option for me.
Also the question is, if the Apple Session management added to rtp-midi ?
this will explode the code for microcontroller to use.

Is there another "MIDI over Ethernet" standard besides RTP-MIDI? Seems like someone would have come up with a simple one by now that could easily be implemented on any embedded system that is capable of ethernet.

Is the Apple Session management optional?

Brian Willoughby
Sound Consulting

[Winfried Ritsch]

Hello,

Post by Brian Willoughby

Post by Winfried Ritsch

Post by Brian Willoughby

Post by Hanspeter Portner

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as
RTP-MIDI.>

Also take into consideration that RTP-MIDI is really exotic outside of the
Apple world, e.g. there are no (maintained) free RTP-MIDI
implementations
for GNU/Linux et al. that I'd know of. So, if you really want to make
your piano bot be accessible for *everyone*, RTP-MIDI may just not be
ideal. And it'll be more complicated to implement than OSC (especially if
you care about journaling), I'm afraid.

See Linux, particularly Raspberry Pi, MIDIKit, and Ubuntu (Scenic
software). The Wikipedia article for RTP-MIDI should bring you up to
date on what's available.
See also: Arduino, MIDIBox, and Axoloti hardware platforms for their implementations.

http://lists.linuxaudio.org/pipermail/linux-audio-user/2016-March/104446.h
tml
meaning, there is nothing really easily or a rough consensus to use for
Linux, so it is no option for me.
Also the question is, if the Apple Session management added to rtp-midi ?
this will explode the code for microcontroller to use.

Is there another "MIDI over Ethernet" standard besides RTP-MIDI? Seems like
someone would have come up with a simple one by now that could easily be
implemented on any embedded system that is capable of ethernet.

When I first send MIDI around the world (Innsbruck-Vancouver using an Atari ST)
in beginning of 90ers we just send MIDI data over MODEMs (2400 Baud or even
300 Baud I cant remember).

With Ethernet coming, we just opened a port as UDP and send MIDI data.
The problem was/is MIDI as stateful protocol, dont miss somedata. For example
if note off was missing, we had a problem (solved limiting the maximum note
duration to 30sec, like diskklavier does it until today ;-)
Anyway TCP/IP solved it, but had poor timing.

Anyhow OSC is good as a transport format for TCP/IP and some plugins and so on
exist to send MIDI over OSC over TCP/IP or UDP.

Post by Brian Willoughby
Is the Apple Session management optional?

not for all applications and so apple session management is not RFC 4695
conform, but anyhow it seems it is more important for Apple who will be
technology leader than how achieve the best compatibility with other systems.
So I am not optimistic for open hardware... except arduino has a AppleMIDI
lib.

mfg
winfried

Post by Brian Willoughby
Brian Willoughby
Sound Consulting
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Brian Willoughby]

Post by IOhannes m zmoelnig

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as RTP-MIDI.

while i suggested something similar, you also have to be aware of the
drawback: now your receiver on a limited-ressources microcontroller must
speak 2 protocols (OSC and RTP-MIDI), which both can do similar
non-trivial things (scheduling events at timestamps).
fg
asmdr
IOhannes

OSC is not very compatible with resource-limited micro controllers. It's an order of magnitude less efficient in terms of parsing. You could easily handle eight to ten MIDI streams in real time before reaching the complexity of OSC. A good design should easily scale from a single MIDI stream to multiple MIDI streams. Adding OSC is where the trouble starts, not MIDI.

See Angelo Fraietta's paper for one viewpoint on the limitations of OSC for embedded implementations. I'm working on a design revision to streamline OSC for embedded situations, and hope to have a working example soon.

Brian

[Jeroen]

Hi Brian,

Excuse me for breaking in to this conversation. In your comment you
mention Angelo Fraietta's paper. Is that the paper he has been linking
in an earlier post? If so, that paper is from 2008. A lot has happened
since then. Do you think it is still as valid as it was in 2008?

Thanks,

Jeroen

Post by Brian Willoughby
See Angelo Fraietta's paper for one viewpoint on the limitations of OSC for embedded implementations. I'm working on a design revision to streamline OSC for embedded situations, and hope to have a working example soon.
Brian

[IOhannes m zmölnig]

Post by Jeroen
Hi Brian,
Excuse me for breaking in to this conversation. In your comment you
mention Angelo Fraietta's paper. Is that the paper he has been linking
in an earlier post? If so, that paper is from 2008. A lot has happened
since then. Do you think it is still as valid as it was in 2008?

I'd be curious what you think might have changed the gameplay since 2008
(apart from Brexit and Daesh, though i doubt whether these have any
impact on the things discussed here (yet)):

OSC-1.1 (2009) doesn't mention MIDI, which leaves us with OSC-1.0 from 2002.
RTP-MIDI is 2006.
and MIDI, well, ...

gfmsrd
IOhannes

[Jeroen]

_______________________________________________
OSC_dev mailing list
***@lists.mat.ucsb.edu
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Brian Willoughby]

I will be starting a new thread for this sub-topic, because nothing relevant to the embedded world has changed in the OSC design since 2008. In fact, the authors seem ready to take the standard to the next level, so the timing is probably right to address embedded concerns across the board.

I have some very specific recommendations that fit within the existing OSC syntax and paradigm, so I'd like to write them up and present them in a new discussion thread here. I'm not sure whether I should try to use RFC style, write a full paper, or just document the basics and see where the discussion goes.

Brian Willoughby
Sound Consulting

Post by Jeroen
Hi Brian,
Excuse me for breaking in to this conversation. In your comment you
mention Angelo Fraietta's paper. Is that the paper he has been linking
in an earlier post? If so, that paper is from 2008. A lot has happened
since then. Do you think it is still as valid as it was in 2008?
Thanks,
Jeroen

Post by Brian Willoughby
See Angelo Fraietta's paper for one viewpoint on the limitations of OSC for embedded implementations. I'm working on a design revision to streamline OSC for embedded situations, and hope to have a working example soon.
Brian

[Winfried Ritsch]

Post by Brian Willoughby

Post by IOhannes m zmoelnig

Post by Brian Willoughby
I'd recommend keeping the OSC feature, but implement MIDI separately as
RTP-MIDI.>

while i suggested something similar, you also have to be aware of the
drawback: now your receiver on a limited-ressources microcontroller must
speak 2 protocols (OSC and RTP-MIDI), which both can do similar
non-trivial things (scheduling events at timestamps).
fg
asmdr
IOhannes

OSC is not very compatible with resource-limited micro controllers. It's an
order of magnitude less efficient in terms of parsing. You could easily
handle eight to ten MIDI streams in real time before reaching the
complexity of OSC. A good design should easily scale from a single MIDI
stream to multiple MIDI streams. Adding OSC is where the trouble starts,
not MIDI.
See Angelo Fraietta's paper for one viewpoint on the limitations of OSC for
embedded implementations. I'm working on a design revision to streamline
OSC for embedded situations, and hope to have a working example soon.

A design revision to streamline OSC (for embedded situations) is a good idea.

On one side micro-controllers becomes more powerful, on the other side ultra-
low power processors have CPU-power like micro-controllers 20 years ago. I
use both of them.

So micro-controllers are not micro-controllers, they are different:

Eg. the cheap (cheaper then arduino) IoT-Chip ESP8266 has 60Mhz processor and
handles WIFI and can be used with Arduino-IDE, so the OSC parsing is not an
issue (just wrote some cheap OSC-code for them).

The dsPIC33F, used in my machines since 2009 with Ethernet shield needs most
of the power for TCP/IP stack not the OSC, but can do software PWM on 32ports
up to 20kHz.

(Mostly I make a hash on the address+format to identify it, which is cheap
from cpu-power state of view)

One personal note:

Please consider dropping the regex stuff, which I never implemented. If I want
to sent to some group, I implement e.g. "/pianos/*/note" (literally) as a own
receiver so I can handle it for network sessions, but anything else is to
complicated to be implemented and handled, like what a graphical
representation or a sequencer do with regex as data ?

mfg
winfried

Post by Brian Willoughby
Brian
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Martin Habets]

Post by Winfried Ritsch
Hello
I am building robtotic piano player as open hardware and my escher-
microcontroller have a Ethernet interface but no MIDI, since it is also to

You could have a a look at firmata.org.
It extends standard MIDI with control messages for microcontrollers.

Martin

[Roger Dannenberg]

Out of curiosity, I read "White Paper: Comparison of MIDI and OSC",
referred to by "Why MIDI is better ?-)" in Winfried's message below.
Three comments: (1) source is the MIDI industry (MMA), (2) article is
not peer-reviewed, (3) the one redeeming feature of this stupid paper is
that it made me laugh out loud.*

Winfried, what's wrong with using type 'm' for MIDI in OSC? It's
supported in liblo and other libraries, but maybe you are saying it's
not universally supported?

-Roger

*I'm actually a proponent of MIDI /and/ OSC, but when you state that "
However, MIDI messages ... can be time-stamped ..., achieving the exact
same result as ... OSC events," you have to laugh. Yes, and if OSC were
extended with audio packets and NAT punch-through and an intermediary
peer-to-peer network, it could achieve "/the exact same result"/ as
Skype. Right, I'm sure we all agree.

Post by Winfried Ritsch
Hello,
[...]

Is anybody aware of any other (relevant) soft- or hardware which uses the
type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]
MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.
Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
"/midi" ",iii" status data1 data2
"/m" ",i" (status<<16 + data1<<8 + data2)
"/midi/sysex" ",b" [n*data]
"/ms" ",b" [n*data]
The goal is to implement this for Pd and Escher micro-controller, to play my
robotic piano player Rhea_ using OSC.
( see http://algo.mur.at/projects/autoklavierspieler )
a) Why MIDI is better than OSC is stated here ?-)
https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
b) There is on midi.org a lot of specifications and recommendations for a
Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI
but none for OSC, we should propose something like this to MIDI association.
mfG
Winfried

[IOhannes m zmölnig]

Post by Roger Dannenberg
Winfried, what's wrong with using type 'm' for MIDI in OSC? It's
supported in liblo and other libraries, but maybe you are saying it's
not universally supported?

of course i cannot speak for winfried, but it seems that the main
problem is that the 'm' type is so uncommon that it is "easy" to use it
wrongly without ever noticing.
having a few reference applications (rather than a library) against
which to test would be great.

mgfdsr
IOhannes

[Winfried Ritsch]

Post by Roger Dannenberg
Out of curiosity, I read "White Paper: Comparison of MIDI and OSC",
referred to by "Why MIDI is better ?-)" in Winfried's message below.
Three comments: (1) source is the MIDI industry (MMA), (2) article is
not peer-reviewed, (3) the one redeeming feature of this stupid paper is
that it made me laugh out loud.*

had a nearly equalk experience :-)

But anyhow it would be a good place to place a "White-paper" which suggeste a
OSC-MIDI protocol to achieve a rough consensus in future for compatible OSC-
MIDI devices.

Post by Roger Dannenberg
Winfried, what's wrong with using type 'm' for MIDI in OSC? It's
supported in liblo and other libraries, but maybe you are saying it's
not universally supported?

a) MIDI is great since it is so simple, so adding any other information would
make more complicated and less exchangeable like the type 'm' does adding the
port and MIDI already has channels.

For example somebody records a OSC-MIDI stream, converted to MIDI it looses
the port information or a device is a keyboard with OSC out and the other the
device is the receiver, so I change the port and it does not work anymore,
etc...

b) some application, maybe the most, don't support 'm' which is ok for the
OSC-Spec, which suggest to drop any message with a type 'm' , so they will
block the MIDI information, even maybe they are should be a run trough or
distributer.

I hope this makes it clear, since also Hanspeter reported this behavior.


mfg
winfried

Post by Roger Dannenberg
-Roger
*I'm actually a proponent of MIDI /and/ OSC, but when you state that "
However, MIDI messages ... can be time-stamped ..., achieving the exact
same result as ... OSC events," you have to laugh. Yes, and if OSC were
extended with audio packets and NAT punch-through and an intermediary
peer-to-peer network, it could achieve "/the exact same result"/ as
Skype. Right, I'm sure we all agree.

Post by Winfried Ritsch
Hello,
[...]

Is anybody aware of any other (relevant) soft- or hardware which uses the
type 'm' for MIDI ?
Is somewhere out there and does know of an (un)official MIDI-Protocol
definition for OSC Synthax (like TUIO is for sensoric data) ?
Because if someone wants to send MIDI over OSC, I would prefer to be
compatible and not proprietary.

[...]
MIDI is old-aged and not dying, MIDI is a Protocol and OSC a
synthax, so I have to find a protocol with OSC synthax.
Since I did not find anything convincing (see addendum) and in favor for
existing implementations dropping type 'm', I propose to define the MIDI
"/midi" ",iii" status data1 data2
"/m" ",i" (status<<16 + data1<<8 + data2)
"/midi/sysex" ",b" [n*data]
"/ms" ",b" [n*data]
The goal is to implement this for Pd and Escher micro-controller, to play
my robotic piano player Rhea_ using OSC.
( see http://algo.mur.at/projects/autoklavierspieler )
a) Why MIDI is better than OSC is stated here ?-)
https://www.midi.org/articles/white-paper-comparison-of-midi-and-osc
b) There is on midi.org a lot of specifications and recommendations for a
Serial MIDI Ports, 5 Pin DIN, Wireless MIDI, RTP MIDI, USB MIDI, OSX MIDI,
iOS MIDI, Web MIDI, Bluetooth MIDI
but none for OSC, we should propose something like this to MIDI association.
mfG
Winfried