Plugins backup
Last saved by Pierre henri Seylan on March 13, 2016
Context:
This document list the basic concept of audio plugins backup, meaning the backing up of audio softwares files on the server.
This part could have been done directly via the media library, but due to some automations needed and a couple of issues in the media library, it looks like it is better to make it abstract first and then integrating it to the media library, by display ing the plugins in the media lib UI.
The basic concept of audio plugin backup is the auto-push/pull of audio plugins, which can be easily located by the app.
The implementation should be done first on the app only, with the current available functionalities.
Details:
1.Types of plugins:
Mainly, the audio plugins are bundled files with the following extensions:
- .vst
- .vst3
- .vsti
- .component
- .aax
The plugins are located on mac in user/audio/plugins
The juce framework and the vapor app already have a template for scanning those locations on both mac and windows.
2.Backup Process :
2.1: Access to backup mechanism:
On the user interface, the user will have a backup menu, with the following options:
- Projects backup
- Plugins backup
When selecting the plugins backup options, a dialog window appraise with the following message/options:
- messg: You are about to backup your audio plugins, please select the types you want backup:
- options: VST/VST3/AU/AAX
- buttons: OK/Cancel
2.2 First push:
When the user backs up the plugins, the app performs a scan of the plugins and compares with the ones present on the server.
This should contain the hashing step (same as for media library files)
The plugins are pushed to the server accordingly, in 1 single task.
2.3 Update of plugins:
The backup process implies an auto-update mechanism, as for the project and media library files.
The app monitors the relevant directories with the filewatcher functions and pushes the changes to the server.
The plugins are pushed to the server for the following cases:
- file is updated
- new plugin is added
- New plugins: X new plugin(s) installed
- Plugins backup: Your plugins have been uploaded
2.4 Management of local datas:
- The Plugins should NOT be located in the media library, the should not be moved or copied there.
- Plugin DB: a local DB should be created for the plugins, it could be an extension of the media library DB, or a new one done like the projects DB
- Recoup with plugins list: In the VST there is a plugin list that is created after scanning for plugins, for sake of consistency we should use the same list for the 2 areas of the apps, the client should create the plugin DB/ list in the same way as it is done by the VST, so that both apps are editing the same data, it will also facilitate the pushing of the list to the server, which is needed for future features
3. Pull of plugins:
The pull of the plugins will occur via the media library as for regular files
However the plugins are not pulled in the media library, they are pulled to the relevant directory (depending of mac/win)
e.g a VST is pulled to the VST directory, while a .component is pulled to the Audio units directory
4. Display in media library:
The plugins are displayed in the media library, under a new fixed favorite folder (cannot be removed by the user)
the side folder is called: Audio Plugins
Plugins are displayed as media library files, with their own icon, the icon will be delivered via the app backend, e.g it will be a software for which we will throw an exception (not tracked, but used for plugins)
5. Summary of app component used:
- Plugin scanning
- File watcher: to watch for update
- Backup mechanism of media lib/projects: auto-push of files when a change occurs
- Media library interface: displaying the plugins in the media library
- Medias lib or projects DB