I want to create a ‘time loop’ in which a series of events occur. I’m slightly intimidated about how to approach this in SC. In essence I want a ‘master clock’ that will make sure that over time things do not drift out of time.
Having learned a bit of Processing/Javascript, I’m still really struggling with getting my head around not using for/while loops regularly. I know the following code is wrong, but I don’t know why. The idea is the loop starts at 5 seconds, then each time it runs it gets one second longer…
x = 5;
TempoClock.default.sched(1, { x + 1; x.postln; });
I also want eventually for it to stop growing at a point. Let’s say 10 seconds. In Processing/Javascript this would be managed by a for loop, but I feel like I’m barking up the wrong tree by thinking like this in SC.
Any help would be greatly appreciated. I’m trying to avoid disappearing down a rabbit hole of misconceptions.
Could you elaborate a bit more on this? What specifically are you trying to do?
Task
Here is an implementation using Task, I have assumed you don’t want to wait for 10 seconds after the final event.
t = Task({
"starting task".postln;
5.do { |n|
var waitTime = 5 + n;
postf("doing the %th thing then waiting for %\n", n, waitTime);
waitTime.wait
};
"ending task".postln; // put last action here.
})
t.play
t.stop
and the output
starting task
doing the 0th thing then waiting for 5
doing the 1th thing then waiting for 6
doing the 2th thing then waiting for 7
doing the 3th thing then waiting for 8
doing the 4th thing then waiting for 9
ending task
Your code
First you aren’t changing x, it should be:
{ x = x + 1; x.postln; }
Second to stop the scheduler, the docs say ‘Returning nil will stop the task from being rescheduled.’
so you can do this…
x = 5
TempoClock.default.sched(1, {
x = x + 1;
x.postln;
if(x < 10, x, nil)
});
Patterns
Its also worth mentioning Patterns here - but only if you are trying to change a synth, check out the pattern guides here - Streams-Patterns-Events/A-Practial-Guide, then you could do this
Could you elaborate a bit more on this? What specifically are you trying to do?
Sure. I want to take a sample and cut it into x number of slices. Then I want to start by having a loop which equals the length of the sample. The start of that loop could be call 0.
At first all the slices play from point zero, but then the idea is the gradually drift back to their original positions, reassembling the original sample.
So for example if x = 10, the first slice will always stay at point 0 of the loop, whereas the 10th slice will move most quickly away from 0 to reach its original position.
To visualise this is the start
1
2
3
4
5
6
7
8
9
10
… after the process is complete…
1 2 3 4 5 6 7 8 9 10
So the reason I’m talking about a master clock, is that my plan is to have one ‘master’ loop trigger a whole series of parts of the sample that become increasingly delayed, until that resume their original positions. The master clock keeps everything in time, and recognises that the size of the loop will gradually augment, until it has reached its original size.
I hope this makes sense. It’s just been swimming around my brain and I haven’t tried to communicate it to anyone yet.
Here is an implementation using Task, I have assumed you don’t want to wait for 10 seconds after the final event.
Thank you for this. It looks close to what I’m aiming for. Although I presume a for loop might suit my application more easily than do.
Thank you also for the corrections Jordan. Much appreciated. I will revisit the Patterns literature. I’ve read it before, but this current task might help me make better sense of it.
So you should definitely have a go at using Task for this as it will give you lots of flexibility… but you can just do the whole thing on the server… I’ve assumed you are splitting into equal slices, which isn’t the most musical idea, but it does work quite well. This could also be improved by adding some overlap.
Move mouse from left to right slowly, if you jump to the end, it sort of takes of moment to sort itself out.
s.options.memSize = 8192 * 32; // if you have a lot of slices, this might need to be increased
s.boot;
~b = Buffer.read(s, Platform.resourceDir +/+ "sounds/a11wlk01.wav");
SynthDef('drift', {
var numSlices = 8;
var positionsInBuf = numSlices.collect{ |n| n / numSlices };
var timeOfEachSlice = BufDur.kr(~b) * numSlices.reciprocal;
var lerpFactor = MouseX.kr();
var lerp = 0.blend(positionsInBuf, lerpFactor);
var triggerPerLoop = Impulse.kr( max(lerp.last * BufDur.kr(~b), timeOfEachSlice).reciprocal );
var delayTime = lerp * BufDur.kr(~b) ;
var triggerForSlice = DelayN.kr(triggerPerLoop, BufDur.kr(~b), delayTime.poll);
var snd = GrainBuf.ar(
1,
trigger: triggerForSlice,
dur: timeOfEachSlice,
sndbuf: ~b,
pos: positionsInBuf,
);
Out.ar(0, (Mix.ar(snd).tanh)!2) // watch ears when lerpFactor == 0
}).add;
t = Synth('drift')
Actually, n.do is the equivalent of the C style for loop.
Although you should try to think in terms of: collect which takes one collection and transforms it into another, reduce which turns a collection into a single value, inject which pipes together function, and do which will do something for each element (or n times) [but its best to avoid do when one of the others will suffice].
Wow, Jordan, thanks for taking the time to create the code, share it, and provide a description. I’m very grateful. It’s very clearly written, but I’m still trying to get my head around a couple of parts of it.
I’ve assumed you are splitting into equal slices, which isn’t the most musical idea, but it does work quite well.
It was my intention - for the time being - to have things sliced equally, yes. It’s very impressive. I can’t quite reconstruct the original sample, but I’m guessing the overlap might help resolve that.
I’ll try to do as much work over the coming days in research, and to make full sense of your code.
Schedules a task to be performed delta amount of beats after the current Thread’s logical time…
When the scheduling time is up, the task’s awake method is called. If the method returns a number, the task will be rescheduled for the time equal to the last scheduling time plus the returned value.
So it is already documented in the reference, not only in the tutorial.
I can understand why one would land on the Scheduler class when searching for scheduling – but, in practice, I’ve never seen anyone actually use this class, because the clock classes are easier. A better search term would be for sched or play as method selectors.
Oh yeah! It’s not even the base class of TempoClock, dunno how I missed that .
To be fair, I don’t think I’ve actually used either in a project - task or routine is normally easier.
You can also call reset on the thread, from outside the thread itself. I’d say this is more typical.
Depending on the use case. “Standard” usage would be to set the beats per second, and then wait a desired number of beats (0.5 = 8th note, 1/3 = triplet etc)… but quote marks for the word “standard” because abuse of the technology is part of the spirit of SC
If, for example, I want to make a techno track at 132 bpm, then I set the tempo to 132 bpm * 1 min / 60 s = 132/60 bps.
Now a beat value of 1 is exactly the right amount of time for a quarter note. So the 4-on-the-floor kick drum would simply use a time delta = 1.
A hi-hat in 8ths would take time delta = 0.5.
Note that I haven’t discussed any time values in seconds. That’s because the point of TempoClock is to let you think in terms of musical time units without having to bother with conversion at all. (The one case where conversion would be needed is if you need the server to count some time value in seconds, but based on a known number of beats. But this is also not at all difficult: seconds = beats / tempo. In several patterns in my code base, I have something like Pkey(\dur) / Ptempo() where Ptempo is in my ddwPatterns quark and just returns this thread’s clock’s tempo.)
In short, you don’t make use of “beats from tempo.” You orient all of the time handling toward beats (“think in beats”), and let the clock perform it for you (edit: if it’s appropriate for the use case to think in terms of beats – if it makes more sense to think in seconds, then just set tempo = 1 and roll with that).
I have to admit here that I have no idea how a function would help, because the usage is already just about as convenient as it could possibly be: set tempo (once) in the preparatory block of code, and after that, rhythmic values orient around a scale in which 1.0 represents one beat.
There’s an example like this in the tutorial series – last example in this page: 16. Sequencing with Patterns | SuperCollider 3.12.2 Help (actually it’s my example ). I’ll admit that it doesn’t directly explain the rhythmic values, but it does include a cheeky pedagogical question:
// before you play:
// what do you anticipate '\delta, 1' will do?
k = Pbind(\instrument, \kik, \delta, 1, \preamp, 4.5, \amp, 0.32).play(quant: 1);
… which would lead to the inference that 1 is being defined in this example as a rhythmic value which westerners would commonly call a quarter note.
.