Cool, thanks for looking at this!
I’d like to advocate for the re-evaluation of that mindset, zynthian is clearly much more useful if you can send multiple untranslated midi channels through a chain, and ‘not supporting sooperlooper that way’ or ‘having past discussions about it’ doesn’t change that.
On the subject of zynthian support, since zynthian doesn’t yet allow note based mapping (also a future must-have), and the sooperlooper controls were made naively, they dont resemble the type of setup that loopers use, or what you can get out of sooperlooper, and that’s the whole point of mapping it via slgui, which is easily supported if you dont force distructive changes to the midi information before it reaches a chain. Think about it this way: zynthian is supposed to be versatile, some setups require multiple midi channels for tha chain, simple as that.
As for the roadmap for sooperlooper, I do have the long term goal of correcting the zynthian code for that, but that’s not the solution to this problem, especially since zynthian still has a super long way to go for mapping and controller support, and that there is a ton of work to do to fix the sooperlooper gui (done by someone like me who actually uses it for loop performances) since the workflow is currently based on looper selection instead of parallel controls, so I intend to set it up now and fix it later, if I can’t even produce a chain that both things respond to their own controls, then dont have a meaningful platform as a programmer and a pretty serious loop musician to contribute workflow optimizations from, my regular linux setup is competitive with commercial loopers and takes 30 minutes to set up, with any luck I can panelbeat zynthian into behaving like everything else and not forcing midi changes down its lines, and then I can start the project that will eventually make zynthian competitive as a loop station.
Once all of that’s in place, it needs effect chains, those effect chains need to be permanent and global, some of the needed functionality I’ve managed to set up on an older zynthian and still have a fair confidence in being able to do, like a permanent input fx chain thats recorded to the loopers and a permenent output fx chain, some things it couldn’t do, like mapping notes as on/off triggers, but I could get by without that limping along, I havent yet managed to get loopback working for re-recording very seamlessly but I think I managed some experiments using one of my 8 knobs for its volume, that’s pretty much what everything has that’s not more than 10 years old, input fx, output fx and loopback, those are things i’m willing to start without and get working slowly later on, but the basic principal of being able to set up and map the plugins using their built in functionality is how you scaffold everything you need down the line, and telling people that they shouldn’t be using what the plugin can do because the chain has hard-coding to change the incoming midi channel just doesnt make sense to me.
It stands to reason that zynthian should be able to do at least with weeks of tweaking what you can do in 15 minutes with carla
These could be some of the most important potential workflows for zynthian, I see no reason to hard code stuff that makes the obvious impossible.
And by the way, I am pretty aware of the 14 tickets that are already open for sooperlooper, that’s exaclty why I’m working around it , because users ask for a small bug fix in 2022 and end of 2024 its unresolved, sooperlooper isn’t a development priority, but zynthian itself is, so lets get zynthian working the way its supposed to, first we need to evaluate raw global midi inputs for channels, if it is still possible in the current version by working around with a midi only channel and routing, then great, we can fix that easily by just adding another menu option instead of forcing users to ask on the forum and then learn to do that, if that’s no longer possible then its a regression and some of the older mechanisms might have to be rescued or rewritten from previous versions to make it available
I’m first tackling an outstanding of problem how the new oram doesn’t boot without a screen plugged in the way it used to, it no longer works at all with no screen, which is another regression, once that issue is out of the way, I’ll test the midi only channel mechanism, right now its insanely impracticall to try and stretch my pi between its display and my music setup so it adds another hour of practical effort to tests every time, so wont have time this week to try that with a physical display, I’m putting my money on getting headless working again then I’ll spearhead this effort and document what I can find out.
(I’ve tried to shop around but theres no micro hdmi dummies in my country)
Trust me, there are reasons for every line of code. We don’t code things without a reason. 
I understand you want things to work as you are used to. Most of time, everybody want this. But zynthian is not a PC and many things work in a different way. We did a huge work to integrate sooperlooper, and although it’s not perfect and it will be improved, you should try to understand how it works in zynthian before asking to change everything because you don’t want to change.
Anyway, i still don’t fully understand your workflow. Could you share a scheme / drawing so we can better understand what do you want to achieve?
Uhmmmm! Did you try the one-pedal interface? I think this is a very popular interface amid loopers. Indeed it was “copied” from some popular commercial looper.
Perhaps when you say “loopers” you mean “yourself”? (joking! no bitterness at all!! )
All the best!
2 Likes
Can you explain what “carla” means in this context, maybe provide a link?
I tried looking with Google, of course “carla” by itself is hopeless as a search term, and, it turns out, there are an amazing number of people named Carla Looper.
1 Like
As mentioned by @jofemodo, very little of what we do is naive. We spend considerable amount of time considering and developing things. Please ensure you read this thread to understand the extensive discussion here in the forum during sooperlooper integration and testing. You will see that initially it was only really @Baggypants who gave real-life usage feedback. As a musician, zynthian user and developer, I can only develop what I think users want based on user feedback (and also, what I want - which can often be the impetus to start a development). Sooperlooper integration with zynthian certainly has room for improvement but redeisgning the whole of zynthian to make one user’s workflow work is not usually within our roadmap!
Regarding how chains handle MIDI input, like you, I too was initially confused. If I start jack then start a plugin then route MIDI and audio manually in jack I can do all sorts of wonderful things but… I will need more plugins to do some things and some of those plugins don’t exist… so I will have to write them… oh wait! zynthian exists and it does all this magic. Not the way I thought of doing it but it does it. So, do I carry on climbing the massive mountain to build the system I want the way I want it, or do I adapt and adopt the zynthian way? I chose the latter then, with words and actions I helped to shape it. Today’s zynthian is very different to the one that lured me in. Many people have been instrumental in shaping it and the journey is not over. We see out utopia, just beyond those infinite false summits…
Please do keep providing ideas and get engaged with development if you can but avoid heading down rabbit holes of major redesign without consulting our oracle (@jofemodo). He may pour concrete down the hole… he has done it before.
3 Likes
We are surrounded by insurmountable opportunities!
I think @lanmower means this Carla:
It’s a fantastic plugin host from the master of coders, @falkTX.
BTW, if you go back in the zynthian repos (until 2017 or so), you will find i integrated Carla with zynthian at the very beginning.
The best,
2 Likes
I normally come around, at this point, and reference this
Bare with me as a loop artist, and I promise me you’ll see the value of setting it up the way I intend to make it work, I’ve got loads of experience setting up loop stations, making custom ones, building them out of daws, and I also have a hardware loop station, the RC-505 mk2, and use it live all the time and push the boundaries of what it can do to this day, I’m a loop artist and I understand the effective workflows, where it goes wrong, and how to fly it blind. I feel like the loop station potential of zynthian is a massively unexplored area for it, and I can help tow the line
All I need is to get my setup working to some degree so that I can use it in the meantime with zynthian, I don’t really have the time and mental bandwidth to juggle updating zynthian and my own custom linux, so I want to pour my time into zynthian rather than my own custom stuff, once I can get the pi to work without a display plugged in, I can move on to the first step of trying it with a midi-only chain, and seeing if I can get that to work as expected.
The benefit to the community is zynthian would get some progress towards becoming a competitive loop station on top of what it already does, the benefit to me is I dont have to compile rt kernel myself and get to use vitalium without fiddling with the opengl incompatibilities
yeah there we go I mean if you want me to make content, if we can get zynthian to work then all my performances would be zynthian performances
this was this weekend, mininova/RC505 mk2 (with ableton over my own live link to hardware midi bridge)
microkorg/RC505 mk2
here the guy standing is using my custom carla setup with sooperlooper, the midi controller lights work in the daylight, a screen would never work there
Dual custom loopers on Ableton, Mininova, Microkorg and the RC 505 mk2 together
I’d like my future videos to all be zynthian videos
2 Likes
yeah I’ve read the thread before posting, and the github issues, and still disagree, and every looper producing company would also disagree, they disagree so much that they put millions of dollars into making loopers have the layout they have.
looping requires split second time saving so that you can get all the actions you need to do into all the incredibly short loops that you’re recording, and you can’t leave people waiting with loops just repeating in between recordings while you select tracks or even check which track is selected, there is an established workflow for doing it and that is that different switches record different loops, sooperlooper supports this as a workflow, but the design that’s used in zynthian requires the screen to operate and doesn’t provide the functionality that loopers provide, even though its available, I’m happy to set up an artist friendly gui for zynthian, but first I’d need to get my gig-gear working so that I can experiment with the platform and design a practical zynthian based gui module for sooperlooper, since the one that’s in place really wont cut it no matter how thoughtful we describe its author to be in this thread, or how long the 180 posts of past discussion was.
The thing is this isn’t a matter of doing something the ‘zynthian way’ or not here, zynthian needs to get a decent way to do this, and I can develop that over time, zynthian has a very incomplete sooperlooper module, and is currently losing its multi channel midi support, if its not for those two factors, it would be a high quality loop station, no question about it, I understand how zynthian works, and I know the zynthian way to do things, I’ve used an earlier version of oram for 7 months, and used it on stage for about 8 performances, I went over to my own custom linux installation because there just was some things that zynthian wouldn’t do, and I am also doing what you did, I’m going back to zynthian and am willing to do some of the legwork required to make everything work, but it should still be able to take multiple midi channels for chains, and it should still be able to handle custom mappings if plugins support it, that’s a no-brainer.
Hi @lanmower !
Explain your workflow with your typical setup with all the detail you can.
Once we understand your workflow we can think of how to implement it zynthian, what need to be changed, etc. Please, in order to keep your explanation clean and focus in what is important, avoid implementation details. Just the bare workflow!
Thanks
The number of emotional discussions that resolve if people speak of us not I …
You have a very direct approach and a form of presentation that is familiar to many people that have considerable experience of working within media environments. With a successful outcome it is never difficult to find who was responsible because everybody claims a part of it.
This community, for that is what it is, came together as a result of several electronically minded individuals all realising they were trying to do the same thing with a raspberry Pi and a soundcard. My own efforts are lost in the midsts of time but my first Pi audio device was back in well, it’s a long time ago and involved a Pi2B. It worked but served up several more issues. Zynthian was doing it, the code was open-source and it had solved many of the issues the early exploarions had taught me were important. It didn’t actually have an audio in back then, indeed I reckon I was probably one of the first to get an audio injector to actually do something in that regard.
and on and on. Development is a spiraling process, we rotate around the various issues as they emerge, firefighting on occasion and every new version we pick up a slightly different communal context. This drives those who develop in specific directions and the issues aren’t entirely addressed but we frequently get close enough to allow the original issue to be resolved and so it goes on.
Looping has come up several times and sooperlooper has become the most attended implementation thro’ some fairly involved discussion. We do have a graphical background, certainly, but that is down to what was originally a graphic and encoder interface to various audio engines. It the central point where all zynthian goodness comes together.
You can run devices headless, indeed I’ve got a cajon that’s spent some considerable time in fields doing precisely that. driven only by a set of footswitches driving zs3 events. It works.
The looping front end has been a victim of the very flexibility we have tried to place within the infrastructure, how best to set up a simple instance that
1/ Does what one wants a looper to do
2/ Doesn’t require a specially built environment to contain it.
Getting the required kit together to build a default for such, comes up every one in a while as the growing development snake curls up and covers more ground.
So, please, don’t belittle effort that has gone before. If you are a musician of the level you claim, you will have met many people along the way and I’ve met few successful musicians ( and I have worked with quite a few) that decry anyone’s efforts and sadly you do seem to have done a bit of that. We are pretty tough but the conversations are generally built on consensus and a certain acceptance that what we have done so far is heading in the direction we all support.
Input is always welcome, and I suspect that the rendering of a use able component for looping will appear, at the right time. That is always the joy of open source projects, We are not driven by looper 2025 or namm or NAB or any one of the big shows, we’ve all traveled round in pursuit of technolofy new… We simply set our own agenda, ruled over by Jofe, cos it was him what did it first.
So please join in a help. Any information you require will be forthcoming, any successful input you make will be applauded, I used to work on Ubuntu studio when that was such a thing. Chasing and maintaining distributions and libraries was a pain in the back side that stopped me making music and made me concentrate on code, but perhaps that’s where my satisfaction lay at the time.
However I was out at an open mike last night talking about the looping potential of the RC505 one of the performer owned and he was absolutely bowled over I could simply plug up a zynth and a tablet and read all the MIDI messages it was sending out to his Roland pedal board, without a PC or MAC in sight.
The original marketing slogan was the Swiss Army knife of Music. IT’s grown a bit since then, and it’s new problems are all success ones…
Really liked the Audio you posted by the way…
Chris@wyleu.
3 Likes
Don’t you bozos go breaking my looper. I’ll be pissed.
3 Likes
Now what see what you’ve done, you’ve woken something from deep in the mines…
My setup takes advantage of the ability to map sooperlooper at the moment, so I need midi notes to pass through as their original channels to sooperlooper, and sooperloopers channels not to get translated for other instruments to play, so that the midi instruments dont play sooperloopers instruction but sooperlooper responds to them (this was already explained 3 times above in great detail) now I mean I can probably go try and build a custom program to try and connect some part of the jack or alsa stack to another to work around zynthian removing this ability, but the need for it should be a no-brainer, you’re going to have different things listen to different channels in the stack, you can’t force people to use translated messages, even though the creature comforts are nice, they should be easy to provide bypassed.
but first, I need to get zynthian to actually work again, the new oram doesn’t boot without a screen anymore on pi5, so that has to be fixed first before I can try and implement the rest.
The expected behavior is the same as any daw: be able to take on any midi channel, or all midi channels, into an instrument, and have them not be modified before they enter the chain.
This will get me started, since I need to use the custom mapping abilities of the tools themselves to get started, and then I can later on work on replacing the zynthian gui for sooperlooper with something more usable.
If you really need to know how a looper works, look at any looper tutorial video, they dont work the way zynthian has implemented it, you work with parallel channels, you need parallel control, its split-second work with extremely fast timing, you don’t design in extra hurdles to hold yourself back if you design a looper, it needs at least record/play and stop is available at all times to the end user, for all channels at the same time, so that would be the minimal change that’s required for zynthians built-in gui to work properly with sooperlooper, except that to get it to work with all controllers properly it also needs to be ablet o train on notes, and on other styles of cc inputs, since not all controllers are configurable, I’m happy to roll that out down the line if I’m using it, but zynthian needs to work first which means untranslated midi because some tools support mapping and always will support mapping (I’ll test the workaround for midi only channels, if I remember correctly it had an issue I think you had to select the track, but I’ll check, after the not booting issue has been cleared)
apart from that there’s a stack of essentially global effects that I use, some sit on the input and some on the output, and I add in loopback capabilities, but we’ll get to that later, ideally it needs b.oops with sync because that’s the only linux tool that can replace turnado (if you want to see turnado in action watch any beardyman) but there are some workarounds to get something worse but similar with a whole stack of effects that zynthian already has, I can only really evaluate any of that again once everything else is working, first booting has to work, cant develop it if it doesnt boot, then untranslated midi, otherwise I’m stuck swapping back to my old plain-linux setup and continuing progress there.
yeah I think you get it
tbh I’m not here for emotional discussions
loopers arent really loopers if they need their screen, its not the right tool for the job, I consider every menu dive on the rc-505 a failure of design, I’ve seen mark ribilet comment why he still uses the very old mk1 because the mk2 has slightly more dependence on its screen.
loopers use buttons and lights for a reason, because they have to work in the daylight, and they have to work off of muscle memory, not vision
adding a screen to the existing setup makes no sense from that perspective, because it would not ever display anything useful, I could add a screen, and wires for the screen, and power for the screen, and then build protection for the screen, only to close it in the box its in because its not going to do anything, however I do have a crystalfontz usb text display that I’d love to hook up to zynthian for this, it needs a lot less power, works in the sun and has 5 buttons, could be very useful
Right now the looper setup I generally use that uses a pi is a small wooden box with an apc25 on top, an audio interface, a battery, a speaker, and a raspberry pi inside, I made a small app so that the lights on the apc25 show you the loop status, but I used it for 6 months without lights and I was fine, the reason why you can fly blind with loopers is because it depends on muscle memory. the buttons give you the interface, if you have to read heiroglyphics off a screen in the sun or in flashing lights, it would never be a performance instrument with that purpose.
I didn’t belittle the effort that’s been done, I’ve taken great interest in it, followed up on all the github issues and discussions, spent a lot of time testing it, ,and dug deep into the limitations that are at play so that I can not waste anybody’s time any more than what is needed. I feel that the work was done naively, it was not done with ‘great thought and consideration’ for loop musician to be honest, which is understandable, its not like the community is flooded with people like me that play loops every day, so I’m considering the situation with love and respect, and I’m offering my own expertise as a practicing loop musician and a software developer, as you can see in my material we connect many devices together and sync them, and I can add at least 2 new midi controller mappings (apc25mk1 and m-audio oxygen pro) and maintain them over time too, and along side that produce some real looper workflows and demonstrative performances exemplify zynthian. That being said, I’m obviously arriving with very little knowledge of zynthian itself, and have only had a brief look at the python codebase, and that’s why I’m not bullishly claiming that I’ll be able to build the replacement for the gui overnight, it will probably take a year of experimentation to iron out all the kinks, but we’ll probably have a workable replacement in a much shorter time, and in the meantime I can try and get the setup working without the gui
I would like to join in and contribute to zynthian instead of building on top of plain linux, since there is a sense of convergence and it would save me a little time and make the results longer lasting and more reproducible, but I’m just as happy flipping the old memory card in and going on with my life, its just an idea since double work is clearly going to happen here.
You mentioned loop competitions, with a little bit of tweaking that would probably be on the table for sooperlooper versions, maybe not 2025, but with me lending a little bit of elbow grease I dont see why we can’t look at that for 2026, it would possibly raise enough awareness to eventually get sooperlooper possibly forked or replaced with something fresher, it’s not a bad idea to get zynthian into looper competitions in my opinion, there are plenty of artists out there who are absolutely fed up with the commercial offerings for loopers, and I know their pain well, the hardware devices are very limited. It stands to reason we can ask a few small loop celebrities to check it out once its been refined a bit, I’ve had some tech chats with beardyman over discord for instance (he’s built a similar ableton/touchosc setup as I have, and also worked with the rc-505 before that), if its good enough he’d try it and comment on it.
I wish someone would pay me to do this. Maybe they might get what they are asking for!
There are gigging musicians using zynthian as a looper so it can’t be all bad. For single channel loops it works well and therr are many commercial single channel loopers. We have single pedal integration, carefully designed to meet users’ requirements. Sooperlooper is probably the most feature-rich and robust looper on Linux which is why we chose to integrate it, having assessed several contenders. Where some may describe the development (or even the developer) as naive, others may recognise the need for iterative development. The fact that we have a very well integrated looper at all is testament to the deduction of those who engaged with the process. Much of the work done on the zynthian codebase is gifted by generous people through kindness and love and they work on many parts, not just loopers.
If someone builds a custom zynthian and, despite monitoring the forum, doesn’t engage with discussion or testing in a timely manner, they may be regarded as not contributing as much as they are consuming. If they then demand the system be changed to meet their personal preference or workflow but refuse to describe that workflow, then may be expecting more than the community is willing to give.
No one arrives here with an innate knowledge of zynthian’s inner workings. We have to put in the hours to learn and gain sufficient understanding so that we may contribute.
Repeating demands without responding to requests for information is going to get you nowhere. @jofemodo has repeatedly requested a description of the required workflow, not a proposed implementation. If you are such an experienced looper user then you must be very well placed to educate us with your knowledge and experience, yet we still await such sharing of wisdom.
If there is no workflow description forthcoming then this topic is a dead end.
5 Likes
Utter rubbish. You’re narrow minded and opinionated. Again, don’t break my looper.
I’m really not sure you do. Media, entertainment, call it what you will is people driven not technology driven. Get on with the people before you try to get on with the technology.