Text based program and bank VST files?

DSP, Plugin and Host development discussion.
Post Reply New Topic
RELATED
PRODUCTS

Post

For those choosing to use 'chunks' for persisting data for VST plugins, I was wondering if you simply write out the normalized floating point parameter values to the files (with maybe some header info to identify the type of file, plugin, version, etc.), or actually write human readable text files.

Seems like there are advantages and disadvantages to both. A binary file approach would be pretty easy to read and write. But versioning might be a challenge. For example, take a parameter value representing a waveform choices, e.g. saw, square, etc. If in a future version of your plugin you add waveforms, you'll need to take into account the version of the file you're reading and adjust the parameter value accordingly before mapping it to an index or name of the waveform.

That's not to say that versioning would be ignored in a text based approach, but it might be simpler in a lot of cases. In the waveform example, you wouldn't be mapping a normalized parameter value to the waveforms but would rather simply read the waveform name, something like:

Code: Select all

osc1Wave=saw
A text based approach would have the advantage that you could actually edit it by hand. But it would have the disadvantage that you'd have to write some possibly complex code to parse the files. And there's a lot more potential for syntax errors in your files, if they were edited by hand.

Thoughts?

P.S. I'm talking about VST plugins v2.*. I've no idea how VST 3.* handles persistence.

Post

I dont see the point in having patch files human editable / readable, I've never needed that myself and I certainly dont want users messing about with it.

But having a hierarchical structure where everything is named and structured makes life so much easier if you are likely to be expanding / modifying the patch format. In fact I dont think I could have done my synth any other way.

So I have something that is similar to json but all the actual data is binary. Essentially everything is a chunk, either a specific type, int32, float64 etc.. or it is an aggregate chunk, an object chunk with name/value pairs, or an array chunk with just values.

That gives you the best of both IMO, names and structure, but you dont have to worry about conversions to/from text.
Chris Jones
www.sonigen.com

Post

I use human-readable XML files. Being human readable makes things easier for me. I can easily check patch files are being read & written correctly during development.

Regardless of whether you use a binary or human-readable format I think decoupling the internal parameter state and external patch format is good. It makes it easier to change the plugin parameters. (Change a parameters range or adding a new waveform type for example.) I think it can ease importing foreign patch formats as well.
A text based approach would have the advantage that you could actually edit it by hand. But it would have the disadvantage that you'd have to write some possibly complex code to parse the files.
Using a ready-made XML parser or similar takes away much of the work. Then you only need convert parameter values to and from a text string.


Shannon

Post

i store mine as JSON using the excellent yajl library. the unstripped static library is like 88k, the format itself isn't super verbose, easy to handle different versions, etc.
owner/operator LHI Audio

Post

If you are serious about supporting multiple versions - you probably write code that converts older versions to the current one. This would allow the user to use the latest plugin in an old song (with old settings).

That conversion routine is at the binary level. If you choose to make you chunks human readable that is just another layer that converts from readable to binary and may be specific to each version. This also means that your plugin contains all persistence code for all versions you wish to be backwards compatible with.

If you structure you code this way you can go any direction for any version -assumed (binary) values can be converted.

[] = optional
version 1 chunk => [Human->bin =>] version1->version2 => version2-bin
version 2 chunk => [Human->bin =>] version2-bin

Now it does not really matter if you make your patch data human readable or not.

[2c]
Marc
Grtx, Marc Jacobi.
VST.NET | MIDI.NET

Post

Another vote for json format here. If size is a concern, just compress the json data.
I use picojson, which is tiny, fast, and just works.

Post Reply

Return to “DSP and Plugin Development”