This post is to address the bloated CPR file sizes, particularly for large templates and orchestral work.
Current .cpr files are excessively bloated due to what appear to be inefficient base64/XML encoding of plugin states, storing everything in every save, not having compression, and no cache. I’ve seen users discuss session sizes from 300mb to 2gb for orchestral templates .CPR file sizes.
In 2026, with modern NVMe drives, the VEPro decoupled workaround shouldn’t be necessary just to manage file sizes of projects. We’re heading into systems that can immediately have everything stream in via 8tb NVME drives! However, Cubase will need to improve the session sizes to match that reality.
Likely Benefits
-
Dramatically reduced file sizes (potentially 80-90% reduction for large templates)
-
Faster save/load times
-
Less pressure on backup systems
-
Eliminates forced VEPro workflows simply for file size management
-
Any users with samplers and plugins in their Cubase sessions will benefit.
-
Forward thinking for increased library sizes and complexities.
Proposed Solutions
1. Binary Plugin State Storage
-
Store VST plugin states as compressed binary data instead of base64-encoded XML text
-
This could save ~33% and improve save/load performance
2. Delta/Incremental Saving System
Rather than save everything for every save, having a delta differential should allow immense size savings as an option for incremental saves with just new data.
-
Implement a git-like differential save system where:
-
Initial save writes complete project state (full baseline)
-
Subsequent saves only write changed data (deltas) with references to the baseline
-
Every Nth save (configurable, e.g., every 10th save) creates a new full baseline
-
Old baselines can be pruned based on user preferences
-
-
This would dramatically reduce iterative save sizes and save time
3. Optional Lossless Compression
-
Apply compression (zlib/zstd) to project files?
- I read users report RAR can compress 1.91GB files to 28MB, which seems to prove massive redundancy exists.
-
Make this a user preference for those concerned about compatibility?
4. External Plugin State Cache
Having a cache would work similar to VEPro decoupled instance. Plug in configurations could be stored here once and referenced rather than saved in each individual session.
-
Option to store large plugin states (ARA plugins, sample libraries, etc.) in an external linked cache similar to how VEPro decoupled works.
-
Project file stores only references; cache is shared across projects using the same instruments
-
Immense file size savings. One example locally took a small orchestral template from 185MB down to 28mb by using a decoupled VEPro instance.
Summary
With optimizations like a cache, compression, delta based saved as an option, and binary storage the project session file sizes could be immensely smaller. This would be a big win for efficiency, disk size, load and save times, and help streamline projects to be more optimized. As tech improves, and NVME users go from huge external Ram machines with VEPRO, to internal machines these optimizations would help keep orchestral templates all in one place and be far more optimal.
For anyone who uses a library internally in Cubase session this is becoming more and more critical due to increased library sizes. I’m currently using VEPro 8 on an external machine, but in the near future plan to streamline it to a single system. However, even for me now it’s a win because I still use some plugins directly in cubase and my session size is 30mb per save for very little in the session template!
I’m sure these solutions are far more challenging than simply typing them out as ideas, but hopefully the can be explored to de-bloat the session sizes in the future 