Jules, would you consider adding this to the source tree when ready?
Sure, thanks very much!
diff --git a/modules/juce_audio_plugin_client/utility/juce_CheckSettingMacros.h b/modules/juce_audio_plugin_client/utility/juce_CheckSettingMacros.h
index a942404..fcb9e02 100644
@@ -26,7 +26,7 @@
// The following checks should cause a compile error if you've forgotten to
// define all your plugin settings properly..
-#if ! (JucePlugin_Build_VST || JucePlugin_Build_AU || JucePlugin_Build_RTAS || JucePlugin_Build_Standalone)
+#if ! (JucePlugin_Build_VST || JucePlugin_Build_AU || JucePlugin_Build_RTAS || JucePlugin_Build_Standalone || JucePlugin_Build_LV2)
#error "You need to enable at least one plugin format!"
diff --git a/modules/juce_audio_processors/processors/juce_AudioProcessor.cpp b/modules/juce_audio_processors/processors/juce_AudioProcessor.cpp
index 03e0ab4..4d797f5 100644
@@ -246,6 +246,16 @@ void AudioProcessor::setCurrentProgramStateInformation (const void* data, int si
+String AudioProcessor::getStateInformationString ()
+ return String::empty;
+void AudioProcessor::setStateInformationString (const String& data)
// magic number to identify memory blocks that we've stored as XML
const uint32 magicXmlNumber = 0x21324356;
diff --git a/modules/juce_audio_processors/processors/juce_AudioProcessor.h b/modules/juce_audio_processors/processors/juce_AudioProcessor.h
index f5c224c..37866c2 100644
@@ -524,6 +524,12 @@ public:
virtual void setCurrentProgramStateInformation (const void* data, int sizeInBytes);
+ /** LV2 specific calls, saving/restore as string. */
+ virtual String getStateInformationString ();
+ virtual void setStateInformationString (const String& data);
/** Adds a listener that will be called when an aspect of this processor changes. */
jules wrote:Ok.. but I don't understand the need for the string methods. Can't you just convert the binary data to a base-64 string?
jules wrote:But if you just convert the binary data to/from strings, then all existing plugins will work without modification, which is surely a good thing?
Short answer, blobs are not portable
For example, say I save state on an i386, throw that session on a USB key and restore it on a different x64 machine. If the state is just a binary blob, which is not portable (it may contain integers and pointers, for example) this is not only impossible to do correctly, it will fail catastrophically.
Of course it's possible - sometimes. However, if you don't know whether or not the data is indeed portable, then the only safe assumption is that it is not. Therefore, via such an interface, it is impossible. That is the problem.
You can't allow arbitrary non-portable binary data and not even have a mechanism to say so. How is a host to know the state isn't suitable for distribution (e.g. as part of a preset or example session) or loading on a different machine?
Why would you choose something that requires such lofty unrealistic things of plugins (all that binary portability stuff), when a simple superior alternative provides all the benefits while requiring almost nothing of plugins (specify a type or a flag) and allows the host to avoid any potential problems whatsoever? That is not a sensible decision.
What the heck could the disadvantage be of allowing the host to avoid problems by not restoring non-portable state on the wrong platform?
Users browsing this forum: No registered users and 3 guests