Fix sooperlooper per loop binding

[pft]

@riban-bw I think I fixed them all! Controls and monitors are now updated whenever switching loops.

[riban-bw]

Getting there...

Switching "midi cc to selected loop" is confusing. The indication of the mapped CC is not shown but it continues to operate. You have to return to the previous mode to see the mapping.

After mapping single pedal mode whilst "midi cc to selected loop" is disabled, enabling it still sends the CC to the mapped loop. This is confusing. I think we need simpler workflow logic.

Control options menu shows "Unlearn 'single pedal (1)' from None", which doesn't make sense. It should say "Unlearn 'single pedal (1)'" (or similar).

[pft]

Confusing... maybe. But very versatile. For me, it allows me to have dedicated loop-bound pads on my nanopad2, plus a pedal that follows the selected loop.

I thought this was the behaviour you described in zynthian/zynthian-issue-tracking#762 (comment) .

Maybe the description of the toggle could be better. Maybe something along the lines of:

Create MIDI bindings

1. Per loop
2. Following selected

and maybe, if people do want the modes to be exclusive (but I think that would confuse even more):

3. Per loop (ignore follow-bindings)
4. Following selected (ignore per loop bindings)

Or make ignoring the default and add

3. Per loop (allow follow-bindings)
4. Following selected (allow per loop bindings)

By the way, with unlearning I do not get
"Unlearn 'single pedal (1)' from None", I just get "Unlearn 'single pedal (1)'" as expected.

[riban-bw]

Unlearn single pedal from None appears when learned with "midi cc to selected loop" disabled.

We must balance flexibitily with complexity. The current approach is to allow a user to bind a CC to each loop's controls and to filter so that only the currently selected loop's binding acts, if the "midi cc to selected loop" control is enabled. This requires a user to manually learn to multiple loops (we could improve that) but it is obvious to the user what CC is bound to what controller. Hiding such binding is really confusing and undesirable. I don't think we should add this level of complexity to support a workflow to switch between different configurations with the "midi cc to selected loop" controller. Such multiple configs should be held in zs3, e.g. one zs3 maps different CC per loop and another zs3 maps same CC, switched to all loops.

We are trying to implement a flexible solution that suits different users' requirements. Some want a single pedal that may be switched between loops. Others want a pedal per loop. Others want lots of pedals, mapped to individual functions. This is all possible but may require the user to have a little more understanding of how to do what they want.

In my design, I removed the influence of the "midi cc to selected loop" controler from the learning process because of this issue. We could use it as a helper, e.g. to set the binding of other loops or default when loops are added but I currently think your implementation is too challenging for users to understand, even with docs (that they are likely to ignore!) We definitely need the controls to show the current config and not have hidden configs that are only exposed when another control (on a distant page) is changed.

Please reconsider the implementation. Cheers!

[riban-bw]

Don't worry about "...from None". It is a bug in the controller calling zynautoconnect.get_midi_in_devid() and not getting a valid MIDI device name when a CC has been bound to a control in global (not chain) mode.

Regarding switching CC between loops... I think we have two main workflows:

• A single CC is switched between loop controllers, based on the selected loop.
• Multiple CC are directly mapped to each loop controller.

Maybe we could use loop 1's binding for the switched mode, to avoid the need to remap to each control?