MIDI program change causes event parsing error
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The following code causes an "event parsing error!" whenever a 2-byte MIDI message such as a program change is sent: // the midi event MidiIn min; MidiOut mout[3]; // the message for retrieving data MidiMsg msg; // open the device if( !min.open( 0 ) ) me.exit(); <<< "MIDI in device:", min.num(), " <- ", min.name() >>>; for(0 => int i; i < mout.cap(); i++){ if( !mout[i].open( i + 1 ) ) me.exit(); <<< "MIDI out device:", mout[i].num(), " -> ", mout[i].name() >>>; } int eventnum; // TODO: subclass MidiMsg and stick these in there int channel; int command; while( true ) { // wait on the event 'min' min => now; // get the message(s) while( min.recv(msg) ) { msg.data1 & 0x0F => channel; msg.data1 & 0xF0 => command; // print out midi message <<< eventnum, "(", msg.data1, ")", channel, command, msg.data2, msg.data3 >>>; eventnum++; // note, controllers (not bank!!), or pitchbend if (command == 144 || (command == 176 && (msg.data2 != 0 && msg.data2 != 32)) || command == 224) { mout[0].send (msg); } else { // XXX program changes are 2 bytes! // how to make MidiMsg handle those?? mout[1].send(msg); } } } The exact error message is: "RtMidiOut::sendMessage: event parsing error!". How does one cajole MidiMsg into sending a 2-byte Program Change? It's a pretty standard, um, MIDI message. - -ken -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGIe3We8HF+6xeOIcRAgKJAKDTJiuNklwhUD8NLAC+4TEJEif04ACdF1VU ZVfLQqAbb5m0zW9t4FGUWO4= =2CHt -----END PGP SIGNATURE-----
Ken;
The following code causes an "event parsing error!" whenever a 2-byte MIDI message such as a program change is sent:
Yes, that's a known issue, at least on Linux (I take it you are on Linux from your pgp sig ). On Windows it does work, or more likely, Windows let's itself be tricked more easily by ChucK abuse(?). Right now ChucK asumes MIDI mesages are three bytes. Of cource a third byte can be padded on at the end and strictly speaking it should be dropped by all listening devices since you anounce at the start that there will only be one data byte but clearly RTAudio tries to parse them as ChucK hands them to him and fails. Personally I don't think RTAudio should fail there since the MIDI spec clearly incoporates that there might be data that a device doesn't understand and that it should leave it be. I also think a update to ChucK's MIDI with function names like for the newed HID version and proper message lengths would be very welcome. Sorry, no fix but that's the how&why. Yours, Kas.
participants (2)
-
Kassen
-
Ken Restivo