-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changing a NonAutomatedParameter will not mark the plugin state as dirty #33
Comments
This seems to be just the (bad) default behaviour of non automated parameters and requires a workaround. Unfortunately there doesn't seem to be a way to actively mark the plugin's state as dirty from the processor. Some JUCE forum posts also indicate this. A potential workaround would be to re-set the current value of one of the automated parameters. This works with the objectVST, but in the DirectSpeakersVST there are no automated parameters. So this would require adding an additional dummy (e.g. custom bypass) parameter. From the host's / user's view this shouldn't change anything, since the Bypass parameter is always added by default (you just don't have access to it if you don't provide your own). Still this feels a bit convoluted - do you think it would be acceptable? |
Hi Sebastian. I chatted to Matt about this. Is there a risk that adding the custom bypass parameter would break an existing project built before this new parameter was added? That seems the main risk. |
Hi Chris, I did some investigation and it doesn't seem to be an issue, at least not in Reaper. |
Thanks for investigating. Reaper is our primary DAW, especially since the ADM I/O extension is only for Reaper. I also don't expect much use in other DAWs right now, so breaking changes are less of an issue in Cubase/Logic etc. When you say that identifying parameters by index "could of course lead to issues", do you mean issues beyond old projects no longer working? |
No, i think breaking old projects would be the only potential problem, e.g. because a wrong order of the parameter list could be assumed by the host. |
Ok great. In that case I think we should proceed. |
Looking at the JUCE wrapper code, first there is a check if a custom bypass is provided, and if not, one is added at the end of the list. So if we provide one with the same name at the end of the list, at this point in the code there will be no difference to the state before. The ID handling for legacy parameters is done after that, essentially working on the exact same parameter list as before. I'll proceed implementing this. |
Great! |
If e.g. the routing is changed in a just saved project and the project is then closed, REAPER will not ask the user if the project changes should be saved.
From gitlab issue 121
The text was updated successfully, but these errors were encountered: