Category: Tutorials

Today I bring you a little tip useful when we need to work with a RAM limited-computer (a laptop for example) but we at the same time we want to work with heavy size libraries.

As I mentioned before, the way that Kontakt and others samples work in real time is loading part of the sound material in RAM (generally the attack of the notes) and the rest are loaded directly from the hard drive while the attack is being played. In this way, the system is able, with minimum latency, to ‘play’ the MIDI events and play samples.

This is defined in Kontakt as “Direct from Disk” (DFD) operation. If you have the complete version of Kontakt and you open a orchestral library you can check the configuration and see that this mode is enable (you can even choose another mode and load all the instrument in RAM but I don’t recommend it because it consumes RAM memory fast). For this reason, it’s very recommendable to use SSD memory to store heavy size libraries in order to have enough data rate to avoid bottleneck when we are working with a lot of tracks.

But…. what happens with RAM? The RAM size is very important if we are working with many instances of instrument because, even if DFD is enable and almost is loaded directly from hard drive, there’s a lot of data to be loaded in RAM in order to be able to play every MIDI event in any time.

And.. How much data would be loeaded in RAM? There is no concrete answer. It depends of the library. The Libraries with more microphone positions load more than the others (it is neccesary to load data from every note, every dynamic range for each microphone position. The type of instrument also has influence, the instruments with true legate sampled needs more because it needs to load data from each interval between each pair of possible notes. On the other hand, it also depends of how the library has been scripted.

For this reason we need enough RAM in our computer to be able to work with many instances of instruments. If we are working with a laptop or a computer with limited RAM there are two possibilities. The first one is to render the MIDI tracks to audio tracks while we are working and remove the Kontakt instances. With this method we lose the possibility of modify notes or dynamics. The second option is to use the purge command of Kontakt to optimize the use of RAM.

This command free all the RAM memory of the instance. After it, if we play MIDI events Kontatk will load into the RAM only the minimum data needed to play what’s written.

This is better explained with an example. This is one project mine of a orchestral piece of two minutes of duration.

It’s not a big project, it’s only a typical orchestral configuration without non-orchestral instruments neither soloist instruments. The use of layering is minimum. The libraries are not really heavy, maybe the Cinematic Studio Strings are the instruments that consume more RAM. The project takes 22Gb of RAM. If I check a Kontakt instance I can see the RAM that an instruments loads.

In this case, the first violins of Cinematic Studio Strings take 0.77Gb of RAM and it is a lot. This is due the way of these strings have been programed with an instance of instrument for all the articulations sampled and all the microphone positions. But, at the end, we don’t need all of this for each composition. In that case we can purge and optimize RAM as I told before.

If you want to purge, then click the little arrow next to Purge option and select Purge all samples. Although it sounds terrible there is nothing to fear.

After do it, it’s possible to check that the 0.77 Gb of RAM has been released.

If I play now the entire project for the first time, I’ll notice some discrepancies of sounds (silences, jumps in the volume). This is normal because Kontakt is looking from the disk the attack samples and loading it to RAM. But the difference is that now Kontakt only loads in RAM the samples needed to play what is written in MIDI track. Kontakt won’t load the articulations, microphones positions, dynamics and notes that aren’t being used.

After play the project one time, I can replay it without any problem of silences of volumes because Kontakt already has the minimum required data in RAM. If I check the Kontakt instance again I can see that it only needs 48 Mb of RAM memory. From 770 Mb to 48 Mb it’s a great save, isn’t it?

If we do the same with each instance we can reduce the RAM considerably and play the project without problems in RAM-limited computers.

It can be also useful to reduce the loading times when we open big templates.

I hope you like the tip.

Author: Pablo del Campo

I would like to show you my actual personal studio (March-2018) and also provide you some recommendations about equipment for orchestral music production

For composing and production of orchestral cinematic music it is required at least the following equipment:

• A PC
• A MIDI Controller
• Audio interface
• Headphones or Studio Monitor
• Sequencer (software)
• Orchestral VST libraries

In this post I will focus in the PC exclusively and I will post a new post to discuss the rest of elements.

The orchestral music production is a case very exigent (in terms of computelly stress) for a PC due to the high number of tracks that are managed by the sequencer at the same time, so, I is mandatory to take this in account to choose properly the components of the PC. In the case of the microproccesor, in contrast to other uses as gaming, it’s recommended a higher number of processor cores that a higher velocity due to the way of modern sequencers are optimized to paralell proccesing. So, the sequencers manage properly the different cores to work in a efficient way with a high number of tracks that can include different audio proccesing plugins (equalization, compressors, reverbs, etc.) . It is also interesting to have a good velocity per core but, generally,  it is better to choose a procesor with more cores that a processor that works with a higher frequency or a proccesor prepared to work with overockling because for this case it is not neccesary.

An important topic is the RAM memory and the storage memory but, before of give recommendations I would like to explain briefly how manage the samplers with the modern libraries of orchestral sounds. For this reason I will mention the most extended sampler, Kontakt of Native Instruments. The orchestral libraries have a several amount of gigabytes of data even compressed. For this reason, Kontakt doesn’t load the entire amount of samples from an instrument in RAM but it only load the beginning of them.  So, when Kontakt receives as input a MIDI event, it will play the beginning of the sample from RAM and at the same time it load the rest of the sample from the store memory to play it. With this method, it avoid to waste RAM memory and it allows to load templates with dozens or hundreds of virtual instruments.

I can understand that this brief explanation can be difficult, maybe I could write a more detailed post to explain this at the future. At the moment, we need to understand the fact that the memory access speed is an important factor because the most amount of audio data will be read from the storage memory.

It’s important to choose carefully the components. It is necessary to dispose a enough amount of RAM memory due to some instruments loads a high amount of data in RAM (although it is only the beginning of the samples as I mentioned previously). For example, the instruments with true legato have real recording samples of the transition between intervals of notes and for this reason need to load a lot of data in RAM. Also other instruments, for example, pianos need to load high amount of data in RAM due to round robins samples (different samples for the same to avoid the repetition of the same sound clip), true una corda samples, sympathy  resonance, different microphones position. Also the instruments with a lot of samples from different microphones can load several data amount in RAM.

In conclusion, my recommendation is that, with a limited budget, we should spend in both aspects simultaneously. In the case of storage memory, the intelligent choice is the use of Solid State Disks (SSD) especially for libraries with a lot of Gb although, for minor libraries, it is possible to use Hard Drive Disks (HDD) of 7200 rpm. Always is better to distribute the libraries in different disks to avoid bottlenecks in the limitation of data rate that the disk can provide (in reading process). The best choice is the use of SSD with M.2 interface due this interface have a higher limit of data rate that SATA III interface.  In the case of RAM it is not necessary to look for cards with a better work frequency. The use of RAM DDR4 of 2133 MHz or 2400 MHz is enough for the most of uses.

In my particular case, due this different particularities that I have just mentioned I chose to assembly a PC with separate components. After a study of the market I chose the following configuration:

• i7-7820X 3.6Ghz processor. It is a beast, it was launched in mid-2017. It have 8 cores and 16 virtual cores. During this time it works perfectly with exigent projects that manages a lot of plugins instances. One more thing, it is necessary to use a liquid cooler system with this processor to avoid overheat problems.
• Motherboard MSI X299 SLI PLUS. It’s good, modern and it have everything I need: a lot of SATA III ports, 8 slots for RAM, enough PCI ports. It is really interesting that it includes two ports M.2 that are perfect to use SSD M.2 memory (I mentioned before the benefits of this solution).
• At the moment I have the following storage units and it is enough for me. Anyway, I have free ports to add a new HDD, a new SSD SATA and a new SSD M.2:
  • SSD M.2 500 Gb for complex libraries
  • SSD SATA III 256 Gb for OS, programs and plugins
  • HDD 7200 rpm 2Tb for minor libraries, documents and more.
• 4 RAM DDR4 3000 MHz units of 16 Gb each one (64 Gb in total) that are working in multichannel. I can expand this solution to 128 Gb because these are 4 free slots.

I hope this post could be useful or interesting for you. I will write a second part with more recommendations of the rest of elements.

See you!

Author: Pablo del Campo