FINALLY - a way to to OVERSAMPLE your schematic for real!!!

[KG_is_back]

I have been messing around with the "call of Cuthulu" and I may have come up with something game-changing.... A way to oversample sections of your schematic. And I mean really oversample, as in execute the portion of your stream multiple times per sample!!!
It is not limited to assembler!!! You can put in any module with stream inputs/outputs and it will run that module at N-times the sample rate!!!

Now, this module is not fully finished. For proper oversampling the inputs and outputs should be low-passed at Nyquist/N frequency to remove aliasing. I haven't quite done that yet, because I was so excited to share this discovery with you.

The mechanism is actually very simple. In first ASM block in the signal chain I call the "call of Cuthulu" to get the memory address of the machine code at that point. I pass that value to the last ASM block in the signal chain. That one simply does call to that value which makes everything between the first and second ASM blocks repeat again and again. I added counter which breaks that infinite loop after N iterations. (there's a bit more details to it, that I may go over later).

Keep in mind that this will merely make the stream run at N-times the speed - if that code is samplerate dependent (ie. EQ, adsr, delays) you will have to modify them. Typically, multiplying the output of any samplerate prim by the oversampling ratio will do the trick. Some prims, however, read the samplerate in "hidden" way (for example the pitch to freq prims) - you will have to replace them.

[adamszabo]

Cool! Id love to see some real life examples

[Spogg]

Very exciting, I can see why you’re so pleased!

Like Adam said, it would be lovely to see something, maybe with an A/B comparison, to demo the advantage of this true oversampling.

Can the schematic “inside” the system operate on individual samples independently? For example, for better interpolation?

Cheers

Spogg

[KG_is_back]

Ok, here's an example. A bitcrusher. A true ideal bitcrusher should only reduce the amplitude resolution ie. distort the wave into stairs. That means it should only add harmonics and no additional disharmonic noise. That means if you bitcrush frequencies above cca. 12000Hz you should hear no difference (because the harmonics should be outside range of hearing). In reality naive bitcrusher adds massive amount of aliasing because at 44kHz sample rate the harmonics reflect back into audible range. This aliasing can be reduced by oversampling the bitcrusher and low-passing it, so that only harmonics below 20000Hz are there.

In this schematic you have two identical bitcrushers (the knob in the schematic controls the bit resolution of both). one is not oversampled and the other is (it is buried inside the oversampled module). You can switch the selector to see and hear one or the other. You can even increase the oversampling to further reduce the aliasing - it is clearly audible every single time you increase/decrease oversampling.

[Spogg]

OMG what a difference!

Fantastic demo KG.

I see the CPU increases, on my system, from 0.3 to 2.6 so is this just down to the oversampling magic? If there was more going on "inside" the oversampler would this be multiplied too or is it just the over sampling part?

EDIT: I just kinda answered this myself by deleting the Nyquist filters and found it's those that were taking up most of the extra overhead.

Thanks for sharing this. Brilliant!

Spogg

[KG_is_back]

EDIT: I just kinda answered this myself by deleting the Nyquist filters and found it's those that were taking up most of the extra overhead.

I should mention that in current state the oversampling is not very mathematically done I'm not quite sure HOW to interpolate the samples. At the moment I just take the input, oversample it into stairs (for example in 4x oversampling, I just take the original and keep it constant 4 samples, change with new value, keep constant, etc.). I then "smooth out" the stairs using a strong low-pass filter at Niquist/N (where N is the oversampling ratio).
I do the same on output just in reverse - strong low-pass (BTW this where the aliasing actually gets removed) and then take the LAST sample as the downsampled version. I know That this last step effectively delays the output by (N-1)/N samples - I could fix that by taking the first only, but I was lazy....

I'm certain that there are better more rigorous ways to do the up-sampling filter. For example the old way we used to oversample, was to take the input, interlace the input with zeros and low-pass that. The interlacing only introduces frequencies above original Nyquist. My experiments show that doing that stair-lowpass that I did actually introduces phase-shift/delay of 1/N samples.

I REALLY need some serious help with this...

[Spogg]

I just heard Martin’s “Someone needs a filter” alarm going off

[KG_is_back]

The biggest joke of all of this is, that this oversampling trick was actually possible all the way since flowstone was released. In fact it could have been done even back in the days of synthmaker (though ruby made it much easier to implement). Difficulty of implementing oversampling was always a major hurdle in making high-quality audio-plugins with synthmaker/flowstone.

[adamszabo]

Yeah, this is really amazing, I hope other chime in too, as this is a bit over my head at the moment

[tulamide]

Hmm, why am I experiencing something completely different? I started the schematic, it all went ok, then I switched the selector to the oversampling module and Flowstone crashed immediately.

Maybe it is not compatible back to the stoneage? Using v3.0.6 of Flowstone, that's why I ask.