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. Over 300 Preset Parsers have been developed already, and each PresetMagician release will increase support.
Plugins supporting the VST programs standard can be identified by the preset parsers named FullBankVstPresetParser, FallbackVstPresetParserand BankTrickeryVstPresetParser. They only support the raw preset data without any metadata like author, characteristics and types, and should be considered "better than nothing".
Will my favorite plugin be supported?
Preconditions:
The plugin is able to save/load data via the
getChunk()/setChunk()VST interfaces. This is a requirement by the NKS format. When I come across plugins not supporting that interface, I usually document it at the unsupported plugins status page.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.
If these two preconditions are met, chances are good that the plugin will be supported at some point. You can also help by reporting the plugin to the central PresetMagician database, so I can prioritize plugins by their priority. But this also depends on how complex the plugin format is; see below.
Can't I just give you remote access to my machine where the plugins are installed?
Short answer: No.
Long answer: Working on a remote machine would require me to install my complete development environment on your machine which takes a considerable amount of time, and some of these tools have a license which permit me from using them on other machines than the ones I own. Also, the input lag on remote machines is horrible to work with.
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
