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
