Do you have specific details on the implementation of Kontakt that quantifies how multiple instances taxes your CPU, RAM and hard drive more than a single instance...or are you surmising that this must be the case?

I did a test once with the task manager open.  Two instances of Kontakt definitely use more RAM (and I assume more CPU) than one.  Even using two copies of the same instrument within a single Kontakt instance requires more RAM.  It doesn't look like Kontakt re-uses the loaded samples within memory, but instead re-loads them with each new instrument.

Tripecac


I did a test once with the task manager open.  Two instances of Kontakt definitely use more RAM (and I assume more CPU) than one.  Even using two copies of the same instrument within a single Kontakt instance requires more RAM.  It doesn't look like Kontakt re-uses the loaded samples within memory, but instead re-loads them with each new instrument.

...more RAM is behavior that I would expect.  The question is, is the difference significant enough to be worth worrying about?

Assuming that more RAM also equates to more CPU isn't a given.  If each instance is doing some sort of independent polling (a stupid design...but I've seen worse) then...yeah...they may involve more CPU.  If you really want to know, I'd contact Kontakt...er...Native Instruments.

Try this...

• Open a SONAR project and note the RAM usage.
• Load an instance...without loading an instrument...and get the RAM usage again.
• Load another instance (note usage).
• Load an instrument in instance one (note usage).
• Load the same instrument in instance two (note usage).

The difference you are really interested in is the RAM usage difference between one empty instance and two.  I'd be willing to bet that the difference is insignificant compared to the size of the instrument that each instance loads.  My unproven contention is that the RAM consumption difference isn't really a big deal...and it's easy to buy more RAM.

I've tested it, watching memory usage as I added Kontakt instances and loaded libraries. Memory usage was about 40Mb per instance with no libraries loaded, which tells you the basic penalty for each additional instance.

Additionally, there is a significant economy when loading multiple libraries. After the first library, 80Mb of additional memory was allocated, but only 6Mb for each library after that. So it definitely makes much more efficient use of memory to load multiple libraries into a single instance of Kontakt.

In my test, if you loaded 16 libraries in one instance it would be a 120Mb load, but loading the same 16 libraries into 16 instances of Kontakt would take 1.9GB and would probably fail on a 32-bit system.

I can only speculate about CPU usage, as I did not test that. But my guess is there are some economies in a multi-instrument single instance. They may not be huge, but there is no doubt that a single instance would be more CPU-efficient.

P.S. These memory numbers have nothing to do with the sizes of the libraries themselves. I have DFD streaming enabled, so the numbers I showed above reflect allocations for the streaming buffers only. Those will be independent of the library size, although there are settings within Kontakt for adjusting them.

I recall this being debated on the NI forums a while back. One theory doing the rounds was in a 32 bit system a single instance of Kontakt was desirable because of the memory limitations. multiple instances of Kontakt use more memory, so this bit at least makes sense.
 
However the theory continues that on a 64 bit system with more memory multi pule instances of Kontakt are better as there will be less CPU hit.
 
I am not endorsing the theory, just stating my recollection.
 
I had a quick look through the NI forum looking for the thread but did not find it. I did find a statement in one thread that said "Each additional empty instance adds between 40 and 60 MB to RAM usage." however.
As i ave not managed to stress my system yet I don't really worry about it. I will use several instances of Kontakt, each containing several instruments, it just seems to be easier for me to manage if you don't have too many outputs from each instance, so I tend load the 8 output version, unless there is a really good reason I want the 16 out. - But that's just me.

Totally off topic, but what the heck - under the elderly AmigaOS, you load the program (Kontakt for example) and then use as many instances of the plug as you like.
Because the system uses co-operative multitasking and code can be written as re-entrant code, your extra cpu/ram load is limited to a tiny segment needed to redirect signals to the various iterations and of course ram for any EXTRA samples you load. Been that way for decades.
Now why can`t MacOS or Windoze do that?

Windows does use both cooperative and preemptive multitasking, but the O/S has no control over task management for plugins that run within a host application. Windows also shares re-entrant code and only loads one instance for most DLLs, but plugins are managed by the host, not Windows. And for many plugins, the dynamically allocated memory far exceeds the memory footprint of the DLL itself, and the big-ticket items like data buffers typically cannot be shared across multiple instances.

Bottom line is it's not an OS issue. It's up to each plugin developer to make their products operate as efficiently as possible. Unfortunately, not all do.

Aside from the memory and cpu issue, are there other pros and cons of the 4 methods I mentioned:

1) all parts on one track, separated via track layers
-- PRO: requires fewest tracks and least memory/cpu
-- CON: all parts share pan/volume controls
-- CON: editing individual layers isn't as easy as editing separate tracks

2) each part gets its own track, but all parts use same instrument (and MIDI channel) within the single kontakt instance
-- PRO: easier to edit than layers
-- CON: all parts share pan/volume controls

3) each part gets its own track and its own instrument/channel within the single kontakt instance
-- PRO: independent pan/volume controls
-- CON: increased memory/cpu usage
-- CON: need to coordinate patch or effect changes between parts
-- CON: need to coordinate midi channels between sonar and kontakt

4) each part gets its own track and its own kontakt instance
-- PRO: independent pan/volume controls
-- PRO: no need to scroll through instruments within kontakt instance
-- PRO: no need to coordinate midi channels between sonar and kontakt
-- CON: greatest memory/cpu usage
-- CON: need to coordinate patch or effect changes between parts

You forgot one con to option 4: having to add two more video displays so you can show all your instruments at once.

That's a good point!  Since Track View doesn't see which instrument is selected within Kontakt, the only way to see all the instruments is to open all instances of Kontakt.  I guess you could rename each MIDI (and/or audio) track each time you change an instrument, but that would be tedious.