Our plan is to expose more of the innards of Zynthian to remote protocols like OSC This should allow more control and monitoring than the current CUIA interface.
1 Like
Thank you 
For your answers and also for all the work done until now 
thank you for the tip second hand it’s 20 to 30 € here.
1 Like
You’re welcome. I tried to use the nanoPad2 with my feet but it’s not a great experience. I have to get used to that, the pads are a bit small. Anyway, the controller is usefull in other situations.
1 Like
Hi there,
First off, my understanding of and experience with MIDI stinks, so bear with me if I’m talking nonsense.
I am struggling to control sooperlooper with my m-audio axiom 64. Either via the pads (which send Note ON/OFF signals) or via the buttons (which send CC messages).
Ideally I’d like to hit a pad to record and then that same pad to stop recording. Or to hit a pad bound to e.g. overdub to stop recording and start overdub.
The on-screen feedback is currently pretty messy if I want to stop record via overdub: both tallies say they’re on, whilst they are mutually exclusive.
This exclusiveness I think should also be taken into account when deciding how to tackle the MIDI interface. Configuring a device itself to toggle does not do the trick when ‘radio’ toggling it off via another control.
The CC buttons do not let me stop recording, only set recording (or something else) to ON.
By the way, using the 4 buttons on my v4 kit might also suffice, but I cannot find out how to configure those.
On foot pedals: half the time I am recording myself tap dancing, so my feet are already taken, and latching switches are highly difficult to operate in that physical state.
Any pointers are appreciated!
Hi @niels - I think what you want is doable, but the info about how is scattered about the wiki, this forum, and in some cases various individuals.
Here’s one pointer, I hope it helps:
@tunagenes, thanks for your reply.
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:
MAP CH#09 NOFF#35/0:127 => CH#09 CC#35/0:0
This could reduce the velocity linearly:
MAP CH#09 NON#35/0:127 => CH#09 NON#35/0:64
1 Like
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”.
2 Likes
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)?
Depends if you have muting synced to the track or not. It can either instantly mute, or mute the track at the end of the loop.
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 :
21:34:03.015 | RECEIVE | ENDPOINT([::ffff:192.168.0.13]:57296) ADDRESS(/sl/0/hit s:undo) INT32(0)
Hi, try this first if it shows you any communication:
/ping s:return_url s:return_path
If engine is there, it will respond with to the given URL and PATH
with an OSC message with arguments:
s:hosturl s:version i:loopcount
it is from SooperLooper - Documentation :: OSC Interface
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.
1 Like
Oh… I Can only send and not receive but… I’ll give a try tomorrow. Thank you for your feedback !
Sure, it’ll take a little while though.
Turns out I was that bored.
6 Likes
thank you for sharing. But I can’t see any feet in action 
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 
1 Like
Thank you for providing an interesting video of your workflow. Lot of stuff done, with not so much butons pressed in the end.
2 Likes