Restoring state in Cubase 7 doesn't appear to work

I've been trying to get to the bottom of a very odd problem.  This shows up with Juce tips over the last month or so, but doesn't appear to show up in earlier versions.

I create a session in Cubase 7 (Mac/64-bit), load a plugin and change some parameters.  Then I save the session.  When I restore the session, the plugin is in a default state--those saved values haven't been loaded.  But here's what makes it interesting--using the same build of the plugin, I try the same thing in Reaper and Ableton.  Everything works fine and the session is fully restored.  I have testers tell me the same thing with other programs I don't have.  Cubase is alone in this strange behavior.

This doesn't happen with a plugin build using the Juce of 2-3 months ago (I'm really sorry I don't have exact tip dates).  Same version of Cubase 7 restores all values.  Something has changed.

I've been driving this through the debugger, and I can see that Cubase doesn't call setStateInformation with any parameter chunk (Reaper and Ableton do).  Deeper into Cubase, this is based on the effSetChunk opcode. That opcode doesn't appear to pass through the dispatcher. I really can't see anything obvious in the Juce code, but there does appear to be something going on that's unique to Cubase (don't get me started on Cubase).  Still, older versions of Juce work.

Anybody seen this one?  Any ideas?


So it's calling JuceVSTWrapper::getChunk, but not setChunk?? Bizarre...

All I can think of to suggest is that I think Cubase might pay more attention to the plugin's version number than other hosts - perhaps you're somehow returning an inconsistent version number and it's deciding not to give you the chunk back because it doesn't match up?

I found this old post ( that never received a reply from anyone.  In the constructor for the VST wrapper, you'll find the following line:

cEffect.version = convertHexVersionToDecimal (JucePlugin_VersionCode);

The original poster speculated that the meaning of this was different from the normal purpose of JucePlugin_VersionCode.  He was right. JucePlugin_VersionCode is typically used as a display value, whether for the Finder, the DAW or whatever.  It should be changed whenever new code is released.  But the meaning of cEffect.version is very different.  It appears to apply to something more basic about the plugin--the number of parameters or something that would invalidate previously-saved state.  I changed this value back to the previous working version number, leaving JucePlugin_VersionCode with its new value.  The previous state restored perfectly.

I would request that you add a new symbol to AppConfig.h, perhaps named JucePlugin_InternalStructureVersion.  This should change only when something important happens in the plugin.  Use this value to set cEffect.version -- at least in VST ---and Cubase will be happy.  Not every VST DAW checks this value, although perhaps they should.


Edit:  I should also point out that the utility routine convertHexVersionToDecimal is incorrect, scaling by powers of 10 rather than powers of 16.  This means that different hex values can give the same decimal value.  It's probably too late to change it without causing problems to plugins already in the field, but it's worth some serious comment that JucePlugin_VersionCode shouldn't have any of the four byte values greater than 0x09.  Haven't seen Binary Coded Decimal in a while...

Cubase is quite picky about loading chunks. It also doesn’t load a chunk if the version number has decreased (e.g. project saved with 1.1 but loaded with 1.0) or if the number of programs/patches has decreased.


I do want to keep this one alive.  It's a serious issue that will hit developers by surprise.  An innocent change of a version number can cause parameter loads to fail.  This affects Cubase and VSL VePro 5 (probably others too).

Did you see the JUCE_VST_RETURN_HEX_VERSION_NUMBER_DIRECTLY flag in there? If you set that, it won't do any conversion.. Or is that not enough for what you're trying to do?