On Wed, 13 Feb 2013 09:29:19 +0100
<joerg-cyril.hoe...@t-systems.com> wrote:
> 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
I did. It is in the log line that you deleted. Immediately after the
hex dump...
TRACE("dwBufferLength=%u !\n", lpMidiHdr->dwBufferLength);
//~ TRACE(" %02X %02X %02X ... %02X %02X %02X\n",
//~ lpData[0], lpData[1], lpData[2],
lpData[lpMidiHdr->dwBufferLength-3],
//~ lpData[lpMidiHdr->dwBufferLength-2],
lpData[lpMidiHdr->dwBufferLength-1]);
{ unsigned long dwToGo;
#define dprintf(x...) fprintf(stderr, x)
for (dwToGo = 0; dwToGo < lpMidiHdr->dwBufferLength; dwToGo += 16)
{
DWORD i;
BYTE ch;
for (i = 0; i < min(16, lpMidiHdr->dwBufferLength - dwToGo);
i++)
dprintf("%02x ", lpData[dwToGo + i]);
for (; i < 16; i++)
dprintf(" ");
for (i = 0; i < min(16, lpMidiHdr->dwBufferLength - dwToGo);
i++) {
ch = lpData[dwToGo + i];
dprintf("%c", (ch >= 0x20 && ch < 0x7F) ? ch : '.');
}
dprintf("\n");
}
TRACE("dwBytesRecorded=%d\n", lpMidiHdr->dwBytesRecorded);
}
> >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!
No. Maybe dwBytesRecorded *should* be the length of the data. But it
isn't, it's always zero. Yes, really, I checked in several runs.
> 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?)
If I figure out a way to do that I'll let you know...
> 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).
No, I don't have wineOSS. Does it require a proper OSSv4? Or would it
work with ALSA OSS emulation? I don't have 'real' OSS.
