Hi,
Johannes Kroll wrote:
9.532:003a:trace:midi:modLongData dwBufferLength=88 ! f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.....K@z..... 7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@........... 00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f .......@..|..... 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f ................ 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f 7f ................ 7f 7f 01 7f f7 00 00 00 ........
Could you please log dwBytesRecorded next to TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
I once proved that dwBytesRecorded is what gets used with midiSTREAMout
So there is an F7 there... Maybe the app expects that the driver scans through the buffer for the F7 and doesn't send the following bytes...
Net.wisdom is that modLongData need be scanned for coalesced regular status messages, e.g. some people use it to play chords, arguing that one LongMsg is faster than 3 consecutive midiOutShortMsg. That's a patch yet to be written.
However, I wouldn't know what to do with the three 00 bytes. That's not MIDI!
Also, I'm wondering what ALSA does with that packet. Do the bytes as shown really make their way over the serial port? (Perhaps you could use some virtual MIDI device to dump what ALSA processes internally?)
Do you have a working wineOSS? WineOSS simply dumps the bytes one by one and does not require us to tell it what a sysex might be. I already tested that disguising a chord as an ALSA SysEx within midiOutLongMsg doesn't work (at least with a SW synth).
Thank you, Jörg Höhle