Try to construct simple midi note messages

[Keeze]

Hello,

I want to create a USBMidi to OSC bridge for my Midibox Seq4. It looks like this box accepts messages in the Midi format (m) like /midi{port} m0x90305f00 (note-on, note x30, vel x5f). I tried to construct this message, but I get stuck. Please help...

Cheers, Kees

[ssj71]

Sorry I'm not quite understanding how you want to format the message. I think maybe the line:

/midi{0} m, msg : midimessage( msg )

might do what you want. If not, send me a few examples of the OSC messages you expect and their midi equivalents.

EDIT: I should mention, I don't have any devices that use the OSC m type for midi messages, so this part of OSC2MIDI isn't very well tested. If you find issues, I'd love to make it work so please let me know.

[Keeze]

I have tried to use the m type. I have tried many combinations like: /midi1 m, state, n, vel : note( channel, n, vel, state);

matches found:
  noteon ( 0, 48, 12 ) -> /midi1 ,m MIDI [0x00 0x00 0x00 0x00]

I was expecting something like

/midi1, m MIDI [0x90 0x30 0x0C 0x00]

Note that I am a complete noob...

[ssj71]

I'm not sure we currently have a good way to generate exactly what you put. Did you try

/midi1 m, msg : midimessage( msg );

? That should show something like what you printed.

Your mapping:

/midi1 m, state, n, vel : note( channel, n, vel, state);

only lists 1 variable type in the OSC message which is type 'm' The only way to make an 'm' type variable is with the midimessage() command on the midi side of the mapping. Since you only listed 1 variable type, all the other variable names you listed (state, n, and vel) were ignored. Since any midi message can be put into a single 'm' variable in OSC I didn't think it would be necessary to allow arbitrary mappings of select messages to an 'm' variable. If you really need to specify note-ons to fill the OSC message you could try a double mapping with the --strict option which might get the result. The mappings would be something like:

/midi1 miii, msg, state, n, vel : midimessage( msg ); /midi1 miii, msg, state, n, vel : note( channel, n, vel, state);

Since the 2 lines are the same it will require to match both midi commands (any midi message and a note on or off). But this will show something along the lines of:

noteon ( 0, 48, 12 ) -> /midi1 ,miii MIDI [0x90 0x30 0x0C 0x00] 1 48 12

Which I don't think is what you are looking for. So I still think that my first suggestion is the closest to what you want. If I'm still misunderstanding or you really need to be able to arbitrarily map the bytes in a midi type variable let me know.

[Keeze]

The first almost did a great part of the job ( /midi1 m, msg : midimessage( msg ); ) It only looks like the ouput is shifted against the output I get when I route a midi keyboard connected to the SEQ4 to OSC.

Sent from SEQ4: /midi1 m, MIDI [0x90 0x3c 0x35 0x00] Sent from osc2midi: /midi1 ,m MIDI [0x00 0x90 0x3c 0x39]

So, one of the machines has the output shifted. And how to find out which one... I am also creating a topic on the Midibox forum and see what they have to say.

Thanks so far!

[ssj71]

I'd bet its osc2midi, I think I can fix that though. Let me look at it.

[ssj71]

Actually upon investigation, according to http://opensoundcontrol.org/spec-1_0 the m type must have data: "4 byte MIDI message. Bytes from MSB to LSB are: port id, status byte, data1, data2"

EDIT: So I think this is a bug in Midibox. If you would like to make a hacked version of OSC2MIDI that works around this I think the key is to change pair.c line 1444-1446 to read:

                   msg[0] = argv[i]->m[0];
                   msg[1] = argv[i]->m[1];
                   msg[2] = argv[i]->m[2];

and also lines 1793-1796:

 1793                 m[0] = mymsg[0];
 1794                 m[1] = mymsg[1];
 1795                 m[2] = mymsg[2];
 1796                 m[3] = 0;//port ID

(the change is in the indices of the m array). This could at least get you going until its changed upstream. I'm not going to add this since it is not consistent with the OSC documentation. Keep me up to date with what the midibox folks say.

[Keeze]

Your hack works (both ways), so confirmed that the mismatch in datatype encoding is the culprit! Keep you updated

Tnx! Kees

[ssj71]

is there any update on this? I would like to close this issue.

[Keeze]

Hi,

Sorry for the delay, problem is solved and issue can be closed.

The author of the midibox software has fixed the problem (something with parsing the incoming OSC messages).

Cheers, Kees