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.
You ain’t the only one. Stick with this and we will produce something viable and useful.
I’ve got a RC300 available if you do want a loopstation but My first beef with it is that you either have it at table level and operate it with your fists or put it on the floor and find yourself bending down to operate controls…
And the effects are very weak because they want you to buy something else to do that sort of thing…
This allows a minimum from which we can start to consider how best to branch this out to the myriad of options that are available.
Most of the discussions weve had on this have tended to tail off as we talk about allocation of functions…
The one switch solution does mean we start from a same point, which in terms of ctrldev means we are building on something solid.
I have added a single-pedal mode to Sooperlooper (dev branch only). An extra controller is added to page 6, “Global Loops” called, “single_pedal” which can be mapped (MIDI learn) to a MIDI CC that sends >63 when pressed and 0 when released (like a sustain pedal). The current functions are:
Press to start recording
Press to stop recording and start playing
Press to start overdubbing
Press to stop overdubbing and continue playing
Double press to pause playback
Press to restart playback from start
Double press and hold (>1.5s) on second press to reset, clear recording and pause
These actions all happen on the currently selected loop / track. With a single loop like when intialised, it acts like a single pedal looper.
I haven’t yet fully tested this and there are improvements to be had, e.g. the double press and hold to clear only operates on release. It may be better to operated whilst held. I would also like to add an undo/redo option, if we can figure out what hopping dance could be used for this! Maybe long single press to undo / redo one stage only? I haven’t considered the other features Sooperlooper has. We may find it more beneficial to implement some other feature in the happy dancing triggers - I implemented the common single-pedal workflow, similar to what @Joe described.
To access this you need to already be on Oram (64-bit) then use the development branch, “feature/sooperlooper-single-pedal-mode”. If there are any brave testers out there, please let me know how we can improve this.
I start wondering what you guys are doing in your spare time. You are so active and responsive.
This is great work. I’d like to test it, but I don’t fully understand where to download/update it.
Did the update, as you described, but I cannot find any new button “Global Loops”.
BTW is there a numbering of pages somewhere displayed, would be great to see, on which page I am
You are so active and responsive.