I loaded a SSO (Spitfire Symphony Orchestra) template (only strings, brass and woodwinds) on Dorico’s blank Concert orchestra template. In the playback template, each instrument has its dedicated Kontakt instance (plus another for “A due” patches). It takes 2-3 minutes to load, and uses 9 Gb of RAM and 24 Kontakt instances (14 Gb, 41 Kontakt intances for the full version that includes “A due” patches).
I tested it on Dorico’s demo orchestral pieces, it works fine even if involving lot of fine tuning.
However, impossible to load it on a bigger project such as Rite of Spring score (even light playback template version). It loads 9 Gb in the Ram and then nothing happens (play icon doesn’t turn green, in spite of 6 Gb RAM still available).
All Kontakt instances are purged, so I’m really wondering why this is taking so much RAM anyway ? Perheaps one shouldn’t use dedicated Kontakt instance per instrument ?
Those using BBC SO (or even SSO) playback template, how much ram does it take on a full orchestra ? Have you tried it on the Rite of Spring ?
You’ve hit upon another reason not to assign individual instruments to their own VSTs.
In any single instance of Kontakt, if you have identical samples assigned to separate channels, then the additional instruments won’t use extra memory. (By design, anyway.)
Note also that the amount of RAM used by instruments is greatly affected by your Kontakt setting for preload buffer size. I’m composing on a 64GB, 2TB SSD laptop, and with my preload buffer set to 20 (or so) kB, a full orchestra (which generally takes t̶h̶r̶e̶e̶ ̶t̶o̶ ̶f̶o̶u̶r̶ six to seven minutes to load, and inconsistently anywhere from thirty seconds to an ungodly much, much longer time to unload) costs me about 12GB. When I later ramped it up to 96kB (in an attempt to address glitches in playback), the cost in memory nearly tripled.
Of course, I still have problems with playback; my VSTs sometimes c̶r̶a̶s̶h̶ lock up (with frustrating frequency, actually), requiring me to kill the Dorico and VSTAudioEngine processes. I suspect that this has more to do with bugs in Kontakt’s player, though, since this wasn’t an issue until I upgraded it a short while ago. (EDIT: This problem seems to have vanished since I configured the ASIO engine to monopolize sound output, although this has unfortunately significantly worsened the sound quality.)
Very interesting. Does this principle apply to identical instrument banks too ? I will definitely take time to create multis, as you did in your SSO template.
I’ll check this too, thanks.
However, I’m still wondering why this takes that much ram whereas all my Kontakt instances have been through “Purge all samples”.
Assuming the Kontakt player is competently designed and programmed (which is an open question, as far as I’m concerned, considering how buggy it’s been), I would expect any samples that it identifies as identical to some other sample residing in memory for a single instance of the player to point to a single source of data.
Of course, the easiest way for us end users to determine whether this is so is simply to try it, and see how the player’s memory gauge is affected.
I’m not sure what you mean. Are you saying that the VSTAudioEngine process is still eating up RAM even after you’ve purged all of your samples (and haven’t reloaded them, obviously)?
This is what I meant, yes. 9 Gb or 14 Gb seems a lot for purged Kontakt instances…
Also, while my playback template successfully loaded its 14 Gb on Dorico’s orchestral demo, it will stuck at 9 Gb on Rite of Spring. This is really weird behavior. Anyway, I’ll try to reduce RAM impact as suggested, and see if it gets better.
My Vienna Ensemble Pro current template uses 7.32Gb of BBC SO Core plus a little more for the VSL SE woodwind missing in the Core version for a fairly typical 19th century orchestra. Large late romantic orchestras such as required in Le Sacré would need more. The BBC Pro is more resource intensive mainly because of all the microphone positions as the articulation list is generally the same.
Most are agreed that VE Pro manages memory more efficiently than the native host and of course the BBC SO uses its own player as opposed to the SSO which still uses Kontakt. If you have it, I would definitely try running Kontakt under VE Pro. On the specifics of memory use with the SSO, I can’t really add anything as I don’t have it but wouldn’t rule out a bug in Kontakt.
Hello folks, you are peeking into a bee’s n.est, actually there are several issues here.
First, I had already several customer reports with large Kontakt projects that would not load or play. This is not a general case, but depends on the used system. We tried to analyse this from our side and came to the conclusion that Kontakt somehow comes to a standstill. I also got in contact with Native Instruments, but that turned out to be not so fruitful, so the issue is not resolved.
Second issue, memory usage of the sample libraries. I don’t know SSO in conjunction with Kontakt, but I have BBC SO installed and yes, that uses an awful lot of RAM. In the GUI it shows a number of 7, 8 or 9 GB used memory, but that is presumably only for the sound data, but then the plug-in itself uses also a certain amount of memory, which is not indicated. When I load a full BBC SO template, then the VSTAudioEngine process uses up to like 24 GB (and loading time of 30mins because swapping takes place, I only have 16GB physical RAM), but then I can’t distinguish how much memory BBC SO uses and how much the audio engine itself. I’m also already in contact with Spitfire about this memory usage thing, but there is no conclusion to be expected soon.
Furthermore, we know that the audio engine itself has an issue, where we need to work on. The problem here is the size of the virtual mixing console. Every Kontakt 6 instance has 64 output ports and for each of them a channel gets allocated in our virtual mixer. Now have 10 Kontakt instances and you have a mixer of over 600 channels, each one using also up memory buffers, so it’s a total overkill. So we need to give users the possibility to limit the number of channels created for each instance. Cubase has this, Dorico not yet. In turn that will also help reducing the overall memory usage (and thus speed up loading time).
Another word on BBC SO and the templates created by John Barron. BBC SO has already the possibility to reduce the number of outputs ports. By default it’s 16, so that means the virtual mixer allocates yet again 16 channels per BBC SO instance. Multiply this by 40 or 60 instances…
But even when you go into the BBC SO GUI and change the number of output ports, this won’t reduce the number of virtual mixer channels any more, because they are “baked in” to the template. For that reason John will create updated BBC SO templates. Let’s see how much that will reduce the overall memory usage then.
So you see, in overall this is an area that we are aware of and working on, though it is difficult, because it lies not solely in our own hands; we need to work together 3rd parties.
@MiloDC , if you have crashes, please provide diagnostics reports (Help > Create Diagnostics Reports) as they contain also crash dumps. These dump file are important for our debugging. Thanks
good summary, Ulf. I have also assumed that the BBC shown RAM usage is only for the sound data as there does seem to be a hole in the total memory used.
Yeah, this happens to me on playback frequently, or often when I close a score. The Kontakt VSTs just become totally unresponsive. I can’t even save the score, at that point. Very frustrating, because it means that simply auditioning some notation, which one usually does before saving a score, can mean losing work.
Heh, typical. I’ve tried getting in touch with them myself, usually with similarly fruitless results.
@Ulf, do you recall what your preload buffer size was when you reviewed Kontakt’s RAM consumption?
Will this be of any use when the VSTs have locked up? Because that’s what happening (I shouldn’t have written “crash”). Dorico is frozen as a result, and I have to kill the Dorico and VSTAudioEngine processes.
Finally, thanks to @MiloDC advice, my SSO template successfully loaded in 3-4 mn on the Rite : 16 Gb RAM usage. As advised, trick was to group identical instruments in a single Kontakt multi. RAM usage dropped to 6,5 Gb during playback (this is getting esoteric to me…). I’ve yet to try lowering buffer size in Kontakt, for even less RAM usage (but I work on HDD).
It didn’t sound as awful as I expected : Some parts were even somewhat convincing ! Unsurprisingly, lot of work and tweaking needed :
Using “long” patches for “natural” articulation sounds bad most of the time. “Performance legato” would be more realistic in most situations. Even for sustained chords.
A2 (A due), A4, etc… parts should be moved to the appropriate voice to trigger right playback (until proper A2/A4/A6 playback system in Dorico).
Some articulations were not correctly played after a sempre indication (e.g. : staccatos after a sempre staccato).
Some chords played in divisi strings are way too loud, thus need dynamic shaping (No divisi sections in standard SSO strings).
From now on, I have hope to limit my use of Noteperformer, even if its simplicity and performance are absolutely amazing. I’m looking forward notation software replacing DAW (are we getting there ?)
Switch to SSDs as soon as you can; the difference in performance capability is massive. No one who composes music on a computer should be using HDDs.
We’d all love to hear the result! I might take a crack at it myself; Spitfire and Dorico are good enough that a lot of it should sound rather nice.
< nod > Yep, most definitely. As I wrote, I steer clear of using the “long” samples, and stick with the performance sets for most of my instruments. The performance sets sound far more realistic, and they offer the additional benefit of working well in other situations (staccato, legato, et al.). What you can’t get out of them, you can just load into an instrument bank, and have Dorico switch to the bank as needed.
Spitfire’s performance scripting is generally very well done. If you get a chance, check out how their performance sets sound for their Solo Strings library. Really impressive stuff.
I don’t think that Dorico supports this yet, does it? Would be extremely cool if it did; I could make considerable use of such a feature in my own scores. Interesting problem to tackle from a programming standpoint.
I’ve thought about this, and how it might be done artificially, by tweaking some settings in Kontakt. You’d need to load a couple of performance sets, and then pass them through some kind of effect that thins the sound. I’m not sure how doable or how convincing it would be.
NotePerfomer is very good (especially considering what it costs), but I still think that Spitfire Symphonic Orchestra eats its lunch. How does your rendition of The Rite compare to that NP rendition that some guy posted to YouTube?
@MiloDC BBC SO has it’s own plug-in and therefore no Kontakt is involved. Also, I only have the Kontakt player with the most basic factory library.
When the audio engine is not crashing but instead deadlocking, then please (I assume you are on Mac) open the Activity Monitor. At the top is a cog wheel icon, click on that and choose “Spin Dump”. Save that and send me. Thanks very much
@MiloDC Ah, sorry, in that case please get the tool Process Explorer ( Process Explorer - Sysinternals | Microsoft Learn ). In there find the Dorico and VSTAudioEngine process, highlight, right click and choose ‘Create mini dump’. The files are still fairly big, but a full dump would be just too much. Thanks
( Why is it that the Dorico development team, with limited resources according to themselves, has to spend time, effort and apparent frustration(?) on duplicating/transplanting the CUBASE audio engine? Cubase is way ahead of Dorico in all things audio as of today, and there are a lot of music notation issues the Dorico team could focus on… I’ve hosted all audio in Cubase and only used Midi Out from Dorico for over a year now, and I haven’t had a single glitch. Even on dated hardware… )
They spend some time addressing playback issues because there’s enough demand for good playback to warrant doing so. Bugs that cause the application to lock up or crash are understandably of particular interest to them.
I’m sure that each of us would love the developers, with their limited resources, to focus chiefly on only those aspects of the software of greatest interest to us.
Dorico does use the Cubase audio engine. The audio engine itself is only one part of a much larger whole: there’s still a lot of UI and interface code that is required to be able to expose all the functionality of it. Cubase has had a large team of developers implementing all of that over a period of 20+ years. We’re able to get the benefit of a lot of that time investment by using the audio engine, however we don’t have any easy way of reusing lots of the extra UI from Cubase.
In this particular case we don’t yet have the ability to control the number of outputs used by a plugin, which leads to some of this extra memory increase. If you are using all outputs of a plugin then Dorico’s performance will be very similar to Cubase’s.
As a cursory glance at the forum will confirm, many users are interested in high quality playback, and for them the audio engine functionality is very important.
That’s beyond my point. My point was the (partial) duplication of labour and functionality.
Exactly. So STEINBERG could have chosen to market Dorico in tandem with Cubase, leaving the Dorico team to focus 100% on notation issues. and leave most things playback to Cubase. But I guess the answer comes down to some business revenue analyst …
If Steinberg went your way, would we all have to buy Cubase in order to get any playback in Dorico?
I might actually be prepared to do that. I can imagine the initial setup being a turn off for a school music teacher, though, particularly if they’re already umming and erring about switching their school from Sibelius to Dorico.
I might take a crack at it myself; Spitfire and Dorico are good enough that a lot of it should sound rather nice.