SooperLooper - In Testing

Bold press an encoder in the control view to access controller options.

Right. I guess this is only on v5.

Because on v4 there are other actions taken on bold press for each encoder in control view.

Is there another way to access the controller options on v4?

Enter midi-learning and when the ?? is shown, press the controller.

Regards

Thanks. I must be doing something wrong:

  1. On the control view, I press LEARN/SHOT to enter midi learn. Two question marks beneath each parameter (??).
  2. Short-pressing LEARN/SHOT then enters Global midi binding.
  3. Bold-pressing LEARN/SHOT does nothing.
  4. Short SELECT executes Select (control param paging)
  5. Bold SELECT invokes Chain Options (nice by the way, didn’t know this yet

and so on. In global midi learning mode (??#??) there is similar behaviour.

I am on Vangelis though currently. If this is the right way, I can try and switch to Oram.

No, stick on vangelis. This is a regression. I am fixing it now…

This should be fixed now in vangelis.

[Edit] If you have a touchscreen or mouse (e.g. VNC) you can tap/click on the control to toggle MIDI learn and bold tap/click to access MIDI learn options.

Thanks. It now works. It did not at first. Reverted to Oram, didn’t work either, then back to Vangelis. On which I got the infamous error screen. Not even webconf worked. Then I ssh’ed into my zynthian and performed a zynthian_update.sh.

That got me a working system again, with momentary/latch options as described.

For a device sending two values on press and release have to do press twice. Sustain pedal presumably works flaky because it sends multiple values along the way.

When I have time, I’ll try some filtering and or configuration of my midi devices.

I have pushed some changes to vangelis that should provide more flexible sooperlooper MIDI integration.

  • Each loop may have its control parameters bound to different MIDI CC. This allows to control each loop individually if required. You can still bind the same CC to all loops if you want.
  • A new control allows switching beween:
    • MIDI CC controls all parameters bound to the CC.
    • MIDI CC controls the parameters of the selected loop only. (Default behaviour which provides similar functionality as previous implementation.)
  • Removed default MIDI binding, i.e. you must now MIDI learn each control rather than depend on CC 101, 102, etc.)
  • Fixed issue 1285 (you are welcome - @Baggypants).

One thing that I would quite like but have not yet implemented is the ability to MIDI learn to all loops and/or for new loops to inherit MIDI learn from other loops, e.g. loop 1. I think this may be advantageous sometimes to some users so want to find a way to enable this but I don’t want more controllers which gets confusing. Maybe the state of the “midi cc to selected loop” could decide this?

Please test to ensure this hasn’t caused any regression or other adverse effect. Please provide feedback on the implementation to assist with improving sooperlooper integration.

4 Likes

Pretty nice. I found two things:

  1. Single-pedal mode always follows the selected loop. I’d like to be able to bind this to various loops. Especially for the record_or_overdub part.
  2. When changing the selected loop from outside of zynthian (via osc), the binding mechanism still binds to the old loop, even though for all other intents and purposes changing the selected loop outside of zynthian just works (tallies and controlling parameters).
1 Like

I may be missing something obvious. How are you going to bind a single pedal to trigger different loops?

By having multiple pedals or buttons.

The ‘single’ in ‘single pedal’ refers more (well, in my mind it does) to a single CC for multiple actions, not to a a single loop.

To contrast it with multiple pedals (or buttons in my set-up) for rec vs overdub vs pause vs undo_all.

I looked at the code, and I understand it is not implemented (yet). It’s another beast entirely, but it would be awesome.

The per-loop MIDI binding is only done for loop actions like record, overdub, etc. I can look at implementing this for single pedal mode so that different pedals can each act on different loops. Add a feature request to issue tracker.

I tested this and had some troubles:

I was able to assign different CCs to Record on different loops, but I could not activate record on the second loop without switching to that loop first. Also, to assign CCs to different loops I had to use the loop selector control, not the touchscreen. I was having trouble getting Pause to work as well; I think this was also related to using the touch screen rather than loop selector control.

It would be nice to have this on the “Wet” control so you can balance the volume of different loops.

The single pedal mode for multiple loops would be great too, if that’s possible.

Are the gray boxes with words at the top of the SooperLooper GUI meant to be buttons? The words move slightly when touched but they don’t seem to do anything.

Done! Implement per-loop MIDI binding of single pedal mode in sooperlooper · Issue #1294 · zynthian/zynthian-issue-tracking · GitHub

@riban I fixed the issues encountered by @joe and me in Fix sooperlooper per-loop bindings by pft · Pull Request #511 · zynthian/zynthian-ui · GitHub . Please review!

1 Like

I have a pedalboard arriving soon and very much look forward to test / play with these features :smiley:

Thanks for the PR. It may take me a while to check it due to other commitments. I will add comments to the PR as necessary and merge if it is all okay.

Thanks for your comments. I commented on them again.

I don’t know enough about the architecture to see how we could neatly cut this more loose from UI code. So if you’ve got some good pointers please share them (or do accept a speck of dirt).

I’d love to move forward with this.

Hi @niels!

Sorry for the delay. There are lots of other things happening which have demanded my time more urgently.

This is an area of code that we have not yet separated UI from core / backend code. We have started working on that and use of signals seems to be how we may resolve this kind of required integration. What I want to avoid is adding new functionality that tightly binds UI & logic whilst we are trying to seperate these. (We consider MVP but this may not be the exact model we follow.) Hence, I would like to take time to consider the PR (which mostly looks okay). I will try to find time to do so before the next point release merge but that might not be possible.

Hi @riban,

Thanks for your reply. I guess you mean MVC?

1 Like