Oversampling oscillators

LFSaw · June 12, 2023, 8:31pm

thanks for all the efforts, i’ll def. check them out
would possibly be interesting to be able to explicitly set the band limitation freq from the UGen interface, maybe?

cheers

Sam_Pluta · June 12, 2023, 11:07pm

I’m not sure what you mean. For the Oversampled oscillators, the limit frequency is always the nyquist…well, it is always 0.98f * (sampleRate / 2.0f), so real close to nyquist. I could make that an argument, but if you want it lower you could always just use another LPF. For the Bandlimited ones it is also nyquist. Or am I misunderstanding the question?

Sam

Sam_Pluta · June 12, 2023, 11:36pm

BTW - The Bandlimited synths are straight from the faust source, and I know you are a faust hound. I basically just augmented those with some niceties that make them more usable across the entire frequency range.

LFSaw · June 13, 2023, 3:13pm

I’m also not really sure what I mean…
I guess what I meant is, that it might be interesting from a user perspective to be able to manually set the band limit in the BL*-UGens to a specific frequency below Nyquist, to have an included LPF in the UGen itself…

Btw; after installing and compiling, I just glanced at the code and found this residue float cross2 = 1.f; (which is anyhow optimised out by the compiler. I guess…):

github.com

spluta/OversamplingOscillators/blob/d068c980df5f5073749eb0161d1085e46dcbfba8/OversamplingOscillators.cpp#L543


      
          
          
float cross = 1.f;
          
          
if (freq < 4000)
            cross = 0.f;
          else if (freq > 8000)
            cross = 1.f;
          else
            cross = (freq - 4000) / 4000;
          
          
float cross2 = 1.f;
          
          
if (*counter < 2)
            poly2 = 0.f;
          if (*counter < 4)
          {
            *counter = *counter + 1;
            poly4 = 0.f;
          }
          
          
float out = (poly2 * (1 - cross)) + (poly4 * cross);

wehrk · August 12, 2023, 11:11am

Can someone explain how to build it step-by-step, please?

Sam_Pluta · August 12, 2023, 2:56pm

First question: what platform are you on? I don’t know if this compiles on Windows.

You need to have the SC Source Code downloaded and on your machine to do this. You also need cmake installed. Once you have those two things, building any plugin should be easy.

Download the code for the plugin.
Go to terminal. Change directory to the source directory for the plugin.
In the terminal, you can either run each line below separately or paste the whole text in (where “PATH TO SC SOURCE” is the directory where the SC Source Code is:

mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release -DSC_PATH=<PATH TO SC SOURCE> 
cmake --build . --config Release

It will create a bunch of .scx files in the build directory, plus there is a .sc file in the main directory. These need to be in your SuperCollider Extensions folder. I just move the whole “OversamplingOscillators” directory to the Extensions folder. Recompile the class library or quit and restart SC.

Sam

wehrk · August 13, 2023, 11:07am

I’ve got .scx files, but then started to get this error after booting the server (for each file), for example TriOS.scx:

*** ERROR: dlopen ‘/Users/wehrk/Library/Application Support/SuperCollider/Extensions/OversamplingOscillators/TriOS.scx’ err ‘dlopen(/Users/wehrk/Library/Application Support/SuperCollider/Extensions/OversamplingOscillators/TriOS.scx, 0x0002): tried: ‘/Users/wehrk/Library/Application Support/SuperCollider/Extensions/OversamplingOscillators/TriOS.scx’ (mach-o file, but is an incompatible architecture (have ‘arm64’, need ‘x86_64’)), ‘/System/Volumes/Preboot/Cryptexes/OS/Users/wehrk/Library/Application Support/SuperCollider/Extensions/OversamplingOscillators/TriOS.scx’ (no such file), ‘/Users/wehrk/Library/Application Support/SuperCollider/Extensions/OversamplingOscillators/TriOS.scx’ (mach-o file, but is an incompatible architecture (have ‘arm64’, need ‘x86_64’))’

I’m on M1 Mac with SC 3.13.0 x64 installed. I tried to switch to universal version, but all the extensions I use will be gone that way and OversamplingOscillators will not work either (have ‘arm64’, need ‘x86_64’ part of the error report will switch to have ‘x86_64’, need ‘arm64’)

Sam_Pluta · August 13, 2023, 1:20pm

I see. You are still using the Intel build of SC. Then you need to force the compiler to build for x86. So, try changing the first cmake line to:

cmake .. -DCMAKE_BUILD_TYPE=Release -DSC_PATH= <PATH TO SC SOURCE>  -DCMAKE_OSX_ARCHITECTURES=x86_64

edit: you may need to delete the build directory and start the build over.

Sam

wehrk · August 14, 2023, 7:23am

Thank you a lot for helpful instructions. It worked smoothly.

wwerkk · January 10, 2024, 2:30am

Hey, just stumbled upon these, they sound great!
I thought I would have a go at implementing oversampling within a stochastic synthesis UGen I’ve been working on. I managed to get as far as getting it to work more or less and indeed it seems to alias less when frequency or phase are modulated, but I am not sure if I get the saw::next(). I am wondering why does the phase go between -4 and 4, and is then wrapped to -1 and 1?

Here’s my code, quick and dirty:

github.com

wwerkk/MidpointOS/blob/master/MidpointOS.cpp#L17


      
          
          
static InterfaceTable *ft;
          
          
namespace MidpointOS {
          
          
MidpointOSNext::MidpointOSNext() {
          }
          
          
MidpointOSNext::~MidpointOSNext() {}
          
          
float MidpointOSNext::next(float freq, float phaseIn, float freqMul, float depth, float spread, float reduction, float lerp, float* buf, float* buf_, int* mSize, int* mSize_) {
            float phaseDiff = (phaseIn - lastPhase);
            lastPhase = phaseIn;
          
          
  int ix = int(phase * *mSize);
            float z = buf[ix];
            int ix_ = int(phase * *mSize_);
            float z_ = buf_[ix_];
          
          
  if (lerp) {
              float frac = sc_frac(phase * *mSize);

Sam_Pluta · January 11, 2024, 3:47am

Thanks. Well, the output of the Saw should go from -1 to 1, so this is why it is wrapped that way. But since the signal is being wrapped, -4 to 4 is essentially equivalent to -1 to 1. 1.2 wraps to -0.8 and 2 wraps to 0, etc.

I think I use -4 to 4 because SawOSNext::next is inherited by all the other oscillators. So it needs to work as the phase for all of the oscillators. And phase modulation needs to work with an input above and below 1 and -1. I’m not sure if it is always or even ever necessary…but I probably did that for some reason, haha.

BTW – I added Buchla-shaped and Serge-shaped oversampled folders since I last posted about this. They sound pretty good. And added mac and windows precompiled builds.

Sam

wwerkk · January 11, 2024, 7:22am

I see, so this is only about the wrapping for values out of range?
What I was thinking is if sc_wrap is sufficient already then?

Sam_Pluta · January 11, 2024, 12:50pm

It should be, yes.

Sam

Bubo · January 11, 2024, 2:24pm

I just tried these and the whole collection is very impressive. Is there a plan to distribute these with the base software? They are great additions to the existing oscillators and the Buchla part really shines.

Sam_Pluta · January 11, 2024, 5:17pm

Thank you. I think what we really need is a new collection of plugins. SC3-Plugins was frozen over a decade ago and there are a bunch of great new ones floating around github. The project would require someone with some solid cmake and github actions skills. A single download for all of these would be killer.

Sam

dietcv · January 11, 2024, 7:05pm

yeah, new state of the art OSCs in SC! To make aliasing an aesthetic is really not a thing anymore IMO!

jamshark70 · January 12, 2024, 3:06am

Hey @Sam_Pluta – downloaded and built these in Linux, no trouble, thanks!

How hard would it be to port Osc, COsc and VOsc(3) to this set? Oversampling is important for wavetables. (Actually oversampling BufRd would be fantastic too.) I’m not a great C++ person but I would use oversampling wavetable oscillators, maybe a lot, so I may be willing to do a bit of that lifting over my semester break (starting now).

Thanks –
hjh

Sam_Pluta · January 12, 2024, 11:01pm

I had started that at some point and it might have even been the whole reason I started the project. Those are quite a bit harrier than simple oscillators, but doable. Let me see if I can get one of them done.

BTW - it doesn’t say this in the help file, but the buffer position in VOsc is always control rate in and cannot be modulated at audio rate. Thus, you can never really get a smooth transition between buffers ala Vital. This will be fixed in the OS versions.

Osc, VOsc, and Shaper seem like solid targets. The real target would be to bake oversampling (and single sample feedback) into scsynth though.

Sam

Sam_Pluta · January 18, 2024, 1:40am

I added ShaperOS and OscOS. ShaperOS is basically Shaper, but using standard buffers and is oversampled. OscOS, for my needs at least, takes care of all wavetable needs. It can read through a single buffer or load a Vital/Serum style multibuffer, where there are something like 100 iterations of the wave in one file. The benefit of doing it this way is you can sweep through the buffer slices at audio rate, which was not possible with VOsc due to how the server loads buffers on each control cycle.

btw - if anyone can explain the format of Vital wavetables, I would love to know. When they load in Audacity they have half the samples as when they load in sc. I don’t get it.

Let me know if there are any issues with these. They aren’t as tested as the others…and the semester starts next week.

Sam

mousaique · January 18, 2024, 12:18pm

Hi @Sam_Pluta,

thanks so much for your work on these OS Ugens!
I was wondering if it as at all possible or in perspective to have an oversampled BufRd/PlayBuf? Or for that matter, could one use Osc as a replacement (or is there a limitation on buffer size or similar)?
Also, would these also run on a M1 architecture?
Thank you,
Jan