Instrument plug-ins waveforms order.

[Sawuare]

The current ordering of all the instrument plug-ins waveforms (except OpulenZ & SID) isn't logical. This ordering is much more logical (based on harmonics): Sine > Triangle > Square > Exponential > Saw > Moog-like saw > White noise.

Sine: a single fundamental frequency. Triangle: consists off all the odd harmonics of the fundamental frequency with the volume of the harmonics rolling off. Square: consists off all the odd harmonics of the fundamental frequency with constant amplitude across the harmonics. Exponential: consists off all the even & odd harmonics of the fundamental frequency with the volume of the harmonics rolling off. Saw: consists off all the even & odd harmonics of the fundamental frequency with constant amplitude across the harmonics. Moog-like saw: based of the saw. White noise: consists off all the frequencies.

[BaraMGB]

Is there a chance you could fix this? We can teach you if you want.

[zonkmachine]

This is a tradition from how most synths worked way back. In the subtractive synth paradigm you start with an energy rich signal, saw/noise, and then apply filters.

vco -> vcf -> vca -> signal out

Add to this the electronics of generating the signal. Most vco's start out with an saw or a triangle wave and then from the triangle create a sinewave via non-linear amplification (I haven't looked deeper into the sine wave side...) and the square is derived from the saw or triangle. Finally some kind of noise source is stuck to the end. Actually the order we have is pretty standard. Your way of attacking synthesis is more aligned with additive synthesis. There is no right or wrong here but since most of our plugins come from the subtractive tradition, 3osc/lb302/monstro are good examples here but even the SID emulator leans on this tradition. I think the order of the wave forms are pretty much standard.

[Sawuare]

@zonkmachine

This is a tradition from how most synths worked way back. In the subtractive synth paradigm you start with an energy rich signal, saw/noise, and then apply filters.

I knew about this before filing the issue. 😉

and the square is derived from the saw or triangle.

This was what confused me, seeing a saw before a square.

Your way of attacking synthesis is more aligned with additive synthesis.

Exactly. I should have thought about the ordering of the waveforms from a subtractive synthesis side too. 😅

I now understand the reason behind ordering the waveforms in LMMS 👍, but shouldn't the moog-like saw come after the saw and before the square here and in Monstro too? They are really similar harmonically.

@BaraMGB

Is there a chance you could fix this? We can teach you if you want.

The problem here is fixed now, but I'd like to know how to fix small UI problems like this one. Thank you for offering help!

[zonkmachine]

and the square is derived from the saw or triangle.

This was what confused me, seeing a saw before a square.

I double checked and it turns out the waves aren't organised as I rememberered it. I've just gotten used to how things are organised (or not organised). I don't oppose moving things around if anyone has an idea how to do it better. In my mind I would put the saw first if I built a synth and the noise would come last and the stuff in between would depend on the inner logic or electronics. I can't argue against the logic of your wave classification though.

[grejppi]

Changing the order would break projects where there is automation on a waveform chooser. (Rare, but possible.)

[michaelgregorius]

Breaking old projects can likely be prevented by storing a mapping between buttons and their corresponding model index in automatableButtonGroup. The index for each button could for example be given when the buttons are added to the group. However, that might be quite some effort just for reordering the buttons in the GUI.

If implemented like that then automatableButtonGroup::activateButton and automatableButtonGroup::modelChanged would have to use the mapping instead of the implicit index given by the buttons position in the group.

I also have to admit that I find the strongly visible aliasing in the screenshots of the waveforms more of a concern than the ordering of the buttons. :wink:

[Sawuare]

@michaelgregorius

I also have to admit that I find the strongly visible aliasing in the screenshots of the waveforms more of a concern than the ordering of the buttons. 😉

I think it's a concern, too, so I filed #3605.

[tresf]

@grejppi I looked at the source and the few places I looked at didn't store the buttons by index (but rather by specific name), so I think automation would be fine. Did you find a place they would break?

[grejppi]

@tresf The order is defined in the Oscillator class.

Here's an example where the index is increased one by one:

If the order of the buttons were changed to what's proposed in the first comment, the automation would have to be changed to this:

However, if there was a way to map the index to a different value as @michaelgregorius proposed, that would solve a great deal of it; automating or connecting an LFO to it would still possibly look weird, as the input value doesn't correspond to the index in the button group.

[tresf]

the input value doesn't correspond to the index in the button group

Wouldn't this be a candidate for an upgrade routine?