I’ve been working on making some oversampling oscillators in c++. Beginnings of the project are here:
I have made a Saw and VarSaw just as proof of concept and to learn how to do it. These use Jatin Chowdhury’s VariableOversampling class from Mads’s ported plugins. Has anyone else made any oversampling oscillators? I would love to know if I am just repeating work that already exists.
Here is a video comparing FM with a VarSaw and the oversampled OVarSaw2, and despite YouTube’s best attempts to add their own aliasing, I hear a striking difference:
If these will be valuable to the community, I’ll move forward and make more of these. But I would have questions for those who are wiser than I. I had to switch my approach from an “SC Source” approach to a “Mads” approach (basically because I couldn’t get the SC approach to play with the Oversampling library). But I might need help when making wavetable oscillators.
Inside the undocumented classes there are lots of UGens that seems to be oversampling ones, but I am not sure why they are all spread over there, maybe they did not work as expected… It seems that they are part of SCPlugins. I remember seeing even more of them, but I could not find right now…
This is really helpful. I can probably downsample using this code from the BerlachUGens library for wavetable-based synths, since it is written in the SC Plugins MACRO style. The problem I was having adapting to that style of code is that I don’t know how you store a Class, like VariableOversampling, in the classic UGen data structure. I was putting in the Unit struct, but it was getting corrupted somehow. If I make it a global variable, it works, but then there can only be one instance of the oscillator in SC. Not good. If anyone has an easy answer to that, I’m all ears. Or I could just turn the code into a macro, but that seems silly.
As with Dre, I had forgotten about Squine. That’s a great oscillator. But these have very different sounds, mostly because the squine will always be a sine wave in the upper register while the oversampling oscillator doesn’t change shape. Since variety is the spice of life, I think it would be great to have more options.
What would be interesting is a Squine oversampling by 2x and then being downsampled. Might be the best of both worlds.
I’m curious here: what is the difference between a band limited oscillator and an oversampled one? I would understand if the FM was happening before the downsampling needed, but otherwise isn’t it the same thing, apart from the fact the OS one might not be as drastic in its antialiasing?
I’m hearing a difference indeed, but I wonder where it lies… is it in the spill of the DS filter? That would explain the dullness (aka there is more aliasing and we like it…)
Seems like the source code file names have been changed to OversamplingOscillators.cpp instead. Would this fix it? I’m not familiar with cmake… would changing line 17 and 18 in CMakeLists.txt fix it? If so I can submit a pull request.
I tried that, and it allowed me to successfully run cmake .. -DCMAKE_BUILD_TYPE=Release -DSC_PATH=patch/to/sc but then I got the following error during cmake --build . --config Release:
~/OversamplingOscillators/OversamplingOscillators.hpp:6:10: fatal error: 'VariableOversampling.hpp' file not found
Hmm. How was that even building before? Very strange. I fixed it.
Boris, you need to have the source code for ported plugins. I just updated the project so that ported plugins source is in a folder you specify with cmake. So, now the following should work to compile (if you plug in the correct directories on your computer with SC source and ported plugins source):
cmake .. -DCMAKE_BUILD_TYPE=Release -DSC_PATH=<PATH TO SC SOURCE> -DPORTED_PATH=<PATH TO PORTED PLUGINS SOURCE>
cmake --build . --config Release
I am also not exactly a cmake veteran, so hopefully that fixes it.
PA, I’m not sure what you are asking. In the video, I was comparing VarSaw, which is not band-limited, to OVarSaw2, which is oversampled and downsampled. VarSaw has audible folder over. If you like it…well, I can’t really help you. OVarSaw2 computes a signal at N times oversampling, so in the video at 768000 (obviously overkill) and then filters it to downsample. I am using someone else’s library for this, so I have no idea if it is a good filter (and that is way beyond my knowledge), but the code comes from a trusted source. In comparison, Squine I think uses a polyblep approach to bandlimit, though I am not 100 sure.
I’m not going to send a billion updates to this thread, but for fun I coded up JOS’s faust bandlimited sawtooth in C++ and added to the same repo.
It blends two different version of JOS’s oscillator, the second order polynomial for frequencies below 5000 and the 4th order for frequencies above 10000. This is a lovely oscillator that allows frequency modulation across the spectrum.
This reinforces my feeling that we need these oscillators. Aside from basic functionality that has become possible over the past 20 years, there are some questionable design issues in the source. For example: VarSaw doesn’t allow a-rate modulation of the width, which is silly for anyone who has used analog gear. I imagine the same can be said for LFPulse, though I haven’t looked yet. Another weird one: VOsc interpolates over buffers at k-rate, which causes audible glitching with large wavetable sets. I am sure there are more.
So I am going to go forward with making a set of oversampling and polynomial bandlimited. Hopefully it will be of use. I will either see if it can be added to source or perhaps added to the ported plugins if Mads feels it fits there.