Sampling within Tidal

Here's another video from that (pre-lockdown) session:

3 Likes

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 :slight_smile:

1 Like

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.

6 Likes

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!

NB: your camera swaps left-right? (or the poster in the background does) For true satanism that should be up-down? E.g. https://www.discogs.com/Upsidedown-Cross-Upsidedown-Cross/release/2138303

1 Like

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!!!!!!!!!!!!!!!

1 Like

PS I have a live coded black metal/noise band :slight_smile: so you are not alone in live coded metal. We're called Trve Yorkshire Kvlt Ensemble.

Shhhhhhh

We use FoxDot though not Tidal :dizzy_face:

7 Likes

That's epic!

Thank you very much for these kind words and I am very happy that you are having so much fun with the Tidal Looper! :slight_smile:
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.

There is no better way to describe it than "Infernal typing" :love_you_gesture: And good to see/hear that there is more live coded metal out there :slight_smile:

By the way, I was playing with the idea of playing SuperDirt with FoxDot and TidalCycles in parallel. Is that a thing? :thinking:

Hi all,

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!

Hey @sellanraa and thanks for trying the tidal looper! :slight_smile:

Maybe this thread can answer your questions: Live recording into tidal

@yaxu should we rename the linked topic to some general audio input thread for live sampling in TidalCycles?

1 Like

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?

1 Like

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.

1 Like

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.

1 Like

Thank you very much! I think I'll sit down this weekend and think about this topic in more detail and create a roadmap. Now is certainly a good time to tackle such optimizations.

1 Like

Today I transformed the tidal looper so that you can install it as Quark in SuperCollider.

This procedure has the following reasons:

  • Easier to extend and customize.
  • There is a documentation in SuperCollider.
  • The looper can be loaded in the startup script when starting the server.
  • Different releases can be published in the future (but this is not done yet).

I left the existing Looper.scd file in the repository for backward compatibility. Probably this will be removed in the future when it is shown that the Quark variant runs stable and is accepted.

In any case, it is now easier to optimize the whole thing.

@jarm With the attributes rLevel and pLevel you can influence the multipliers for recording. This only works on the SuperCollider side now, but I can also allow it in TidalCycles if you find it useful.

The default SynthDef now doesn't have zero crossing analysis or an envelope, but you can now easily swap the SynthDef for recording and switch between them during runtime. Here is an example of what this looks like with a simple envelope.

(
// Recording synthdef with envelope
SynthDef(\buffRecordEnv, {|input = 0, pLevel = 0.0, rLevel = 1.0, buffer|
    var in = SoundIn.ar(input);
    var env = EnvGen.ar(Env.asr(0.03, 1, 1, 1), 1, doneAction:2);

    RecordBuf.ar(in * env, buffer, recLevel: rLevel, preLevel: pLevel, loop:0, run: 1, doneAction: Done.freeSelf);
}).add;

~looper.looperSynth = "buffRecordEnv";

)

@tgirod Thanks for pointing out to make a Quark out of it! I now believe that this has only advantages. First of all, everyone can experiment with the parameters more easily and the releases in the future are also very charming.

8 Likes

hey! I installed the quark version, nice! The only help I missed was this:

(
SuperDirt.start;
TidalLooper.new(~dirt);
)

About using the looper, I'm pretty sure I saw somewhere a trick to start recording when the next loop starts, but I can't find it! anyone can help?

Yes you are right. I have it in the SuperCollider help, but it is very hidden in the first place. I have adapted the README.

To start the recording when the next loop starts you can use qtrigger. For example:

d1 $ qtrigger 1 ...
d2 $ qtrigger 2 ...

But you should be on at least Tidal 1.7 to have no unwanted effects in the looper context.

1 Like

thanks a lot, that is exactly what I needed!

1 Like

Really cool stuff! Thanks a lot for this @mrreason !

1 Like