After reading this article
http://en.flossmanuals.net/PureData/Antialiasing
I decided to create my own bandlimited signal generator.

This external generates square, triangle saw, reverse saw and saw-triangle waves band limited to the nyquist limit.

In order to conserve CPU usage it uses a series of wavetables. Because of this it might take a little while (a few seconds) to load up the first instance.

The easiest way to use it is to add the bandlimited folder to your path. But you can also use it like this:

[bandlimited/bandlimited~ square]
[bandlimited/bl.sq~]

as long as the bandlimited folder is placed into a folder already in the path (ex: ~/Library/Pd on OS X)

...

There are wrapper abstractions for each waveform type (bl.saw~, bl.tri~, bl.rsaw~, bl.sawtri~, bl.sq~]

Start by taking a look at bandlimited~-help.pd

The object should act a lot like [osc~] and [phasor~]. The first signal inlet controls the frequency while the second float inlet sets the phase and it takes a creation argument for the starting frequency. There are three methods but I'll let the help file explain.

There should already be a win32 dll build and an OS 10.5 build. I'm sure linux folk can take care of themselves in this regard. Tested on PD-Extended 0.41

There's a repository here
http://gitorious.org/bandlimited/bandlimited

I plan on adding more waveforms and am taking suggestions.

v0.92

EDIT:
Version v0.92 includes a new waveform, pulse. This wave form is a lot like a square wave but with a variable duty cycle (it's not symmetric). This new parameter is set by a third signal inlet whose value should be between 0 and 1. 0.5 would give you a square wave.

Version v0.91 includes new method "approximate" which uses the CPU a little less for a close enough waveform.

http://www.pdpatchrepo.info/hurleur/bandlimited.zip

IMPLEMENTATION DETAILS:

adding up harmonics for each phase can use a lot of CPU power, especially for lower frequency. Even in the current optimized state if you try playing a low frequency such as 2 or 3 hz it'll probably go above 100% usage.

So I decide to trade memory for cpu. Once you create the first instance of bandlimited~ it'll create 138 wavetables of size 2051 for each waveform type (square, triangle, saw, saw-triangle; rsaw is just saw inverted). In each table there will be a waveform generated with a different amount of harmonics, it iterates by 8.

So the tables will look like this:
8, 16, 24, 32, 40 ... 1104 harmonics

In the perform loop what it does is calculate the number of harmonics needed for the specified frequency: cutoff / frequency (cutoff is the nyquist limite), rounds down to the nearest integer.

It then checks to see which wave table is closest the this number and then calculates the missing component, ex:

44.1Kzh, nyquist = 22050
generated frequency = 330hz
number of harmonics = 66
the closest wave table has 64 harmonics

It'll then use 4 point interpolation (borrowed from tabread4~) to generate a signal from this wave table and add the harmonics 65-66.

This way the calculation loop is guaranteed to never be greater than 4 iterations.

The sin function itself is also placed in a wavetable of size 2051 (3 guard points). But when creating the waveform wavetables it'll use the real function.

Because the wavetables represent waveforms up to 1104 harmonics any frequency that requires more will start to eat up the CPU. These frequencies would be the frequencies below the nyquist limite divided by 1104.

That would be about 20hz at 44.1Kzh, 30hz at 88.2kz ...

EDIT: grammar

from the description it sounds super!
perfectionism at work....

but why not the easier solution:

• span the tables over the preferred band (eg.: 5hz-20khz) so it is not samplerate dependant which frequency's get attention
• scale the harmonics exponential to reduce table count (== space usage) eg.: 8 16 32....
• if 66 harmonics are calculated use the nearest table 64 and just pan over to 128 or whatever is the next one (naturally not linear)

if you use a band limited generator you don't expect a perfect signal... just a good approximation of it...
with 2 key points:
1. NO aliasing
2. not much more time & space usage
so maybe do a simpler version, which doesn't try to be perfect (but hell keep this good work!)
well that's my opinion

what are the results of your comparison tests with oversampling+filtering?

thanks

Perfection is there reason. With this you get a signal that fits perfectly in the band.

If I understand you correctly you could still get aliasing. If you start at a high frequency and move to a lower frequency in the time it takes to mix from the wavetable with a lots of harmonics to the one with few you could get aliasing.

As for using an antialias filter, if you're using one filter over many signals than that is certainly cheaper than this solution. On a Core 2 Duo machine one object uses about 5 percent of the CPU. It can add up. But again like you said, this solution should be perfect. With a filter you would need it perfectly flat on the passband, no stop band and no FIR delay to get it this good.

In the end 138 (number of wavetables) * 4 (number of waveforms) * 2051 (wavetable size) * 4 (float word length) = 4.32MB
which isn't that much memory.

As far as the code is concerned I wouldn't be at all surprised if there are more optimizations that can be performed.

One limitation I have found with this solution is its inability to make a pulse wave with variable duty cycle. Which is a bummer because those sound cool.

yeah but is your perfection audible?

the question was if you did already all that could you make a cheaper version?
to compare: my current msia3 (the oto distortion) uses ~ 4.5% cpu on my c2d
and how much worse does it get if you choose lfo like speeds of lets say 2hz at a 120khz samplerate?

you could make the pan start at the point where the next table sets in to completely avoid aliasing
or a little bit sooner. who cares if the harmonically richer signal is at .1 versus .9 and the last harmonic is at 25khz with a nyquist of 22.1khz?
i bet its inaudible

a common mistake i found in a lot filters: does your bandlimited recognise when the samplerate changes and recalculate?
also i think it would be nice to set the band manually: min(userchoice,nyquist)

well that's the sad reason why they invented analogue synths :/
you have to force them to create aliasing

>you could make the pan start at the point where the next table sets in to completely >avoid aliasing
>or a little bit sooner.
Kinda hard to know when to change sooner if you're playing it on a keyboard.

>a common mistake i found in a lot filters: does your bandlimited recognise when >the samplerate changes and recalculate?
It gets the the samplerate when dsp is turned on. My computer crashes whenever I change the samplerate with the dsp on so it's not an issue for me. But if it is for you it's just a matter of placing that bit of code inside the perform function.

>also i think it would be nice to set the band manually: min(userchoice,nyquist)
There is a method that let you set the max number of harmonics and one to lower the cutoff frequency. Pretty much acts like a brick wall low pass filter.

>the question was if you did already all that could you make a cheaper version?
>to compare: my current msia3 (the oto distortion) uses ~ 4.5% cpu on my c2d
>and how much worse does it get if you choose lfo like speeds of lets say 2hz at a >120khz samplerate?
bandlimited~ uses 5% on mine as long as it's within the wavetables. It does not work at all at LF (2hz even at 44.1khz), but you can lower the number of generated harmonics to make it work (20hz is the lower limite at 44.1, at 120khz it would be 54hz). You could alter the code to make it generate more wavetables easily though.

I wouldn't really use this object for a control signal though, I would just use a regular square wave (phasor~ minus pharor~ with a phase of .5 between them) and use a low pass filter if need be.

You right that about it not needing to go all the way about to 22.05khz. Between 14-15 khz is when I notice a difference.

Made some changes. The new version includes a method "approximate float". If 0 then the object will calculate the number of harmonics perfectly. If 1 then it will use the nearest wavetable with numer of harmonics less than or equal to the required number of harmonics. Approximate should be good enough for most cases and uses slightly less CPU.

The difference in CPU usage is not great but if a lot of bandlimited~ objects are used it adds up. By enabling approximate the object will not perform a loop up to 4 iterations calculating a 4 point wave table interpolation and be off by at most 7 harmonics.

neat... thanks
now it should be possible to go down to what ever lf you want to...
i have to try it

Just realized though that even with the expensive algorithm it will never go above 1104 harmonics. So anything below 20hz will be "approximate" irrespective of the setting.

Did't mean to make it work this way, but it's probably a good idea.

wow. This is really huge.

thanks for the work towards this.

a good band limited oscillator is a great addition, I'll be using this extensively.

the zip in the attachment, is that updated to .91 ?

thanks,

yes it is

Has anyone done this in vanilla Pd? A while ago I made something similar that generated a bandlimited sawtooth table for each MIDI note in the audible range, but I can't figure out a way to switch between tables at signal rate using vanilla objects.

I first mocked it in PD without C. I ran into that very problem, switching only occurs at the beginning of the block.

Yeah, I thought I could circumvent it by using [bang~] instead of [metro] to trigger a [snapshot~], but then I found out that even when you reblock, [bang~] won't bang more than once every 64 samples. I think this is the first time I've hit against one of Pd's limitations.

So I'll have to try your external!

I actually came up with a Pd implementation that seems to work at about the same time saturno posted these externals (which are nice, btw!). Since he helped me out with testing [vphasor.mmb~] I decided not to post them right away so as not to steal any thunder. But seeing this reminded me that I never did finish the triangle wave, so I'll try to finish it up and post them in the next day or so in the abstract~ section...hopefully.

square, triangle and saw are pretty easy. I gave up on variable duty cycle pulse wave. It was be pretty nice to have noise generators too.

Here's Maelstorm's version which is not implemented as an external

http://puredata.hurleur.com/viewtopic.php?pid=18931

New version

Version v0.92 includes a new waveform, pulse. This wave form is a lot like a square wave but with a variable duty cycle (it's not symmetric). This new parameter is set by a third signal inlet whose value should be between 0 and 1. 0.5 would give you a square wave.

Duty cycle is the ratio between the pulse duration and the period.
http://en.wikipedia.org/wiki/Pulse_wave

This is very impressive and immensely helpful, Saturno & Maelstorm.

I am wondering why an 8 order LPF will not accomplish anti-aliasing satisfactorily, that is, to an inaudible level. Feel free not to get carried away if it's the imperfection of digital filters/ oversampling discussion.

Perhaps I distort a band-limited oscillator - will this add frequencies past the nyquist? FM seems even more dangerous.

In other words, is it possible to design an abstraction to place before all DACs so that one does not have to worry about aliasing?

the trouble with that is the aliasing artifacts are fold-over artifacts, the frequencies fold over into lower-than nyquist bands.

So if you generate a signal that aliases, the artifacts are already present in the audible range.

so you must supersample your oscillator from the start, or generate from band-limited look-ups.

These externals aren't really built for fm, they don't take through-zero audio-rate modulations, If I recall correctly

Then if you want to distort these without aliasing, you must upsample your signal, distort and then downsample with the filters in. Steep filters at nyquist only work when you use supersampling like that

This is the way I have come to understand it. Although I am only involved in all this casually and not professionally. Someone feel free to correct me.

Distorting often adds harmonic frequencies which would lead to aliasing, even with an originally bandlimited signal.