Re: [LMMS-devel] [Warning, Long text]: Some considerations on alias-free/-reduced waveform-generation in general and in conjunction to lmms...

[Paul G. <dr...@gm...>]

Stefan -

Thank you for your work on this! Also thanks for the explanation, that
helps me understand things a bit better.  I know we have a policy for
maintaining consistent behavior across versions. However, if there is
something broken in the system - it should be fixed.  LMMS's
waveforms, with their aliasing issues, is a problem.  I haven't talked
to Toby about any of this yet, but here is my view:

Could we provide a way for the user to switch modes (backwards-compat,
and alias-free) at runtime?  This would basically solve the problem of
backwards compatibility for projects.  Presets on the other hand... we
will have to listen to them.  If they still sound OK (even if it isn't
close to the original sound) then I think we are fine.  The version of
the preset files can also be used to provide a hint to the user that
they are using an old preset that is designed for the older behavior.

Further, I am working on a grounds-up replacement for LMMS.  I will
require oscillator code.  Therefore, I'm also interested in seeing how
your solution would turn out in a "clean room" environment.  That is,
if you were to write a reusable oscillator library, what would it be
like?  Would it use templates like the LMMS code? How do you plan to
manage precalculated waveforms?  I don't necessarily want LMMS's code
to restrict your ability to write a great library.  If the library is
general enough, we may be able to adapt LMMS to it; not the other way
around.

Again, I really appreciate the research and work you've put into it. I
can guarantee you, personally at least, that your efforts will not be
wasted.

-Paul

On Thu, Sep 30, 2010 at 5:32 PM, Stefan Fendt <st...@sf...> wrote:
> Hi everybody,
>
> through to the last weeks I used my spare-time to think about
> alias-suppressed and/or alias-free waveform-generation and to rework
> LMMS' waveform-generation according to this thoughts...
>
> There are generally two approaches to get rid of audible aliasing with
> virtual-synthesizers: a) massive oversampling and b) alias-free
> generation of waveforms.
>
> While oversampling on a first glance has the benefit of being
> conceptually simple by just brute-forcing the desired result out of an
> otherwise simple (AKA: "naive") generator by sampling it with such a
> high rate, that the highest audible overtones do not become aliased any
> more... Because I ran into trouble because of the modulations used in
> LMMS' with alias-free generators I tried to deal with the problem by
> using this approach... and ran in trouble, too...
>
> So I began to ask myself how much oversampling would be required for an
> audibly alias-free waveform-generation (later and modulation)? Given a
> simple static sawtooth (or square or Moog-saw, the harmonics fall off
> equally on all these by 6dB/octave and in priciple have infinite
> harmonics) played at 22050Hz (nyquist for 44.1kHz) without any
> modulation and a desired SNR of at least 48dB (I would prefer even more,
> but...), so how high must the oversampling-factor be?
>
> The overtone (harmonic) which has a distance of 48dB to the fundamental
> frequency is (due to the 6dB/octave falloff for this waveforms) 8
> octaves above 22.05 kHz. This is 256-times 22.05 kHz = 5.6448 MHz. This
> must not produce an alias-frequency in the audible range when
> downsampled, so we can calculate how high the new sample-rate must be: 2
> x 5.6448 Mhz - 22.05 kHz = 11.26755 MHz. This is an oversampling-factor
> of 255.5 (or roughly 256).
>
> One could argue if such a high pitched "note" makes sense at all...
> Well, I don't think so,... but LMMS' can produce these (and the 127
> Midi-Note-Range nearly does support this case, too) and so, even these
> should be alias-free in the final rendering. But even if limited to a
> fundametal-frequency of 8 kHz the required oversampling-factor for this
> SNR only would be reduced to 93 times (4.07395 MHz). Even worse:
> 48dB/SNR is rather bad and usually one will modulate the signal by some
> means... Even the simplest modulation (ringmodulation)
> tripple-oscillator supports will raise the required oversampling-factor
> by 2. Not given the fact that for FM at high modulation-indexes the
> spectrum becomes nearly infinite and would therefore require an infinite
> sampling-rate, too...
>
> For this simple reason: Oversampling can not be the way to go... never.
>
> Remark: Just think of these multi-megaherz-sample-rates processed by
> IIR-filters (numeric stability) or even more complex DSP-plugins. It's
> just a no-go... (if still not convinced, use the above example to
> calculate this for the more reasonable case of an SNR of 96dB and
> 44.1kHz sampling-rate... approximately 2¹⁶-times oversampling would be
> required for this and still without modulations...)
>
> So, from my point of view: The only way to go is alias-free generation
> (which I allready can do via the wavetable-approach in a fast
> (realtime-capable) way I described in an earlier mail). But how to
> handle modulations then? So, let's take a peek on what tripple-osc is
> doing there:
>
> Mix:
> This does not add new harmonics. If the generator runs without alias,
> then this will be alias-free, too.
> --> So, what should/can be done: Nothing. All is OK here if the
> bandlimit is imposed before...
>
> AM/RM:
> Without going into too much detail why this happens: This doubles the
> required bandwith, so this can be handled by an additional 2x upsampling
> of the two signals, performing the modulation and downsampling two times
> again. This will give the correct result without aliasing.
> Nitpicking: What is implemented in the LMMS-oscillator-model is not AM.
> It is RM (if you never heard of this: "RingModulation"). The difference
> is this, for one carrier and one modulator: f1 and f2. With real AM you
> will three frequencies in the spectrum: f1+f2, f1-f2 and f1 itself. That
> is you get carrier-frequency plus modulator-frequency and
> carrier-frequency minus modulator-frequency and the carrier-frequency
> itself. For ringmodulation a DSB-signal is created, that is you get only
> f1-f2 and f1+f2 but you do not get the carrier itself... (But really who
> cares about?)
> --> So, what should/can be done: oversampling 2 times just on the
> modulator-level.
>
> PM/FM:
> This is a real problem... At first some Nitpicking, again...
> Frequency-Modulation(FM) and Phase-Modulation(PM) are the same. Really.
> No kidding. The only difference is the modulation-index which in the one
> case is a (low) constant and in the other is a (high) constant depending
> on the fundamental-frequency. OK, forget about it... the problem is: it
> potentially can create infinite(!) spectra from just sine-waves... What?
> Yes, infinite spectra... So there is really no way of getting really
> alias-free modulations with these two... But there is a trick (which was
> used in the old Yamaha DX7 already): Based on the fundamental-frequency
> of the carrier one can reduce the modulation-index to zero for higher
> frequencies near nyquist. While this is only alias-free for the nyquist
> itself (for non-sine-waves), it reduces alias below the audible range,
> not ever but usually...
> Further nitpicking: I suspect that I personally was the only one (or at
> least there only exist few people despite me) who ever used LMMS' FM
> modulation — and I used it only for testing. This is because the
> modulation-index was *WAY*, *WAY* to high. So usually you only get
> garbage sounds by using it.
> --> So, what should/can be done: Oversampling can't help. Adaptively
> (rather ad hoc, but...) reducing the modulation-index can. But this
> would require a) to reduce the base-modulation-index to some sane range,
> too and therefor would *drastically* alter the way FM/PM-Sound (from
> previous presets) would sound. From my personal taste: A
> modulation-index of 4 for 0Hz (for FM) and of 0.5 (for PM) really is
> enough to have harsch metallic sounds... (StarTrek "Vigar" greeting)...
>
> Hard-Sync:
> This is another problem case... It in principle does produce harmonics
> with a 6dB falloff, again... so it could be "solved" using
> oversampling... But as seen above: not really. It furthermore can not be
> precalculated nor can it be solved for general waveforms with
> BLITs/BLEPs... There simply is no solution other than keeping the
> modulator (master-clock) low... Fortunately this type of modulation
> usually is used for bass-sounds...
> --> So, what should/can be done: use with care and just ignore the lower
> carrier (master-clock) frequencies for prominent sounds...
>
>
> Overview of what I currently have working and what not:
> --------------------------------------------------------------------------------
>
> Alias-free generators using a set of wavetables:
> Works in realtime. (Generation of the wavetable is slower than possible,
> currently. Reading it with cubic-interpolation is a wink...)
>
> Mix:
> Works.
>
> AM/RM:
> tested with a proof-of-concept-code. Not implemented in the real
> code-base, yet...
>
> PM/FM:
> Works completely in realtime. Tested. Still not absolutely sure about
> the exponential modulation-index-falloff required. The currently used
> value works well but maybe ist to drastic... (It's a trade-off... So,
> it's a matter of taste somehow...)
>
> Hard-Sync:
> Does not work correct. Will most probably never work correct... :(
>
> cu
> Stefan
>
> PS: Why this loooong mail? ... Well,... I can make Mix/AM(RM) work so it
> sounds like before but without alias. I can't do so for FM/PM... will
> sound different, drastically — whatever I do to get rid of the alias...
> I would just ignore the Hard-Sync-Case... But all this will be a *lot*
> of work till now. I am willed however to do it... but not if
> "sound-changes" (FM/PM) would be unacceptable for the maintainers of
> LMMS... because it that case I would put a lot of work into something
> useless...
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> LMMS-devel mailing list
> LMM...@li...
> https://lists.sourceforge.net/lists/listinfo/lmms-devel
>