synth creation with loop

someone · Joined: Apr 11, 2009 Posts: 9 Location: somewhere

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?

dewdrop_world · Posted: Tue May 19, 2009 9:10 am Post subject:

Ah, interesting!

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.

someone · Joined: Apr 11, 2009 Posts: 9 Location: somewhere

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?

dewdrop_world · Posted: Tue May 19, 2009 7:16 pm Post subject:

Known solution. See the ServerTiming helpfile.

someone · Joined: Apr 11, 2009 Posts: 9 Location: somewhere

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?

dewdrop_world · Posted: Thu May 21, 2009 11:30 am Post subject:

It should.

If you're on Windows, the audio driver latency might be too low. Booting the server on my winxp machine shows this:

Device options:
- MME : Microsoft Sound Mapper - Input (device #0 with 2 ins 0 outs)
- MME : SigmaTel Audio (device #1 with 2 ins 0 outs)
- MME : Microsoft Sound Mapper - Output (device #2 with 0 ins 2 outs)
- MME : SigmaTel Audio (device #3 with 0 ins 2 outs)

Booting with:
In: MME : SigmaTel Audio
Out: MME : SigmaTel Audio
Sample rate: 44100.000
Latency (in/out): 0.232 / 0.232 sec
SuperCollider 3 server ready..

What do you see there?
James

dewdrop_world · Posted: Fri May 22, 2009 2:31 pm Post subject:

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).

someone · Joined: Apr 11, 2009 Posts: 9 Location: somewhere

Sorry for the delay in my response. Here is what is printed when I boot the server (I've got a Mac G5):

booting 57110
Number of Devices: 4
0 : "Built-in Audio"
1 : "MOTU 828"
2 : "PCI-424"
3 : "Aggregate Device"

"MOTU 828" Input Device
Streams: 2
0 channels 8
1 channels 2

"MOTU 828" Output Device
Streams: 2
0 channels 8
1 channels 2

SC_AudioDriver: sample rate = 48000.000000, driver's block size = 512
SuperCollider 3 server ready..
notification is on

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.

dewdrop_world · Posted: Tue May 26, 2009 1:22 pm Post subject:

It took awhile, but I remembered one factor here.

Synth onset is always at a control block boundary. If the rate of Synth creation is below the rate of perception, it isn't really a big deal (64/44100 < 2ms) but it is slightly inaccurate.

To solve that problem, use OffsetOut which measures the difference between the control block boundary time and the real sounding time, and adjust the output to start at exactly the indicated time.

OffsetOut.ar(bus, result) // instead of Out.ar(...)

There might be something else in your SynthDef to interfere, but I think this might help.

hjh

someone · Joined: Apr 11, 2009 Posts: 9 Location: somewhere

You got it. With the combination of the OffsetOut in the SynthDef and the latency in the sendBundle method used in the loop of the Routine, I'm getting exactly what I intended.

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?

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

dewdrop_world · Posted: Sun May 31, 2009 12:25 pm Post subject:

someone · Joined: Apr 11, 2009 Posts: 9 Location: somewhere

Thank you so much for helping me out with this issue. I appreciate your patience and assistance in finding the solution.