Lmms: Free Distortion VST Temper resets values when project is re-opened

[EtornaZ]

I've recently installed a great distortion VST called Temper. My problem with it is that whenever I close a project with a Temper effect in it and re-open the project, the effect has reset back to its default values. This can be fixed by connecting every value to an automation track (7 values total), but that's rather annoying in cases where you're not automating.
I'm on a Windows 10 computer using the latest beta version of LMMS (1.2.0 rc6)

You can download Temper here: https://www.pluginboutique.com/product/2-Effects/30-Distortion/4378-Temper

[SecondFlight]

Reminds me of https://github.com/LMMS/lmms/issues/1049, but that's been closed for a while.

[zonkmachine]

Sounds like this could have been fixed in https://github.com/LMMS/lmms/pull/4401
Test RC7 when it's released.

[EtornaZ]

Will do.

[PhysSong]

Sounds like this could have been fixed in #4401

No, it's not. I can still reproduce this with #4401. It's also different from #1049 because Temper uses a chunk for loading/setting settings.

I don't know if this is LMMS bug or upstream one, but here's some information I found so far:

• Upstream repo: https://github.com/creativeintent/temper
• Related parts of the plugin: https://github.com/creativeintent/temper/blob/17d1a4f288105f9e6f72fc4b28a83074dbd82e7a/Source/PluginProcessor.cpp#L266-L278

Tagging @DomClark.

[PhysSong]

Probably something like https://forum.juce.com/t/save-load-presets-problem-using-valuetreestate-fixed/26257 ?

[DomClark]

I've tested the plugin in Reaper and it works fine; in Ardour the values are restored correctly in the GUI but it seems it has reset to default values for the actual audio processing; in LMMS it resets to the default values as described. I'll investigate.

[DomClark]

The settings appear to be saved correctly - the chunk in the LMMS project file matches that in the Reaper project file. The bug seems to be in loading the settings again.

[DomClark]

After loading the chunk, LMMS restores the VST's currently selected program. Temper doesn't save modified programs in the chunk however, only the current state, so setting the program overrides previously saved settings.

It's not clear what the correct behaviour is here; looking around online it seems some hosts (Cubase, Ableton, etc.) set the program after the chunk whereas others (Reaper, Ardour, etc.) don't. I suppose Cubase should be the reference implementation as it's by Steinberg, but since there's inconsistency and the current implementation has this issue, I think we should change it so the program is only set if loading the chunk or parameters fails. If this causes problems for other plugins in RC7, we can revert before releasing 1.2.

[DomClark]

Should I add the proposed change to #4540?

[PhysSong]

if loading the chunk or parameters fails.

How can you check that?

[musikBear]

@DomClark

It's not clear what the correct behaviour is here

Imo LMMS could set all values independent of the chunk, in fact it could be omitted. LMMS only need to set changes for those controllers that is kept in the LMMS-VST-dials-array. Only those makes sense, because they are the ones that can be automated. If the plugin has controllers, we cant automate, then the plugin should not be used.
One drawback are those VSTs that has internal banks, but isent that transparent in respect to LMMS?

[DomClark]

if loading the chunk or paramters fails.

How can you check that?

I worded that badly, sorry - what I mean is to change the last if to an else if in VstPlugin::loadSettings:
https://github.com/LMMS/lmms/blob/4bb6586c66fdeb0ef2f84667958d340a8355c5fe/plugins/vst_base/VstPlugin.cpp#L158-L184

@musikBear

Imo LMMS could set all values independent of the chunk, in fact it could be omitted. LMMS only need to set changes for those controllers that is kept in the LMMS-VST-dials-array.

We already do this for plugins that don't support chunks. I don't think we should stop using chunks - they were added to the VST specification for a reason, and many plugins use them to store data beyond what is available through parameters exposed to the host. The only effect would be that some plugins won't work as well in LMMS as in other hosts, which isn't something we want.

If the plugin has controllers, we cant automate, then the plugin should not be used.

If we tell users not to use plugin foo because it doesn't behave how we like, they're not going to say "Ah yes, you're right, I'll use a different plugin", they'll say "Ugh, LMMS is rubbish; it doesn't work with plugin foo". The VST plugin standard was designed by a professional audio company and is implemented across many different hosts; if we decide we don't like how it works and do something different, we're not going to be setting a trend; people will just ignore our way and we'll just become less and less compatible with the plugins out there.

One drawback are those VSTs that has internal banks, but isent that transparent in respect to LMMS?

It is transparent to LMMS; that is one of the main uses for chunks.

Ultimately, most hosts support most plugins quite well, and if they can, there's no reason we shouldn't be able to. Sometimes there are tricky corner cases like this, but we need to work out a compromise, rather than being stubborn, running away from the standard and putting off users (who are the reason we write this software).

[PhysSong]

I worded that badly, sorry - what I mean is to change the last if to an else if in VstPlugin::loadSettings:

So does that mean you're going to make LMMS set the program only if there's neither a chunk or a parameter dump?
And just a random idea: how about setting the program before loading chunks/dumps? It seems to work a little bit better.

[musikBear]

@DomClark -okey -good arguments 👍

[DomClark]

So does that mean you're going to make LMMS set the program only if there's neither a chunk or a parameter dump?

Correct.

And just a random idea: how about setting the program before loading chunks/dumps? It seems to work a little bit better.

I originally discounted this option because the program would be overwritten by the chunk/dump, but on second thoughts overwriting it wouldn't hurt, and this has the same behaviour as my suggestion when no chunk/dump is present. I think this is probably the best solution. Shall I implement this in #4540?

[DomClark]

Done.