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

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.

@PonZo said:

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?

No. If that were the case, it would probably be a vanilla object by now, because everyone would want it. The best you can do is to make sure you don't alias to begin with.

One more thing. Using a LPF by itself often is not enough, you have to do so in an upsampled block. Check out the original article.

http://en.flossmanuals.net/PureData/Antialiasing

Thanks, it hadn't occurred to me that the aliasing was present in the data itself, before DAC, but that makes sense because the data is also limited to the sample rate, duh.

What a pain, it really makes me wish I could afford more outboard gear, and now that I understand the perils I'll be listening carefully for any dirty harmonics. With the amount of synthesis that I need I feel that the upsampling is not practical.

Good one, Maelstorm, I imagine it would be built into the DAC object if it were possible!