Most composers rely on custom composing templates for their work. No matter how we set them up, whether simply by feeding back audio channels into our master machine, or using specialized software such as VSL’s Vienna Ensemble Pro – they allow us to have the tools of our trade at our disposal at the click of a mouse. But the bigger these templates get, the more important caring for it and optimizing it will become.

As someone who has had the chance to set up quite a sizable number of composing templates with the help of VE Pro, I’ve had my fair share of bottlenecks that can really bring a template to a crawl. Fortunately, there are a few things you can do to make everything work as smoothly as possible. This article is based on Vienna Ensemble Pro 5, but most things mentioned here will probably also work with either VE Pro 4, or a completely different hosting software. You may even be able to use some of the tips when working solely in your sequencer.

A tiny bit of terminology: The machine where your sequencer (Logic, Cubase, Studio One,…) runs on is called „DAW“ in this article, which stands for Digital Audio Workstation. Any additional machines used for hosting instruments or for applying FX are called „Slave(s)“.

1) Planning a template:

Before even thinking about building a template, you need to be aware of what you want to have in there. This is extremely important; not just to save time during the actual process of building the template (we’ll come to that in another article!), but also in making sure everything performs nicely. Regardless of whether you want to use external hosts like VE Pro or have everything sitting in your sequencer, the most important point to think about is load distribution. Spread your instruments over multiple instances of Kontakt/Play or whatever sampler you are using. If using VE Pro or similar software, do not fit everything into one single instance, but spread it a bit so that each instance has a bit to do all the time and not just one single instance working away like mad. If you have very CPU-intensive instruments, it can make sense so spread a single library over multiple instances of the sampler. You might for example want to have all your Violins and Violas in one Kontakt instance, with a second instance housing the Cellos and Basses. This way, the CPU load is distributed across two instances and consequently two cores.

Balancing the load gets even more important when using slaves. Make sure each machine shares an equal workload. It does not make sense to dedicate one machine solely to Sough-East-Carribean Bongo tremolos and other „esoteric“ sounds, unless you really need them daily. As a rule of thumb, I try to have the bread and butter sounds of one section as well as some more special instruments from another section per slave if enough slaves are available. So slave 1 would for example do all the basic woodwinds and some brass effects and the big taikos. Slave 2 has the basic brass sounds and more special woodwinds like alto flute, contrabassoon and some tuned percussion. And so on…  Of course how you spread things totally depends on the available resources and your way of working. Just try to balance things evenly. I know it is tempting to say „this machine does all the strings“, but this is not the best idea: As soon as you have a solo string piece, this one machine needs to do all the work and the rest sits around idle. Slaves give you the unique advantage of doing their own processing – they can be loaded to the brim and the DAW won’t even notice a hit in performance! Again more about this in greater detail in a later article.

2) Using fast drives/SSDs and adjusting the preload buffer:

Most sampled instruments only load a bit of the sample material into the system memory and stream the rest from disk. The amount of what is loaded into memory is determined by preload buffer setting. I have found that it most of the time is set relatively high and can be lowered a fair bit even if you are using conventional hard drives. In fact, I still have a „green“ energy-saving drive in daily use and it performs remarkably well. If you use very fast drives (10.000rpm conventional drives or SSDs), you can set this preload buffer even lower. Lowering it means that your loaded samples consume less memory at the expense of your sampler needing to read much more directly from disk. Toy around with this setting and see what works for you. If you get crackles, pops, lost notes and other issues, raise it a bit.

In Kontakt 5, you will find the preload buffer setting in the options inside the Memory tab. By default it is set to 60kb; on regular 7.200 rmp drives you should be able to pull it back to at least 40 or even lower on pieces not requiring every single instrument to play at the same time.

Vienna Instruments (Pro) has a similar setting in its options, accessible by clicking the little gearwheel icon:

Again experiment with the settings to see what works for you.

3) Switching off unused or unnecessary articulations/mic positions:

Sounds painfully obvious: It makes no sense to have stuff running you never need. If possible, switch off any articulations you do not need. Many sample libraries allow you to unload unused articulation directly within the plugin GUI. If that does not work, use the „Purge all“ feature if such a feature is present in the sampler you are using. Kontakt, for example, has this ability: Click „Purge all samples“ in the purge menu and Kontakt will unload all samples. Samples will then be reloaded while you use the instruments on a „need to“ basis.

If you are using reasonably fast hard drives, or even SSDs, this process should be instantaneous. In any case, it saves you a ton of loading times after reloading the project and you can be sure that only the samples really needed in the project use up memory.

Most libraries also have the ability to unload unused microphone positions. Especially if you are using a 3^rd party reverb quite heavily, switching off highly reverberated samples with lots of room information can not only save you a lot of memory, but also make your mix less cluttered. If you have a rather wet library or microphone position (i.e. one with lots of room information bakes into the samples), after applying a reverb, you basically have two rooms at the same time: The room where the samples were recorded and the room your reverb adds. Especially when using special positioning and reverberation tools such as VSL MIR Pro with 3^rd party sample libraries, it is often a good idea to only use the close microphone position, if one is available. VSL MIR in particular works best with extremely dry samples.

Both tips 2 and 3 do not directly influence CPU load, but they do indirectly: With a lower preload buffer, CPU load will increase a tiny bit because more stuff needs to be loaded. This effect, however, is negligible in most cases. Having less articulations loaded reduces the amount of samples that need to be loaded. And reducing the number of active microphone positions means less samples need to by played at the same time when pressing a key.

4) Only switch on multicore support for one host:

Most hosting applications and samplers today have multicore support. That means that they will intelligently balance their workload over all available cores of your machine. Some also allow you to specify a number of cores for the application to use. While this in theory is all nice and well, the cold harsh reality quickly shows that these multicore balancing features tend to get in each others way. One practical example: If you host Kontakt 5 within VE Pro 5, by default, both applications have multicore support enabled. It is my experience that CPU consumptil will drop noticeably when you either switch off multiprocessing in Kontakt, or alternatively in VE Pro. In my experience, setting VE Pro to use 2 threads per instance and switching off Kontakt’s multicore support works best, but you should definitely try this for yourself!

You can find the relevant settings in VE Pro’s and Kontakt’s Options:

Especially on OSX, if your VE Pro instances consume 10-20% CPU per instance when doing absolutely nothing, this will most likely solve the issue! I have so far not seen any performance impact by switching off multicore support – on the contrary. If you are running parts of your template in the DAW, make sure to experiment a lot with different multicore settings: Having both VE Pro (or any other host) as well as your sequencer running, both of them probably offering support for threads, it might even make sense to deactivate multiprocessing support completely in the sequencer. I have made very good experiences doing that with Cubase, especially on the Mac.

5) Bonus Cubase Tip: Use only 8 MIDI ports for VST3:

This one curiously enough has crept up at least a dozen times in the last two weeks: Many people using Cubase with very large templates have only two or three VE Pro instances, because the VST3 version of VE Pro allows the use of multiple MIDI ports. Consequently, they use a lot of ports – the highest I have seen was 64 MIDI ports per instance.

(Let us briefly hold a minute’s silence for all Logic and DP users out there stuck with just 1 MIDI port as part of the Audio Unit plugin standard. Ok, minute over.)

Cubase users with lots of MIDI ports face the issue that their templates will take ages to load. This is due to a behaviour of Cubase that makes it take a very long time to initialize any VST3 plugin that exceeds 8 MIDI ports. What I have heard is that Cubase somehow initializes all the additional ports and checks their allocations. The first eight MIDI ports are not treated this way. This is why it makes sense to only use 8 MIDI ports per VE Pro instance and in order to be able to have the number of instruments required, use more instances with 8 ports instead of just a few instances with 64 ports.

As far as I can tell, only Cubase shows this behaviour. Users of Studio One (which is also able to use VST3 plugins) can use 64 ports without overly long loading times.

I hope you found this article informative. In due course there will be a second one with some planning advice for templates, as promised earlier. Post your feedback and questions in the comments and I’ll be happy to address it.