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
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.
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…):
Can someone explain how to build it step-by-step, please?
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
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’)
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
Thank you a lot for helpful instructions. It worked smoothly.
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:
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
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?
It should be, yes.
Sam
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.
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
yeah, new state of the art OSCs in SC! To make aliasing an aesthetic is really not a thing anymore IMO!
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
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
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
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
Very eager to try these out! I hacked up a sweepy wavetable pseudo-UGen but it’s CPU heavy, and the sweep ended up not working all that well anyway. If you did it better than I did, I’m delighted 
hjh