IMPROVE PRESETS + MENUS - static pop-out browser instead of drop-down, save/replace, more

awesomeaudio · March 18, 2026, 9:08pm

Static Pop-Out Browser, instead of temporary drop-down.

I’ve long been hoping Cubase would change the way preset menus work in Cubase.

Who this is for:
- Sound-Designers looking for just the right effect, or exploring.
- Pop Producers “ “
- Post-Production “ “
- Preset Makers “ “
- ………………………. Everyone……………
Benefits:
- Easier casual preset exploration
- Users can easily browse presets across multiple plugins that are chained together.
- Easier sound design/project management

Working from the current drop-down menu is not great

It doesn’t stay open
- As you are browsing/loading/testing presets you might want to:
  - Adjust a modulator
  - Adjust a channel fader
  - Move the plugin window
  - adjust automation
  - adjust a send level
  - Hit talk-back
  - etc

Every time you open it, it’s covering the plugin
The preset menu does allow auto-loading - yet what good is that if it’s blocking the plugin for users to see and understand what is changing.

The Open Menu and Load Preset functions are essentially the same but cover different parts of the plugin:

The ‘Load Preset’ option, doesn’t remember its window reposition, always re-opening in the same spot, which is center screen.

The “solution” is to move the plugin away, which as stated, closes the menu.

Multiple Potential Solutions to the Above Issues

Solution 1 (combo):
- Preset menu never opens over the plugin GUI, ie, the menu automatically detects where plugin window is, what the users screen real-estate is, and opens the menu in a convenient location (detects other plugins/windows open as well)
- Give users a preference/setting: ‘Leave Plugin Preset Menu Open’ + ‘Plugin Preset Menu Always On top.
Solution 2 - Preset Browser Pop-Out (My preferred solution)
- Steinberg has already started to implement expandable GUI of the native “wrapper” with modulators and quick controls:
- Preset Browser would always stay open until the user closes it
  - Preset Browser Open/Close state would be saved with the preset, thus it’s open state can be saved to the Preset Default.
  - If a user closes a plugin with the browser open, it will be open again when that user re-opens that particular plugin/insert.
  - Browser conditions remembered - last typed search, etc
- Allow users to decide where the preset browser pops out (right of plugin, bottom, etc) stored per plugin.dll/.vst3 to accommodate users screen format, each plugins size, and browser columns width needs.

Right Orientation

Bottom Orientation

Header Button

Right Zone Integration:
- Button in plugins header that quick links them to the directory in the Right Zone media browser

The best option, is to do all three of these things. They all have their pros and cons based on user workflow needs, type of profession, user scree size, plugin size, etc.

Plugin Preset Saving and Name Size

Please, allow the preset name space to be larger. Us sound-designers use descriptive naming and also save revisions often. I need to know what revision/preset I am in.

I know you have the scripting capability to auto-resize the name space/truncate the name if the plugin is smaller, as well as relocate the header space to be double or even triple row.

The name space problem is definitely compounded by the saving protocol…

…When saving a plugin preset, it doesn’t recall the name in the ‘Save Name box’…. As stated above, this is very problematic as a sound-designer/preset maker if you have made multiple revisions of a preset and you can’t see the name if you want to save over it.

SAVE NEW VERSION (for plugins)

Plugins should have the same ‘-01’ to ‘-xx’ Save New Version protocol.

There should be a button in the header for this. Clicking it saves a New Version. Right clicking it brings open a drop-down menu and Save Versions of that particular preset (ie, it investigates name and looks for same name with ‘-xx-’ at the end of the name.)

One great side benefit thing about this, is it gives users an expanded A/B system which sometimes isn’t enough.

I think that’s it for now. Thanks

to finish

Here’s a mockup of two plugins in series both with their browsers open:

Think about the sound-design workflow……… It’s the simple things like this, that can yield powerful results.

edit

Save Plugin State - Save modulators, QCs, etc

I was pondering something else but didn’t come to a conclusion. Modulators aren’t saved with plugin presets… Yet. modulators could create an effect in combination with a plugin that in which the combination is the effect.

There is a benefit to Modulators not saving with presets, and that is, you might want a modulator to stay the same/active on a parameter while browsing presets.

Do we need a new plugin save level that is customizable on both Save and Load?

‘Save Plugin State’ could include both Modulators and Quick Controls, as well as Browser search results.

When the user selects ‘Save Plugin State’, it brings up a check-box prompt window where the user selects:

Which of individual modulators to save / all
Which of individual Quick Controls to save / all
Which of browser settings to save / all
- Search box text
- filters
- file index location

When loading ‘Load Plugin State’, a similar prompt window appears where the user selects what will be loaded / all, and for example, conflicts are shown if there are already existing Quick Controls on the channel, and the user can decide to replace or relocate loaded QC to a different slot, etc.

Modulators being loaded would always be additive to already existing modulators, but the user would have to resolve conflicts in the ‘Load State’ prompt - keeping the current modulator, or loading in the replacement.

Or another way of deconflicting save current modulator vs loaded, is to bypass the current and load State Preset active.

Both regular plugin saved files, and ‘Save State’ files would appear together in the Load Preset browser, ‘Save State’ files would have a different icon. Modulators would preview, but QCs would not.