When changing parameters and setting them via notifying the host, prompts the DAW to remind the user to save the session before closing as to not lose their changes. This is normally indicated by the dirty bit in the DAWs main window.
Now, my plugin has some configuration stuff that it does not necessarily have to notify the host for, say, e.g. a name string or something, for the sake of argument. The thing now is, when saving the session I want to of course recall this meta information for the user.
But, because I’m not notifying the host about anything, the host does not know what the state of the session has changed and the user could potentially close the session without saving, meaning this information (like the name example) will not be recalled correctly when reloading Some DAWs even go so far as to not even letting the user save the session without having this dirty bit set, so the user could never save the newly set name without changing something else that provokes the DAW to finally let him save his session.
Of course, my question is now, how can I get the DAW to set its dirty bit so that the user is prompted to save the session (or not, if he/she chooses) whenever I want from the plugin? In other words, how can I tell the DAW the state of the session has changed, even though those are values that the do not concern the DAW directly, so it would not know otherwise?
Hi, sorry, answered too soon! After trying it out, simply calling the method does not what I expected…
After changing the name, using my previous example, the DAW is still not in ‘dirty’ mode, meaning I could close it without getting a save prompt. Is there some trick I need to do into fooling the DAW that something has changed so it will remind (or even allow) the user to save?
I was test driving my plugin with Ableton Live, so perhaps this is also a DAW related issue?
That’s strange, it works for me. I used it with Logic (AU) and ProTools (AAX).
It is a very basic functionality, so I would be surprised, if there was a bug, but you never know…
Are you sure, the updateHostDisplay() is really called?
Also, which format are you implementing? AU or VST or VST3? I don’t have Ableton to test…
Yes, just to be sure, I put a printout after it and starting Ableton from the console sure enough prints my text, so the method has to be called.
It must be an issue of Ableton ignoring the call for some reason (well, more that Ableton reacts to this function in a different way…). I do not have Logic and ProTools on this machine right now to test, but good to know that it should work! On Monday I will have a chance to have a go at those two DAWs and see. For ProTools that would be especially good, because it was one of the DAWs that does not allow to save without any changes!
Concerning Ableton, I also have this issue that calling setValueNotifyingHost in every situation does not always work. I was wondering if it has to do with thread related issues and Ableton blocking calls in certain situations for whatever reason. For example, receiving a parameter change via OSC, which comes from a dynamic library (because I’m sharing an OSC receiver among my several different types of plugins) is not registered by Ableton anymore, i.e. the parameter automation line inside the DAW is not moving. When I had the OSC receiver in a single VST project only, effectively blocking the port for my other VST projects, it was working (but was useless for me, unfortunately). I eventually solved this by setting a flag and reading the changed parameter inside the processBlock() method. Maybe someone will kill me now but its the only way I was able for Ableton to finally react and record automation data from an external controller over OSC using a dylib.
That said, doing something similar for updateHostDisplay() did not do the trick, unfortunately If anyone has experience with Ableton Live, I would be grateful to get any pointers in the right direction! Thanks!
If it’s any consolation, calling updateHostDisplay does not work in Reaper either. (In Reaper the plugin could notify the parameter -1 has changed to indicate a generic state change has happened, but Juce does not officially support that. Using the parameter -1 may also be a Reaper-specific convention, so hacking the Juce source code to allow that might not work for Ableton Live and other hosts.)
I kinda remember reading in this forum an old workaround for this:
it was suggested to add a dummy parameter to the automation, not actually connected to any aspect of the processing, and then setting it at a different value every time it was needed to signal a “modified state” to the DAW
Hi there!
Actually it’s not a good solution to show an automatable parameter that the user cannot change it. Has anyone found a better trick to do this?
Also, I tried to call updateHostDisplay and it didn’t work.
(Tested in Ableton Live v9.6, AU plugin format, Juce 5.2.1)
Some DAWs even go so far as to not even letting the user save the session without having this dirty bit set, so the user could never save the newly set name without changing something else that provokes the DAW to finally let him save his session.
but its the only way I was able for Ableton to finally react and record automation data from an external controller over OSC using a dylib.