Hi folks,
Is it possible to sample using Tidal? I.e. to have audio captured from an external source, and play back from a buffer in SuperCollider, or something like that?
Hi folks,
Is it possible to sample using Tidal? I.e. to have audio captured from an external source, and play back from a buffer in SuperCollider, or something like that?
The short answer is "yes", but unfortunately I'm having trouble tracking down the way to do it. I know I've seen it before. The method is to define a SuperCollider synthdef that can then be used in Tidal for both recording and playback. Will report back here when I find it, unless someone else beats me to it.
Wonderful! I did some Google-izing but could not find anything.
In the SuperDirt/hacks/ folder looper.scd
Would like to add that it's possible to get TidalCycles to sample its own output, which you can then load back into TidalCycles as a sample that you can hack up like a breakbeat, ad-infinitum. One of the tracks on the album I'm working on is a demonstration of this, and you can achieve some really weird/cool stuff this way.
Hot, thanks!
Nice! Using the above looper.scd?
My own code, but loosely based on this. If I recall, it required some fiddling to get working properly. I'll try to dig up the code and verify that it still works.
This sounds super spicy, thank you!
I just spent the last hour trying to get this project running in latest TidalCycles but unfortunately SuperDirt and TidalCycles seem to have diverged too deeply for my code to still function. I got it playing and my libs updated, but the self-sampling no longer works. I suspect the SuperDirt feature it relies on was deprecated, and the record events are no longer being sent out at the correct intervals.
@vin Have you had any luck with the looper.scd stuff? I would love to get something like this working again, but I suspect I'm going to be starting largely from scratch at this point.
No such luck! I tried, the github repo said that the hacks directory stuff should already work, but alas, it did not, and I couldn't get the looper.scd to work. Admittedly I didn't spend a huge amount of time on it.
Finally I came up with a first basic version of a new looper in TidalCycles!
I uploaded the code on my Github page
What I did so far:
You can find a demo video where I demonstrate all of these here:
What I am still loosely planning to implement are more complex looper variants with the following features:
I would be very happy to receive feedback and ideas!
Awesome! I've got a collab working with an ace vocalist Eimear O'Donovan coming up, and can imagine making good use of this!
We've been talking about pattering sound input taking a bit of a different approach to live looping - instead recording loops then manipulating them, having the live sound continually recorded into a buffer and then working with that with Tidal patterns. I guess the only difference would be instead of manipulating a named / numbered loop, you instead manipulate whatever the sound input was (say) 3 cycles ago. So you could set up some kind of canon structure with tidal, keep that fixed while playing with it by changing the nature of the sound input..
Btw did you see this looper in the superdirt hacks folder?
Maybe there are ideas in there to pick up / merge?
[Edit:]It seems that eris has developed her own looper loosely based on the looper hack. So I had misunderstood that while reading it. But the rest should be correct so far.
Yes I know the looper hack. In this topic it was already referenced and apparently written by @eris. According to the conversation, it no longer worked. However, I found the usability quite limited and I plan to implement / use more looper variants with additional features. So with my implementation you should have more control over start and stop, because the length and the record duration of a buffer is specified by the length of the pattern.I wrote this so that the recording stops automatically when the looper is no longer sent.
For example you can write this to starts the recording every second cycle:
d1 $ s "<loop ~>"
And here every second cycle nothing will be recorded:
d1 $ s "loop" # lnr "<0 ~ 1 ~>"
Correct me if I am wrong, but the looper in the hack has to be retriggered to save a buffer. This is how I understand the code. I think the code d1 $ silence
won't save the last recording.
The length of the buffers are fixed in the looper hack and you had no possibility to specify input ports or buffer numbers as patterns (but that was one of my goals). Basically the buffer changed implicitly with round robin.
Btw. Eris herself wrote in this topic that she would like to see a way to sample and reuse the output of a channel. With my implementation I demonstrated at least one way how to do that.
But there is one thing I ignored, what is contained in the looper hack code. I don't know why it was in there. That is the envelope of the input signal. Maybe someone can please explain this to me?
I would love to see that!
If you implement the other approach, would you publish the code for it?
I would have no good idea how to realize such behaviour.
I'm having a lot of fun just increasing the number of buffers in your looper and cycling through them on input:
d1 $ lnr (slow 2 "[0 .. 15]") # s "loop"
While playing with that at the same time:
d2 $ jux rev $ off 0.25 (|+ note "-5 12 -12 7") $
stack [slow 4 $ s "loop0 loop1 loop2 loop3 loop4 loop5 loop6 loop7 loop8 loop9 loop10 loop11 loop12 loop13 loop14 loop15" # legato 1 # pF "tilt" 0.25 |* speed 2
]
I'm not quite ready to share the rebecca black cover I just sang with that
Thanks for clarifying, and sorry for not reading the whole thread.
I agree using the delta of the sound event works really well. I just had to adjust the 'tilt' parameter to remove discontinuities at the start/end. Maybe that is what the envelope is for in the looper in the hacks folder?
Glad to hear it! I will definitely optimize the code to avoid these problems during the transitions. I don't know if the enveloper is the solution, because I have the feeling that a small piece is cut off if the buffers get longer (maybe I need a better calculation?). Is it possible that the enveloper provides clean transitions when you record and play back several buffers one after the other?
I am definitely curious about vocal experiments with the looper and TidalCycles. Your code already looks as if you can create funny/interesting effects with it
Probably the handling is even more comfortable if you append several buffers under one name. Then you can access them with the n
function (maybe as an alternative usage?). The only problem I see with this is that it might be difficult to overwrite single buffers if something went wrong during the recording.