sendControlChange not working on Windows

[tenderbolton]

Hi there,

I'm doing some testing on an app I'm building that uses ofxMidi, and discovered that on Windows (Win 8.1 in my case), this method is not working properly:

ofxMidiOut::sendControlChange

Whenever I try yo send a midi control message with it, the receiver reports a "System Reset 0" message.

It is very simple to reproduce it using the examples. Just change the midiOut.sendNoteOn(channel, note, velocity); instruction with:

    midiOut.sendControlChange(1, 35, 255);

You should get the error at the receiver.

As far as I debugged, the error seems to be at the MidiOutWinMM::sendMessage( std::vector *message)

The vector message seems to be OK when the method is called.

This error does not occur on MacOSX.

[tenderbolton]

I'm using loopMidi to connect both apps.

Will try a different loop application to rule it out as the problem.

[tenderbolton]

When trying using LoopBe instead of loopMidi I get a different result.

The receiver gets the following messages:

1- The first time I execute sendControlChange, the receiver prints a System Reset 0 message.

2- The following times, the receiver prints a Control Change 1 (so it gets the control change message), and immediately next it prints a System Reset 0 message (two prints in total).

[danomatika]

There is a new rtmidi-2.1.0 branch which updates to RtMidi 2.1.0. Hopefully that fixes the issue which looks like it's an RtMidi internal problem.

[tenderbolton]

I've just downloaded the new branch and did the same test using the examples.

The error is still happening, the only thing that changed now is that when I close the exampleOut app, the receiver gets a bunch of Control Change messages (with Ids of 1,2,3,4,5, ... until 16, and some of them are repeated).

1- LoopMidi still outputs a single System Reset 0 message.

2- LoopBe still outputs a single System Reset 0 message on the first message, and then a Control Change and System Reset 0 messages on subsequent messages.

Obviously LoopMidi and LoopBe manage their output (or input) buffers differently.

Might ofxMidi be sending some garbage data to the output buffer?

[danomatika]

I don't know. I haven't tested ofxMidi personally on Windows for a few years now. That's what you guys are for :D

The SYS RESET byte is 0xFF so it might be a bad bit mask or integer value overflow etc

[tenderbolton]

Ok. I'll try some changes tonight and will let you know what I find.

I've never used RtMidi directly before. Will try to send a simple control message using RTMidi with no middleman first.

[danomatika]

Thanks. I fixed a couple RtMidi bugs on Linux when I rewrote ofxMidi a few years ago, so I wouldn't be surprised if it's something similar.

... It's also one reason why I've looked into moving ofxMidi to portmidi which seems a bit more stable.

[danomatika]

I just updated to RtMidi 2.1.1. Can you see if that fixes the issue?

[danomatika]

Closing due to lack of activity.

[SFR75]

So is it possible to write to midi port using ofxMidi ? I'm on windows and I have the same issue.. :(

[danomatika]

@tenderbolton Since this somehow is being resurrected, I noticed the following:

It is very simple to reproduce it using the examples. Just change the midiOut.sendNoteOn(channel, note, velocity); instruction with: midiOut.sendControlChange(1, 35, 255);

255 is the wrong value, max should be 127, so 255 -> 0xFF aka Sys Reset...

@SFR75 What is your exact issue other then "it doesn't work"? Please open a new issue with details. If Midi Output was broken on Windows in general, I think there would be quite a long issue discussion by now, so it's likely something with your setup or usage.

[SFR75]

@danomatika yes, my fault. I posted my comment too early. I ported my code from OSX to Windows and apparently in windows there is a Microsoft GS Wavetable Sync device (out), so there is an offset between midiIn and midiOut numbering. In OSX they are in sync. Anyway, once I used correct IDs, it's working on windows. Thanks! )