Ability to map MIDI CC to parameters of each SooperLooper channel

[riban-bw]

Is your feature request related to a problem? Please describe. It is currently possible to map MIDI CC to each SooperLooper control (MIDI learn) but this applies to the currently selected channel only. It would be advantageous to be able to assign CC to the controls of each channel individually, e.g. to be able to mute channel 1 separate to channel 2.

Describe the solution you'd like Ability to MIDI learn to each channel's controllers.

Describe alternatives you've considered Learn to dance to select various pedals quickly.

Additional context When the selected channel is changed, the controllers send messages to the selected channel. Maybe the MIDI learn could relate to the selected channel only for controls that are channel specific, i.e.:

• Record
• Overdub
• Multiply
• Replace
• Substitue
• Insert
• Trigger
• Oneshot
• Reverse
• Mute
• Pause
• Direction
• Pitch
• Speed
• Stretch

There are also various sync options that are per-channel although maybe less likely to want to map but should be available for completeness.

Such a solution may be suboptimal if it blocks workflows, e.g. someone may want a single CC for the selected channel.

[jofemodo]

Most of times, you want your MIDI controller rotaries/faders follow the "active chain". But it's true that when you are using something like SooperLooper, you want to have access to SooperLooper all the time, using, for instance, some pads/buttons in your MIDI controoller:

• It could be easily addressed when having per-device MIDI filtering, using a dedicated MIDI controller for SooperLooper.

• If you want to do it with a single MIDI controller, things get funnier. For solving this, we would need assigning several (or ALL) MIDI channels to any chain and refact the MIDI learning code for supporting this. Omni mode (stage) has to be improved so it knows what to do, for instance, when selecting a chain having more than one MIDI channel assigned, etc.

Regards,

[pft]

Sooperlooper itself is capable of loading a configuration file with midi-mappings (*.slb, which is just a text file) with -m <file>, for seemingly everything.

A user can create this via slgui,either via midi-learn or manually.

So if we had a way for sooperlooper in zynthian to load such a file and are able to hook up a midi device to the sooperlooper instance itself, I think we've got ourselves a nice work-around.

[lanmower]

This issue, in general, should be one of the top priorities in my opinion, zynthian is inches away from being a synced looper, I'm willing to spend time to help and also test on this, I have a performance slgui mapping, and a custom tool that produces button lighting by watching sooperlooper so I can see the loop status in hardware, I'd love to get this working in zynthian so that I can finally ditch my sucky default rpi install.

What I can share here is what is important for me as an end user, and what I can provide is some development legwork and testing in various conditions.

To get sooperlooper playing nice we need it to always receive a certain midi device, with all of its channels as they are without modification... Maybe what's missing here is just for the user to add patching instructions somewhere easily, if I could for instance just instruct zynthian to always automatically connect certain things like that instrument to sooperlooper via my midi modification app, then we have a good starting point for testing

Is there a way I can instruct it to always add a few alsa connections somehow by tweaking the config files?

[riban-bw]

This is not how zynthian works. We avoid using processors' own MIDI mapping and instead we implement a consistent mechanism for mapping MIDI CC to processor parameters. We sometimes use a processor's MIDI mapping to access it's parameters but we don't need to with sooperlooper because we access it via OSC.

With Oram you can map a MIDI CC to a processor control with chain mode (only sends CC when chain selected) or you can map it to send on the same MIDI channel. So this may be resolved. Please try.

[riban-bw]

We could add controllers for each loop/channel so that a user may bind MIDI CC to each controller individually but this may remove the ability for a user to use fewer CCs that follow the selected loop.

We could add a mode control that allows different user workflows:

• Follow mode: A single set of controllers act on the currently selected loop. The MIDI binding of each controller acts on the selected loop.
• All mode: A set of controllers for each loop. The MIDI binding of each controller only acts its corresponding loop.

To avoid increasing the quantity of displayed controllers/pages six-fold, we could retarget the controllers based on the mode and the selected loop, e.g. In ALL mode with loop 3 is selected, the record controller would act on loop 3 and its MIDI binding would control loop 3. Selecting loop 2, the record controller would act on loop 2 and its MIDI binding would control loop 2. The MIDI binding to loop 3 continues to act on loop 3. In FOLLOW mode with loop 3 selected, the behaviour would be similar except the same CC would control loop 2 when loop 2 is selected.

The mode control decides whether changing loop selection changes the displayed controls or uses a common set. You could use both external MIDI controller workflows simultaneously if desired by assigning MIDI CC to the common controllers and the individual loop controllers.

This adds a level of complexity to the code and user workflow but the flexibility it provides resolves some conflicts between different user workflows. Once a user has chosen a workflow (which should be carefully documented) then they should be familiar with it but aware that the control exists and can change behaviour.

I won't start work on this until we have some feedback from users. There may be complications other workflows, e.g. single pedal mode (yet to be analysed) so the proposal may prove challenging to implement. Let's decide what is a good next step before investing in development time.

[Joe-wachter]

I like this idea, but I think looping is one area where it will be impossible to please everybody. I exclusively use the single pedal mode because I'm used to other hardware loop pedals and I don't want to dance around, but I recognize that other people might want different pedals or pads for different controls. If your MIDI controller can send multiple messages, you could achieve the effect described above by sending CC for Loop Select and then the desired command.

Maybe it would be helpful to try to emulate the workflows and controls of various popular looping devices, e.g. Boss, Pigtronix, or Electo-Harmonix, or the new Sheeran Looper X, as a way to demonstrate the capabilities and limitations of SooperLooper. There could be a mode selector that changes control behavior (default, Boss, EH, etc) to make SooperLooper a little easier to use for users with hardware looper experience.

[lanmower]

I also like the idea of behavior mimicing... I do also appreciate the way sooperlooper works and how it allows the record to be freely available, it allows you to quickly re-record if there's a mistake without the old school hold the button clearing

of course I'm saying this from the perspective of someone who plugged an apc25 into it, it has too many buttons instead of too few

[pft]

I do like the idea of FOLLOW versus ALL mode, if I understand it correctly. Like having bound a MIDI event to loop 2 while in ALL mode would continue to work on loop 2 when switching to FOLLOW mode.

The single pedal mode does not pose a problem I think - although it may be harder to implement. Binding the control in ALL mode should cause the CC to work on that loop alone.

One thing that I think I mentioned earlier would be very nice to have is if the selected loop control could cycle back to loop 1 (and maybe through -1 for 'all loops' - but that's another question). That way you can have one designated pedal for loop cycling.

@lanmower you may be interested in my nascent osc-based 'driver' to control sooperlooper (https://github.com/pft/sl-apckey25mk2) with akai apc key25 mk2 (if that's what you're talking about). I'm developing it actively, trying it out a lot and revising it still. There may be kinks. Docs are in the works.