VOsc randomly giving up

Questions
1

Ive just started getting into wavetable synthesis and experimenting with VOsc. Ive noticed, that VOsc crashes when you use a Sine wave to modulate the bufpos. Without any error.
`~b0 = Buffer.alloc(s, 2048);
~b1 = Buffer.alloc(s, 2048);
~b2 = Buffer.alloc(s, 2048);
~b3 = Buffer.alloc(s, 2048);

(
var sig1, sig2, sig3, sig4, wt1, wt2, wt3, wt4, osc;
sig1 = Env([1,-1,1], [0.5,0.5], \sine).asSignal(1024);
sig2 = Env([1, -1], [1], \lin).asSignal(1024);
sig3 = Env([-1,1,-1], [1,1], \lin).asSignal(1024);
sig4 = Env([-1,-1,1], [1,1], \step).asSignal(1024);

wt1 = sig1.asWavetable;
wt2 = sig2.asWavetable;
wt3 = sig3.asWavetable;
wt4 = sig4.asWavetable;

~b0.loadCollection(wt1);
~b1.loadCollection(wt2);
~b2.loadCollection(wt3);
~b3.loadCollection(wt4);

{
osc = VOsc.ar(SinOsc.kr(1).range(~b0.bufnum,~b3.bufnum), [100,100.1,100.2,100.3]).mean!2;
}.play;
)
`
If i play this it just falls silent at some point. Any other waveform used for modulating doesnt crash. Why does the sinewave not work for modulating?

2

Ive noticed that if i subtract some number x (0 < x < 1) from ~b3.bufnum in the range argument, it doesnt seem to crash. However if x becomes very small it starts to crash again. This is very peculiar to me. Does anyone have any clue whats going on?

3

This might be an issue with how you allocate the Buffers - you need to use the Buffer method .allocConsecutive with VOsc.

VOsc help says: “If you use Buffer objects to manage buffer numbers, you can use the [*allocConsecutive] method to allocate a continuous block of buffers. See the Buffer helpfile for details.”

Buffer help says:

Buffer.allocConsecutive(numBufs: 1, server, numFrames, numChannels: 1, completionMessage, bufnum)

Allocates a range of consecutively-numbered buffers, for use with UGens like VOsc and VOsc3 that require a contiguous block of buffers, and returns an array of corresponding Buffer objects.

Best,
Paul

4

The buffers have bufnum 0 to 3, so they are already consecutive. Also i dont see how this can be related to the buffers, since only a change in the kind of LFO determines if it will crash or not.

edit: i just tested with allocConsecutive, but it still falls silent at some point.

5

I think I found the issue, I can’t really explain why, but here it goes. First I tried creating a 5th dummy buffer which solved the problem. Also, subtracting 0.02 from ~b3.bufnum in the range method fixed it which leads me to believe that SinOsc.kr(1) sometimes outputs a value > 1, which then leads VOsc to look for a buffer after the last defined buffer as the output of the SinOsc after the range method has been applied might be something like 3.0001. Changing SinOsc.kr to SinOsc.ar also fixed the problem, so it seems to be an issue only related to kr signals. Somebody with more insight than me will probably be able to explain this in more detail.

6

I think youre right! That explains why subtracting the small amount prevented it from crashing.