Plugin Support
Is my Plugin supported?
This depends on the plugin itself. You can check the supported plugins database to find out.
PresetMagician supports plugins implementing the VST Programs Standard. For all other plugins a special piece of software, called a Preset Parser, needs to be implemented.
Do you prefer some plugin vendors when implementing new vendor-specific support?
Absolutely yes! I prefer vendors which:
use the same or a similar format in memory as the preset files on disk. This makes it easy to implement vendor-specific support.
use the same or a similar format for all their plugins. This saves lots of effort, as I only need to write support for one vendor and apply it to all plugins.
have public demo versions which support save/recall using the
getChunk()/setChunk()VST interfaces. Some vendors disable them in their demo versions, and without actually buying the plugins, I'm not able to write support for these plugins.Plugins I personally own and fulfill the requirements above
Basically I need access to a demo version which is not limited in saving/recalling presets (getChunk() / setChunk() support, see above), because I really can't afford buying all plugins.
Please don't offer to send me your license for a specific plugin, unless you will never use the license again and permanently transfer the license to me.
Sharing licenses are mostly illegal, even for development purposes. I need to be able to use the license whenever I need to - for example, if somebody reports a problem with a specific plugin or preset parser.
If everything goes well, I can pull off support for a plugin within minutes. However, especially the big brands, tend to use complicated mechanisms to store their presets, and the required effort can take several hours, days or even requires assistance by the developer. Staring at bits and bytes without an obvious pattern can be tedious.
Why is it so complicated to support all plugins on the market?
Each vendor uses a different format to store their presets, sometimes the format even differs from plugin to plugin from the same vendor. The plugin might store presets in individual files, or in a database, or a combination of both. Sometimes the preset format on disk is completely different to what the plugin expects when loading the preset using a DAW.
The general process I use to implement support for a plugin:
Figuring out where the plugin stores its preset, and in which format
Figuring out if the plugin's in-memory format is equal or similar to the format on-disk
If it's the same or similar format, it's relatively easy to implement a specific Preset Parser for that plugin
If the format is different, things are starting to get complicated (and interesting). I have to figure out where the differences are, which is relatively easy for presets stored in text format but hard to very hard for binary files.
Reverse engineering a binary file format is a bit like (legally) cracking a safe. It can take minutes, hours, or a very long time.
After understanding the plugin's preset format and implementing a Preset Parser, I actually need to test the implementation. That involves checking if the audio previews are generated correctly and if the generated NKS file can be opened in Maschine and if the plugin also receives the correct data. That's why I actually need the plugin itself
After everything went well, I finally write automated unit and/or functional tests to ensure that the Preset Parser works with each release (note that I started this with PresetMagician 0.5.5, so it can take a while until every Preset Parser has their tests in place)
Why support plugins which are already NKS-enabled?
NKS support across plugins is mostly incomplete. For example, when you install a new sound bank, the plugin typically does not generate NKS presets for that new sound bank. Also, some vendors don't include audio previews in their plugins, despite the fact they do supply the NKS files.
Last updated
