What's new

How do you set up your orchestral template?

I've spent an hour or so googling and the problem does seem to be present in other DAWs too, but to a lesser extend, because they save in binary file formats and reaper uses a "human readable" text file format. E.g. a project with just an empty Kontakt instance saves as 8kb, if I load the Action Strikes ensemble patch the project file grows to over 10 mb. If I add a second instance of that patch within the same kontakt instance, it's over 20mb already with just 2 patches loaded. It's crazy...
I assume this is more a Kontakt / NI issue than a reaper issue. All other aspects of Reaper are very lightweight and high-performance indeed. As far as I can tell, there is no fix and the problem has been known about for many many years.
There is an option not to save the full plugin state, but that's not recommended and breaks things. And I already set all the options for "minimal undo state" or "don't save undo history" etc..
Wow, that seems like it would be a workflow killer for many people. 20mb project file with two patches is nuts.
 
Wow, that seems like it would be a workflow killer for many people. 20mb project file with two patches is nuts.

It varies extremely and 10mb per patch is the biggest I've seen. The Action Strikes "hits" patch adds about 0.7 mb, and Metropolis Ark 1 patches seem to add roughly 2 to 4mb each.


I know we have quite a few Reaper users here, do you all use VEPro or don't have big templates with lots of libraries loaded?
 
It varies extremely and 10mb per patch is the biggest I've seen. The Action Strikes "hits" patch adds about 0.7 mb, and Metropolis Ark 1 patches seem to add roughly 2 to 4mb each.


I know we have quite a few Reaper users here, do you all use VEPro or don't have big templates with lots of libraries loaded?

I've made a few large templates (approx 400 tracks), but use custom actions so that the tracks are all in a default disabled state upon opening, then can either use Alt+E to enable/Alt+D to disable selected tracks, or use toolbar buttons created on the Main Toolbar to do the same. I got some help a couple of years ago to figure out a good way to do this, and it works splendidly. When the tracks are disabled, they consume virtually no system resources and the template loads extremely quickly. But tracks can be easily and quickly activated as needed.

The macros are setup as follows:

Disable:
Xenakios/SWS: Set selected tracks record unarmed
Track: Set all FX offline for selected tracks
Xenakios/SWS: Bypass FX of selected tracks
Track: Lock track controls

Enable:
Track: Unlock track controls
Track: Set all FX online for selected tracks
Xenakios/SWS: Unbypass FX of selected tracks
Xenakios/SWS: Set selected tracks record armed

Then in Theme Development you can tweak the color of your locked track overlay color and transparency to taste. I like to make it fairly obvious at a glance whether a track is disabled or not.
 
I've made a few large templates (approx 400 tracks), but use custom actions so that the tracks are all in a default disabled state upon opening, then can either use Alt+E to enable/Alt+D to disable selected tracks, or use toolbar buttons created on the Main Toolbar to do the same. I got some help a couple of years ago to figure out a good way to do this, and it works splendidly. When the tracks are disabled, they consume virtually no system resources and the template loads extremely quickly. But tracks can be easily and quickly activated as needed.

The macros are setup as follows:

Disable:
Xenakios/SWS: Set selected tracks record unarmed
Track: Set all FX offline for selected tracks
Xenakios/SWS: Bypass FX of selected tracks
Track: Lock track controls

Enable:
Track: Unlock track controls
Track: Set all FX online for selected tracks
Xenakios/SWS: Unbypass FX of selected tracks
Xenakios/SWS: Set selected tracks record armed

Then in Theme Development you can tweak the color of your locked track overlay color and transparency to taste. I like to make it fairly obvious at a glance whether a track is disabled or not.

Thanks for the recommendation! But I believe that addresses a different issue. At least I can't imagine how freezing tracks would prevent the project file from getting big because the plugin settings need to be saved either way or else they would get lost.
Can you please check how big the .rpp file of your biggest orchestral template is on your harddisk? That would be interesting to know.

RAM isn't the issue here because the RAM load of the loaded sample libraries should not affect the saving time of the project file. It will affect the loading time (greatly) compared to your method, but I only load once and save often, so I'm more worried about optimizing the saving time, especially to make a quicker autosave interval feasible.
 
Thanks for the recommendation! But I believe that addresses a different issue. At least I can't imagine how freezing tracks would prevent the project file from getting big because the plugin settings need to be saved either way or else they would get lost.
Can you please check how big the .rpp file of your biggest orchestral template is on your harddisk? That would be interesting to know.

RAM isn't the issue here because the RAM load of the loaded sample libraries should not affect the saving time of the project file. It will affect the loading time (greatly) compared to your method, but I only load once and save often, so I'm more worried about optimizing the saving time, especially to make a quicker autosave interval feasible.

On the hard disk itself, in Reaper's Project Templates folder, my largest "master" template currently has 358 tracks, and the .rpp weighs in at 163 MB. It loads virtually instantaneously in its disabled state (about the same as empty tracks would), and in Reaper's Performance tab in the dock it shows CPU hovering between approx. 0.6% and 1.0% (i7 2600).

The utilized RAM displays as 454 MB. Just as an experiment, I enabled 6 selected Kontakt 5 Spitfire Albion instrument tracks (with a single click) and the memory usage then jumped to about 3 GB.

Disabling and locking a track in Reaper is different than freezing it, though I don't know the nuances of how that all works in terms of resource consumption. All I know is that I can have fairly large templates without long waiting times and without fuss, and that performance and resource limitations do not seem to come into play until the active project itself gets too large, IOW too full of fully-unlocked, enabled tracks.

EDIT: I haven't analyzed saving times, but it hasn't been a noticeable issue, as I believe that when saving the time is only affected by the enabled tracks active in the project, and that the disabled, locked and unused tracks do not add to the amount of time it takes to save a project. Or if they do, it's not significant.
 
On the hard disk itself, in Reaper's Project Templates folder, my largest "master" template currently has 358 tracks, and the .rpp weighs in at 163 MB. It loads virtually instantaneously in its disabled state (about the same as empty tracks would), and in Reaper's Performance tab in the dock it shows CPU hovering between approx. 0.6% and 1.0% (i7 2600).

The utilized RAM displays as 454 MB. Just as an experiment, I enabled 6 selected Kontakt 5 Spitfire Albion instrument tracks (with a single click) and the memory usage then jumped to about 3 GB.

Disabling and locking a track in Reaper is different than freezing it, though I don't know the nuances of how that all works in terms of resource consumption. All I know is that I can have fairly large templates without long waiting times and without fuss, and that performance and resource limitations do not seem to come into play until the active project itself gets too large, IOW too full of fully-unlocked, enabled tracks.

EDIT: I haven't analyzed saving times, but it hasn't been a noticeable issue, as I believe that when saving the time is only affected by the enabled tracks active in the project, and that the disabled, locked and unused tracks do not add to the amount of time it takes to save a project. Or if they do, it's not significant.

Thanks a lot for giving me all that info! It turns out you were right all along and I was making the wrong assumptions. I saw both filesize and saving time increase roughly in sync, thus I thought the filesize causes the longer delay and that anything that doesn't affect filesize couldn't also affect saving time - which is wildly incorrect as it turns out. When I save an empty project with just 8x kontakt instances with one action strikes ensemble patch each, that takes about 18 seconds to save, but when I freeze all tracks it saves basically instantaneously. This is huge! I need to rethink how I'm handling my template in regards to freezing tracks. So far I always had enough RAM to keep everything loaded and valued the convenience of not having to deal with the delays for freezing and unfreezing tracks, but now that I know it can cut down dramatically on saving times, I need to rething that approach and at the very least freeze all the tracks that I haven't used in a project yet.

Thanks!
 
Top Bottom