I wanted to see if someone had any suggestions for getting the rate at which synths are created in a loop to change in real-time. Here is an example of what I'm talking about:

var rate;
r = Routine({ loop{Synth(\test);
rate.wait;
}}).play;

Forgive me if there are a few mistakes in this code, as I am away from my computer that runs Supercollider. I hope you can get the gist of what I'm trying to do, though. I've got a SCSlider that changes the variable rate. While this gets close to what I'm going for, .wait isn't capable of immediately changing with a change in the value of rate. Is there a way to use a UGen (like Impulse) to trigger the creation of synths?

The wait call schedules the routine to wake up again at a specific number of beats in the future. It isn't possible to change that. But, you could time travel by warping time, i.e. changing the speed of the clock.

You can create as many TempoClocks as you need and control their speeds independently. Then, I would say, wait a constant amount of time inside the routine and have the slider change the clock's tempo.

Okay. I tried using a TempoClock and it definitely worked as you said, only once I got the tempo up to around 100 (to get the Synths oscillating) slight inaccuracies in the scheduling became apparent. In other words, the frequency of the oscillating Synths seemed to vary ever so slightly. Is there a known issue with the accuracy of TempoClocks?

After reading the ServerTiming helpfile, I feel I have a better understanding of the cause of the scheduling inaccuracies. As for the solution using latency, though, I'm having difficulty seeing and hearing the difference with it - at least, from the examples in the helpfile. I ran the first example, heard the slight variations and saw them in the post window. Then I ran the second example (which uses latency) and it didn't seem like anything had changed.
Am I wrong in expecting the latency to sync the playback of the synths in both routines?

Had another thought... depending on the sound you're using, granular synthesis UGens might be better for this than triggering one synth per grain.

Sound in a buffer: TGrains, Warp1, GrainBuf

With the JoshUGens from the sc3-plugins pack, there are sine-grain ugens and FM grain ugens.

Also, if the sound is in a buffer, convolution can be more cpu-friendly if the grain rate is high and the grains use exactly the same buffer (whereas the "real" granulators can move through a buffer).

Code:

// depending on your buffered sound, you might be able to just Buffer.read it
// but here, we're taking a random snippet out of a longer file
// without a windowing function, there will be a lot of ugly clicks
// so we do it the long way - load soundfile data into a client array,
// then multiply by an Envelope shape
b = Buffer.alloc(s, 10000, 1);
f = SoundFile.openRead("sounds/a11wlk01.wav");
f.seek(100000.rand);
f.readData(d = Signal.newClear(10000));
b.sendCollection(d * (Env(#[0, 1, 1, 0], #[0.25, 0.5, 0.25], \sin).discretize(10000)));

The reason why I'm trying to use a routine is that I want to get a Synth oscillating that is using one of the grain UGens. I would ideally like to be able to granulate a sample and have the granulated output oscillate as well.

So when you say that Synth onset is at a control block boundary, does that mean that synths are only created at the beginning of a control cycle running at the control rate?

Yes.

someone wrote:

Also, wouldn't it always be advantageous to use OffsetOut over Out?

There might be some extra cpu overhead for OffsetOut, but if any, it wouldn't be much. There's probably no particular harm in using it everywhere. (Note, though, there is no OffsetOut.kr, because there are no sub-control-rate values for kr buses.)

A lot of applications don't demand sub-microsecond timing accuracy (humans can't detect separate attacks occurring less than 5-10 ms or so apart). It becomes an issue here because of the rate of synth creation and the desire to get oscillation in the range of hearing.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum

Please support our site. If you click through and buy from our affiliate partners, we earn a small commission.