Aliasing in native LMMS instruments

[he29-net]

Alias-free wavetable oscillators #5826 were recently added to LMMS, resolving many aliasing issues in TripleOscillator. This first step was relatively time-sensitive, since the original PR was abandoned and in danger to be drowned in merge conflicts that would make it harder to resurrect later. Now that the code safely made it to the main LMMS repository, it can be gradually put into use in other affected instruments as well.

After doing some quick testing and based on the discussion below, I sorted the native instruments into several categories:

A) Instruments that have aliasing artifacts, use (or could use) LMMS Oscillator class and could benefit from the new wavetable mode:

• TripleOscillator (aliasing still present in PM and PF modulation, correct wavetable must be selected based on frequecy that results from this modulation)
• BitInvader (more work: includes Oscillator.h but does not actually use it anywhere)
• Kicker (low priority, usually does not play notes high enough to cause trouble)
• Organic (looks like a standard Oscillator user, basically an "OctupleOscillator")
• sfxr (very alien and self-contained code, but possibly could be refactored to take samples from Oscillator)
• Watsyn (less alien, but also quite custom and perhaps more complex; hard to say of it should be A or B)

B) Instruments that have aliasing artifacts, but do not (or can not) use LMMS Oscillator class, or they already have a partially working solution:

• AFP (Sinc interpolation is available for resampling; it takes care of aliasing, but it is CPU intensive and not the default. Using the Oscillator class may not be suitable, because the loaded sample may be quite long and take up a lot of memory if duplicated into ~128 band-limited versions)
• LB302 (low-priority, like Kicker? Already uses band-limited waves, but apparently not everywhere it needs to.)
• Monstro (PhysSong: "uses oversampling, but it doesn't use a good filtering algorithm before downsampling")
• Mallets (uses STK library https://ccrma.stanford.edu/software/stk/)
• OpulenZ (uses AdPlug library http://adplug.github.io/ and emulates a HW synth, so aliasing may be intended)
• Xpressive (generates waves based on formulas using http://www.partow.net/programming/exprtk/, probably not a good match; includes Oscillator.h but does not actually use it anywhere)

C) Instruments that seem to be OK or unclear:

• Nescaline (seems OK, but has very noisy output, hard to see for sure; emulates HW, so aliasing may be intended; seems to be using Oscillator, but only for noise samples?)
• SID (behaves very strangely for the last few notes, so it's hard to say if it's also aliasing; also emulates HW and and does not use Oscillator class)
• Vibed (seems pretty much perfectly clean)
• not tested: VeSTige (depends on plugins), GIG / PAT / SF2 (probably depends on quality and number of samples in the library).

With Monstro, sfxr or Nescaline and possibly others, I'm not sure if aliasing could be even expected and intended. With Monstro it possibly contributes to "nastier" sound, and with 8-bit like instruments, well, output of the original machines probably wasn't very clean and precise in the first place, and I wouldn't be surprised if aliasing should be present in a correctly emulated NES output. On the other hand, SID, for example, emulates a dedicated sound generator chip, which could have been designed to avoid aliasing. So some of these instruments may require further research.

I'm currently not actively working on this, so if anyone wants to use the new code to fix some of the affected instruments in category A, or research instruments in categories B and C, go ahead. After the refactoring dust settles, I will probably try to resolve the remaining issues in TripleOsc, since I'm already familiar with the code.

[softrabbit]

I'd put OpulenZ in the same category as NES, an emulation of some hardware that might very well alias. Here's some audio for anyone interested to assess the situation, first a digital recording straight off the chip: https://sid.fi/~grue/688_attack_sub_opl3_left_opl2_right_digital_rip.flac and second an analogue one: https://sid.fi/~grue/Torben_Hansen_Space13_L_opl2_R_opl3.flac

[rdrpenguin04]

A note: most emulators do de-alias NES sound nowadays, probably because blargg pushed it (Wayback Machine link), but I'm fairly sure Nescaline doesn't. I'm fairly sure SID is also aliasing.

On the other hand, I can imagine Vibed being fine because it uses a very different type of synthesis. ... On the other hand, it probably needs a separate algorithm revamp to actually follow the algorithm it was designed around.

[PhysSong]

Monstro uses oversampling, but it doesn't use a good filtering algorithm before downsampling.

[softrabbit]

So, I fooled around with the available emulators in Adplug (which OpulenZ includes as a submodule). Four seemed reasonably working and I rendered a test piece using each one in turn. Can't say my ears can tell a difference except for one that was clearly louder. Looking at Audacitys spectrum view I selected the cleanest and dirtiest looking ones and fed them to the spectrum analyzer in LMMS.

Switching to the new and shiny aliasfree oscillators sounds like a nice idea, but if the old emulation is to be dragged along for backwards compatibility... maybe better to create an entirely new successor and let the old code rot in OpulenZ. The code as it looks now is pretty much from another planet compared to LMMS Oscillator classes.

[he29-net]

Thanks everyone for the input. I went through some of the source files and updated the overview, dividing the plugins into 3 categories based from what I could gather so far:

• A) probably could make use of the improved Oscillator class,
• B) not a good match (e.g. uses an external library or already has a different partial solution), and
• C) probably does not suffer from aliasing or needs more research.

[PhysSong]

3605 could be relevant for some plugins.