Emulating an antialiased Osc ( \[Phasor~\] )
Hey,
isn't there already a way to just emulate the behaviour of an anti-aliased [phasor~] (..to just limit the problem to a ramp-shape (or other simple shapes)..) ??
-If not, do you think it's possible to achieve that??
The procedure shown in the "J.08 classicsynth"-example is a CPU-killer with all those filters and the "times 16"-samplerate... can't one somehow predict or approximate the shape of the, again downsampled, signal?
Bye
Flipp
For an arbitrary shape, the upsample-and-filter method is really it. In the case of "classic" waveforms in which we already know the shape and spectrum, there are ways to band-limit without upsampling. J09.bandlimited.pd shows a way of replacing the discontinuous jump every cycle with a smooth transition (the jump is where the aliasing comes from). It's not perfect, but it's pretty efficient. If you actually are looking for specifically the shape of a filtered [phasor~], I think that's probably the way to do it.
The bandlimited oscillators from my library uses many waveforms built from sums of sinusoids and selects the appropriate one depending on the frequency. There's virtually no aliasing and they're pretty efficient. The tables take up about 25MB of memory, but these days that's not a big deal. If aliasing is your main concern, that's a good way to go.
At first I thought about having some wavetables (..the more the better..), say one per half-an-octave and kind of interpolate between them for frequencies in between?? -Do you mean something like this??..
..Or what's about using fft and just 'cut' the high frequencies?! But I guess it'll introduce some other artefacts...
Anyways, the "J09.bandlimited.pd" example is a good point to start from. ..I think I'll have to read it a 'second' time, to get it..
You don't have this library uploaded anywhere, do you?? I guess the 25Mb don't fit into your "whole freakin lib"...
Is it ok to say that in time-domain the reason for the aliasing is the "jitter" since we have a quantized (..to samplerate) time?! So that the jump from high to low often (if not always..) occurs a little too early or too late..??
@Flipp said:
At first I thought about having some wavetables (..the more the better..), say one per half-an-octave and kind of interpolate between them for frequencies in between?? -Do you mean something like this??..
Yep. I did one for every harmonic that gets lost past Nyquist when the fundamental increases, starting at about 30Hz. But that's probably more than necessary.
..Or what's about using fft and just 'cut' the high frequencies?! But I guess it'll introduce some other artefacts...
That won't work, because they'd already be aliased when you do the FFT. You would still have to upsample first.
You don't have this library uploaded anywhere, do you?? I guess the 25Mb don't fit into your "whole freakin lib"...
It's part of that library:
Is it ok to say that in time-domain the reason for the aliasing is the "jitter" since we have a quantized (..to samplerate) time?! So that the jump from high to low often (if not always..) occurs a little too early or too late..??
It's not the jitter. It's because discontinuities, from a Fourier perspective, are made from an infinite number of sinusoids whose phases happen to be perfectly lined up to create a sudden jump. The "infinite number" is what causes the aliasing. A perfect analog sawtooth will still have an infinite number of harmonics, which alias when converted to digital.
Thanks, Maelstorm. That's an interesting lib, I'll have to take a closer look at it tonight..
I found some interesting things on the web. There's a pdf that outlines some (not to say many) of anti-aliasing methods... Could you tell me how exactly the technique you use is called?!?
And what do you think of just ifft-ing a given, "bandlimited" spectrum??
..Or using some ~100 sine-oscs + amps for each harmonic and switch everything above f_nyquist off, so additive...??
..and are you shure it's not the jitter in time (of the high-low transition)? I agree with the fourier-perspective but that's frequency-domain again.
I mean, if you take an analog signal and feed it directly into your speaker, you won't hear any aliasing..
Now if we put a raw "adc-dac" with its limited time-resolution, like a pc, in between, the digital speaker-signal only differs from the analog one at the discontinuities, especially if we take in concern that the speaker itself has a non-zero mass so kind of interpolates (or "LPs") the steppy digital signal.. ..so if that's the only thing that is different, the jitter must be the cause for the aliasing seen form the time-domain-view...
@Flipp said:
Could you tell me how exactly the technique you use is called?!?
Table look-up, I think.
And what do you think of just ifft-ing a given, "bandlimited" spectrum??
..Or using some ~100 sine-oscs + amps for each harmonic and switch everything above f_nyquist off, so additive...??
I've tried calculating a spectrum in the frequency domain and IFFT-ing it. It's a pain in the ass. The major problem, I think, is that the FFT discretizes the spectrum and that no window acts as a perfect bandpass filter. So frequencies that don't sit right in the middle of an FFT bin have energy spread out to other bins. If you want to do it that way, you'd have to figure out what the energy distribution of the individual frequencies would have to be as well, and it becomes a computational mess. I don't think I ever figured it out.
As far as additive, the more oscillators you use, the higher the computation. And the less you use, the lower the accuracy. For low fundamentals, there's room between the fundamental and Nyquist for around 700 harmonics. So there are trade-offs you'll have to make. But you can easily ensure no aliasing this way.
..and are you shure it's not the jitter in time (of the high-low transition)? I agree with the fourier-perspective but that's frequency-domain again.
All audio signals can be represented in both the time domain and the frequency domain. They are still the same signal, just different representations of it.
I mean, if you take an analog signal and feed it directly into your speaker, you won't hear any aliasing..
Analog signals don't alias. You can make an analog signal jitter if you want, but it won't sound like aliasing.
Now if we put a raw "adc-dac" with its limited time-resolution, like a pc, in between, the digital speaker-signal only differs from the analog one at the discontinuities...
That's because the adc low-pass filters the analog signal when converting it to digital. The lowpass filter causes the discontinuity to smooth out like that because it no longer has the infinite number of harmonics to make it jump like that.
@Flipp said:
There's a pdf that outlines some (not to say many) of anti-aliasing methods...
Could you please share the link ?
Thanks,
Nau
Yeah, frequency- and time-domain are alternatives. So whats the reason described in time-domain..
That's because the adc low-pass filters the analog signal when converting it to digital. The lowpass filter causes the discontinuity to smooth out like that because it no longer has the infinite number of harmonics to make it jump like that.
...But... 
..if I filter an analog signal with an analog lp there is no aliasing. So a lowpass-behaviour is not the reason in general. And technically there is no analog circuit that produces an instantaneous jump (some ns but not 0s), so even analoge waves won't have that infinite number.. And what's about Tri-waves, they 'at least' don't have a jump but just a (ehhh what do you say...: knee??) ..a knee, a kink... So it can just be connected with the quantized time..
@Flipp said:
Yeah, frequency- and time-domain are alternatives. So whats the reason described in time-domain..
They're still the same signal. If it happens in the frequency domain, it's happening in the time domain. We're just looking at a different representation of it.
..if I filter an analog signal with an analog lp there is no aliasing. So a lowpass-behaviour is not the reason in general.
There's no aliasing because it's not digital. Digital signals cannot faithfully reproduce frequencies above half the sampling rate (Nyquist frequency). Anything above that gets aliased. Analog signals are not restricted by a sampling rate and therefore do not alias. It has nothing to do with the filter. The filter in an adc is meant to get rid of those frequencies above Nyquist to keep those frequencies from aliasing when being converted to a digital signal.
And technically there is no analog circuit that produces an instantaneous jump (some ns but not 0s), so even analoge waves won't have that infinite number..
True, but they are fast enough to generate frequencies higher than a 44.1kHz digital signal can handle.
And what's about Tri-waves, they 'at least' don't have a jump but just a (ehhh what do you say...: knee??) ..a knee, a kink... So it can just be connected with the quantized time..
Triangle waves are a little trickier to understand. The corners themselves are not discontinuities. But those corners are produced by discontinuities in the first derivative of a triangle wave. This still requires an infinite number of harmonics to produce, but they roll-off faster.
They're still the same signal. If it happens in the frequency domain, it's happening in the time domain. We're just looking at a different representation of it.
Yeah, dude, I know that... that's what i said: They are (the) two descriptions of one signal, since it's a transformation! But the 'reason' why things are like they are get "transformed" as well. And I just wanted to get a "time-domain-approach"!!!
E.g. (..it was too simple to directly remember this): You can actually even see the alias of a raw saw-osc in the timedomain! Just have a look at the [phasor~]s output: There is a saw with a different f "occuring" mixed with the original. And the reason for this simply is the oscs wrap-function and the discrete time (and that in a saw the out-value is directly related to the position per period (->time per period))!!!
This is how a saw actually is calculated, it's (..or was..) a recursive algorithm:
Say S_n: Saw-Signal at Sample "n" , f: osc-freq., sr: samplerate
Then S_n = wrap(S_(n-1)+f/sr); "wrap" wraps between 0 and 1.
Or lets say it like this: if S+f/sr < 1, then S=S+f/sr, else S=S+f/sr-1.
I don't say that explanations become easier in time-domain, they in fact mostly don't.. but sometimes:
For Example have a 'spectral' look at the [phasor~] at f=sr/n, with n=1,2,3,...
There is no (almost no, tiny, tiny little...really) aliasing at these frequencies. And the reason for this in time-domain is simply that the phasors stepsize perfectly fits into one period (and so does the quantized time!!), sothat there is no offset (or borrow, or carryover) for the steps of the next period:
Each Period looks the same!! In contrast, if you'd take a slightly different f, and take a look at the above formula there will be an offset introduced (added to the old offset) like Ofs=S-1+f/sr each time the jump occurs. And this offset itself will wrap between "0" and "f/sr" (=stepsize)! ...Now there comes a fractal natur: Since the Offset behaves just like the original saw-algorithm (.."sr" becomes "jump-rate"...), one can introduce (calculate) the offsets-offset, and so on and so on... but that can be classified as "higher order" and just makes things more confusing.. (but is true..)
==> So this recursive algorithm in timedomain can finally be split into two ("1st order") signals: The fundamental-saw with its own f & amp and the "alias-saw" or "offset-saw" with its own f and amp (=stepsize) 
If noone has any objections against this statements, ..lets say they are correct..
I don't understand your argument here. If you set the frequency of [phasor~] to be an integer multiple of the sampling rate so that you don't get this "jitter", you will still hear tons of aliasing. If the aliasing is still there, how could you say that this jitter is what's causing the aliasing?
If noone has any objections against this statements, ..lets say they are correct..
That's probably not the best idea. 
"tons of aliasing" slightly differs from "almost no, tiny, tiny little...really" ...
At "f=sr/n" I just took your "bl-saw" and substracted it from the aliasing-saw... ...that 'mouse-whisper' I hear has nothing to do with "tons of alasing", and I mean at these f's the occurance of unwanted frequencies is suppressend best (without any further manipulations). ...your bl-saw is a little more quiet than the raw-saw, don't forget.. so 1:1 mixing won't work...
With aliasing I at first mean the audible pseudo-saw(s), that is mixed with the 'original' and goes up and down in freq. while the originals f just goes into one direction. So we have some unwanted inharmonic frequencies as well..
That there still is aliasing can be explained by the fact that we make "lines out of points", it's like a s&h-unit: the value at one specific timepoint is kept until the next one comes in. Physically spoken, the loundspeaker is always a little behind..
..but that "unwanted frequencies-aliasing" is (due to no jitter -respectively: since every period looks the same) gone.
Okay, there actually is tons of aliasing when the when using an integer multiples of the sampling rate, it's just not as noticeable because the aliased frequencies all fold over ON TOP of the harmonics. In other words, the aliased frequencies happen to be harmonically related.
Take a look at the attached patched. You'll see when you switch to the [phasor~] that the harmonics increase in level. That's because the aliased frequencies are added to the non-aliased once. You can specifically see it at the DC frequency. That DC is entirely created by the aliased harmonics.
That's what i meant. ..f-domain is way cool to use.. However, I think everything related with foldover is a f-domain-description again.
...yeah, I did the same as in the patch, and the folding over explains the dc. But DC doesn't influence the tone. In time-domain the reason for the dc at f=sr/n lies in the osc-algorithm: say we start at 0 and add 0.2 each sample and finally wrap that:
0, 0.2, 0.4, 0.6, 0.8, 0, 0.2, ... So we have a relative offset of -0.1 (=> 0.4 instead of the "usual 0.5"). ...-"stepsize/2" in general. ...sadly osc's tend to drift (in numerical values)...
I attached a patch, derived from your "bl-saw.mmb~-help.pd"-patch, that compensates that offset, or DC (without an HPass), and approximately brings out the aliasing.. and I don't hear much..
Isn't it a saw that folds over on top of the saw, so that it still is a saw but lounder?? So the bl-saw is "normal" and the raw-saw is just .."louder".. (argh.. maybe not really, but "sawish" ..no, not sawfish.. )
...and there still is more aliasing occuring at upper f's since the "time-smear" i mentioned before becomes more and more relevant..
... Could you please share the link ?
Oh, sorry Nau. I just took a look at the whole thread, ..didn't see you before...
..and the answer is NO ...I don't remember exactly.
I googled something like "alias oscillator". Try that ..there are many documents.
Thank you anyway, Flipp...
@Flipp said:
That's what i meant. ..f-domain is way cool to use.. However, I think everything related with foldover is a f-domain-description again.
Right...I guess I'm just not sure why you have a problem with that. I mean, we're talking about aliasing here. That's a frequency phenomenon. Why do you want to describe what happens in the frequency domain using the time domain?
As for your patch, there's still a DC offset there, and I think it is because you are really only attempting to deal with 0 Hz. But the aliasing is coming from frequencies above that (such as 44100 Hz). Simply making a waveform perfectly symmetrical doesn't mean there is no DC offset. Take a look at a pulse train, for example. And you're not going to hear so much aliasing because, again, the aliased frequencies are sitting right on top of the non-aliased ones.
Isn't it a saw that folds over on top of the saw, so that it still is a saw but lounder?? So the bl-saw is "normal" and the raw-saw is just .."louder".. (argh.. maybe not really, but "sawish" ..no, not sawfish..
Yeah, not really. The frequencies between Nyquist and the sampling rate, after aliasing, have a spectrum that looks more like a "reverse saw". Then between SR and 1.5*SR, it looks like a saw, and so on.
...and there still is more aliasing occuring at upper f's since the "time-smear" i mentioned before becomes more and more relevant..
No, this is because of the "reverse saw" spectrum. The loudest frequencies that alias are just above Nyquist
Right...I guess I'm just not sure why you have a problem with that. I mean, we're talking about aliasing here. That's a frequency phenomenon. Why do you want to describe what happens in the frequency domain using the time domain?
...f-domain is so handy because the pc does all the calculations, and there are used approximations, interpolations or leaky integrators as well... And that's already the reason: Calcuations in the time-domain are faster, while harder to "design", most of the time. I already have some things that work pretty well in terms of alias-suppression. But the math behind it is just "1st order" and of course using higher math uses more cpu-power.. (I also got a saw-osc that doesn't produce these wobble-sweep-harmonics while it's f gradually changes. It works with smoothing the jump.. But i won't post it yet, 'cause the "math" are just values from experiments i did with the osc, and yet i don't know completely where these numbers come from... )
That's a frequency phenomenon.
...yeah OR a time-phenomenon... one doesn't exclude the other...
...hmm, the patch... ...I tried it again, and it didn't work as well. But that's not our fault!! (Everything points to a dsp-bug i mentioned in an other post.. or it's a bug with the [vline~] ..if i remember correctly that object is a little buggy anyways..)
Soooo I did a second one, that can hande the "crazy situation" and posted it here.
Please have a second try. ...Actually i just didn't change the calculations, but rearranged the dsp-order...
From time to time if i load the patch it doesn't work from the start! If that happens to you click the [-0.5( !! ...but it would be best not to happen at all...
--> It seems the ramp sometimes doesn't start at "0" (..0, 0.2, 0.4...) but at the next value "0.2". So we have to use [0.5( or [-0.5(...
Well, if everything works as it should, one can see that there is NO DC! But it slowly comes back due to numerical errors. That's why we have to sync, or rather "restart" the oscs from time to time.
Simply making a waveform perfectly symmetrical doesn't mean there is no DC offset
I don't think so! Mathematically it does just mean that.
E.g. if I invert a waveforms amplitude and play it time-reversed, and the waveform still looks the same, there can't be any DC-offset. If there was, it wouldn't look the same anymore...!!!
No, this is because of the "reverse saw" spectrum. The loudest frequencies that alias are just above Nyquist
...but that's f-domain again. Lets imagine we could hear far beyond the samplingrate (say 44100). Now as we sweep up a sine, it starts as a sine and at 22050Hz ends up as a square! And if ther was no "smear", that is a s&h-like behavior in time, the output of the sweeped osc at 22050Hz would rather be a tri-shape since we just have points instead of "lines" in time (and we assume "physics to be steady outside the pc", so we kind of interpolate between those points).
...this just as one reason for aliasing seen in time-domain!
An example where timedomain is really "better": Imagine we have to build an ANALOG "aliasing-device". It simulates aliasing of a given waveform/spectrum:
-As a freq.-domain approach we would take some sine-oscs and tune each according to the foldover-theorems etc. (and the waveform itself) ...as well as setting each amlitude of course.
So we create a "additive-aliasing-synth" that beside the harmonics has to calculate even the disharmonics... That's faaar too much...
-As a time-domain approach we would just use... well..a pc.. ...rather a sample'n'hold-unit ((..like in d'n'b, -hihi . )), since it's part of any "adc-dac".
Well if that wasn't easier, then idk...!!!
@Flipp said:
...f-domain is so handy because the pc does all the calculations, and there are used approximations, interpolations or leaky integrators as well... And that's already the reason: Calcuations in the time-domain are faster, while harder to "design", most of the time.
The frequency domain is also a useful tool for designing time-domain solutions. The easiest way to design an arbitrary FIR filter, for example, is to do plot the desired spectrum and perform an inverse Fourier transform on it.
It works with smoothing the jump.. But i won't post it yet, 'cause the "math" are just values from experiments i did with the osc, and yet i don't know completely where these numbers come from...
Have you looked at BLEP synthesis? It's basically that. Might help you with the math.
I don't think so! Mathematically it does just mean that.
E.g. if I invert a waveforms amplitude and play it time-reversed, and the waveform still looks the same, there can't be any DC-offset. If there was, it wouldn't look the same anymore...!!!
It doesn't mean symmetrical. It means it's centered around the average value. Again, look at a pulse train.
Anyway, of course with a saw the average value is also right there in the middle. I was just assuming your patch was right and trying to come up with a possible explanation as to why there was still some DC. It does work now.
...but that's f-domain again.
One doesn't exclude the other.
...this just as one reason for aliasing seen in time-domain!
No it isn't. When you're dealing with discrete time, you don't make assumptions about what happens between samples. Those square steps only occur at the dac before the filter, which smoothes out those steps. The raw data itself doesn't have that, but the aliasing is still there. Pushing a sine wave toward Nyquist doesn't make it less of a sine wave. It doesn't alias.
The reason for aliasing is because there simply isn't enough resolution in discrete-time signals to represent a frequency above Nyquist. The fluctuations between samples get lost, and you end up with a lower frequency. That's it. That's the time-domain explanation.
So we create a "additive-aliasing-synth" that beside the harmonics has to calculate even the disharmonics... That's faaar too much...
That's also technically still in the time domain.
The easiest way to design an arbitrary FIR filter, for example, is to do plot the desired spectrum and perform an inverse Fourier transform on it.
I never digged deeper into digital filterdesign, but i made a pseudo-digital analog filter ...uhh it just dawned on me to implement a simulation of it in "slowed down time" (<-see the attached patch). .."realtime" won't work cause the analog filter needs a "driver-freq." higher than 44100.. ..I need a better soundcard...
...anyways that's another line of work, as if there wasn't enough already...
...but if it is like drawing a spectrum relative to the filters f_c and "multiplying" it with an input-spectrum, to get a filtered input, I did that some time ago. It's cool since you can record the spectrum of e.g. a saw or a vowel and use it as a tuneable filtershape for other audio.
BLEP-synthesis.. I heared of it... I'll have a closer look at it, thx! (...it's not much but what else should I say...)
Those square steps only occur at the dac before the filter, which smoothes out those steps.
Just to make shure are u speaking of an input- or an output-filter?
The reason for aliasing is because there simply isn't enough resolution in discrete-time signals to represent a frequency above Nyquist. The fluctuations between samples get lost, and you end up with a lower frequency. That's it. That's the time-domain explanation.
Yeah shure, that causes those sub-non-harmonics and that stuff. But I think there are different types of aliasing in t-domain: the subharmonics-stuff caused by descrete time, and a kind of waveshaper that brings out more overtones due to the louder or harder (cause higher) jump from step to step as the frequency of a given signal raises. (<- see patch)
And of course in a pc there is no need to store a value for EVERY single point in real-time if the following points would just be the same. So we just take "the beginning of a line"
But at the digital-to-analog-converter (dac) there is ALWAYS a voltage (not just at certain timepoints and between them there is like nothing..). And this voltage is steppy (if not filtered afterwards). ..Anyways, filters already reduce the aliasing, so they can be excluded from "aliasing-production"..
Pushing a sine wave toward Nyquist doesn't make it less of a sine wave. It doesn't alias.
If I get you right, this is correct in "slowed down time" as well: Have a look at the attached patch, (there's even a little more ...text... inside). I can see and hear a squarewave there...
That's also technically still in the time domain.
okok.. technically everything that IS is in timedomain..
..but the calculations could be in f-domain.. ...to me everything that deals with sinusoids and harmonics belongs to the f-domain.. ..(<- does it look too feminine without a nose?!)...
@Flipp said:
...but if it is like drawing a spectrum relative to the filters f_c and "multiplying" it with an input-spectrum, to get a filtered input, I did that some time ago.
It's not quite like that. When you do the inverse Fourier transform of a desired filter's frequency response, you end up with its impulse response, which is in the time domain. The coefficients of an FIR filter are exactly the same as the impulse response. So you end up with time-domain solution. And that's the point I was trying to make. Just because you're looking for a time-domain solution doesn't mean you should ignore the frequency domain.
Just to make shure are u speaking of an input- or an output-filter?
Output.
But at the digital-to-analog-converter (dac) there is ALWAYS a voltage (not just at certain timepoints and between them there is like nothing..). And this voltage is steppy (if not filtered afterwards). ..Anyways, filters already reduce the aliasing, so they can be excluded from "aliasing-production"..
Exactly. The steppiness you're referring to happens AFTER the data is converted to voltage and is no longer a discrete time signal. You can make it as steppy as you want at that point, it's not going to alias. It will generate high frequencies above Nyquist, but the filter should get rid of those.
If I get you right, this is correct in "slowed down time" as well: Have a look at the attached patch, (there's even a little more ...text... inside). I can see and hear a squarewave there...
Yeah, and look at the spectrum of that. It's not aliasing around the artificial sampling rate set by [samphold~]. The distortion extends up to the global sampling rate's Nyquist frequency and aliases there. What you're basically showing is that harmonics are being generated past the artificial sampling rate, just like what would happen when the signal is converted to analog. Except once it's analog, there is no global sampling rate anymore, so those harmonics just extend without aliasing.
It kind of looks like a frog to me. That's cool, though. I like frogs.
Oops! Looks like something went wrong!
