Has anyone managed to implement a polyBLEP or similar oscillator with sync in PD? I have a good saw osc & a good PWM but I can't figure out sync.

Also can't figure out triangles. I suppose I can just filter a square but trying to avoid lots of upsampling & filtering.

@nuromantix Triangles can be gotten from you saw, just run it through {abs~] and then multiply by 2 and subtract 1 to get levels back to normal. This assumes the saw has an amplitude of -1 to 1 and the saw is reasonably formed, if not a little futzing with the numbers and shifting the waveform should solve the issues.

@nuromantix I'm working on a bandlimited ramp/tri/saw osc based on 8 partials ([phasor~] going through 8 [cos~] objects with amplitude and phase mapped according to desired shape). It's a bit convoluted but not too heavy on CPU.

BLsaw-tri-ramp.zip

Amplitude and phase was mapped using FFT and a lot of math - same method can be used to map any morphing waveshaper of your desire

I'd post the mapping patch but it's a mess, so maybe later when I've done some clean up.

The problem with sync is you get infinitely sharp transitions at the sync point which you'd then have to bandlimit - maybe the trick used in j09.bandlimited.pd can be applied?

Also, please share your oscillators if you dont mind?

@oid said:

@nuromantix Triangles can be gotten from you saw, just run it through {abs~] and then multiply by 2 and subtract 1 to get levels back to normal. This assumes the saw has an amplitude of -1 to 1 and the saw is reasonably formed, if not a little futzing with the numbers and shifting the waveform should solve the issues.

The problem here is if your saw is bandlimited you will get weird spikes at the short transition.

@oid - yes that won't work with BLEPped or bandlimited wavetables. fine for a naive triangle if you don't mind aliasing.

@bocanegra - thanks, I will check out your patch. I am using the PWM & sawtooth from the Heavy library, here:
link text
Yes creating your synced oscillators at a high sample rate, filtering and then downsampling works but it's very processor intensive. I can find some much more efficient implementations in C++ but can't see a way to implement them in pure data.

@nuromantix said:

Yes creating your synced oscillators at a high sample rate, filtering and then downsampling works but it's very processor intensive. I can find some much more efficient implementations in C++ but can't see a way to implement them in pure data.

There is no upsampling involved in j09.bandlimited.pd - it's a waveshaper that substitutes the infinitely short transition in a ramp for a short bandlimited one. Check it out

(If I am not mistaken the heavy library oscs implement the same technique)

@nuromantix I think that generally the way hard sync is done is by putting windowed sincs into a delay line. you can also make the impulses/steps more minimum-phase in order to avoid the delay. (that's what the bandlimited oscillators in the creb library use)
check out this paper http://www.cs.cmu.edu/~eli/papers/icmc01-hardsync.ps

@bocanegra - oh yes I remember now. You are right, they are both using similar techniques. The Heavy one is better because it has PWM, I think.

@seb-harmonik- I will check the link but I don't think I am going to understand it

jpcex external library has band limited PolyBLEP oscs with sync.

Find them via Find Externals.

Thanks. I will probably end up using them or creb. But I would love to figure out a way in PD vanilla without externals. I think I have almost got an anti-aliased triangle wave working without upsampling or filtering.

Shadylib also has band limited oscs. I think they don't use upsampling, actually.

@jaffasplaffa they don't use upsampling but they do use blit (leaky integration of a periodic sinc function/bandlimited impulse train) and so they can't use hard sync or too much frequency modulation unfortunately.
bc blit sounds better when you don't need those things imo. (I haven't checked out jpcex yet though, seems like it uses minblep too which might sound ok with long tables)

Ahh okay, that makes sense.

I think the jpcex sounds decent for what I tried for now. Haven't used it in a synth yet, only experimented with it.

Actually I used your Shadylib oscs for a Moog clone I was working on at some point and I had some issues with frequency modulation, it kind of "blows up" at times. Especially when feeding the same osc back to itselfs frequency input, like feedback, it blows up. Thought it was something in my patching, but since you mention it here, I think I'll try some other oscs and see if I get a better result. I like the ones form your library, cause it was pretty easy to get the right waveforms I was looking for, like sharktooth Moogish style

@jaffasplaffa yeah that's one of the issues, a result of the shape of the bandlimited pulse changing from jumping around frequencies (so the negative and positive parts don't exactly cancel out in the sum, and so then they build up in the integrator.)

@seb-harmonik-ar

I am going to take your word for it, this is a bit beyond my knowledge on the subject

Re: blit oscillators not being good for FM...
I think if you are doing FM and you don't want aliasing, you are going to have to upsample and filter anyway, so you may as well start with mathematically perfect waveforms and at least know what results to expect.
Anyway a bit of aliasing is nice on FM isn't it? The sound of Yamaha

tri wave from phasor is possible the same way than the others, (i cant tell you offhand now, but i think tri was the one where you also have to care for the phase(!).)

(eventually you will have to raise the number of partials from 8 to 12 or 16 to get the same spectral content as for sawtooth, not sure.)

and the most basic hard sync is indeed simple, you would just restart the phase accumulator early.

and of course you are right, when you run bl waveforms which you did by additive, you also wasnt to use bl sync.

regarding the use of blep/blit like phase accumulator modulations i kinda have the same request like you, so i keep watching, though it is doubtful anyone can answer how to do it on pd patch layer - efficiently and easy to use, that is,

@nuromantix For reference:

PolyBLEP triangle
http://www.martin-finke.de/blog/articles/audio-plugins-018-polyblep-oscillator/

https://christianfloisand.wordpress.com/2014/09/03/custom-pure-data-external-polyblep-sawtooth-oscillator/

https://www.kvraudio.com/forum/viewtopic.php?t=375517

Hard Sync without Aliasing in this thread:
https://forum.pdpatchrepo.info/topic/5507/antialiasing/7

Did someone do aliasing-free sync without filter in pd yet?

I've been digesting this and trying out stuff for a couple of weeks: http://argos.vu/wp-content/uploads/2016/05/Digital_Sound_Generation_1.pdf

It's a pragmatic "hands on" cookbook with recipes for -among other things- BLEP oscs (including triangle), FM and hard sync. It provides polynomial approximations for both sinc and sin/cos functions. The BLEPs are based on table lookups but you can cook your own with either cheap polynomials or just as cheap [cos~] lookups.

I am getting curious as to how (in)accurate PD's native [cos~] object is, prompting MP to use a 2000(+) sample array for his BLEP rather than [cos~] on the fly...

Thanks for the fascinating link.

polyBLEP is also implemented in faust. so faust2puredata and you are ready to go. i did not do any benchmark test, but gess faust generated externals are not so CPU greedy...

https://faustlibraries.grame.fr/libs/oscillators/