How to build piecewise oscillator algorithm using polybleps in Reaktor

Hello friends!
I'm trying to make analog-like osc in Reaktor, so I'm interesting in piecewise oscillator algorithm.
I don't know much about it, because on the web only code is presented, but nothing Reaktor-related.
Can you help me to implement it in Reaktor please?
Thanks!

 

Have a look at the R6 library oscillators these are mostly poly blep implementations. So are the Monark and Bento Box oscillator blocks, The Bento Box one is a heavily modified version of the library '4-wave' macro.

It is much easier to understand if you can read normal code though. Also search for academic papers that explain some of the maths. And while you're at it, search the kvraudio forums for 'poly blep'. You'll get lots of useful info there.

Poly Blep is a horrible thing to implement because it is a huge fudge. There are lots of corner cases, so you need to build a complex structure of routers that apply different bits of code depending on the current circumstances. Adding sync increases the complexity, adding FM increases it some more.

Mystran on kvraudio has written a pretty good explanation of one approach to implementing poly blep, so definitely look there.

Also worth looking at PTR and EPTR algorithms. There are pretty good papers available explaining these. And the basic idea is very similar to polyBlep, in fact they are probably a specific form of polyBlep.

EDIT: note also, that there is absolutely NO POINT in doing this as an attempt to model a specific analog oscillator (e.g. Voyager) unless you have the actual hardware available to analyse, the tools to analyse it with, and an understanding of how to use them without causing costly damage.
I guess what would be worth doing is rather than trying to create an 'authentic' model, just try creating an anti-aliased digital oscillator that morphs between waveforms in the same way voyager does. This would be a good project, and definitely achievable using polyBleps or (e)PTR.

 

My mind was blown away! Thanks!

 

maybe i did something wrong, but i found eptr to alias pretty badly when i tried it.
that was a while back though, so again, i may have screwed up somewhere.

 

My understanding is that 2nd order eptr isn't great, but as you increase the order, things improve significantly. Eptr is equivalent to ptr. There is a website accompanying the ptr paper that has examples of different orders, it does clean up a lot.

I still found that the basic 2nd order version was still a huge improvement over naive.

EDIT: here's the site
There are audio examples of ptr at width 3 and one at width 2 with comparisons to naive. Sounds pretty good to me. There are also source code files to download.

 

okay, i'm not saying it's terrible or anything - and i probably tested with a lower order. i used to play in some pretty loud bands in high school so my ears aren't the greatest - i do my testing with a spectral analyzer and judge by how much aliasing you can see. i usually can only hear it in the higher registers, for a decently designed osicillator. you can see on that link some pretty significant artifacts all the way down to around 14kHz, even with a higher order. whether you can hear them, i dunno.

but it's certainly worse than DSF/BLIT based methods, which are 100% alias free. EPTR seem quite similar to (and somehow related to) the valimaki DPW oscillators from a decade ago.

here's a paper on creating an EPTR wave that can morph from sawtooth to triangle, so maybe good for that purpose.

http://home.mit.bme.hu/~bank/publist/smc13.pdf


XOR synthesis looks cool, i wonder if a properly implemented hardsync could achieve that.

 

Such osc sounds is pretty much like analog osc? I mean quality of the sound.
Do I need to bandlimit it? And why?

How to make it?=)

 

Guys I also found this publication https://www.researchgate.net/publication/3321831_Antialiasing_Oscillators_in_Subtractive_Synthesis
It seems like only BLEP and Additive algorithms sound excellent

 

I suppose it depends on your philosophy. For me it's about sound. If it sound good enough then it is good enough.
The ptr approach is very cheap, so you can over sample it, that's really useful, because you're probably oversampling no linearities on filters anyway, so you don't need to up-sample in-between.

I have found that although it's a pain to implement, stuff like sync is much easier to implement gracefully in ptr (or one of the other blep approaches).

It is directly related to dpw. Just cheaper and more versatile.

Yes, if you want 100% alias free, then you need to look elsewhere, but as an engineering compromise it is ideal in some circumstances.

Personally I find the basic w1 eptr is pretty good at 96k and very good at 192k

 

oversampling is an interesting idea - really, wouldn't only the transition period actually need oversampling? the rest is already anti-aliased. i guess at that point you're getting something closer to a blep, but the implementation seems easier to me. i dunnno, seems like the CPU hit from doing that might make it not worth it.

i guess it would be cheaper to increase the order, duh...

 

It's not worth trying to oversample just the transitions, the overhead of the management code would be way more than the cost of repeating the non-transition section per oversample.

My point is that if you have a filter that you are 4x oversampling, and you are using a non-oversampled oscillator, then you need to upsample the oscillator. However, if you are 4x oversampling the oscillator already, then no upsampling is required. In this case you can use a cheaper oscillator algorithm - although it would still be better to low pass filter the output of the oscillator before the filter input to wipe out as much ultrasonic as possible, particularly when using aliased reduced algorithms rather than alias free. So that increases the cost again...

If you just need pure classic waveforms, then you're probably better off with one of the 100% bandlimited algorithms, but if you want e.g. hard sync, or if you want to build more accurate 'analog' modelling into your oscillator using piecewise sections, then maybe bleps or PTR have the advantage ?

 

Yes, I built that one a while back to see what it sounded like. It's not the same type of morph as the Moog oscillators have though.
The one in the EPTR paper morphs by changing the symmetry of a triangle wave, making one side steeper and the other less steep until it approaches a saw. The Moog oscillators do it by turning the triangle into a 'sharktooth' and increasing the size of the saw tip on the sharktooth. It's a completely different sound to the transition.

I've attached a naïve implementation of a Moog style morphing osc - no good unless you like mucho aliasing, but it demonstrates the concept.

 

Awesome, Colin!

 

but I think original saw has more bend- and a 'sharktooth' of original saw has higher peak (transition when the triangle becomes a saw)
And I think PWM should stop at around 0.504 of "Shape" knob

 

The posted example is a 'naive' implementation. You can't use because the aliasing will be terrible - it is not bandlimited or anti-aliased. I just posted it to demonstrate the type of waveshape morphing that Voyager oscs have.

As far as 'bend', some of the 'bend' you see in scope plots doesn't come from the oscillator - it can come from filtering after the osc, and also from the scope itself depending on the settings used. It can also be introduced by saturation in amps stages.
That's why there is no point in trying to model hardware unless you have the hardware and the knowledge to work out the details by analysis.

Not sure what you mean by a "higher peak (transition when the triangle becomes a saw)"

 

I mean this

For example, here is Voyager wavetable in Serum


Original "element" is thinner and higher

Also take a look at this bend-

 

That's just a function of the scope setting and the waveshape setting.
Try changing the scope time base to 50 and increase the shape setting a bit.

That's where analog modelling comes in. There is no way to know how to accurately model that without having a lot more data and doing a lot more work. If you want to create the model, then you need to collect the data, and you need to do the work. The links I have posted have all the information and knowledge you need.
Alternatively, just use one of Reaktors excellent library oscillators, or one of the superb Oscillator Blocks from R6.

 

Thank you, Colin! I will modify Bento Box osc and/or Monark osc using your method for morphing=)

 

So sorry to say this is beyond my forces now

 

it seems like you could make that oscillator completely bandlimited with a hard-synced BLIT core, with the master oscillator running faster than the slave, and the reset starting at a position other than zero. not sure if that last condition is possible, but i don't see why not?

EDIT - after testing, it certainly seems to give a similar response the misha's picture once bandlimited. creating a full oscillator around it would be pretty complex but i think doable. i just tested the saw-square transition.