Hello!

I have a question about antialiasing.
When i generate a rich harmonic sound using [tabosc4~] on high frequencies, i have aliasing noise: each overtone over sr/2 is flipped down and sounds unharmonic.

I've read about it here: https://ccrma.stanford.edu/~jos/mdft/Alias_Operator.html
and maybe not completly inderstand

So, as i can imagine, to avoid aliasing i need many tables for same wave, but with lower resolution for high frequencies. Or i need one hires table, and pregenerate new one for each new note, depending to frequency. Both ways looks to comlex.

Maybe there's an easier and faster way to do it?

Yeah, you can do that, or, depending on the CPU situation, you can oversample, read the table, and then filter out the frequencies above the lower sampling rate's Nyquist frequency before downsampling. Or, if you're just looking for a bandlimited sawtooth, square, pulse, triangle, or parabola wave, take a look at Maelstorm's patches here.

i've found this http://en.flossmanuals.net/pure-data/ch026_antialiasing/. it seems what maelstorm abstractions generates bandlimited sinesums, like is this manual.

i'm searching for optimal cpu-safe way for any-shape wave, but oversampling with complex lowpass filtering don't looks so.

If you're running at 96 kHz, you can use wavetables multisampled per octave. This way you don't need too many multisamples but will always have at least 20 kHz bandwidth and no audible aliasing.

Many synthesis techniques (FM, for example) are just inherently not bandlimited. The best you can do in those cases is be careful and oversample.

Also it won't help if you want truly arbitrary waveforms, but Moorer's DSF stuff includes bandlimited versions. I suspect most people are more interested in BLEPs these days, but they're still useful.

My band-limited oscillators are just table look-up, so processing-wise they're pretty efficient. They do take up a little bit of memory as I played it safe and just generated every waveform needed between 30 Hz and 22050 Hz, but each instance can share the same tables, so it's not really a problem. Now that I think of it, I actually have some pretty nice updates to those patches I should upload...

For arbitrary signals in which you don't know the spectral content beforehand, I think oversample-and-filter is probably the way to go.

so, oversampltng and filtering - is a standard solution?
but if i have 8 oscillators for each voice in polyphonic synth - it will not overload the CPU?

i've download your patches they sounds good. i didn't research deep inside yet. and i'm not completely understand why you need tables with size 754845?
also here is an conflict [wrap] vs [zexy/wrap], check it...
if you will update it, write more comments inside please

first time i hear about Moorer's DSF and BLEP.
Abuot Moorer i've found some, but what is BLEP?
would you give some links about please?

and one more thought: if after all this i freq-modulate one antialiased oscil by other, then i still get aliasing... ^^'

BLEP is a band limited step. There are other variations, BLIT, minBLEP, polyBLEP, etc. You can synthesize a waveform with discontinuities (saw, square, oscillator sync, plus triangle if you integrate again) by playing the discontinuity itself as a tabularized sample, without scaling its pitch. Audio example J09 isn't the fanciest version, but you should get the idea.

Here are a couple papers:

https://ccrma.stanford.edu/~stilti/papers/blit.pdf

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=707B9C1B98AC0C6CF6891873A577E8B9?doi=10.1.1.24.4317&rep=rep1&type=pdf

And yes you will still get aliasing if you add FM to something bandlimited (or waveshaping, distortion...). This is a big problem with virtual analogs since there's a demand for both high sound quality and modular-like features. It can't deliver both without a big penalty. In this case all you can do is oversample. But FM of arbitrary waveforms really isn't that useful. Any good result from wavetable FM or waveshaping will have to use very smooth waveforms anyway.

And I can't really answer for Maelstorm but he may be using large tables because interpolation performs much better on oversampled data.

Thanks for all answers.
I didn't expect that the subject is so deep.
Need to update my knowledge base.

@mozz: Actually, the reason why the tables are so large is because I'm putting all the generated waveforms back-to-back in one long table. The reason for this is that it allows for smooth transitions to the next waveform at audio rate by just adding or subtracting an offset. The alternative--using the [set( message for [tabread4~]--updates at block boundaries, which could result in some brief aliasing while it waits or possibly even some clicks.

And don't worry about that [wrap] "error". That's just there because previous version of Pd-extended loaded zexy's [wrap] by default instead of the vanilla one. It now defaults to the vanilla one, but [wrap] with no arguments is the same for both versions. It's just there to let people know that may need to update old patches. It should really be more of a warning than an error.

@acreil: Thanks for pointing out that J09 is based on BLEP. I've read those papers, and I could quite wrap my head around how to implement BLEP. I suspect something like this might be a useful approach for "softening" the transitions of hard-syncing oscillators.

Thank you everybody for this stimulating answers !

@Maelstorm said:

@acreil: Thanks for pointing out that J09 is based on BLEP. I've read those papers, and I could quite wrap my head around how to implement BLEP. I suspect something like this might be a useful approach for "softening" the transitions of hard-syncing oscillators.

Well considering one of the papers is called "Hard Sync Without Aliasing", you may just be onto something.

J09 uses a floating point divide, though, so it's not necessarily the best possible implementation. I did repackage it into abstractions for saw and PWM waves, but I suspect there's a better alternative out there that I haven't come across (not that I've really looked).

@acreil said:

Well considering one of the papers is called "Hard Sync Without Aliasing", you may just be onto something.

Haha! I think I opened up the wrong paper after downloading. Though I've actually read that one, too, so it's probably why I thought that.