Possible fix for the mark as change bug

[LPChip]

Currently, a VST(i) can trigger the song to be changed, which generates an astrix near the songtitle.

I find this bug very frustrating cus I usually play my music before I go to bed. I have a song that continously triggers this. This means, that after pressing save, the astrix reappears. (when I press my power button to shutdown my pc, it triggers the "do you want to save your changes dialog", and doesn't shutdown.)

Now, Its not possible to detect whether a slider is being changed inside the GUI, but it is possible to detect wether a GUI is visible.

You can disable the monitor for VST(i) changes if no GUI window is visible. As soon as you click edit, it can activate the monitoring, and once no windows are open anymore, the monitoring stops.

[LPChip]

*bump*

Rewbs, I haven't seen a reply on this matter. I was wondering what you've though about this solution. Cheers.

[rewbs]

Sounds good, I'll try it out. This means that some plugs will cause the song to be marked as modified as soon as the plug GUI is opened - which is perfectly acceptable and is how some other hosts work for all plugins.

[LPChip]

Sounds good, I'll try it out. This means that some plugs will cause the song to be marked as modified as soon as the plug GUI is opened - which is perfectly acceptable and is how some other hosts work for all plugins.

Not necessarily. Now, upon load, it can generate this item. This is due to plugin initialisation. You can still allow this, just not mark the song as changed due to it.

Also another suggestion: If auto save saves the song when there was an astrix, can you make the astrix to be changed to... AS, indicating that AutoSave saved the song? This way, AutoSave doesn't have to save again if nothing changed to the song during that time. I sometimes do not want to save my changes because i want to listen to them. I have this 17 meg song which takes up to 1 second of saving. Auto Save makes my song being jammed for a second every now and then which just sucks

[rewbs]

Sounds good, I'll try it out. This means that some plugs will cause the song to be marked as modified as soon as the plug GUI is opened - which is perfectly acceptable and is how some other hosts work for all plugins.

Not necessarily. Now, upon load, it can generate this item. This is due to plugin initialisation. You can still allow this, just not mark the song as changed due to it.

What?
We mark the song as modified when the plug dispatches a audioMasterAutomate message to the host.
This happens when the plugin calls setParameterAutomated, which should be called "after a control has changed in the editor" (editor here means plugin GUI) - see the VST sdk doc. OK... it doesn't say it should ONLY be called in this case, but it's kind of implied - such is the VST spec.

Anyway, some plugs erroneously report audioMasterAutomate events at arbitrary moments (e.g. during playback or at load time), even if the user isn't touching the GUI.
Yes we can filter out some of those "arbitrary moments" by checking if the GUI is actually open or not - this is a good idea. I was just saying that if such an "arbitrary moment" occurs when the GUI is open, we will still incorrectly mark the file as modified. But I don't see this as a problem. Some hosts intentionally mark the song as modified as soon as the GUI is opened for all plugs.

Also another suggestion: If auto save saves the song when there was an astrix, can you make the astrix to be changed to... AS

Hmm.. the asterisk is kind of out of my hands. We just set/unset the MFC document modified flag and Windows adds the * in the titlebar. I guess I could add something to track changes between autosaves to avoid superfluous autosaves.