PlayBuf.ar and RecordBuf.ar seem to run at control rate

Questions
1

Hi all,

I’m trying to generate a stream of audio rate samples by applying a math operation to the previous sample, but it’s not working as expected.

For this example code:

{
    var buffer = Buffer.alloc(s, 1);
    var previous = PlayBuf.ar(1, buffer);
    var current = previous + 1;
    RecordBuf.ar(current, buffer);
    Poll.kr(Impulse.kr(30), current)
}.play

I would expect each sample to be 1 higher than the previous, but the 1 only seems to get added for each control rate sample rather than audio rate sample. Is there a way to force it to work in audio rate?

Another distantly-related issue that would solve the same problem: Is there a way to force Phasor to start with a random value instead of the minimum one?

Thanks,
Tom

2

That’s the way audio is calculated: in chunks of length blocksize (control block length). A rude way to circumvent this is rebooting the server with blockSize set to 1 (ServerOptions). A way to get so-called single sample feedback without setting blockSize to 1 is Fb1 from miSCellaneous_lib quark. But that’s probably not necessary in your use case. Phasor has a reset pos arg, this can be a random ugen triggered together with trig. Besides there is Sweep, which is often practical for such situations.

1 Like
3 
(
{
  var current = Phasor.ar(Impulse.kr(0), 1, 0, 1e10);
  Poll.kr(Impulse.kr(30), current)
}.play
)

This will work up to a point. This won’t be sample accurate once it gets beyond a certain value (but that would be true of any approach that just keeps counting up).

Impulse.kr(0) is being used to kick the whole thing off (it fires an impulse at initialization, and then never again).

2 Likes
4

Thanks! Fb1 looks potentially very useful. But yes, it seems that Phasor will work fine in this case.

5

Impulse.kr(0) does indeed solve this problem, thanks! Could you elaborate on why it would stop being sample accurate, or is that only for certain sets of arguments where the outputted values become unrepresentable?

6

It’s the latter. After a while the numbers are going to get too big so you’re just not going to get the numerical accuracy you need. Floats are 32 bit in SuperCollider, so (estimates widely) after 1-2 hours maybe?

7

That sounds fine then, my wrap ranges will be small anyway. Thanks again!