VOsc using Ableton Wavetable sprites

Trying to use Ableton Wavetable sprites with VOsc (to port one of my presets to sc), but can’t set it to work correctly. This article says Wavetable using audio files called sprites which are a collections of 1024 sample long single cycle waveform wavetables in one file. VOsc requires a collection of buffers filled with a wavetable format signal.

The first step is to divide the sprite into waveforms. For this example I’m using “Filter Sweep 1” sprite from /Applications/Ableton Live 11 Suite.app/Contents/App-Resources/Builtin/Samples/Vector/Sprites. I’m uploaded it here (piracy?). This sprite is 32768 samples long which are 32 wavetables. Reading sprite parts with Signal, converting to Wavetable format and loading them to the server:

(
var file, size, cycles;
file = "/Applications/Ableton Live 11 Suite.app/Contents/App-Resources/Builtin/Samples/Vector/Sprites/Vector_Sprite_Filter Sweep 1.wav";
size = SoundFile.use(file, { | f | f.numFrames })/1024;
cycles = ();
size.do({ | i |
	cycles[i] = Signal.read(file, 1024, i*1024, 0);
	cycles[i] = cycles[i].asWavetable;
});
size.do({ | i | Buffer.loadCollection(Server.default, cycles[i]) });
)

Running VOsc:

{ VOsc.ar(MouseX.kr(31, 0), MouseY.kr(30, 300))!2 * -15.dbamp }.play;

Changes in bufpos input cause clicks. The faster bufpos changes the more clicks occur. This sounds like there was sample inaccuracy during sprite conversion and uploading process. How can this code be fixed?

Forgot to mention that .read method is from the SignalBox quark.

I think this is actually a bug. It looks like the bufpos input isn’t audio rate and seems to jump around across the buffer.

I was wondering if @nathan had any ideas, I think GitHub says you wrote the code, as I can’t quite make sense of it.

Also, you should always you use allocConsecutive here

~bufs = Buffer.allocConsecutive(numBufs, s, 1024);
s.sync;
~bufs.do{|b,i|
	b.allocRead(path, i*1024, 1024)
}
.... later
var bufpos = MouseX.kr(~bufs[0].bufnum, ~bufs.last.bufnum)

In the mean time you might find better results using WaveTerrain from the SLUgens?

Hey, I have been doing some Wavetable testing resently and this might be a bit off-topic, but I’m curious why the helpfiles of Vosc or Vosc3 don’t really mention that you can also just load a wav-buffer into it and it works completely fine, if you are using the spesific size (numFrames the power of 2). I’m not totally sure if you really have to convert it to the wavetable format (if you have already the wav file). It could also be that I’m doing something wrong but I can clearly hear the classic wavetable synthesis, wavescrolling effect with these examples I have been doing recently:


(
q = q ? ();
q.b40=Buffer.read(s,"C:/tee/Ableton2/Liveset453-pspawn-vst-vital Project/Liveset453-pspawn-vst-vital-mono.wav",startFrame:rrand(0,44100*120), numFrames:2.pow(16));
q.b41=Buffer.read(s,"C:/tee/Ableton2/Liveset453-pspawn-vst-vital Project/Liveset453-pspawn-vst-vital-mono.wav",startFrame:rrand(0,44100*120), numFrames:2.pow(16));
q.b42=Buffer.read(s,"C:/tee/Ableton2/Liveset453-pspawn-vst-vital Project/Liveset453-pspawn-vst-vital-mono.wav",startFrame:rrand(0,44100*120), numFrames:2.pow(16));
q.b43=Buffer.read(s,"C:/tee/Ableton2/Liveset453-pspawn-vst-vital Project/Liveset453-pspawn-vst-vital-mono.wav",startFrame:rrand(0,44100*120), numFrames:2.pow(16));
)



Ndef(\vosc_test, {VOsc.ar(MouseX.kr(q.b40.bufnum, q.b43.bufnum), MouseY.kr(0.01, 100))});

Ndef(\vosc_test).play(0,2);

Ndef(\vosc_test, {VOsc.ar(LFTri.kr(0.000002).range(0,3).clip(0,3), 0.5)});

After several other tests with different sprites and custom wavetables I think this is just how Ableton Wavetable works (it’s definitely doing some pre-processing of the file and there is no official information about this except that it deletes silent parts). Maybe that is why sprites work in a strange way with VOsc. Eventually I just reproduced the Filter Sweeps sprites in SC and made my own versions of these wavetables and everything works good.

Hi!

Yes you’re right and help files mention that.

You have to if it’s not already pre-processed wavetable file(s). I think in your example you are already using some king of prepared files?

No I’m not. Just a random jam I recorded with the Vital VST. I bounced it to mono though.

UGens don’t care where the data come from.

OK, let’s try what happens if the data are not in wavetable format.

s.boot;

b = Buffer.sendCollection(s, Signal.sineFill(2048, [1]));

b.plot;  // looks OK

{ Osc.ar(b, 440) }.plot;  // does not look OK

osc-non-wavetable

So, you don’t have to use wavetable format if you don’t mind jittery distortion.

If you pre-convert the wave cycles into wavetable format and write these to an audio file (or collection of audio files), then these could be loaded from disk and they will work with the Osc family.

hjh

Ah, I see! My source material is so noisey that I probably have missed any jitterness (actually I might prefer it). But I’ll definitely do some testing with the Signal class and asWavetables to see the difference. I seem to have the SignalBox installed, which should help with loading.