MIDI filtering does not seem to cut it in this case.
Enabling a toggling behaviour for a single CC is not possible. For that you’d need it to remember the last signal for the same CC. MIDI filtering rules do not offer that.
What I am now contemplating is getting e.g. binding CC 25 to record, CC 24 to overdub, CC 23 to multiply and so forth (where the buttons always send the value of 127), and mapping CC 20 (with value 127) to multiple other CC’s, namely CC 23 trough 25 (or more) a value of 0.
That way, I’d have a single button to set SooperLooper’s state to OFF (whatever it was doing), and dedicated other buttons to start record/overdub/multiply/replace/substitute/insert.
But mapping specific CC values to to other values seems impossible, and I do not know whether n:m mapping is at all possible with MIDI filtering rules.
Ok, I’ve now got the pressure pads set up in latching mode. They send CC with a value of 127 when pressed, a value of 0 when released.
But I still haven’t found a way to do something momentary. I thought setting up the trigger pads as note on/off with velocity lock would work, but the axiom only allows me to send a value of 1, not zero, so filtering rules for NoteOFF=>CC translate to a CC command with value 1 (or higher), leaving no way to turn it off.
What I would love is for the MIDI filtering rules to be able also to map values.
Something like the following could map any Note OFF value for channel 10, note 35 to a CC 35 message with a value of 0:
I posted this in another sooperlooper thread but it relates to the discussion here so here I go, cross posting…
Sooperlooper does not really have a stop state so you just need to tell it what state to change to. You can assign pedals that fire MIDI CC with value > 0 for each state, e.g.
CC 102: record
CC 103: overdub
CC 104: replace
CC 105: trigger
CC 106: mute
CC 107: pause
CC 108 (value 0): undo
CC 108 (value >0): redo
Then you can start a recording by sending CC 102 and end the recording and start loop playback by sending CC 105. To overdub the current loop send CC 103 and to replace the current loop send CC 104. Send CC 105 to resume playback at any time. Sending CC 106 will continue to play the loop but silence output whilst sending CC 107 will pause playback (the closest thing to stop in sooperlooper).
So you don’t need toggle foot switches. You just need a pedal that sends one CC message when pressed and nothing when released. If you have a pedal that sends a CC when released too then you could use it as a “record whilst pressed”.
Thanks @riban, I tried this out; with my setup I can now Record w/ 102 and end it with Trigger. But if you quit overdub (103) with Trigger, the loop is reset at the beginning, instead of continuing to play the remainder of the loop.
Just bought a nanopad2 so at least I have the option of toggling CC (sadly enough the nanopad2 is dumbed down in configuration options). This works better for some controls, not for others.
By the way, I noticed that muting/unmuting does via not always work. It does most of the time, but also fails quite often. I see the midi CC messages (CC 109 (have the CC numbers changed?) with a value of 127 for on, and 0 for off) coming in the MIDI log, but SooperLooper does not always mute/unmute. I do not know where in the chain of events the cause of this might be (MIDI routing, zynthian_engine_sooperlooper.py, the OSC-messaging, SooperLooper itself)?
Getting a bit frustrated I am taking a look at using SooperLooper’s internal MIDI mapping, which seems to offer greater flexibility. Such as being able to map a MIDI event to ‘next loop’. Is there any we might be able to let (all) MIDI events reach SooperLooper itself (and provide our own mapping via the -m command line switch – prepared on a computer)?
Aren’t they on/off states? I start a recording with CC102 and then stop it with CC102, which also triggers the loop. Then when I overdub I enable the overdub with CC103 and disable it with CC103. I use a latching button which presumably sends ON/OFF for each CC.
Or am I confusing it with the zynthian MIDI learn UI?
Hello !
As you use OSC for SooperLooper and i’ve just made a protoboard to do that, do you have the possibility to run Protokol | hexler.net Protokol and snif what happen ?
I see my messages, but they do nothing. It should be a typo or so but i don’t find what i’m doing wrong :
I can’t find the my notes, but I feel like it must start with the /ping command because it acts as a registration and tells where sooperlooper should send responses.
Hi !
So it seem that’s not a “ping” problem. I may miss something dumb.
That say, that was why i’ve asked to check what the software “Protokol” see from your perspective… to compare with what i have.
You don’t know how much I would like to have a day with a long time user of Zynthian, talking and testing at home
Thank you. Having channel selector buttons, and channel mute buttons would be nicer than poking at the screen. But otherwise I’m happy with my workflow.
Thanks so much for that @Baggypants
All driven from the touchscreen… Which buttons would you allocate if you had an substantial switchbox and what is the minimum number you could get away with to do this?
I’ll quickly rework my controller to send osc commands for sooperlooper tonight and let you know.
I could not install the mentioned program for monitoring osc commands under Windows. I might try the mobile version, but I don’t know if I’ll be able to track midi and osc messages all over my network. For midi signal processing I use BomeBox, two raspberry pi 4 and one PC with Bome Network midi. I have about 7 controllers on it, 6 synthesizers, one of which is a Zynthian with rtp-midi. And I still have two more Zynthians disassembled and ready to be installed in the box. But I always change something in the layout and connection I’m also severely affected by zynthian affection.
I’m also severely affected by zynthian affection.