I just found out that some time ago, a change was made to the copyXmlToBinary method which might lead to hosts thinking that a plugin state has changed compared to a previously saved state although it didn’t. I’m not sure if this could cause issues, but this is what happened:
In commit 2e2cfb5f6c206006c1b2fa895b408765f0f15187 (on 2019-05-09), this line in juce_AudioProcessor.cpp:
xml.writeToStream (out, String(), true, false);
got changed into this line:
xml.writeTo (out, XmlElement::TextFormat().singleLine());
And since the default value of TextFormat.addDefaultHeader is true:
bool addDefaultHeader = true; /**< If true, a default header will be generated; otherwise just bare XML will be emitted. */
this effectively changed the contents of what gets saved for the plugin’s state, because now you always get this header in front of your XML data:
<?xml version="1.0" encoding="UTF-8"?>
I noticed this as I was manually comparing plugin state saved with the last release of my plugin (JUCE 5.4.1) with plugin state saved with the same plugin using latest JUCE 6.1.2 master.
TBH, I am not sure if this can cause actual issues (will report if I encounter any), but depending on how hosts deal with plugin state blobs internally, I can imagine that this might lead to situations where:
- a host requests a plugin state and compares it to a previously saved state
- it now sees a difference due to that extra header and flags this as a changed state
- it therefore considers the DAW project as “dirty”, leading to an unnecessary “Save project…” dialog
Just wanted to report this here, in case anyone encounters strange issues related to “changed state” where it should not.