I wanted to share a set of structured recommendations for improving Cubase’s startup efficiency, especially around plugin scanning and subsystem initialization. These ideas focus on reducing unnecessary work during launch, improving caching, and making the startup pipeline more resilient and responsive.
Modernize the plugin scanning system
Scan plugins only when they change, using file hashes or timestamps.
Sandbox plugin scanning in a separate process so a single plugin cannot stall Cubase.
Cache plugin metadata in a binary database for instant loading.
Prioritize VST3 and freeze VST2 scanning unless the user forces a rescan.
Introduce lazy loading for non‑critical subsystems
Load the UI immediately and initialize MediaBay, Hub, Control Room, and remote devices in the background.
Initialize the ASIO driver only when a project is opened.
Load HALion/Groove Agent content only when needed.
Parallelize the startup pipeline
Run plugin scanning, MediaBay indexing, and Hub loading in parallel threads.
Delay non‑critical tasks until after the user can interact with the program.
Improve MediaBay performance
Use incremental indexing instead of full rescans.
Load database snapshots instantly.
Index folders on demand and in the background.
Streamline licensing and authentication
Cache license validation results locally.
Perform online checks after Cubase is already open.
Allow plugin DRM checks to run asynchronously.
Add automatic resilience for problematic plugins
Detect crashing or unresponsive plugins and skip them automatically on the next launch.
Provide a built‑in startup profiler
Show which plugins or subsystems delayed startup.
Help users identify slow or misbehaving components
A built‑in performance and startup profiler
A profiler would show:
Which plugins or subsystems delayed startup.
Which tracks or plugins are causing single‑core overload.
Whether disk, CPU, or licensing is the bottleneck.
This gives users visibility into performance issues instead of guessing.
These changes would make Cubase feel significantly faster and more responsive, even on systems with large plugin collections.
I’m pretty sure Cubase already does this. It’s why a plugin scan from the plugin manager takes a lot longer than a normal Cubase launch.
That might’ve been an option in previous versions but wouldn’t work well with project previews introduced in v15.
I believe most (all?) of your suggestions is how MediaBay already operates.
You don’t specify, but if you’re talking about 3rd party plugins, Cubase has no control over this.
This might sound trivial in theory but once you start sketching on concrete rules, it’s not very clear cut at all. Ideally, plugins should never crash but if they do, Steinberg’s design philosophy is to not interfere even if that means the misbehaving plugin takes Cubase down with it. But a misbehaving plugin doesn’t automatically mean it will crash the host. Either way, I would personally want the authority to determine whether or not a plugin should be excluded.
Furthermore, metrics like “delayed startup” or “slow subsystem” is not easy to put in number when you factor in a myriad of 3rd party components with different requirements running on a plethora of differently configured computer systems.
I’m all for a more resilient application with safeguards where needed. Same goes for improved application launch time and a snappier UI. There are several suggestions in your post that might make sense and could be implemented but I also don’t think the current state of affairs is as problematic as your post might read.
Cubase 15 Pro starts here in 7 seconds and the services are fully available when startup is complete. I don’t feel the need for developers to spend any time shortening it to something less.
Scan plugins only when they change, using file hashes or timestamps.
They are only scanned when they change. The exception is for some plugin such as Waves, add a flag that says ‘do not cache the results’ – these need to be scanned every time as they need to contact their license server.
Sandbox plugin scanning in a separate process so a single plugin cannot stall Cubase.
They are already scanned in a separate process
Cache plugin metadata in a binary database for instant loading.
Plugin metadata is read from an XML file. On my system it is read in 5ms. A binary file is not likely to give any extra performance improvement
Detect crashing or unresponsive plugins and skip them automatically on the next launch.
Plugins are scanned in a separate process and are blocked on the next launch.
The next update will have some improvements for plugin scanning. If you are experiencing very slow startup, then the likely cause is plugins that require scanning every time, and there’s nothing Cubase can do to improve this.