Re: [PATCH] winealsa.drv: Fix handling of system real time MIDI messages

[Andrew Eikum]

On Tue, Jan 31, 2017 at 04:16:17AM -0200, Bruno Jesus wrote:
> MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages.

Looking at this spec, should Tune Request be handled the same way as
these system real time messages? I also noticed Reset is still handled
as a SysEx after your patch. Should it be?

Aside from that, I also noticed an old patch that unfortunately never
got merged:

https://www.winehq.org/pipermail/wine-patches/2013-January/121366.html

If you understand this MIDI stuff a little bit, you might be a good
person to review and re-submit that patch :)

Thanks,
Andrew

[PATCH] winealsa.drv: Fix handling of system real time MIDI messages

[Bruno Jesus]

On Tue, Jan 31, 2017 at 1:39 PM, Andrew Eikum  wrote:
> On Tue, Jan 31, 2017 at 04:16:17AM -0200, Bruno Jesus wrote:
> > MIDI spec at http://www.somascape.org/midi/tech/spec.html state that system real time messages "... are each single byte messages, with no following data bytes...", currently wine is prepending SYSEX header generating invalid messages.
>
> Looking at this spec, should Tune Request be handled the same way as
> these system real time messages? I also noticed Reset is still handled
> as a SysEx after your patch. Should it be?

I'm now using the program SendMIDI [1] to test together with
gmidimonitor to receive the messages. This program has the advantage
that it lets me send manually all sorts of messages.

Tune Request is a one byte system common message like the other system
real time messages, that is why it falls in the same case.

I didn't want to touch the reset message, it is like that since
forever and was based in OSS [2] code added ages ago. According to [3]
the sequence {0xf0, 0x7e, 0x7f, 0x09, 0x01, 0xf7} stands for "GM
System On", seems to be a vendor specific message. But I cannot state
it is right or wrong.

To test all this:
gmidimonitor --alsa &
wine sendmidi.exe dev "MIDI monitor - midi in" start stop cont spp 10
ss 1 tun as clock 100 rst

(clock message will repeat 48 times)

[1] https://github.com/gbevin/SendMIDI
[2] http://source.winehq.org/git/wine.git/commitdiff/d30dfd24#patch172
[3] http://openmidiproject.osdn.jp/documentations_en.html
> Aside from that, I also noticed an old patch that unfortunately never
> got merged:
>
> https://www.winehq.org/pipermail/wine-patches/2013-January/121366.html
>
> If you understand this MIDI stuff a little bit, you might be a good
> person to review and re-submit that patch :)

The patch makes sense, 0x7F is the sysex terminator (EOX). I'll do
some test to ensure it is correct and resend.

Best wishes,
Bruno

[PATCH] winealsa.drv: Fix handling of system real time MIDI messages

[Bruno Jesus]

On Thu, Feb 2, 2017 at 2:31 AM, Bruno Jesus  wrote:
> On Tue, Jan 31, 2017 at 1:39 PM, Andrew Eikum  wrote:
> I didn't want to touch the reset message, it is like that since
> forever and was based in OSS [2] code added ages ago. According to [3]
> the sequence {0xf0, 0x7e, 0x7f, 0x09, 0x01, 0xf7} stands for "GM
> System On", seems to be a vendor specific message. But I cannot state
> it is right or wrong.

Actually GM stands for General MIDI [1] and [2] explains a bit better
the byte sequence used in the reset, but still I can't know if it is
right.

[1] https://www.midi.org/specifications/category/gm-specifications
[2] http://www.gweep.net/~prefect/eng/reference/protocol/midispec.html#Common