controller assigns to midinote and not to midiCC

[Jee-Bee]

I want to assign controlls to the Keith Mcmillen Quneo. But the sliders of the quneo send multiple signals at once. The problem is that is mess up with notes and CC data. For example i want to add the master volume to the large horizontal slider. the following signals are send Midi note # 10 - note on off Midi CC # 10 - position midi CC 22 - touch pressure Luppp give assigns automatically to note on/off (i guess first) and ignores the others. Is it possible to force assign to midiCC value.

[harryhaaren]

Hi,

Indeed Luppp today takes the first MIDI event, and uses that as the event type to be bound. I gather that the Queno sends an On/Off first, and then CC's in-between. Hence Luppp will recieve a On/Off, and the CC won't be bound.

I agree it would be nice to be able to have this type of flexibility built into the Luppp bindings. I don't see myself finding time to implement this feature soon - just setting expectations - sorry. Its a good feature request.

[Jee-Bee]

How does Luppp understand what to use note# or CC# (and on which channel)? If i read https://github.com/openAVproductions/openAV-Luppp/blob/master/resources/controllers/akai_apc.ctlr . All data is just a single number.

[harryhaaren]

Correct, the MIDI standard for Note and CC events is 3 bytes, with a specific meaning attached to each. (See MIDI spec summary here; https://www.midi.org/specifications-old/item/table-1-summary-of-midi-message).

The MIDI messages make a lot more sense in Hex encoding - so I advise you learn them that way (not using the decimal like Luppp .ctlr files dump them). With hex encoding, you'll notice that the lowest 4 bits are always for the 16 channels, while the higher nibble identifies a specific type of MIDI message.

So the "status" piece defines the type of message (Note On/Off, CC change etc), and the "data" is the key, or CC change number. The actual "value" of the message (3rd byte) is used at runtime by Luppp's C++ code (not the .ctlr file binding part), and will set the value in the software (eg channel faders).

Does that explaination make more sense?

[Jee-Bee]

Yes with a small bit of testing i understand what you meant. But from user perspective i would prefer in the assignment page to see 3 (or maybe more depends on function) columns:

Channel	type	value(data number in ctrl )	lower limit?	upper limit?

The upper and lower limits would could be cool for custom limits for example for BPM set lower limit on 80 to upper limit 180. etc Probably second feature request