MidiDevices InputEvent Filter parsing error (ActiveX)

[rbe]

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.

[Administrator]

Hello,

could you be so kind to send a small sample project reproducing the issue? In this way it would be easier finding the nature of the issue.

Kind Regards

Severino Delaurenti
MultiMedia Soft

[rbe]

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

[Administrator]

Hello,

thanks for your feedback: effectively it seems that this situation was managed in error but a new build that should fix the problem is already available inside our web site.
I suggest to uninstall the current version and to download and install the latest one.
After the upgrade, it would be very kind of you if you could report if the issue is fixed on your side also.

Kind regards

Severino Delaurenti
MultiMedia Soft

[rbe]

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

[rbe]

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.

[Administrator]

Hello and, once again, thanks for your feedback.
Effectively the nature of the issue is exactly the same and now it should be fixed: I suggest to uninstall and reinstall the setup package that has just been updated on our server.

Kind regards

Severino Delaurenti
MultiMedia Soft

[rbe]

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.

[Administrator]

You are welcome and thanks again for your feedback 

Kind regards

Severino Delaurenti
MultiMedia Soft