Q Light Controller+

Hi,

I received an Akai APC20 MIDI controller and tried it on QLC+. The funny thing is that the buttons are divided over several MIDI channels. So in the Inputs/Outputs mapping I set the MIDI Channel setting to 1 - 16. Now every button I press is received by QLC+. The problem is that there is no way to distinct one button from another if it is on the same MIDI channel.
Did I miss something, or is this currently not possible?
And if it is not possible, where in the code of the QLC+ should it be added do you think?
I am thinking about sending the channel number from the MIDI plugin up to the rest of QLC+.

Here is a link to the mapping
http://www.akaipro.com/apc40map

Thanks
Joep

Hi,

the channel number is currently more or less ignored - you can specify that QLC+ will listen on a specific channel; if you specify "any" channel, all the messages will be merged.

Current code uses a fixed mapping - CC messages are mapped to addresses 0-127, note on/off messages to 128-256, etc., totalling somewhere around 380 addresses (see [here](https://github.com/mcallegari/qlcplus/b ... col.h#L103) and [here](https://github.com/mcallegari/qlcplus/b ... ol.cpp#L31)). It allows for very simple mapping in input profiles - when you give the DMX address, everything else is clear.

If you just add channel number, you will multiply these 380 by 16, and that is clearly over limit of 512 addresses.

So the goal is to allow controls on different channels; in the same time, it would be great to allow input profiles that occupy just one channel, and the channel is defined
outside input profile. E.g. classic MIDI keyboard sends all notes on one channel, and you can select the channel in the keyboard setup.

In my opinion, what has to be done here is:
- remove MidiDevice::mode()
- keep MidiDevice::midiChannel()
- add more attributes to tag in input profiles:
- midich (0-15) - this can be omitted
- message (note, control change, program change, pitch bend)
- value (0-127, or 0-16383 for 14bit messages)
- change the data structures and processing accordingly
- update the profiles
- update/write unit tests

Ok, it's a bit harder: QLCInputProfile (description of the external device) operates a level above (MIDI) plugins, i.e. it doesn't know about MIDI, it knows only DMX addresses. That's why fixed DMX-MIDI mapping is used - the input profiles are in fact independent on plugins.

Also, there is the "learn" function in GUI - move a control and the GUI widget wil use it. The proposed change could require two-step learn process: first, make the input profile by learning MIDI messages, then configure GUI by learning DMX addresses. It may get confusing to the user.

What we could do is use the two-step learning and setup a default mapping in the new MIDI message mapping. This default mapping should then behave the same as the fixed mapping we have currently. This way nobody gets hurt but we have a more advanced option to map controllers.

On the other hand, why does the mapping to dmx happen in the MIDI plugin? Isn't it better to do this in the QLCInputProfile?

Current design provides an abstraction layer and thus you don't need QLCMidiInputProfile, QLCOscInputProfile, etc.

There's also very small difference between input plugin with feedback and input/output plugin. That way you can use external DMX console as remote controller,
or a MIDI device to run lights (e.g. MIDI2DMX convertor). It's pretty flexible in a way (though not as flexible in another...)

Ok, I'm back from my holiday and ready to play with QLC+ again
How do you feel about my suggestion to implement the two-step setup with a default mapping?
Shall I create this functionality in a fork?

I think I've got a simpler solution.
Those 2-3 lines of code that I like a lot

Right now a plugin channel is represented by a 32bit variable. I decided to use the MSB 16bit for pagination.
So, there are 16 bits to be used, thus no need to implement super-complicated solutions.
To map MIDI channels you just need 4 bits (let's say the MSB) and you still have 12 bits for all the rest of MIDI signalling. (I guess 380 fits in 4096 )

In other words: cccc dddd dddd dddd
Where c = MIDI channel and d = MIDI data.
This, of course, just for the MIDI OMNI mode. When selecting a specific MIDI channel, bitmask is not needed.

And by the way, the selected MIDI channel is not ignored at all:
https://github.com/mcallegari/qlcplus/b ... ol.cpp#L44

Here's a patch. Can you test it an tell me if it works with your APC thingy ?

Nice!

I tested the patch with my APC20.
With the 1-16 MIDI channel setting I can now use the buttons from the other channels as well.

I'll do some more testing this afternoon with a real DMX circuit attached.
Oh and I'll try to see if I can get the feedback working to let the APC show which button is active.

Ok, that was a quick patch.
Feedbacks are another story and need to be changed according to the omni mode behaviour. If you confirm the patch works OK, tonight I will fix feedbacks too.

Thanks

Yep, tested with it this afternoon and all buttons seem to work fine.
Feedback would be awesome.

I did some testing with feedback and the APC20 in 1channel mode.
In the input/output tab I enabled input and feedback on the APC20.
I tried to set the input and output mode to Note Velocity and also tried Control Change.

To debug and see whats going on, I run Midi monitor (http://www.snoize.com/MIDIMonitor/).
I confirmed the APC20 is working by sending midi notes from Bomes Midi translator. I can set the color of the buttons with midi notes.

Now when I press a button on the APC20, or I click the corresponding button in the virtual console, I expect QLC+ to resend that midi note to the APC20. This would make the led in the button go on.
Unfortunately this is not happening.
Midi monitor show's no outgoing midi signals from QLC+.

Did I miss something?

I've had a deeper look at the code that handles feedbacks.
I think it needs a major change to handle all the cases.
Of course it'll need some time.

I might need your help when it comes the moment to test feedbacks with the APC device.

I've done some changes to the feedback mechanism and created a branch on GIT named "midi_omni".

@Joep: if you test it please let me know the results. I'm completely blind here cause I have no MIDI devices supporting feedbacks

I checked the new branch and it works!
Wohoo!

There was one small bug in it for MacOS compilation:
coremidioutputdevice.cpp row 200 should be a return instead of a break.

There are some minor nice to haves, but I can see if I can fix those myself:
- Setting the controller in the right mode (ableton mode2) when QLC+ starts.
- Choosing the colour of the leds.

Thanks for your time and quick patches.

I did some tests for the controller mode (a sysex Midi message).
The Midi message to set the APC in ableton mode2 is F0 47 00 7B 60 00 04 41 09 00 05 F7.
I added a method to CoreMidiOutputDevice which allows to send a given Midi message to the controller.
I now hardcoded a call to this method in the CoreMidiOutputDevice::open() method and this works fine.
Now I am thinking about adding a field to the input profile where a Midi message can be set.
This Midi message will be send to the controller when it is being opened.

What do you think about this plan?

Hi, sorry for the delay.
Why in the input profile ?
This is something related to the MIDI plugin only, so I'd rather prefer to improve the MIDI configuration dialog.

Well, I thought of the init message as something related to the device your using. When this is embedded in the profile config, a user can plug in it's APC20 and it would work out of the box.
When the setting is added to the midi configuration dialog, every user thas is using the APC must know the initialization midi message and add it to the midi config.

Adding it to the midi settings would be more simpel from a programming perspective I gues

As far as I know, OSC and ArtNet don't have init codes, nor they use Sysex.

"every user thas is using the APC must know the initialization midi message and add it to the midi config" --> that's why presets exist
They'll just need to tick the preset they need, or (advanced) enter a custom one.

Dude, keep it simple ! You always want to walk the hardest way

I'd know how to implement this, but right now my time goes to something much bigger...you'll see

"that's why presets exist "
Do you mean there are presets in other parts of QLC+?
Of do you mean I'd have to make something like a preset with hardcoded init messages?

"my time goes to something much bigger"
Yeah, I did see some interesting commits in a new branch last week.
It just keeps getting better and better