I’m encountering an issue where AudioProcessor::getXmlFromBinary() returns a null xml, only in Digital Performer for VST3 plugin format (maybe only from JUCE 8, but I still need to investigate).
The first condition (sizeInBytes > 8) is ok, but ByteOrder::littleEndianInt(data) == magicXmlNumberreturn return false. So when setStateInformation() is called, our plugin loses the saved state.
I’ve tested this with the VST3 plugin format. Could this be related to JUCE 8? Has anyone else experienced this issue or has more insights?
In other hosts/DAWs, the saved state is restored correctly.
Have you tried saving/restoring the state of any JUCE example VST3, e.g. AudioPluginDemo?
Do you see the same results in all cases?
It might be interesting to try viewing the binary data that is passed to the plugin (e.g. print as hex, or display in the ‘memory’ pane in your debugger) to see whether you can work out what the host is passing instead of the ‘correct’ state. e.g. maybe the endian-ness of some fields has been swapped, or maybe some extra bytes are being added/removed somewhere.
We’ve seen the same thing with the latest and greatest Digital Performer, for VST3 plugins on both Windows and macOS and JUCE8.0.x.
The binary blob that is provided to the host via the getStateInformation is vastly different (in terms of blob size and in terms of content) from what Digital Performer returns via setStateInformation in the AudioProcessor class.
We managed to reproduce this with the JUCE gain plugin example, but only when the flag was set that the VST3 can replace VST2 plugin. Without that flag set, DP seems to provide the correct blob back to the plugin.
We tried to contact DP devs several times about this, because it seems a bug in DP, but we haven’t received any response from them so far. VST(2) and AU seem to work fine.
I remember debugging an issue a couple of years ago where I discovered that DP simply never deletes plugin editors, it just happily leaks them. So since then I think of DP as a buggy host in my book
MOTU would love to get to the bottom of these reports. If you are a VST3 developer using Juce and are willing to work with MOTU to troubleshoot these reported issues, please DM me, thank you.
Hi - MOTU engineer here, just wanted to mention that we addressed an issue with plugin editors in one of the bugfix updates for DP11, and that may have resolved the issue you were seeing. MOTU would love to get to the bottom of these reports. If you know of any other issues (or are still seeing this one) and are willing to work with MOTU to troubleshoot, please DM me - thank you!
I think all the information to reproduce the issue is available here; open the JUCE gain plugin example, set ‘VST3 can replace VST2’, and try to let DP re-instate the VST3 state after saving a project and re-opening it. Or better, check the binary blob that is provided by the plugin with the getStateInformation() when saving a DP session, and check if the same blob is returned to the plugin using setStateInformation() when that session is reloaded.
Thanks for clarifying! I saw the repro steps detailed originally in the thread, but my initial attempt to repro ran into some completely unrelated snags that were my own fault. Once I got my environment cleaned up I was able to reproduce precisely the issue you’re describing, and our team will be investigating the issue. Please don’t hesitate to reach out if you run into any other issues of this nature - thanks again!
A quick update from MOTU: DP 11.34 is now shipping. Among other fixes, this maintenance update addresses the plugin data save/restore bug mentioned in this thread. Thank you to everyone here for bringing this to our attention! We would love to know how it goes for you all, and of course, please don’t hesitate to reach out if you run into similar issues in the future.
