SooperLooper feet setup

Hardware
81

Wait :no_mouth:
Since when ?

82

You are both right. You can add only one instance of Sooperlooper at a time but it may be added to any chain including the main chain. It can be positioned anywhere in that chain, in parallel or series with other processors and pre/post fader. This is in Oram.

3 Likes
83

Hi !
We are agree that we can’t have this windows into vnc :
midi_bindings_dial
https://sonosaurus.com/sooperlooper/doc_midi.html
But
 Can we use a .slb file somehow, and load it every time as a preset ?

84

I’m not sure this helps. MIDI CC commands are stripped before reaching processors. They are then mapped or bound to actions or parameters by Zynthian’s MIDI Learning mechanism.

What might be advantageous is to provide a method of configuring CC binding, e.g. setting range, offset, etc. maybe this could be done via a submenu for each control.

85

Thanks for the answer. All of the answers :wink:
What I see here is that we can have a midi command for “loop 3 overdub” that can’t be reach with the actual system.
Right now, I can only make “highlighted loop” commands.

This is my quest lol, as using osc is not so easy in the end. I bet PedalinoMini with one page per loop and one page for general can be a good solution.
I really hope to make a 3d printed pedal station “just” for SooperLooper into Zynthian.





Oh gosh, I have to take a new look to the “driver” thing ! As zynthian talk to SooperLooper, there must be cuia messages ?

1 Like
86

I am quite certain this would not work right now. I changed the python code to read in a midi mapping file with the -m switch, but no midi does actually seem to reach the sooperlooper engine itself.

I know too little of zynthian’s inner MIDI handling to know how to make that happen.

87

No, as described, no MIDI continuous controller (CC) commands reach any processors (including SooperLooper) directly. CC are stripped off then used to modulate parameters that they have been mapped to. This may be via MIDI commands but for SooperLooper we convert the CC to the relevant OSC command. So in the current architecture, SooperLooper’s own MIDI mapping is not (and cannot be) used.

1 Like
88

That said, that may explain why sometimes a midi command is sent but no action is made (yes “mute”, I talk about you), there maybe be a little bug into the translation to osc messages.

89

Hi @riban!
We have a mechanism for passing CC to engines. Access MIDI CC submenĂș from chain options, then check the desired CC and they should reach the chain.
This is not recommended for normal operation because it could cause trouble, specially with some engines like zynaddsubfx, fluid, setbfree, etc.

Regards

2 Likes
90

Yay! I thought so but haven’t yet used this (fairly new) feature so forgot exactly what was available or how to use it. As @jofemodo says, this should not be the normal way to control processors. You should prefer the standard MIDI learn feature.

I can’t reproduce this. If I send a MIDI CC that is learned / mapped / bound to MUTE then it always works. Remember that it only operates on the selected track / loop. (We have discussed how we might allow direct mapping of CC to individual track operations but have not yet figured that out.)

91

For the last sentence, is it not “as easy” as having more parameters after the ones we already have ?
We have the “generals” ones, after that we can have the “individuals” 6 others ones ?
Maybe as an other preset for people who don’t want to see everything.
It will be a lot of screens to go thru for midi mapping but well
 We have new way to use midi controllers

92

That is a lot of screens and parameters:

  • record
  • overdub
  • multiply
  • replace
  • substitute
  • insert
  • trigger
  • oneshot
  • reverse
  • pause
  • mute

for each of (up to) 6 tracks/loops is 66 extra parameters which would span 16 extra pages. It feels clumsy. We may not have to do all of those parameters but you can bet there will be someone who wants the one we miss.

93

Can it be an “other” engine ? “SooperLooper General” and “SooperLooper per channel” ?

Yes it IS a lot of pages. But the idea is not to visit these pages more than once. :sweat_smile:

94

We use to have a simplified 1-channel LV2 version of Sooper looper that can be instantiated several times. Perhaps it could be recovered from the basements.

Regards

1 Like
95

I don’t think that would be particularly beneficial nor solve any issues discussed here. I doubt there are many user workflows that require more than one looper. (How much stage dancing can you do to swap between instances and control them and can your mind cope with that level of complexity?) If that were a real requirement then we could modify the current implementation, e.g. use different OSC ports.

I also don’t see the benefit in having an option to load one with fewer / more parameters exposed. We have engines with many pages of parameters so that isn’t necessarily a limitation.

I do want to challenge how many parameters we need to expose and the best way to do that. Simply adding more pages of controls for parameters that may not exist (e.g. tracks 2-6 when a user only has track 1) and that many (most) users will never need seems inapppropriate, but it may be a pragmatic / simple solution.

1 Like
96

Simple question then : is this last option the easiest to test and see ? :thinking:

97

If you mean, last option is extra instance of SooperLooper in the list of available processors then no, it isn’t the easiest to test. The simplest to implement might be adding lots of extra controls for each track. But simplest does not necessarily mean easy. There is quite a bit of logic and abstraction in the SooperLooper zynthian engine which would require expanding. Maybe a simple, blunt addition might work but there may be more complexity to this. I did add all the possible parameters and commented out ones that are not used but I don’t see the required per-track parameters so maybe I missed them. Some further investigation would be required.

I am no eager to revisit this until there is an actual requirement detailed and discussed. Maybe someone wants to open (or check to see if there is already open) a feature request in the issue tracker.

1 Like
98

Hi,
No I was thinking of exposing the parameters for the 6 tracks.
https://sonosaurus.com/sooperlooper/doc_midi.html
https://sonosaurus.com/sooperlooper/doc_midi_commands.html
Your are right that the documentation is not clear.
We are looking for a “loop number” or “loop index” that is right now set to “all” or “selected” into Zynthian. I guess I won’t know how it’s made until I’ll open a Linux computer and generate a .slb file and open it to see what happen.

The idea is still to make a pedal board dedicated to this tool. I have two projects in mind, and can do a 3d printed inclosure with the right labels.
At first I wanted to use PedalinoMini but there is a restriction about midi over usb, so maybe OpenDeck will be better here https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://shanteacontrols.com/&ved=2ahUKEwjZr47t9fOHAxVTQ6QEHWUWL8kQFnoECBUQAQ&usg=AOvVaw1I45cdkT9sZGNLgt8UWlwu

99

We don’t use slb files. We start a default instance of sooperlooper then set its parameters from a zynthian preset file. We do not drive it with MIDI. All connection is via OSC. SooperLooper is a fantastic, complex, flexible, configurable bit of software. No one is likely to use all of its features. They are there to allow users to chose what suits them. We don’t use MIDI because we use OSC but if you were a user that did not have the OSC client, you may use MIDI. We don’t use many of the looping features because they don’t provide sufficient benefit, e.g. we have other plugins that will do some of these things that frankly, don’t belong in a looper. We try to make it a looper that people can use, rather than a toolkit that you can build your own, bespoke looper from. (We already did that.)

But it is still fairly young. The software has been in zynthian for years but languished unloved for a long time because it wasn’t easy to drive. We flirted with other loopers but each had its issues. When there was an increased intereset in loopers (I blame Ed!) we looked at what was needed to make SL work and put in a lot of effort to make that happen. We told people that it was there and mostly useable and asked them to try it. Our friend @Baggypants did exactly that and gave feedback, recorded video, posted here. It then fell quiet again until recently when interest was reignited (bloody Ed!) and we looked again. This time there was more interest in driving it with feet. How many feet? That depends on the dexterity of the user. Some wanted one pedal. Some wanted many. Most wanted it to perform just like the pedal they had learned to use. So here we are, with a mostly working implementation and a few users, each with opinions of what it should do and how it should do it.

We would probably benefit from documenting how to use it so that supported workflows are better understood. We are finding from our current efforts to document Oram that what is built is not necessarily what we want. Documenting how to use it helps to clarify this, leading to fixes and changes which give better implementation. It also leads to discussions about alternative ideas.

Anyway, to add per-track control will take someone a bit of time. It is best to identify user workflows so that we don’t end up with a million options that few people know how to use and leave it as a scary processor that some will never use due to the apparent mountain of learning they perceive.

1 Like
100

It make sense :thinking:
I will try the other way then, make an hardware that fit this software.
Right now the most difficult is selecting a loop or knowing what loop we are into, without looking at the screen.
But hey
 If we have to count in our head let’s start this way !

Thank you (again !) for the big text, it help avoid translation issue (I guess it’s my fault, I may not use the right words to make my sentence easy to be understood)