Instrument Profiles – Reducing Setup Complexity for Modern VST Libraries

Cubase
, ,
1

Instrument Profiles – Reducing Setup Complexity for Modern VST Libraries

Why does a DAW know so little about the VST instruments it hosts ?

VST Instruments in 2026

Load instrument → Assign audio → Create Quick Controls → Set up drum maps → Create expression maps → Set tuning → Configure microphone positions…

After numerous setup steps in various menus, the instrument is finally fully configured.

I am specifically not referring to simple VST instruments where “load instrument, play MIDI notes, and you’re done” is all it takes.

I’m referring to modern libraries with articulations, multiple microphone positions, extensive controller functions, multi-output routing, and many other possibilities. It is precisely these instruments that offer enormous potential today, but at the same time require a disproportionately high amount of setup effort before their full range of functions can even be utilized.

Experienced users often address this problem with their templates or user presets. While these save time in everyday use, they do not solve the actual problem itself.
The setup effort remains, and as soon as new instruments or libraries need to be integrated into an existing template, many of these steps must be repeated.

The Problem

Virtual instruments have evolved tremendously in recent years.

Today, modern libraries offer numerous features such as articulations, triggers, controllers, multi-output routing, preset browsers, and much more. Some plugins now even integrate license management or complete online stores directly into their user interface.

While a USB-MIDI keyboard automatically transmits its properties to the operating system when connected, there is still no comparable way for virtual instruments to convey their musical properties and control options to the DAW in a standardized manner.

Instead, a great deal of information, such as controller mappings, articulations, playable ranges or notation data, must still be configured manually through various menu options within the DAW.

Most of this information is already available within the instrument itself. However, they remain locked within the plugin rather than being accessible to the DAW.

The Idea

Instrument Profiles

An instrument profile could provide a standardized way to describe the musical characteristics and control capabilities of a virtual instrument and make them available to the DAW.

Such a profile could, for example, contain the following information:

• Instrument type
• Playable note range
• Articulations
• Controller mapping
• Notation rules
• Transposition
• Library and preset information
• Audio setup
• as well as other instrument-specific properties

I don’t think I’m speaking only for myself when I say that I don’t want yet another individual feature that must be set up manually all over again.

Rather, I’d like to see a common foundation for integrating modern VST instruments, one that existing Cubase features can build upon.

Cubase already has the building blocks

Cubase already offers many excellent tools for working with modern VST instruments:

• Drum Maps
• Expression Maps
• Note Editor
• MIDI/Key Editor
• Instrument Rack
• Quick Controls
• VST
To just Name a few.

Taken individually, these tools work well.

In everyday use, however, they often feel like separate systems, even though they all require the same information about the same instrument.

In my opinion, this is why there is a need for a shared, central database that all existing functions can access.

This would not only reduce complexity and improve the workflow but also create a standardized foundation for future automation and new features.

How might this work in practice?

Audio Routing:

An instrument profile could, for example, provide the necessary information for the audio setup of a VST instrument.

A drum VST instrument could specify, for example, that the kick, snare, toms, or overheads can be routed to separate outputs.

Cubase could automatically read this information when loading the instrument, activate the corresponding audio outputs, and set up the routing on its own.

Expression and Drum Maps:

Many VST instruments already contain all the necessary information about their articulations, triggers, controllers, and playing styles. However, Cubase does not initially have access to this data.

For this reason, this information often must be re-entered in the form of expression or drum maps.

An instrument profile could provide this information directly. Cubase could then automatically generate appropriate expression and drum maps or configure other existing functions accordingly.

Notation:

An instrument profile could also provide the information needed by the Note Editor.

Instead of relying solely on a track’s MIDI data, Cubase could additionally access information from the Instrument Profile - such as instrument type, articulations, notation rules, or data from expression and drum maps.

This would make automatic notation not only more precise but also significantly more consistent, as it could take an instrument’s musical context into account much more effectively.

Visual Feedback:

An Instrument Profile could also improve the way the instrument is displayed within Cubase.

Based on the information stored in the profile, Cubase could automatically adapt the Key Editor to the respective instrument, for example by automatically displaying the Expression and Drum Map or by visually limiting the Piano Roll to the range of notes that can actually be played.

This would allow the user interface to adapt much better to the loaded instrument, and unnecessary information could be hidden without limiting the user’s flexibility.

Who creates the instrument profile?

An instrument profile could be created not only by the user or by Cubase itself, ideally it should already be provided by the manufacturer along with the VST instrument.

The manufacturer would not provide pre-configured Cubase settings but rather a standardized description of the instrument’s characteristics, playing style, and control options.

Cubase can then use this information to automatically configure existing features such as audio routing, expression or drum maps and the Note Editor.

Standardization and Backward Compatibility

Instrument profiles should not be reserved exclusively for future VST instruments.

Like MIDI remote profiles or drum maps, users could also create their own instrument profiles for existing VST instruments or share them with other users.

This would make the system backward compatible from the start and allow almost any existing VST instrument to be integrated gradually.

One piece of information, many functions

A piece of information should only need to be defined once and then be available wherever it is needed. An Instrument Profile could therefore become the central source of information for all instrument-specific properties within Cubase.

Instead of maintaining the same information separately in Drum Maps, Expression Maps, Notation or other areas of Cubase, the user, manufacturer or Cubase itself would define this data once in the Instrument Profiles database.

All Cubase functions based on this information could then make use of it automatically.

This preserves full flexibility for individual workflows while significantly reducing repetitive setup steps and duplicated data entries.

Closing Remarks

For me, this proposal is primarily about making the integration of modern VST instruments more user-friendly.

At the same time, such a foundation would open new possibilities, as it would consolidate existing information in one central location, eliminate the need for duplicate data maintenance, and allow existing Cubase features to be linked together in even more meaningful ways.

Perhaps this could even be a first step toward a new standard for integrating modern VST instruments, like the VST standard once standardized communication between DAWs and plugins.

Cubase could once again take on a pioneering role and demonstrate how modern VST instruments can work effectively with a DAW in the future.

I would therefore be interested to hear how other users view this idea and what other potential applications they see for such a concept.

2

Most of this could be done with Track Archives right?
→ Setup an Instrument Track, with the VST loaded, drum map, an expression map, transposition, Quick Controls, mic positions etc. configured, and then export the selected instrument track.

Yet nobody is bothered to maintain a central database with ready to use Track Archives for different sample libraries. And I can’t name a single VST-developer that is bothered to make a ready to use Track Archive for their product.

Of course it sounds enticing if there was a way to have somebody else do all the set up work, but I don’t think this would work in practice. (Everyone has their own unique way of working with their sample library, every artist has their own sound that they are going for, and therefore different choices the setup (routing/ mic positions/ notation etc.) are necessary.)

3

I actually believe that’s exactly why Track Archives aren’t the solution either.

Why would anyone go through all that effort to manually recreate information inside Cubase when most of it already exists inside the VST instrument itself?

Don’t get me wrong — I’ve created a few of my own instruments, but I eventually stopped because it simply takes far too much time.

What I’m trying to say is this:

The developer of a VST instrument already defines a default configuration. They know the playable range, articulations, controller assignments, available outputs, notation behavior, and much more. They also design the VST interface and define the instrument’s MIDI and audio capabilities.

So most of the needed information already exists within the Instrument itself.

Now take Expression Maps and Drum Maps as an example.

When creating one of them, you’re essentially doing two different things at the same time:

  1. You describe the instrument itself and what sounds it contains, which MIDI notes they are assigned to, and how Cubase should interpreted them.

  2. You’re customizing those settings to match your own workflow and preferences, telling Cubase how you personally want to interpret and work with that instrument.

Those are two completely different responsibilities, yet today they are handled as if they were the same thing.

  • The first step is describing the capabilities oft the instrument. This could be largely automated because the required information already exists inside the intrument itself.

  • The second step is personal customization. This is where every user creates their own unique workflow, and that should always remain fully customizable.

Track Archives are excellent for preserving your own setup, but they don’t eliminate the need to manually describe every instrument before you can customize it and save it as a Track Archive.

Whether someone owns 10, 500, or 20,000 instruments, user templates or not, the same problem remains: those initial setup steps have to be repeated at least once for every instrument by manually recreating information that already exists inside the instrument.

4

This, alone, has me drooling. But then again, I didn’t know that this was an option (that each kit piece could be routed to its own mixer track ) for a very long time. I won’t proceed to humiliate myself by divulging my “workaround” :wink: It truely was a " I was, today, X years old when I found out . . . " a day of elation mixed with a tinge of disgust. But, I digress. . .

However, I’m completely naive when it comes to making VSTs and have no clue as to what it would take to implement something along these lines. . . I imagine a situation similar to the early 80’s when the MIDI 1.0 specs were hashed out.

A VST 3.5 spec - if you will - an addendum to it might fit the bill that regulates how a VST interfaces with the user (in general terms) while within Cubase. But I can imagine this could turn out to be a nightmare for VST developers along with Steinberg trying to hold things together in something isn’t “mission critical”

But, I think you’re right. The information is already there within the VST - is there a way that can be passed on to the host DAW? Maybe, we can dream?

5

It sounds like a modern, virtual version of SysEx might solve the problem you’re describing. It would require cooperation between Steinberg and 3rd party developers tho. And that seems to be a depreciated component in recent years.

That said, It also sounds like the parameters you’re describing are very project / user specific.

I don’t find the need to set up all of the parameters you mentioned on the front end of every project. Sometimes I’m able to get my work done with very little customization of settings. But that’s me.

At some point SOMEONE is going to have to do all that work. Who should be responsible for a “shared, central database”? How are software programmers supposed to predict what every user expects to be a default state?

Maybe this should be some kind of open source project?

All THAT said, I really appreciate the way you presented and framed your argument. It’s probably something I would have skipped if it were presented like the typical , run-on, user forum diatribe. I actually read the whole thing!

:peace_symbol:

6

I mean i was clearly daydreaming about possible real world usecases.
I love logical automation and now talking about it… Probably even the Logical Editor could potentially benefit from having access to existing instruments data.

:joy: I know exactly what u mean. When i was new to Cubase, i had moments like that way to often.

Who would have thought that MIDI would evolve from “just connecting synthesizers” into a protocol that´s now used by countless other applications ?
But I´m drifting … Back to topic​:sweat_smile:

To be honest, I don’t know what the best technical solution would be either.

For me, the feature request is really just about the idea itself - a dream, if you will - rather than a polished master plan ready for implementation tomorrow.

Whether the solution ends up being an extension to the VST specification, a standardized metadata format, a protocol, database, or something completely different is probably something that people with much deeper knowledge of that area should decide.

I just think there’s a lot of potential in reusing information that many instruments already conatin instead of asking useres to recreate it manually.

To be fair, not every user will ever need all those feature that could benefit from such a concept. But anyone who wants to use things like, Expression Maps, Drum Maps, notation, the Logical Editor or similar functionality currently has to describe the instrument at least once - whether they later customize those settings or simply keep the instrument´s default layout.

That´s really the main point of my feature request.

7

I think none of that is necessary to add as it is already possible. But… the plugin developers have to program it and I think none of them actually do that.
The closest I’ve seen to this is Groove Agent 5, which looks like this internally when using one of the accoustic or percussion agents:

grafik
grafik1024×659 191 KB

And it let’s you transfer all the internal mixer settings to Cubase:

grafik
grafik356×595 70.3 KB

I think the latter functionality is not available to 3rd party developers but they should be able to activate their plugin’s outputs and name them. The whole routing happens inside the plugin already.

8

The idea for this feature request actually came from exactly that experience while building a large orchestral template with around 500 tracks, setting up Drum Maps, Expression Maps, and so on… so yes, it comes from someone who actually did the work. :sweat_smile:

However, thank you for taking the time to read all of that. I really do appreciate it.

I hope I managed to explain the underlying problem and the idea behind it clearly enough, even if the implementation is still an open question.

9

One of the issues for this great idea is that, just because those variables are located in a VST instrument, they are not necessarily exposed externally (other than standard midi channels and values).

Each programmer probably handles these internal data points in a unique way.

There would have to be a control data interface standard (or API for “Application Programming Interface”) developed. Not impossible but not simple either as each VST publisher would have to add the interface layer to their products.

10

Exactly. In fact, that’s one of the things that led me to this feature request in the first place.

Groove Agent already demonstrates that Cubase has some of the building blocks for this kind of workflow. My idea was basically to take that concept a step further and make it more consistent across instruments and DAW feature.

As far as I know, this currently only works for Groove Agent (and perhaps other Steinberg instruments implementing the same functionality?). I´m honestly not sure wheter third-praty developers can use it as well.

The same concept could potentially be useful for many other instrument-specific features, whether it’s drums, orchestral libraries, guitars, synths or anything else.

And yes, in many cases the routing information already exists inside the instrument. That’s exactly why I started wondering whether some of that information could be exposed to Cubase and reused instead of asking users to recreate it manually.

Anyway, I imagine something like this would be a long journey and would probably require some level of standardization.

But perhaps it doesn’t have to start with everything at once. Even simply bringing together Cubase’s own instrument data and user preferences, then reusing that information consistently across existing tools instead of asking users to configure the same instrument in multiple different places, would already be a huge step forward.

11

This in a sense is what Native Instrument’s NKS is. What it does is essentially what is described here, but for their Komplete Kontrol keyboards with the led strip over the keys. Once the script is loaded, the keyboard will display whichever colors keys have in the Kontakt instrument being selected along with things like articulations on the keys. If I’m not mistaken, Cakewalk’s intrument presets. Not only will they save the routing and eventual maps, but also the state the instrument in question was set when the preset was saved.

12

Could you stop using AI to write posts, especially about imaginary problems that don’t even exist.

13

So imaginary other users have voiced their opinion about the issue with some offering workarounds.