My MIDI foot pedal only has four switches, so I made a patch in Pure Data to make one switch act like a typical single-pedal hardware looper. With this patch, a single press of the pedal starts the recording, then a second press triggers and sets overdub on, then successive presses toggle between overdub on and off. A double press pauses, then the next press triggers the loop to play again. A triple press erases the loop and resets so the next press records again.
This might also be a good template for using “dumb” controllers with limited programability to do more complex things. Here is a picture of the patch. I will also upload the zip file with the yml file so you can load it up and try it. It worked for me but I’m no expert in any of this so it might not be the best.
Kudos on the nice work and thank you for sharing the yml file. I think this is a great idea, and when combined with the new “Driver” support in Zynthian (assuming that is possible) it becomes even more powerful.
Thanks for the kind words! Right now I’m using the other switches to send Program Change messages to switch ZS3s. I am using a guitar with dual outputs and a synth pickup so the ZS3s let me easily switch to different sounds for layering and improvising on the loops. The biggest advantage, for me, is that when I’m standing at a microphone and playing (and maybe also singing), I can leave my foot in place and not have to dance around the pedals too much.
I am also going to try duplicating or triplicating the PD patch with the other switches to make a true multitrack looper. The “-3” in the OSC codes sends the command to the currently selected loop, but that could be changed to 0,1,2,etc. to directly control each loop. You could also use similar code to map CC sliders (like a nanokontrol or something) to control the volume of each loop independently.
I think I would go red=recording, yellow=overdub, green=playing as that’s what I’m used to on the Boss pedal.
One thing I would like to add but can’t quite figure out is how to get the status from SooperLooper back to Pure Data. In zynthan_engine_sooperlooper.py I see reference to osc_server_url for receiving /get or state commands but I don’t know where those are going. There is no reference to receiving OSC in zynthian_engine_puredata.py. There must be something because the widget gets updated with status.
Now that I’m looking again I see osc_server_port is 1370 in zynthian_gui.py so maybe that’s it? I’m not near my Zynthian right now but I can try it later unless someone has a better idea. Thanks!
I’m also trying to understand how to get OSC back from SooperLooper. I can control SL via OSC sent from processing, but can’t work out how this bit should look:
Have you looked at the python source code for the Zynthian’s native control of sooperlooper? We provide extensive control and monitoring of sooperlooper using OSC. Sooperlooper allows different methods of control and registering for monitoring which are explained in the upstream project 's documentation.
I am interested to know what you want to do with Pure Data that isn’t already implemented in the Zynthian control of Sooperlooper. We spent some time implementing this then asked users to share their experience and feedback so that it can be improved. The feedback received so far has mostly been resolved.
Thanks @riban
I’m trying to get the current tempo from sooperLooper via OSC, but just can’t work out the syntax. Is return_url the network address and return_path the port? It may be that the listener function for incoming OSC isn’t working correctly.
I’m using processing to send OSC rather than pure data - replied to this post as seems to be same issue @Joe is having.
I’ve only recently discovered Zynthian, but hugely impressed by it.
Trying to read the tempo, but can’t get a reply to OSC /get from zynthian. Maybe forming the message wrong?
This is processing code to send OSC:
getLooperTempo = new OscMessage(“/get”) ;
getLooperTempo.add(“tempo”);
getLooperTempo.add(“192.168.1.109”); // path to listen on
getLooperTempo.add(“/got”); // port to listen on
oscP5.send(getLooperTempo, zynthLooper);
These are instructions for SL:
GLOBAL PARAMETERS
/get s:param s:return_url s:retpath
where param is one of:
tempo :: bpm
Thanks, that helped. Working nicely now, though I’ve not yet worked out what SL tempo actually does, as it doesn’t seem to correlate with main tempo. Have managed to set main tempo via OSC as well, though only SooperLooper talks back.
/get requests look like this:
oscP5.send(“/get”, new Object {“tempo”, “osc.udp://192.168.1.109:4560”, “/tempo_reply”}, zynthLooper);
Have put into new thread, as I’m using Processing language, not Pure Data.
@robert What are you asking? I don’t know whether you want to implement it on a Zynthian without PureData, or want to know how to use PureData on Zynthian or how to load the patch provided above or ?
Zynthian supports PureData or Pure Data - see the Wiki.
OK, there is a lot of information online, here are some links that may be helpful on PureData itself:
A chapter from a book “Starting with Pure Data”
A site-page with links to PureData resources:
which includes a link to the excellent-fun book about it:
and the author’s (Miller Puckette) website at ucsd: https://msp.ucsd.edu/
Feel free to ask questions if you get lost, but please try to include enough info so we can tell where you are! And if you simply want to implement @Joe 's patch for your pedal without learning about Pd we might be able to figure it out or get some instructions on how to do it.
Okay, I have now had time to read this thread properly (particularly the first post by @Joe) and watched some videos on single-switch looper workflows. I understand the problem and feel that after a few options:
Modify the Zynthian Sooperlooper implementation to add a controller that gives this workflow, i.e. a single controller that reacts to toggle events and progresses through the workflow: record, play, overdub, etc.
Add a device driver that can be selected on an input to drive the sooperlooper as required.
Use internal (like pure data) or external (like MIDI processor) to manipulate current Sooperlooper implementation.
Each has its pros and cons but broadly the coding solution to all is similar.
Modifying the zyngine world require someone to do this work. It may be the most robust solution for to the direct binding of control and monitoring.
The driver option may need modification to the driver code which currently binds a USB input globally to the driver, i.e. all MIDI data from that input is processed. (There was a modification recently that may resolve this.) It would require someone to write the driver.
I wonder whether users may complain that their preferred workflow isn’t implemented by the logic, e.g. @Joe implemented a different workflow to the one I saw demonstrated by a hardware pedal. We could (should) just designed one and day, “This is how we doit”!
Thanks for picking this up. If i’m the only one, it would be better just tell me to shut up and buy a Boss loopstation. But I think I found more posts with similar questions.
Another solution might be to add a programmable midi plugin. That takes a midi CC command as an input and toggles between 3 different output commands at its output. I’d like to make it, but I don’t have a clue where to start programming midi plugins.
I think a ctrldev driver is the best solution. A ctrldev driver that could be loaded into any MIDI device, including DIN-5 MIDI. It would capture a single CC (CC-64, but ideally it should be configurable), and implement the single-switch workflow.
This is a easy solution that have the advantage of having multiple drivers with alternate implementations, so everybody would be happy.
We could have more elaborated drivers for specific devices, like the FB1010, implementing highly customized workflows, etc.
