Re: Midi2 handling of SysEx data

Sorry for the late replies, $REAL_LIFE intercepted...

Matthijs Hollemans wrote:
> However, you can override the Data() hook to look for a sysex yourself.=
=20
> The data buffer that is passed to Data() does include the control bytes=
=20
> (at least 0xF0, but not necessarily 0xF7). You would do something like=20
> this:
> ...

Oh... I think I should take the time to RTFM. :-) This approach  should=20
work nicely. I'll rework my code as soon as I have time.
I think it might be a good idea to include your example code in the Data(=
)=20
or SystemExclusive() section. This will tell anyone interested in doing=20
SysEx receive the best way to get raw SysEx data.

And 0xf7 isn't handled by the system. I have a first version of my SysEx=20
receiver tool running, and Midi2 kit spits "Not Handling Event 0xf7" to=20
stderr for each received SysEx.
As I transfer bulk dumps from my XG unit which consist of about 1700 sing=
le=20
SysEx messages of mostly 8-10 bytes length, this produces some nice load =
on=20
the system. :-\ Can be solved by redirecting stderr of course, but still=20
annoying.

=20
> As far as the documentation is concerned, I thought it would be obvious=
=20
> that the MIDI control bytes (0xF0 and 0xF7) are stripped from the data,=
=20
> since none of the other callbacks includes control bytes either.

I regard SysEx as something special, as it is not useful to most instance=
s=20
which handle MIDI data, and will simply be saved to a file in most cases.=
=20
And if porting programs from other systems, parsing of SysEx segments wil=
l=20
also likely be based on raw chunks with status bytes. Well, this can be=20
handled by Data(), so it's no biggie.

=20
> By the way, you can get the most up-to-date docs from:=20
> http://home.tiscali.nl/mahlzeit/openbeos.html

Thanks, had lost track of that link. And thanks for updating the docs so=20
fast.

Bye,
Chris