View Issue Details
|0007679: Plugin preset switching is difficult and cannot be automated, and presets cannot be easily imported
|Many VST instruments, e.g. modular synths, depend heavily on presets. One workflow involves using a bank of presets, switching quickly between presets until you have something close to the sound you want, and then fine-tuning.
Issue 0000001: This is wildly impractical with the current interface: in a long list of presets, it can take a minute or more to switch from one preset to the next preset in the list, because when you click on the drop-down menu, it resets you the center of the list (see attached screenshot). This is unsuitable for real-time composition.
Feature Request 0000001: Assignable keyboard shortcuts to move to the next/previous preset in the list. (Compare to how digital pianos let you switch tones with a single button press)
Issue #2: While you can automate every parameter of a plugin individually, it seems you cannot automate switching presets. This would be a useful feature for live performance / recording, as it enables you to use a midi controller to switch between presets. The current workaround is to have multiple instances of the same VST on different channels set to different presets (an ugly and resource intensive hack).
Feature Request #2: Allow automation of preset selection.
Issue #3: The GUI does not have a way to import/export presets. It also seems that default presets cannot be deleted or re-ordered through the GUI.
Feature Request #3: Create a GUI means of importing/exporting presets, deleting default presets, and organizing presets.
|Steps To Reproduce
|To see how difficult preset switching is (issue 0000001):
1. Load a VST plugin with >150 presets.
2. Create two new presets, one named Preset A, the other Preset B.
3. Select Preset A.
4. Now, try to switch to Preset B (which is immediately next to Preset A)
|Issue 0000001 is the most pressing, as there is currently no workaround. It should be a relatively simple feature to implement: just create a new action which cycles forward and backwards through the list of presets for a plugin when focused on the Edit menu of a plugin.
This is not really an issue for post-production work, but it hampers creative flow when used for real-time composition.
|No tags attached.
At least "Feature Request #2: Allow automation of preset selection" is a no-go for VST. It is not realtime-safe to change presets that include plugin internal state (that is not exposed as control ports).
The vast majority of VST plugins do not expose presets to begin with but have a custom preset method provided by the plugin itself.
Is there a particular plugin that has > 150 presets but no internal preset management that you can suggest to test?
I've recently toyed with https://lhiaudio.com/cadmium that comes with a lot of presets and didn't find it as unpleasant to use as you describe, granted though, user-presets are sorted last.
Ob-Xd (one of the few free cross-platform VSTs) is an example: https://www.discodsp.com/obxd/
You can see it includes a lot of identical "default" presets. Presumably the idea being that you will fill these in as you desire. "Save" and "Delete" buttons are greyed out for these, but if you modify them, the changes are automatically persistently saved by Ardour on a per-session basis (but settings do not cross between sessions, so it's not saved anywhere internal to the VST). I presume that this means these presets are thus exposed to some degree to Ardour. I'm running on Arch Linux with Gnome 3.30 (not sure if this is relevant).
When using this plugin, you can create user presets, and these user-created presets are sorted last, but if you click on the preset drop-down menu, it puts you right in the middle of list (rather than over where you were), so you have to scroll all the way back down to switch between user-created presets that are adjacent to each other. This may be a Linux specific problem. Putting the cursor over the dropdown menu and mouse-wheeling up or down does seem to work, however, so it's only an issue when you actually click the drop-down menu.
Most of my problems would be solved if there were an assignable keyboard shortcut to switch between the presets in the drop-down menu. From what I understand, at least for this VST plugin, changing a preset is the same as simultaneously adjusting the already-exposed controls. If I wanted to assign a MIDI function to emulate switching between presets, I could do that by making a bunch of different tracks set to listen to different MIDI channels, but that would take hours. Preset switching for this plugin could also be emulated in a single track by automating each of the controls separately, but this is too tedious for live use. If there were an assignable keyboard shortcut, I could use an external program to intercept MIDI signals from a controller and input keystrokes.
Prodigious Synthesizer is another example: https://www.kvraudio.com/product/prodigious-synthesizer-by-synthescience
This one I know for a fact has >100 different presets by default. I'm running it through LinVST (which wraps a Windows VST through an emulation layer as a Linux VST).
When run in Reaper on Windows, the presets have names. Here they are just labeled "Preset 1", "Preset 2", etc. That may just be LinVST doing a bad job wrapping it, though. Everything else seems to work perfectly, though.
Here's it's easy to see the problem. Click on the drop-down preset menu. Select "Preset 100". Now click on the drop-down preset menu again: your mouse is now over "Preset 18".
Is there a reason why the "Program Change" MIDI signal can't be routed to select the preset of a VST instrument (as it would do for a physical instrument)? Ardour has access to this preset list, since they can be switched between in the part of the GUI controlled by Ardour and not the plugin. I'm not sure I understand the safety concern, since this switching can be done "live" using the mouse, even in the middle of recording automation. The only issue is that when you change the preset in, say, Prodigious, the corresponding changes in parameters are not registered in the automation recording until some other slight manual change is made to one of the parameters. Perhaps the values of the parameters are not polled when a preset is changed?
I have not personally encountered a VST instrument whose preset cannot be changed live. I can see how this might be an issue for a VST which has hidden parameters and an internal preset switching, but for these Ardour would not see this internal preset list anyway (so let's put these VSTs aside for this discussion).
I'm open to an argument that if a VST instrument does not make any use of Program Change commands, that's its own fault, and not the fault of the DAW. It would also be possible (although tedious) to use write a plugin to control the parameters of a VST instrument based on Program Change commands (it would require configuring each VST instrument separately). A third option would be to write a VST wrapper that acts as a primitive VST host, accepts Program Change commands, and changes the preset of the wrapped VST instrument, and passes through all other parameters.
It's just as a practical matter, there are many VSTs which do not respond to Program Change commands, but do have a somewhat standard way of switching between presets, and it would be nice to be able to trigger this by a MIDI event or something similar.
One more thing: the situation with preset switching is most difficult on a laptop trackpad. Trying to double-finger scroll on a tiny drop-down menu without accidentally clicking is difficult. Even just adding two buttons for "<" and ">" for previous and next preset would help a lot with usability.
In any case, thanks for considering this!
|File Added: PresetScreenshot.png
|Note Added: 0020452
|Note Added: 0020454
|Note Added: 0020455
|Note Added: 0020456
|Note Edited: 0020456