4.12.3 Multi-page frame sends incorrect MIDI messages

[lighthacker2020]

I'm seeing unexpected behavior in 4.12.3 (tested on MacOS) where a multi-page frame sends incorrect MIDI messages for any page after the 1st. Verified that in 4.12.2 the messages are sent as expected.

In the attached (somewhat contrived) file, a multi-page solo frame contains 3 pages of 2 buttons each. The expected behavior is that each button sends a MIDI PC message when pressed. This works fine on the 1st page, but on the 2nd page, the MIDI messages are coming out as Channel Aftertouch messages; and on the 3rd the messages are sent as Pitch Wheel messages.

I've seen the behavior in 4.12.3 for solo and normal frames, and there seems to be some relation to how the Input Channel configuration is handled in the frame when the widget (button, in this case) is defined as a direct child in the frame. I see the behavior when I define a button matrix, which creates the buttons inside a frame; and similarly when I right-click inside the frame and add an element that way.

As a workaround, if I define and configure the element outside of the frame, then cut and paste it in to target page of the frame, it behaves as expected.

EDIT - was also able to confirm that the behavior exists in a RaspberryPi built from source on or around Dec 12th

Thanks,

Mike

[lighthacker2020]

Did a bit more digging on this, and added some extra logging around the midi plugin feedback methods. I noticed that the midi channel increases by 16 for each page in the multi page frame. So for page 1 the feedback is sent on midi channel 0 (as expected), when moving to page 2 the feedback is sent on midi channel 16 (sort of suspect, since using zero-based counting valid midi channels should only be 0-15), and when using page 3 the feedback is sent on midi channel 32 (?!?!? that's not even a valid midi channel)

If I make a small update to QLCMIDIProtocol::feedbackToMidi() in midiprotocol.cpp to change

Code: Select all

    // for OMNI mode, retrieve the original MIDI channel where data was sent
    if (midiChannel == MAX_MIDI_CHANNELS)
        midiChannel = channel >> 12;

to

Code: Select all

    // for OMNI mode, retrieve the original MIDI channel where data was sent
    if (midiChannel == MAX_MIDI_CHANNELS)
        midiChannel = (channel >> 12) % MAX_MIDI_CHANNELS;

I start seeing the expected midi messages when I navigate through the pages. (My use of MAX_MIDI_CHANNELS is just a convenience because the offset aligns, and not because I think there's any actual magic correlation between VC frame pages and midi feedback channels.)

I'm hoping to get some feedback from someone more familiar with the codebase about whether or not this would be the place to make a change to address the issue I'm seeing, or if I should dig a bit further into the feedback mechanism for VC widgets? My concern is that a change in the VC widget logic may have a much wider impact. Happy to put together a PR if folks think this is sufficient.

Thanks,

Mike

[mcallegari]

Which MIDI channel are you using?

Also, I haven't checked the code, but maybe each frame page adds an offset to the feedback channel. I don't think it's 16

[lighthacker2020]

Hi Massimo,

For this particular case, it's possible I could be using a MIDI channel between 1 and 6, depending on what action I want to send using the feedback. So to make that work, I have the plugin set to send feedback on the omni (1-16) channel.

A bit of back story might be helpful. I'm trying to use QLC+ to send midi commands to a Behringer X32 mixer to load various kinds of presets in the mixer; some actions are sent as PC messages on channel 1 (scene loading), another type of action also sends PC messages, but using channel 2 (snippet loading), and a 3rd kind of action (which consists of 512 possible events, for cue loading) is using PC messages across midi channels 3 through 6. In order to accomplish this ... especially for that 3rd case ... I need to use the feedback channel, as opposed to using a midi output channel. It's an unconventional way to use QLC+, but it seems like it could work if I'm able to figure out the offset changes when using a paged frame.

Thanks,

Mike

[lighthacker2020]

I found a couple of places in the UI code which align with my assertion about the page number affecting the channel number:

in inputselectionwidget.cpp:
InputSelectionWidget::slotInputValueChanged()
InputSelectionWidget::slotChooseInputClicked()

in vcframe.cpp:
VCFrame::slotInputValueChanged()

All of those methods are synthesizing a new channel number based on left-shifting the page number for the frame 16 bits and OR'ing that with the "actual" channel number. I double checked the workspace file, and it has the new/calculated channel set for the input property (which I would expect, looking at the code).

Don't know if it's germane or not to the discussion, but in the interest of full disclosure, I did a bit more testing on different platforms to see this behavior, and I was left slightly more confused. On MacOS 10.14.6 all of the 4.12.x versions do not exhibit this behavior, and I see the midi messages as expected. Using MacOS 10.15.7, Linux on x86, or Linux on RaspberryPi, those same 4.12.x versions are showing this behavior. Not sure why MacOS 10.14 is special in this regard, but it seems that the behavior I'm seeing is not tied explicitly to the 4.12.3 release. So maybe it's better to re-frame the discussion as the channel re-numbering being expected behavior (there seems to be good reasoning for it in the git history), and how can midi feedback be modified to accommodate that?

[lighthacker2020]

I submitted pull request 1254 after doing a bit more testing of this fix. (Ensuring sending on the correct MIDI channel based on the configured feedback channel, when expected channel is greater than 1 and making sure that values for VC pages greater than 16 work as expected)

[lighthacker2020]

Forgot to supply some updated workspaces I used for testing this. The midi-frame-test workspace is just a couple of single-page button matrixes, which should work for any version of QLC (at least the ones I've tested with in the 4.12 lineage), and could be used as a baseline for the expected MIDI feedback message for a given button. The midi-page-test splits those buttons across multiple pages in a frame, where we'll start to see strange behavior without this patch.