Messages

That seems to have fixed it. Problem solved. Many thanks, and compliments on your support for the product.

I have to check some of the functionality regarding these system messages. I am not a professional programmer and am interested in this product to control a piece of musical equipment I own. Your product costs significantly more than a number of available off-the-shelf hardware controllers, so I need to ensure the additional cost will deliver me benefits in terms of being able to implement a controller customized to my personal needs. This looks extremely likely.

Once again, many thanks for your impressive support and help.

Rob.

It's now correctly parsing the FE command but the filter still doesn't work properly.

If I set the filter to 'FE' it doesn't filter the FE messages. If I set the filter to 'F0' then it filters the FE messages along with all messages between F0 and FF.

It seems the filter is still converting the FE messages to F0 when it looks at them. It should be seeing everything from F0 to FF as that message byte and not as F0.

OK. I will do that and get back to you. Many thanks.

I can't give you a project as I'm simply running you MidiMonitor example in my old VB6 setup to see if can do what I want. That includes correctly handling system messages.

The point is that if it receives a packet with three bytes 'FE 00 00', it is presenting it as 'F0 00 00' with channel of 14 (0E). This is wrong. There can be no channel for any message type of F0 or higher. The nature of the issue is that your code should not be extracting any channel value for messages of F0 or higher, as these are all system-wide messages.

So, if MessageByte >= 240 (F0) then don't modify MessageByte and don't set a Channel value (or set it to something like -1). Test the unmodified MessageByte against the Filters and return this in the MidiDevicesEventReceived event/callback, if applicable. That way, I can set a filter for 254 (FE) and block just these messages without blocking other system messages.

I tried to attach an image, but it wouldn't accept it, so here's a summary of what is happening.

The incoming message is of the form: FE 00 00 and it is being returned as a short message of the form: Command=F0, Channel=0E, Data1=00, Data2=00.

It should be Command=FE, Channel=undefined, Data1=00, Data2=00.

Your input handler should be identifying the messages as system message type FE, with no channel, data1 as 00 and data2 as 00. This is as per the midi specification. This applies to all messages of types F0 to FF.

Here is the list of system messages. Only F0, F1, F2 and F3 have any associated data bytes.

F0 = SysEx
F1 = Midi Time Code
F2 = Song Position
F3 = Song Select
F6 = Tune Request
F7 = EOX
F8 = Timing Clock
FA = Start
FB = Continue
FC = Stop
FE = Active Sensing
FF = System Reset

I am trying to filter an Active Sensing message (MIDI command FE) but it appears that the Input Event Filter sees it as a System Exclusive message with a channel of 15. MIDI messages from F0 and upwards are system wide messages and can have no channel. So F1 is Time Clock, F2 is Song Pointer, and so on up to FF (System Reset). If I set a filter at FE, it does not trap the Active Sensing messages, passing them through - erroneously - as System Exclusive. This appears to be a bug in an otherwise excellent product.