enhance VST3 API:Vienna Ensemble Pro “Send-snapshot data only" option for plugin-save-state data

It actually needs NI to liaise with Steinberg in order to improve VST3 in order to support the feature here.

This suggestion addresses KONTAKT and Vienna Ensemble Pro with regard to the slow speed of communicating COUPLED instance data from Vienna Ensemble Pro client plugins to VEP Vienna Ensemble Pro Servers hosting multiple instances of KONTAKT sample instruments and other plugins which store very large amounts of plugin saved-state data.

Kontakt has a feature called SNAPSHOTS which allows one to save different parameter settings for things like reverb, effects, volumes etc while leaving data such as sample metadata, KSP scripts and everything to do with the particular Kontakt insrtument “core” datas alone.

The amount of data involved in Kontakt snapshots is generally tiny in comparison with the complete data needed for the Kontakt instrument itself and its sample layer metadata - so to save and recall just this alone would be significantly faster - arguably near-instant compared the waits for Kontakt to load and initialise the Kontakt instrument saved-state data in its entirety.
If an updated version of VST3 incorporated the additional concept of snapshot state-saving and loading - then VST3 plugin hosts like VEP could use this to make saving and restoring small tweaks to plugins hosted in VEP very fast.
Of course because a single instance of KONTAKT can use more than one KONTAKT instrument in the form of MULTIS. There would have to be support for saving and loading more snapshot data for potentially more than just one “instrument” but this could easily be added to an API by means of an index to indicate “multi-instrument 1, multi-instrument 2 etc etc

Such an improvement in VST3 would have a huge positive effect on workflow. The only other major aspect in a VST3 “+” would be to allow the plugin editor panel to be presented on the CLIENT machine - ie in a VEP CLIENT plugin if one could tweak a plugin held on a VEP server as if it were local - instead of having to use VNC or some other remote access software - then again there would be a huge benefit to workflow.

 

Snapshots on their own cannot work - they require the NKI they are tied to, in order to load the data they don't contain. So, as far as host chunk data is concerned, this can only really be the whole multi, not snapshots in any form.

 

Yes I realise this. So any improvements to the VST3 API would have to support something like a "Multi-instrument-index" parameter so that when sending or loading such snapshot data - the plugin ( say KONTAKT ) can apply the data to the instrument in the KONTAKT MULTI-RACK corresponding to the index.

 

I doubt this will happen, since snapshots are really Kontakt-specific, this wouldn't apply to any other plugin. Also snapshots literally aren't a part of anything in Kontakt - they themselves are NOT stored in the multi, or host chunk, at all, so there's no savings in host chunk size to be had here.

 

Well this might be true in that snapshots - as implemented by and for NI for Kontakt specifically - is currently an in-house proprietary API standard.
However the concept behind snapshots (sometimes called scenes for example in Kemper profilers ) is found in many other products. Maybe even in Halion (not sure). So the concept could be introduced and supported in plugins across the board if all parties came to an agreement about how to implement this in an updated VST3 API. A similar API could also on agreement with Apple devs be introduced to AU or ( more likely ) AUv3.

In many cases where the save/load snapshots feature would in effect offer nothing different in performance to loading the entire plugin saved-state the API could simply do the same thing - but in a different way. Currently loading/saving plugin states involved sending an anonymous single block of data. The same would apply to sending snapshot data - it would be a just an identical block of data but with a checksum header built into both the full save-state API AND the snapshot API - there could be mechanisms built in to ensure that if exactly the same state information has been received by the plugin by both API's. the second occurrence would just be ignored. These things can all be sorted out by the experienced and talented VST and plugin and API developers such as Ivan Grabit at Steinberg - along with the key players here - NI and Vienna.

<they themselves are NOT stored in the multi, or host chunk, at all, so there's no savings in host chunk size >

Yes the whole point of this is that NO changes are ( or NEED ) to be made to the host chunk in Kontakt - what is being discussed here is being able to quickly recall parameter changes made to one or more specific instrument instances in an instance of Kontakt.

~remember that the point of this API request and change is all about when an instrument is ALREADY fully loaded and initialised with save state data - IN A PLUGIN SERVER HOST. In VEP the most common and beneficial use case is when plugins remain instantiated all the time - independently of Cubase or DAW projects being opened and closed which connect to the server. So the idea is that - say a KONTAKT instance loaded in VEP that contains a bunch of different KONTAKT grand piano instruments - say all the pianos in KOMPLETE ULTIMATE - gets loaded initially once at the beginning of the day - and each piano gets the initial startup block of save-state data as stored in the Vienna Ensemble Pro Server project file.
This would take a lot of time but is only done once until the server is shut down. But then throughout the day as different DAW projects get loaded up and used and then switched - that use the pianos in the VEP server - any differences in the parameters for one or more of the piano instances held in the KONTAKT instance - would be transmitted by the DAW - after the DAW project file is loaded.

In fact VEP already can send plugin parameter data from its client plugin in DAW to the VEP server plugin instance. But I don't think this can currently - include parameter data of specific instrument instances. ( NEED TO LOOK INTO THAT).

Such a new API would include an index to indicate which Kontakt instrument instance the incoming parameter data is for.

The first instrument would be index 0 ( or 1 dependent on developer preference ) and if a particular plugin doesn't support the concept of multis then the index would just be ignored.

 

I think you're overcomplicating this whole thing. There's no API for snapshots at all, just like there's no API for anything else in Kontakt. This does not need to be tied to a plugin format at all. What you're asking for is basically being able to load snapshots remotely, with some sort of command (i.e. via MIDI program change or KSP multiscript), right?

If VEP basically just sends plugin chunks, then that already contains all the plugin parameter data (the whole multi, in case of Kontakt)...