Thankyou very much for this project. It's rlly exciting and relevant to me.
I'm having trouble getting it working, however. I'm able to write one or two loops, then I start recieving errors. It's the same error message that Mook recieved, but it seems to happen on the basic looper too. I first recieve one message then a different error repeats, like so:
This seems to happen when I try to write a loop and play a loop at the same time, maybe I need to write code that alternates recording time with playback time?
I'm no expert with code btw; sorry if my problem is obvious.
I am very happy to hear that you like this project!
But I'm just wondering about your error messages. This looks really strange. The current version of the basic looper does not send OSC messages by itself. Do you have any special setup? But generally writing and reading to a buffer should be possible in parallel.
Can you please share what your TidalCycles code looks like?
Otherwise, I will release a new version of the basic looper today or tomorrow, which should make it even easier to use. So if I can reproduce the problem with your TidalCycles code, I'll try to fix it as well!
As promised, I have uploaded a new version of the basic looper. I would like to ask you to try the new code from basic-looper.scd on GitHub. Please note the changed handling (I removed the lnr parameter , you don't need to specify each buffer name and everything is controllable with the n function).
That's awesome! I am very curious what comes out of the project.
Seeing this in the video makes me really want to use this live coding/live looping collaboratively in a project.
Sometimes I feel that I am still missing two or three arms
I used the time to simplify the Tidal looper under https://github.com/thgrund/tidal-looper.
All previous features are now in one file Looper.scd. And there is only one subfolder for the feedback examples I have used so far. There should be no breaking changes.
The biggest change is that there is now a true overdub mode that doesn't require any additional functions, which I think makes all the features more accessible and everything is all in one place now.
Awesome! When I see it like this it catches my mind again that I still have so much to try out myself. Thanks for creating and sharing the video. It is very inspiring
I have now managed to record a new small performance and experimented a bit more with the looper. First I'm curious to see how this is accepted here, since in this genre (metal?), I think not so much exists yet in live coding?
Btw. I found the annotation from your video very helpful and got inspired by it.
Yes! need more metal! - For comparison, I wonder how Igorrr does it (e.g., https://igorrr.bandcamp.com/track/apopathodiaphulatophobie) Their wikipedia page says "cubase" which I guess has some automation but Tidal should be so much more expressive ... Mrreason is definitely onto something here. Go ahead!
Just want to say a MASSIVE thank you for doing this <3 I love it, and am using it loads. Super simple to get working and has given me soooooooo many possiblities. THANK YOU!!!!!!!!!!!!!!!
Thank you very much for these kind words and I am very happy that you are having so much fun with the Tidal Looper!
I'm super excited to see what else you do with it. Your Solstice performance in the forest was really fascinating - I would probably not have come up with such an idea.
Relatively new to TidalCycles, but I'm curious how you'd get this looper set up to take the input from an external audio interface. I have a MOTU Ultralite AVB. Can anyone explain what I'd need to modify? I assume it'd be in the .scd file?
Thanks @mrreason for this great tool. The way you've structured the Tidal UI makes it really straightforward to use.
When recording from an orbit, I am finding that the buffer is significantly quieter, and that there's sometimes issues with pops and clicks at the cycle start/end points.
With the first issue, this might be difficult to deal with if the loudness is being set elsewhere in the SuperDirt signal chain than the orbit. But if that's not the case maybe there's something that could be done within the looper that wouldn't risk escalating gain?
With the second issue, this could be addressed somewhat using the inbuilt ADSR in SuperDirt, but this would make recursive looping tricky. Perhaps doing some zero crossing analysis at the start/end of the buffer, and/or providing an xfade parameter could be useful for addressing this?
Thanks for the kind words! Good points, in any case I am also very interested to extend the looper!
With the first issue, this might be difficult to deal with if the loudness is being set elsewhere in the SuperDirt signal chain than the orbit
Not really. Actually I just set the recLevel to 0.85 You can adjust this value to your needs. Maybe it would make more sense to record the audio signal usually at full volume. In overdub mode the signal must be mixed but for this you can use the parameter preLevel. My only concern is that the levels can clip while overdubbing.
The simplest variant is to use a limiter here. Otherwise I have to look again how other loopers solve this concretely.
Perhaps doing some zero crossing analysis at the start/end of the buffer, and/or providing an xfade parameter could be useful for addressing this
Another good point. IMHO I don't like ADSR and xfade so much here because it changes the audio signal too much. But I have also thought about zero crossing analysis. Maybe this will do the trick.
I've played around with analysis in advance. Maybe I should add a looper with more optimizations and analyses (quantizing, zero crossing, audio meter) in an extra file on Github and see how it does in practice.
For such points I would also be happy if tickets are created on GitHub, then we (and of course everyone else) can discuss about it. I can create those tickets in the first place.
I've never implemented a looper and I'm sure there are many subtleties of which these are just a few, so doubtless there's resources out there that can provide better suggestions for how to address these issues than I can.
That being said, in general I agree with your suggestion that trialling these ideas in practice is likely the best way forward, and I am happy to create GitHub issues and provide empirical notes.
And good to see/hear that there is more live coded metal out there 
