OSC message format is not "symmetric"

[jkbd]

Hello, I just compiled m2o and o2m from commit a1205b4ce976d73ccf9e987fee1f1c0e664ef6b4 on Arch Linux. In one terminal, I run:

$ m2o --list
Found 2 MIDI inputs.
   (0): Midi Through Port-0
   (1): UA-25 MIDI 1
$ m2o --oschost 127.0.0.1

In another terminal, I run:

$ o2m --oscport 57120

I expected o2m to receive OSC and forward MIDI events. But if I play a note on a connected MIDI keyboard (connected to UA-25 MIDI 1), o2m starts printing

[2021-10-06 11:04:31.190] [console] [info] Received OSC message with address pattern: /logging
[2021-10-06 11:04:31.190] [console] [error] No match on address pattern: /logging
...

in an endless loop at 100% CPU. Within this huge chunk of messages, there is one mention of a MIDI Note-on:

[2021-10-06 11:04:31.191] [console] [info] Received OSC message with address pattern: /midi/ua-25_midi_1/1/1/note_on
[2021-10-06 11:04:31.192] [console] [error] Unknown command on OSC message: ua-25_midi_1/1/1/note_on. Ignoring

However, if I run oscdump as a receiver,

$ oscdump osc.udp://:57120

I notice, there is no endless stream of /logging s "..." and /midi/ua-25_midi_1/1/1/note_on ii 50 86 looks fine to me. Am I doing something wrong? I get the same results, using an --oschost in the LAN and with any setting of --monitor.

[llloret]

Hi, @jkbd, the problem is that you are creating a loopback between o2m's input and logging ports. The default output port is 57120, which happens to be the same where it is listening in your configuration. You can either change the listening port, or the output port (using -O or --oscoutputport). Let me know if this solves your issue.

[llloret]

I will add a warning at runtime to highlight when this happens.

[jkbd]

Thank you for your quick reply! My initial assumption was, that one can use m2o and o2m to bridge ALSA-MIDI events over the local network, without a dispatcher in the middle. Reading the outgoing OSC message format and the incoming OSC message format in detail tells me, my assumption is wrong. From my point of view, this issue can be closed.

I hope the following helps future tinkerers:

For example, m2o sends OSC equivalent to

> oscsend localhost 57120 /midi/ua-25_midi_1/0/1/note_on ii 2 3

where /1 is the channel. On the other hand o2m expects OSC equivalent to

> oscsend localhost 57200 '/*/note_on' iii 1 2 3

where the channel not encoded in the address string. Also I don't see a way to use --osctemplate with m2o to match this format.

P.S. It took me long to understand the meaning of the OSC message format description in the README. That's why I wrote examples using oscsend, which I find more legible. Some code-markup or similar examples might improve the format description a lot.

[llloret]

The thing is that osmid evolved as the MIDI interfacing for Sonic Pi, and it was tailored to that use case.

I think that what you are saying about briding events over the local network would be very interesting and quite simple to implement. I could just add a switch to make it work in "o2m compatible format", so that you could do what you are after. Or perhaps it could even be the default now, since this is no longer used in Sonic Pi.

Or even use the -r switch, to send in raw mode, and adjust the sending on m2o's side to match what o2m is expecting. That should be quite straightforward, and you get the original raw midi without any conversions. I think I like this idea more.

Would that of interest to you if that gets implemented within a few days?

[llloret]

After thinking a bit more, you might be able to get the behaviour you expected using this:

• m2o -t /*/raw -r -o 57200 (Note 57200 is the default input port for o2m) (Note that the "*" is esscaped to prevent shell expansion
• o2m

Does that work for you, @jkbd?

[jkbd]

You are right, this works (with some No match on address pattern: /logging errors)! Thank you very much! Apart from that, I don't have a clear goal that legitimates changes in the code. I am somehow experimenting with scaling up synthesizer setups without expensive hardware.

[llloret]

You can add "-m 6" at the end of m2o and it should make the logging messages disappear.