I am making another post here because my issues with WL 12 are worse than I thought. In addition to not saving the DITHER plugin in the montage MASTERSECTION I also just discovered it is not always saving changes to OUTPUT section plugins. I can change settings in the OUTPUT section plugins and the FILE “SAVE” option is greyed out - like it does not recognize any changes. However, if I toggle a plugin bypass on/off, make changes in the timeline or touch any settings in the CLIP section plugins the FILE “SAVE” option IS available.
So I have been tweaking settings in OUTPUT section plugins that were not always being saved!
I have completely removed WL12, including all the config and registry files, and re-installed with the SAME RESULT.
PLEASE check your system and see if this works for you. I am on Windows 11. I do not remember having these problems on my Win 10 machine.
Just tried that and you are correct however it seems odd. The VST parameters are sent to the DAW as soon as the control is changed (thus changing the sound) - so why is closing the plugin window (a graphics function) necessary for WL to recognize a parameter change? I don’t understand that. It’s not how Cubase works. “SAVE” is always active to save whenever you want to save.
I have a habit of pressing SAVE anytime I change something significant no matter what DAW I’m working in. When I saw WL wasn’t doing that I became concerned that it wasn’t saving my changes. Thank you for pointing out this peculiarity in WL.
(In addition to being a WL user I am also a plugin developer. You can talk details.)
Because WaveLab has no control on what is going on in the plugin itself.
When the plugin closes, WaveLab collects all parameters and compares them to the previous ones. If they are different, then WaveLab sets the flag that the file should be saved.
Note: certain plugins change internal data even if no parameters are changed, which causes WaveLab to sometimes flag a change when there is none.
I understand what you’ve done there but I think you’ve made it more complicated than it needs to be. Any time a user changes ANYTHING - plugin parameter, bypass button, fader level, etc. - that SAVE option should become available. It doesn’t matter if that new value matches or does not match any previously saved value - save it anyway.
OK, based on your explanation, if I make changes to a plugin’s parameters and close it’s UI but do not yet SAVE the updated project what values are being used if I immediately render that project - the old ones that were saved or the new ones that haven’t yet been saved? The reason I ask this is because I was making changes to my limiter settings the other day and running the Loudness Analysis (which say it takes all plugins into account) showed NO CHANGE in the audio. That was baffling but now maybe I understand why - I hadn’t SAVEd the updates yet. Yes/No?
You told me a few years ago that Wavelab doesn’t use the playback plugins for rendering but, instead, makes a copy of them to process the render (basically “off line”). Is that still how it works? If so, is it possible that some plugins are not using the current settings if immediately rendered before saving the file? As I said above, I was adjusting a limiter the other day and checking with the “Loudness Analysis” tool and it showed the levels weren’t changing. After I saved the project and THEN rendered it produced the expected levels.
And SOMEHOW the “pre-Gain” and “post-gain” Output section faders had both moved down to -0.1dB. How did that happen? Is there some kind of auto-level function somewhere that can change those levels? I always keep them at 0dB (and now I have them “locked” at 0dB JIC).
These things were driving me crazy to say the least.
Normally, no, because before rendering, WaveLab saves all plugin settings.
If the plugin has a failure to copy its settings, that could be an explanation.
But this kind of error is less common today. And if you use serious plugins (eg. Steinberg, FabFilters, among others of course), this should not be the problem.
No. Maybe it happened that the mouse was located over one slider, and the mouse wheel was moved a bit at the same time, not intentionally. To be on the safe side, there is a slider lock option:
