Aug 16, 2015 at 8:36 AM
I need to store complex XML inside the Ableton project. I don't want the user to have to save the XML externally anywhere.

I assumed Ableton would call GetChunk() when requesting this from the plugin for a save, and SetChunk once the project is reloaded. However, it's not doing this. I'm stuck.
Aug 17, 2015 at 9:44 AM
Just set this:
            PluginInfo.Flags = VstPluginFlags.HasEditor | VstPluginFlags.CanReplacing | VstPluginFlags.IsSynth | VstPluginFlags.ProgramChunks;
And this:
        public VstCanDoResult BeginLoadBank(VstPatchChunkInfo chunkInfo)
            return VstCanDoResult.Yes;

        /// <inheritdoc />
        public VstCanDoResult BeginLoadProgram(VstPatchChunkInfo chunkInfo)
            return VstCanDoResult.Yes;
And boom! She's blowing chunks!
Aug 22, 2015 at 6:54 AM
Are you using the Framework? Because if you are, you should only have to implement the IVstPluginPersistence interface, override the CreatePersistence on the InterfaceManager to return an instance of you implementation and you should be set...
Aug 23, 2015 at 12:19 AM
Ah - I see.

I didn't realise that there was built in functionality for persistence. I wrote my own code for it.

It's very simple. I just serialize to and from Xml. It's only a few lines of code. It's called in GetChunk, and SetChunk.

But, perhaps I should look at using the IVSTPluginPersistence?
Aug 23, 2015 at 2:35 AM
Actually - I'm really struggling with the standard .Net serializers. They are really painful to work with. I have to mark classes as serialize, and tell collections which types are to be expected - all with attributes. The problem is that I won't know what types the app should expect at compile time. I will only know at runtime - so attributes are useless.

Any ideas here? Do I need to use some different serializers? Does the plugin persistence framework get around this?
Aug 23, 2015 at 7:00 AM
The standard XmlSerializer simply serializes all public members. Use [XmlIgnore] to tag members you don't want serialized. Instantiate the XmlSerializer only specifying the root type and store in a static member. If you don't have any complex polymorphic xml constructs - that should be very easy. If you write an xsd, you can use xsd.exe (VS tools) to generate the classes for you. I never use these - but they are a great way to check if you have your code in order.

The persistence interface is geared towards storing custom presets. Might well be that if you just want an xml-blob, that overriding the command stub methods is more efficient. Downside could be that you need to know a couple of details on the VST interfacing spec. But it's not wrong or anything.

Hope it helps,
Aug 29, 2015 at 12:23 AM

I'm going to be looking at this today. The standard .net serializer simply doesn't work. I've been evaluating different options like Newtonsoft and sharp serializer. Both seem to be very problematic.

So far, wcf's data contract serializer is a clear winner. It allows for polymorphism and it also allows for calculating known types at runtime which is a must for me. Will report more of my findings soon.
Aug 29, 2015 at 6:40 AM
Edited Aug 29, 2015 at 6:40 AM
In .Net libraries:
linq to xml is easy but slow
XmlReader/Writer is fast but hard
Aug 30, 2015 at 3:50 AM
Here's a rundown of serialization technologies I've evaluated. I've ended sticking to WCF DataContract Serialization.

Here's my two cents. Firstly, I see serialization as something that should be simple, and should just work without having to do much. Obviously, you're always going to have to define which properties and types you want to serialize, and those that you do not. But, the technology should be flexible enough to allow for scenarios that would not be expected. One of the constant issues that comes up is when the serializer encounters a type that it does not know about. While I think that the DataContractSerializer is clunky, it at least allows for dealing with unexpected types. Of course verbosity and performance are factors, but I haven't been focused on those much.

Standard .Net Serialization
This has been around since the early days of .Net. It uses XML. It works when dealing with properties like floats and strings etc. but gets a bit clunky when dealing with anything more complex. It works by including all properties unless you explicitly exclude them. It can deal with unexpected types, but you have to define these with attributes at compile time. So, for me, this renders the technology useless. On top of this, it inexplicably complains when your collections contain type arguments for polymorphism. The dumb thing about that it is that its perfectly happy to accept types of "object" for type arguments. You can get around these issues with custom serialization, but that really defeats the purpose.

Newtonsoft Json.Net
This is a pretty decent library. It uses Json so it's a bit less verbose than XML. It's very straight forward to get started, but it seems pretty difficult to define which properties and types should be serialized. I didn't delve in to it deeply, but it's not as simple as just marking properties with attributes. I don't even know how you would tell it not to serialize a particular field. This would be worth having a go, but as yet, I've never really successfully used it for anything very complex. This library is very popular and has a lot of support.

Sharp Serializer
To be honest, I haven't got much to say about this. I just remember trying it, and instantly giving up because it seemed to hard to get it to work. That doesn't mean to say that it is too hard - it just didn't work for me right away.

WCF DataContract Serialization
This is the library behind the way WCF works. It is markup language agnostic so it has the flexibility to be serialized in any supported language, although I haven't really played with this. It defaults to XML. I chose this for one main reason. The reason is that this library accepts collections with a type argument where the type argument is an interface - i.e. polymorphic. This is what I needed for my project because I do not know what I will be putting in the collection until I hit the save button. Actually, because the user can define types, it's necessary for the serializer to be able to do this. With this serializer you can provide a list of known types so that it is not surprised by types when it attempts to serialize/deserialize. Basically, I've had success with this, without have to do much. The one downside (or perhaps upside) is that you have to explicitly elect which properties and types to serialize by marking them with attributes. I think this is overkill, but what are you gonna do?