Do you think this would be useful to have? |
Yes |
|
40% |
[ 2 ] |
Don't care |
|
20% |
[ 1 ] |
No |
|
40% |
[ 2 ] |
|
Total Votes : 5 |
|
Author |
Message |
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Thu Nov 04, 2004 2:13 am Post subject:
Anti-aliasing module |
 |
|
The G2 oscillators have good anti-alias algorithms, which allows them to go into quite high pitch ranges before the annoying intermodulations kick in. However, this is not necessarily the case whenever you start to do DIY oscillators.
A simple example where aliasing is a problem is the derivation of a variable width pulsewave from a sawtooth oscillator via a comparator module -just the way it is done in the analogue realm. Using the hereby generated logic gate pulse as an audio signal readily produces intrusive artefacts caused by the intermodulation of the gate frequency with the G2 sampling frequency.
My knowledge on the maths involved in anti-aliasing technology is limited, so actually I don't know if it is at all possible to anti-alias a signal post facto. Maybe this would only be possible strictly for oscillators, and the module would require a pitch control signal and syncing pulse, so that it "knows" what the phase and frequency of the oscillator is. I'm just hypothesizing here...
However, if it is possible, I think it would be great to have as a separate module, in order to take care of such issues. |
|
Back to top
|
|
 |
blue hell
Site Admin

Joined: Apr 03, 2004 Posts: 24476 Location: The Netherlands, Enschede
Audio files: 298
G2 patch files: 320
|
Posted: Thu Nov 04, 2004 9:03 am Post subject:
|
 |
|
To anti alias a signal one must make certain that no frequencies above half the sample rate are present.
Once those frequencies got in its not possible to remove them any more as such frequencies are not really present but they are reflected back rather into the representable spectrum (and so they have become 'indistinguishable' from the real signal).
So it is not possible to make a module that removes aliassing, all audio mudules will have to prevent it internally.
Maybe it would be possible for Clavia to make anti-aliasing an option on certain modules as DSP resources are needed to implement it and it's not always needed.
Jan. |
|
Back to top
|
|
 |
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Thu Nov 04, 2004 10:31 am Post subject:
|
 |
|
Well, I suspected that, but I wasn't sure.
In that case, this wish doesn't make much sense, does it...
And adding an "anti alias" option for logic signals is asking for a bit much, I guess...
oh well...  |
|
Back to top
|
|
 |
jksuperstar

Joined: Aug 20, 2004 Posts: 2503 Location: Denver
Audio files: 1
G2 patch files: 18
|
Posted: Thu Nov 04, 2004 10:42 am Post subject:
You probably know this, but it's good info for others |
 |
|
Throwing in a simple low-pass filter fully opened up should prevent any aliasing (this would put the cut-off ~20kHz, less than the 1/4 rate point). Where to put it depends on your system. 6db would be plenty, though for some strong feedback systems or fast edges (squares, sawtooth) a 12db might be needed, or use a lower cutoff. For controlling aliasing of Blue or Yellow signals, set the cutoff between 6-12kHz. (the control signals run at 24kHz). In a digtial system is that those sharp edges can easily be described without aliasing...all you need to do is filter out the high frequencies/harmonics before *using* them where they would "fold" back into an audible range...so in your example, put the pulse train threw the lo-pass I mentioned before using it elsewhere. The lo-pass should *not* follow the keyboard, and should be static at 20kHz!
In essence, the lo-pass *is* an anti-aliasing filter. At least, there is nothing else (DSP wise) that clavia could do to a module's output. The rest would be handled by designing the oscillator (or the whole system) properly.
There's a good paper on designing oscillators here:
http://www.harmony-central.com/Computer/Programming/blit.pdf |
|
Back to top
|
|
 |
mosc
Site Admin

Joined: Jan 31, 2003 Posts: 18251 Location: Durham, NC
Audio files: 226
G2 patch files: 60
|
Posted: Fri Nov 05, 2004 1:18 pm Post subject:
Re: You probably know this, but it's good info for others |
 |
|
jksuperstar wrote: | Throwing in a simple low-pass filter fully opened up should prevent any aliasing |
Good suggestion. If resources were very tight, you could build a simple FIR filter using a shift register and a mixer. Not very precise but I thought I'd throw that in for fun. _________________ --Howard
my music and other stuff |
|
Back to top
|
|
 |
ian-s

Joined: Apr 01, 2004 Posts: 2672 Location: Auckland, New Zealand
Audio files: 42
G2 patch files: 626
|
Posted: Fri Nov 05, 2004 3:25 pm Post subject:
Re: You probably know this, but it's good info for others |
 |
|
mosc wrote: | jksuperstar wrote: | Throwing in a simple low-pass filter fully opened up should prevent any aliasing |
Good suggestion. If resources were very tight, you could build a simple FIR filter using a shift register and a mixer. Not very precise but I thought I'd throw that in for fun. |
Sorry to disagree with you good people
While simple filtering is very helpful when sampling continuous real time signals, it is of no use for reducing aliasing which already exists in a digitally generated signal. As Jan pointed out, the aliasing harmonics generated, have folded into the audio range, not necessarily close to the sample rate.
I suspect that Clavia is quietly working on the aliasing of orange signals, things may still get better. |
|
Back to top
|
|
 |
Tim Kleinert
Joined: Mar 12, 2004 Posts: 1148 Location: Zürich, Switzerland
Audio files: 7
G2 patch files: 236
|
Posted: Sun Nov 07, 2004 5:49 am Post subject:
|
 |
|
g2ian wrote:
Quote: | As Jan pointed out, the aliasing harmonics generated, have folded into the audio range, not necessarily close to the sample rate.
I suspect that Clavia is quietly working on the aliasing of orange signals, things may still get better. |
Yes, that's what I was thinking of, mainly.
AFAIK, there is an algorithm within the osc modules that alleviates the intermodulations that occur between the pulse waves and the G2 sampling frequency.
I was wondering if it would be possible to provide this algorithm as a standalone module, into which orange (or yellow) logic pulses could be routed, in order to make them alias-free so you can use them as audio oscillators.
I was thinking about this lately because I came across a G2 patch (I think it was a Juno106 replica) which used the aforementioned classic technique of deriving the pulse wave from the saw wave via a comparator. And that patch produced horrible aliasing... |
|
Back to top
|
|
 |
jksuperstar

Joined: Aug 20, 2004 Posts: 2503 Location: Denver
Audio files: 1
G2 patch files: 18
|
Posted: Mon Nov 08, 2004 2:43 pm Post subject:
|
 |
|
Quote: | it is of no use for reducing aliasing which already exists in a digitally generated signal. |
True. and there's no module you can add on once the frequencies have folded.
However, if the frequencies have not folded yet, a low-pass is simplest the answer. Take the case of a square wave of 48kHz. This obviously has harmonics that are far beyond the 96kHz sample rate. However, in the digital system, you can easy see how the square wave is represented..01010101... stored in memory. Hence, there is no aliasing, at least not yet. Stuffing that square wave into another module *may* cause frequencies to fold back, depending on the module...but using a low-pass filter should help prevent that from happening. The square would be "rounded" enough to remove the high frequency harmonics, but still be sharp enough that it isn't audible (thinking back, a 48kHz sqr is a bad example for this, but it helps illustrate the point).
So the only true way of preventing aliasing is through the proper design of the oscillator, but that entirely depends on what oscillator is being created. In this sense, it is difficult to simply take an analog circuit (continuous time domain) and "translate" it into the digital (discrete time domain) as is usually the case (How many analog-modeling synths are there?). You actually should design for the discrete domain from the beginning, which involves frequency analysis at every step. It gets convoluted, though, since the modules you're designing with are mock-ups of analog circuits already  |
|
Back to top
|
|
 |
|