Different Midi input issues with sliders

[dobo365]

Hi my friends, here is a simple but strange to understand list of issues with Midi input on sliders.
I think that you will be interested in this one, John ;-) (@dnaldoog)

Found while developing panels for synths with 2 layers using either the same or different Midi channels.
Don't know what to do at this stage...

Tested with 5.3.201
You need to switch to Panel mode back and forth after modifying the properties of the sliders.

• create a new panel
• add a slider with CC 18 and CH 1 (it can be another CC number than 18 of course)
• add a slider with CC 18 and CH 2 with Override Midi Channel = Yes
• add a slider with CC 18 and CH 1
• add a slider with CC 18 and CH 2 with Override Midi Channel = Yes
• set Midi Input channel to 0 (All)
• with your controller, change the value of CC 18 on CH1: only the first slider will move; not the second one. Expected: both should move together
• with your controller, change the value of CC 18 on CH2: both sliders will move. OK!
• copy paste slider CC18 CH1
• copy paste slider CC18 CH2
• with your controller, change the value of CC 18 on CH1: only the first slider will move; not the other ones. Expected: all should move together
• with your controller, change the value of CC 18 on CH2: all three sliders will move. OK!
• change Midi input channel to 1. Still only the first CC 18 CH1 is moving (not OK). None of the CC 18 CH2 are moving (OK)
• change Midi input channel to 2. CC18 CH 1 sliders are not moving (OK). All 3 CC 18 CH2 are moving (OK)
• With Midi input channel still on 2, Set Override Midi Channel = No for the first of the CC 18 CH2. It will not move while the 2 others CC18 CH2 are moving (not OK)
• change Midi input channel to 0. Set Override Midi Channel = Yes for the 3 CC 18 CH 1. Still only the first one is moving but you can see the 2 others making a quick jump then be frozen. Set Override Midi Channel = No. Same behavior
• change Midi input channel to 1. Set Override Midi Channel = Yes for the 3 CC 18 CH 1. Still only the first one is moving but you can see the 2 others making a quick jump then be frozen. Set Override Midi Channel = No. Same behavior

I tried further by adding another set of sliders with CC 19...
Can't figure out the behavior. Don't think it is linked to Override property.

Don't know what it can be...
Some issue in CtrlrMidiInputCompararatorSingle.cpp?

Thx in advance for your help/ideas!

[dnaldoog]

Hi @dobo365

I confirmed all that you said, but I also discovered that on CtrlrX - if you set all the CH2 ccs to Override only one control moves whereas as you said in 5.3.201 all three move! Headwrecking!

Goodweather's cc anomaly_1_0.zip

ccmapping controller_2_0.zip

[dobo365]

Glad you like that one ;-)

I also observed the following:

• so, once we have the 6 sliders whereof mod1 is CC18CH1 and mod2 is CC18CH2, when Midi Input is on CH0, only the first CH1 slider is moving while the 3 CH2 sliders are moving
• now, delete the first CH1 slider (mod1) and it continues to be surprising! Now it is only the first CH2 slider that is moving (instead of the 3 of them) BUT you get all the CH1 sliders moving

I think that this observation should help us to understand where the issue is.
What can we derive?

• the order of creation of sliders has an impact on the scanning of the mods
• the scanning of the mods against the input messages is not correct

Do you know where the code of the scanning is?

[damiensellier]

That's quite a good news, if in 5.3.20 it's working, I'll check the difference in the code compared to what we have now in 5.6+
All the sliders value update comes from the midi stream and how it's managed from CtrlrProcessor.cpp and downward. We just need to follow the stream and see where it stops.

[dobo365]

Thx Damien. I'll go through CtrlrProcessor.cpp to see where the issue can come from.
Pay attention to what John said and what you understood...

I have made all my tests in 5.3.201 and it is there that we have the different issues.
John found that in CtrlrX we have an additional issue (and I didn't test it in CtrlrX) ;-)

[damiensellier]

Oh ok, yeah that's another extra to fix then. It probably comes from the same issue though.