The nature of mixing

Just a little thought in between, while I'm writing a longer post...

The concept of mixing audio, applying filters, processors and whatnot to perfect and polish the sound is actually quite artificial, at least to the extend that it's being done these days.

If you think about how music was performed for most of humanities existence, all you had were the "raw" sounds of the performers. There were some limited ways to tweaks those, like "hey you, don't hit those drums so hard" or "you, come to the front, so we can hear you better", but that's about it.
And while people for sure noticed the difference that the environment had on the experience, if they didn't have a cathedral at hand that would give the chorus that impressive volume, they would still enjoy the performance in a normal room.

The ability to micromanage sounds, in the way we can do it now in the studio, feels like a qualitative step beyond what we used to be able to do in the past. Like going from some salt and the herbs that grow in your backyard for spicing your food, to glutamat and a whole catalog of E-something chemicals used for industrialized food production.

Yes, those tools that we have today are great, and it's even greater that they're now available to anyone with a computer. But be careful and conscious about how you apply them.
At least I, when I make a pizza myself at home, don't want it to taste like a frozen pizza out of some factory.

LV2 confusion with internal presets

I managed to get the Helm synth working as an LV2 in noisicaä, including UI. Which is great, because that's a very nice synth.
But I ran into an issue, which caused me some head scratching, because I thought that I was doing something wrong. As it turned out, this is really a problem with (at least) LV2 and Helm's feature to load presets from within its own UI.

Helm's internal state is determined by the values of the 100+ control input ports, plus some additional state that isn't captured by those ports (e.g. which controls are modulated by an LFO).
Now when you load a preset, Helm sets all of its control to specific values, but it has no way to tell the host about those values. Which means the host is still feeding the previous values into all control input ports. Helm seems to have some logic to ignore those values from the host, until you actually change them from outside of Helm (e.g. via automation or the generic UI). If you change some control manually in Helm's UI, then the values are posted from the UI to the host, so it can update the value that it feeds into the respective control port.

But if you now close the project and open it again, Helm's state gets all messed up, because for most control the host never learned about the right value from the preset that you selected, and Helm gets initialized with effectively random values. Things get even more confusing, because the control values are also stored in Helm's 'internal state' blob and depending on the order in which control ports and internal state are initialized you get different results.

Turns out that Ardour has the same issue, so I'm not alone with it.
I don't know, if e.g. the VST API solves this issue, or if it was generally a bad idea to have presets, which change the values of control ports - and manage them within the plugin itself. If the presets would be handled in the UI, then LV2 has the API to set the control ports... or is it just a bug in Helm, that this API isn't used when switching presets?

So the lesson is to not touch the preset browser in Helm, but instead use the preset menu from the host - which has the same list of presets, and knows how to set the control port correctly when loading a preset.
But noisicaä doesn't know about presets yet...