# A full Berlin template (purged) is running ridiculously high in ram



## SimonCharlesHanna (Apr 30, 2017)

I have just started to make a template with my Berlin orchestra (Winds & Brass) and I am a bit concerned as I have just *purged *all samples and the template is using 66% of my 32 gig of ram.

Without loading a single sample, this VST is using 66% of my 32gig ram??? Is this normal? Should I ditch the Capsule?


----------



## storyteller (Apr 30, 2017)

Not having Berlin Brass, that actually sounds light if you are using the single articulation NKIs. I do have BWW and it takes about 12-13GB purged. Then you have ram allocated to your OS and DAW. On a mac, OSX (with 32GB) will take up about 7.5-8.5GB. Assume the higher, so 13+8.5 = 21.5GB taken up with BWW alone. Someone else made the claim Berlin Brass cannot be fully loaded with 32GB.... which may very well be right.

EDIT: My workflow uses a disabled template - where i am able to enable a section at a time with my 32GB machine.


----------



## EvilDragon (Apr 30, 2017)

That's normal if the instrument has a LOT of groups, zones, FX and modulators, and a ton of persistent variables in scripts.


----------



## SimonCharlesHanna (Apr 30, 2017)

Wow. Vienna Instruments Pro can do all this and more for a fraction of the ram. What rubbish.


----------



## EvilDragon (Apr 30, 2017)

SimonCharlesHanna said:


> Wow. Vienna Instruments Pro can do all this and more for a fraction of the ram. What rubbish.



Spitfire can do the same and use much less RAM than OT stuff...


----------



## SimonCharlesHanna (Apr 30, 2017)

EvilDragon said:


> Spitfire can do the same and use much less RAM than OT stuff...


Yeah I have the Spitfire Orchestra completed (as oppose to the Berlin one which has just winds and brass atm) and have no issues what so ever. Why is the Berlin ram footprint so high?


----------



## FriFlo (Apr 30, 2017)

EvilDragon said:


> That's normal if the instrument has a LOT of groups, zones, FX and modulators, and a ton of persistent variables in scripts.


How much Ram does an array made persistent (e.g. an array[16,128,16]) actually use? I was not under the impression it could be anywhere as high as wave files loaded into Ram, but I might be wrong...


----------



## EvilDragon (Apr 30, 2017)

It's definitely not as much as samples, but it does take a small chunk of memory. And as opposed to samples - if you load the same script twice, it doesn't share memory, it allocates a new and separate chunk of RAM for both instances. It's still peanuts, but it becomes not negligible if you stack a lot of instruments that have hundreds upon hundreds of such variables.

However I would say that the amount of groups and effects used (especially if a lot of filters are used!) plays a big impact with OT libraries. Also, another factor that is very often forgotten: setting max polyphony in an instrument also allocates a certain amount of RAM for voice-related tasks! The higher the max polyphony, the more voice memory Kontakt needs. You can see this in Monitor (Expert in 5.6)->Engine tab, as Voice Memory. Object Memory is what effects, groups, zones, modulators use.

These numbers can immediately tell you how efficient (or not) a particular instrument is.


----------



## Saxer (Apr 30, 2017)

EvilDragon said:


> Also, another factor that is very often forgotten: setting max polyphony in an instrument also allocates a certain amount of RAM for voice-related tasks! The higher the max polyphony, the more voice memory Kontakt needs. You can see this in Monitor (Expert in 5.6)->Engine tab, as Voice Memory. Object Memory is what effects, groups, zones, modulators use.


That was new to me. Good to know, thanks!


----------



## SimonCharlesHanna (Apr 30, 2017)

Well it's official - it takes 32 gigs of ram to have the Berlin Strings/Brass/Winds loaded *with samples purged*
Not a single sample loaded. Unbelievable.


----------



## Lawson. (May 1, 2017)

My entire Berlin orchestra (plus all expansions minus the brass ones and low solo winds) takes about 90GB fully purged. That IS with every track loaded, though. Worth it, IMO!


----------



## NameOfBand (May 1, 2017)

Except for the tips from EvilDragon, can other settings in Kontakt be tweaked to tackle this problem? Like lowering the preload buffer size and such?


----------



## EvilDragon (May 1, 2017)

Nope. Preload size affects how big of a chunk of each sample gets loaded into RAM, it doesn't do anything regarding the bare necessities that an instrument needs (which is object and voice memory) and that absolutely MUST be loaded for the instrument to work, with or without samples.


----------



## NameOfBand (May 1, 2017)

EvilDragon said:


> Nope. Preload size affects how big of a chunk of each sample gets loaded into RAM, it doesn't do anything regarding the bare necessities that an instrument needs (which is object and voice memory) and that absolutely MUST be loaded for the instrument to work, with or without samples.


Cool, thanks! So, what's the trade-off for tweaking the voice memory and object memory?


----------



## storyteller (May 1, 2017)

Lawson. said:


> My entire Berlin orchestra (plus all expansions minus the brass ones and low solo winds) takes about 90GB fully purged. That IS with every track loaded, though. Worth it, IMO!



Hey Lawson - were you the one that mentioned Brass (Main) was bigger than 32GB purged by itself? I can't recall who said that in an earlier thread. I know BWW Main + A is what I have been quoting since it sits in my main template. I guess I could add that BWW Solo B is about 4GB purged. Those are with all articulations loaded on individual NKIs and the run multis.


----------



## novaburst (May 1, 2017)

SimonCharlesHanna said:


> Without loading a single sample, this VST is using 66% of my 32gig ram???



If your using multis (key switch) for your articulations then this is problematic for most library's, big ram factor you need to use more single patches.


----------



## galactic orange (May 1, 2017)

Out of curiosity, which would use more RAM in a single Kontakt instance:

1) one Capsule patch with two articulations, sustain and staccato. Samples purged.

2) two Capsule patches each with one articulation, sustain and staccato. Samples purged.

If the Capsule scripting takes up a considerable amount of RAM, in certain scenarios would one multi-articulation patch be more efficient than a bunch of Capsule-armed singles eating RAM?


----------



## The Darris (May 1, 2017)

Lawson. said:


> My entire Berlin orchestra (plus all expansions minus the brass ones and low solo winds) takes about 90GB fully purged. That IS with every track loaded, though. Worth it, IMO!


I do love the sound but in all fairness, that just seems absurd considering I can load current/modern orchestral samples in a full orch template completely purged well under 18 gb. As a user of many of their libraries, I still wish they would make their CAPSULE engine more efficient.


----------



## prodigalson (May 1, 2017)

galactic orange said:


> Out of curiosity, which would use more RAM in a single Kontakt instance:
> 
> 1) one Capsule patch with two articulations, sustain and staccato. Samples purged.
> 
> ...



I don't use a lot of Orchestral Tools in my template (though I do own most of the Berlin series) but isn't your 1st option the whole point of Capsule? I always thought their goal for Capsule was for the user to have a general set up of 2 patches per instrument: the legato patch and a capsule multi?


----------



## galactic orange (May 1, 2017)

novaburst said:


> If your using multis (key switch) for your articulations then this is problematic for most library's, big ram factor you need to use more single patches.





prodigalson said:


> I don't use a lot of Orchestral Tools in my template (though I do own most of the Berlin series) but isn't your 1st option the whole point of Capsule? I always thought their goal for Capsule was for the user to have a general set up of 2 patches per instrument: the legato patch and a capsule multi?



I agree, which is why I wanted to make a distinction between saving RAM by using single articulation patches in most sample libraries vs. using Capsule. You shouldn't get the same resulting RAM usage reduction in your template by using a lot of single articulation patches with Capsule. Better to stick with the keyswitch multi patch and remove unused articulations, correct?


----------



## EvilDragon (May 1, 2017)

NameOfBand said:


> So, what's the trade-off for tweaking the voice memory and object memory?



There is no tradeoff. You cannot tweak object memory. You can change voice memory somewhat by reducing max polyphony. That's all there's to it. Object memory contains *fixed* resources that the instrument *needs* to work as developers intended. Now, if developers didn't optimize the instrument very well, it can blow up. Like, when using a shitton of heavy graphics, that alone can take up a lot of RAM (I love Output guys but they're really guilty of that  for instance, fully purged, an Analog Strings patch takes over 1 GB of RAM, and great majority of that is the graphics!)


----------



## SimonCharlesHanna (May 1, 2017)

Loaded all of my old VSL template (solo strings chamber strings orchestral strings app. Strings dimension strings brass complete dimension brass 1 and 2 winds complete brass complete choirs complete etc etc with every articulation loaded and disabled) and it took 15 gig. And VIP has far more features and processes than kontakt.


----------



## ctsai89 (May 1, 2017)

Lawson. said:


> My entire Berlin orchestra (plus all expansions minus the brass ones and low solo winds) takes about 90GB fully purged. That IS with every track loaded, though. Worth it, IMO!



only with 1 mic right? ridiculous lol. I just need about 32gigs of RAM to load everything in spitfire orchestra using tree mic.


----------



## SimonCharlesHanna (May 1, 2017)

I don't mind upgrading my system if I have to, but at the moment this feels like wasted resources.


----------



## ctsai89 (May 1, 2017)

SimonCharlesHanna said:


> I don't mind upgrading my system if I have to, but at the moment this feels like wasted resources.



make light resources great again.. bring it all back down to 44100hz 16 bit.. no kidding though. Wouldn't it be nice to be able to use the lap top and compose anywhere with realistic sounding samples that doesn't require much resources?


----------



## storyteller (May 1, 2017)

ctsai89 said:


> only with 1 mic right? ridiculous lol. I just need about 32gigs of RAM to load everything in spitfire orchestra using tree mic.


In a purged state, it doesn't matter if you have every mic loaded or only one mic - the same amount of ram will be used before any samples are played. Fun fact that I didn't realize at first...


----------



## ctsai89 (May 1, 2017)

storyteller said:


> In a purged state, it doesn't matter if you have every mic loaded or only one mic - the same amount of ram will be used before any samples are played. Fun fact that I didn't realize at first...



don't know but I don't feel safe purging all samples. Keeping my way of working the way it is for a while because I've finally gotten to a point where I don't encounter bugs at all for once.


----------



## novaburst (May 1, 2017)

SimonCharlesHanna said:


> Loaded all of my old VSL template (solo strings chamber strings orchestral strings app. Strings dimension strings brass complete dimension brass 1 and 2 winds complete brass complete choirs complete etc etc with every articulation loaded and disabled) and it took 15 gig. And VIP has far more features and processes than kontakt.


VSL are very strange when it comes to sample files, it's clear that they have a small ram foot print

But what's more strange is where ever you look on your system you can't find where they put those huge files they seem to disappear.


----------



## Phryq (May 2, 2017)

EvilDragon said:


> There is no tradeoff. You cannot tweak object memory. You can change voice memory somewhat by reducing max polyphony. That's all there's to it. Object memory contains *fixed* resources that the instrument *needs* to work as developers intended. Now, if developers didn't optimize the instrument very well, it can blow up. Like, when using a shitton of heavy graphics, that alone can take up a lot of RAM (I love Output guys but they're really guilty of that  for instance, fully purged, an Analog Strings patch takes over 1 GB of RAM, and great majority of that is the graphics!)



That seems so silly - too bad the 'graphics' of the VST can't simply be unloaded from RAM when you're not looking at the GUI?

What about using Reaper's Non-GUI-Gui alternative. Will that reduce RAM somehow?


----------



## EvilDragon (May 2, 2017)

Nope, Kontakt is not programmed to work that way (some other plugins are, like u-he's), and I'm pretty sure there are good reasons as to why (huge lagging with that amount of graphics when re-showing the GUI comes to mind). Basic plugin GUI view wouldn't help you either way - it's just a way of displaying the plugin differently. All the graphics still stay in RAM regardless of that.


----------



## Lawson. (May 2, 2017)

storyteller said:


> Hey Lawson - were you the one that mentioned Brass (Main) was bigger than 32GB purged by itself? I can't recall who said that in an earlier thread. I know BWW Main + A is what I have been quoting since it sits in my main template. I guess I could add that BWW Solo B is about 4GB purged. Those are with all articulations loaded on individual NKIs and the run multis.



I'd have to check, but off the top of my head I'm pretty sure BBR (every single patch loaded and purged) comes in at around 40GB. I could be totally wrong though so please don't quote me on this.


----------



## The Darris (May 2, 2017)

Lawson. said:


> I'd have to check, but off the top of my head I'm pretty sure BBR (every single patch loaded and purged) comes in at around 40GB. I could be totally wrong though so please don't quote me on this.


I quoted you on this. 

Is that single patches + Multis + Legato patches?


----------



## Lawson. (May 3, 2017)

The Darris said:


> I quoted you on this.
> 
> Is that single patches + Multis + Legato patches?



Curses!!!! Foiled again. 

Every single articulation-per-patch available, so no Multis.


----------



## Saxer (May 3, 2017)

SimonCharlesHanna said:


> Loaded all of my old VSL template (solo strings chamber strings orchestral strings app. Strings dimension strings brass complete dimension brass 1 and 2 winds complete brass complete choirs complete etc etc with every articulation loaded and disabled) and it took 15 gig. And VIP has far more features and processes than kontakt.


That VSL RAM footprint will change with a complete Syncron orchestra library completely.


----------



## rocking.xmas.man (May 3, 2017)

ok - has anyone figures to compare? 
how much ram does a full cinesamples template take fully purged? how much ram for a spitfire symphonic template? What else do we got that makes a fully blown orchestra - EW Hollywood?


----------



## novaburst (May 3, 2017)

Lawson. said:


> Curses!!!! Foiled again.
> 
> Every single articulation-per-patch available, so no Multis.



Right so I am guessing that capsule can engage with all of the multis articulations without you needing to load a multi, 

If this is the case the ram may infact be higher than is needed to be than just loading a few single patches and maybe one or two multis.


----------



## Phryq (May 3, 2017)

I think a fair comparison of Berlin vs. VSL would be *Berlin Legato+Multi* _only close-mics.
_
I never thought wet mics were much good anyhow, personally. It's too bad VSL is going wet. Would be nice if Chris Hein or Embertone made an orchestra.


----------



## storyteller (May 3, 2017)

Phryq said:


> I think a fair comparison of Berlin vs. VSL would be *Berlin Legato+Multi* _only close-mics.
> _
> I never thought wet mics were much good anyhow, personally. It's too bad VSL is going wet. Would be nice if Chris Hein or Embertone made an orchestra.


If you are talking about sound alone, I'd agree with you about close mics (with the footnote that VSL instruments are recorded in an anechoic chamber which will always be more dry than close mic on a stage). You can get close with close stage mics by trimming down the release tails dramatically. But, aside from that, if you are talking about memory footprints, like I mentioned earlier, _the_ _purged ram state will be identical for a single mic position loaded, or every mic position loaded simultaneously_. The difference in ram consumption will occur _beyond_ the purged state - after the first note is played.


----------



## Phryq (May 3, 2017)

Ok, I thought adding more mics would also add more to RAM use in purged state, but that was just an assumption.

I wish more samples were recorded anechoic (anechoic with super-cardioids. Maybe dynamic, ribbon, and condenser summed to a single ultra-dry mono sample. But that's off topic).

So Berlin's Ram problem isn't even about the mics, it's simple the CAPSULE interface. Too bad.


----------



## erica-grace (May 3, 2017)

rocking.xmas.man said:


> how much ram does a full cinesamples template take fully purged? how much ram for a spitfire symphonic template?


How many patches are loaded? How many articulations? Which mic positions?


----------



## Steve Steele (May 3, 2017)

SimonCharlesHanna said:


> I have just started to make a template with my Berlin orchestra (Winds & Brass) and I am a bit concerned as I have just *purged *all samples and the template is using 66% of my 32 gig of ram.
> 
> Without loading a single sample, this VST is using 66% of my 32gig ram??? Is this normal? Should I ditch the Capsule?



Not trying to promote myself but watch my Kontakt optimization video. You can load up ANY library with 0% footprint. There's an extra step you would need to perform, just PM me.


----------



## NoamL (May 3, 2017)

This isn't surprising... unfortunately I have found OT's extra spiffy Kontakt features are not worth it for me.

Hear me out... when I first got Berlin Brass I thought *C.A.P.S.U.L.E.* was the smartest thing in the world and that every developer should implement it or license the code from OT.

But when actually trying to use Berlin Brass in commercial workflows it hasn't quite worked out, several times. CAPSULE ends up being a timesink as you try to find exactly the right combo of attack and sustain. Over and over I experienced thinking I finally had the right articulations, only to load up the session the next morning and immediately have my teeth on edge from very audible stacking and phasing of samples (especially on close mics). It just doesn't work as well as I want (in fairness, I've seen it working better with Metropolis Ark where the sound of 2 samples at once is much more blurred).

The only way to create truly musical articulations is to have recorded them. Right now I'm helping out on a huge sounding project, and my template has *16 GB* of strings (a stack of three libraries to get the sound I want). But a mere *450 MB* of brass - just six patches, none of which have a single keyswitch! Because that's all I need and the samples are brilliant oneshots that are perfect for a particular style of brass writing.


----------



## Phryq (May 4, 2017)

I have a full Berin Template (Strings, Brass, Woods) loaded, close mics only, purged, buffer at 6kb. I loaded the legato patches _as well as_ the multi (which I fill with articulations). Basically everything is loaded (except when there are too many articulations to fit in a single capsule).

Task Manager shows my *entire system* is consuming 52% of my 32gb ram (also running Firefox with some tabs open).

Windows 10. (Reaper).
Laptop, DDR3
Haswell 47W i7

Is my computer magic? Simply a well-tweak Windows?

I also have an EQ/Limiter on each track, 27 tracks altogether (I like to put e.g. 3 flutes onto the same track and just use midi channels to differentiate, so my score is nice and compact).


----------



## Paul T McGraw (May 4, 2017)

SimonCharlesHanna said:


> Wow. Vienna Instruments Pro can do all this and more for a fraction of the ram. What rubbish.



I agree. And VSL brass with the Teledex MIR Pro or MIRx sounds very similar to the Berlin brass. I have not done a head to head comparison of the winds and strings, but my guess is that they also would sound comparable. Plus with VSL you can use the Vienna Instruments Pro, which in my opinion is the best sample player available as it includes humanization of both pitch and timing and limitless customization possibilities. And with VSL if you retire, or get sick of making music, you can sell your libraries. Not so with Berlin. No resales allowed.

My only VSL problem area is the trumpets. Berlin trumpets have a better tone quality than VSL trumpets. As I mentioned, I don't really know if the strings and woods are better or worse.


----------



## SimonCharlesHanna (May 4, 2017)

Phryq said:


> I have a full Berin Template (Strings, Brass, Woods) loaded, close mics only, purged, buffer at 6kb. I loaded the legato patches _as well as_ the multi (which I fill with articulations). Basically everything is loaded (except when there are too many articulations to fit in a single capsule).
> 
> Task Manager shows my *entire system* is consuming 52% of my 32gb ram (also running Firefox with some tabs open).
> 
> ...


I just tried to emulate what you have said and I am still on 93% (of 32gig). On windows 7.


----------



## SimonCharlesHanna (May 4, 2017)

Paul T McGraw said:


> Plus with VSL you can use the Vienna Instruments Pro, which in my opinion is the best sample player



At this point I see that as an objective fact.


----------



## C-Wave (May 4, 2017)

Guy Rowland made this excellent video just yesterday:

Enjoy!


----------



## Phryq (May 5, 2017)

So I wonder what makes Vienna Ensemble Pro so efficient. Is it worth it for Reaper Users with no VSL instruments? This guy is using an insane number of libraries.

Btw, I loaded the same template again today, and the DAW is using 40.8% of CPU. My entire system uses 43%, so Windows etc. is using 2.2% (with Virtualbox, Firefox [12 tabs], chat client, firewall).

{Edit} I've written 4 bars of Enselmbe Strings, Solo Strings, and 3 Flutes. Memory has gone up to 45.9% in Reaper. If I try playing back, the first time there are huge crackles, but the second time (once samples are loaded into memory) playback is fine. I'm running a 4096 ASIO Buffer. All samples are sent to an Altiverb track.

The system is getting laggy now though. I ran LatencyMon, and appearently tiworker.exe is the worst culprit (Windows update) so I'm wondering how to safely disable that. When I first setup my Windows I tried disabling every service possible, but sometimes it would cause Windows to not-start. I'm afraid to take that risk now, after all the work I've put into my Windows config.


----------



## novaburst (May 5, 2017)

Are we not talking about 24bit nearly double the resources, hmmm no option for 16bit .

I hear spitfire is good on resources is this 24bit.


----------



## novaburst (May 5, 2017)

Phryq said:


> So I wonder what makes Vienna Ensemble Pro so efficient.



Haha the difference between open scripting and secret scripting is that we don't get to know secret scripting.

There must be some very very strict rules over there in VSL, they do seem to be in a class of there own, also this efficiency is part of the price package we pay for.

Don't know how they keep a lid on there coding but it's certainly working and for many years now.


----------



## mwarsell (May 5, 2017)

Phryq said:


> I have a full Berin Template (Strings, Brass, Woods) loaded, close mics only, purged, buffer at 6kb. I loaded the legato patches _as well as_ the multi (which I fill with articulations). Basically everything is loaded (except when there are too many articulations to fit in a single capsule).
> 
> Task Manager shows my *entire system* is consuming 52% of my 32gb ram (also running Firefox with some tabs open).
> 
> ...



Yes, it's magic. I loaded all of Ark 1 and I was at 18Gb. 14Gb left and goes like puff if I even show any Berlin stuff to Kontakt.


----------



## Phryq (May 5, 2017)

I'm not using Ark, just regular Berlin Strings, + Expansion D, + Brass, + Woods. I'll try adding Embertone instruments tomorrow.

When I save, it takes about 20 seconds... don't know why that is.

How much ram is used simply by your OS?


----------



## Critz (May 8, 2017)

I confirm that for a full Berlin Brass multi-template, 3 mic position (1 and 2 close plus tree) 32 gb of ram are not enough. Now, that's ridiculous for a 180 gb library. Let's say unusable. With less than 3 mic positions the great sound of this Library (because the sound is beautiful) is too penalized.
My idea is that a company like Orchestral Tools should definitely quite kontakt to develop an indipendent sampler.


----------



## Phryq (May 8, 2017)

Maybe a mixed mic?

Or simple compose with 1 mic position, then when it's time to mix, freeze tracks with each mic, and mix the frozen tracks.

Personally I prefer close-mic only. I wish they'd make it even drier.


Also, an option to use 16 bit for mixing, but render 24bit. Would that be useful?


----------



## Critz (May 8, 2017)

All your suggestions are good, but here my thoughts:

1) single mic: it's problem the problem here is how CAPSULE's scripting is huge, it's not just a matter of samples.

1) Compose with a single mic: if it's just for composing, it's fine. But we have to compose and at the same time create a definitive mock-up, to save time, right? Well, believe me, there are some articulation or some passages that sound wrong with a single mic, so it happens to give up on a certain passage when it would be ok with all mics.

2) Freeze tracks: made exception for very important work, we can't process and freeze every single instrument. I can accept to process and then freeze the whole brass section, but it's impossibile, because 32 gb of ram aren't enough.

3) Close position: I also prefer close mic: less samples, more freedom to develop our personal sound. But this library is not made for that. It's clear that the spot mics don't represent perfectly the instrument. VSL instrument are mono and dry, but they are recorded in order to represent the overall character of the instrument with a single mic.
4) 16-24 bit; do we have the possibility to choose 16 or 24 bit in Berlin Brass?


----------



## Phryq (May 8, 2017)

Maybe a 16bit 'mixed mic' for composing. Then 24bit separate mics for mix.

So it wouldn't make the download so huge, simply add a 16bit mix-mic option.


Anyhow, I'm wondering if it's still better to use the non-Capsule version... only some features lacking (mixing 2 mics at once for woodwinds, legato between articulations).


----------



## Critz (May 9, 2017)

You 


prodigalson said:


> I don't use a lot of Orchestral Tools in my template (though I do own most of the Berlin series) but isn't your 1st option the whole point of Capsule? I always thought their goal for Capsule was for the user to have a general set up of 2 patches per instrument: the legato patch and a capsule multi?



You OWN berlin libraries and you don't use it?
Wow..I would like to have money to thrash..


----------



## sazema (May 9, 2017)

Yes, it's true that is intensive even purged, just compared Berlin violins 2 patches with Albions 2 patches

Starting point with empty Kontakt is about 220 - 300mb is used
2 purged Berlin patches = about 1Gb, so 600mb just for GUI
2 purged Albion patches = about 760Mb, so about 450Mb just for GUI
Now, you can imagine where is your RAM gone 
To be honest, I think with Berlin multi-patches situation is even worse. As I'm not using multi-patches and key-switches I have no problems. But, I can remember once when I messing up with multi-patches something was very strange about legato and purge legato on settings tab. There is something bad in there but don't know exactly what.

Examples:


----------



## Critz (May 9, 2017)

it's not the GUI, they say it's the scripting. Now I wonder how could they be proud of this capsule system. What Capsule does it's remarkable just because it's inside Kontakt. Otherwise, a sampler that let you customize the keyswitches for a multi patch, let you stretch samples, let you crossfade between them...it's the normality. It's what a sampler does. Who force them to produce kontakt libraries?
And people still complain about PLAY. To work with play it's a pleasure if we look at Kontakt world.


----------



## MarcelM (May 9, 2017)

´400 or 600 mb for scripting? honestly? thats alot of code and i cannot really believe it. well, maybe iam wrong. iam a programmer but i never scripted a kontakt library


----------



## sazema (May 9, 2017)

Critz said:


> it's not the GUI, they say it's the scripting. Now I wonder how could they be proud of this capsule system. What Capsule does it's remarkable just because it's inside Kontakt. Otherwise, a sampler that let you customize the keyswitches for a multi patch, let you stretch samples, let you crossfade between them...it's the normality. It's what a sampler does. Who force them to produce kontakt libraries?
> And people still complain about PLAY. To work with play it's a pleasure if we look at Kontakt world.



I know, I said GUI just like that... who knows what else is loaded. Why will script took that memory?
I can only think about script has some startup methods to load some other stuff in background, some effects, IRs, or so.
But I can't talk about that because I really have no idea. I made few very basic scripts in Kontakt and that's all.

Also, I remember this video was quite interesting while I watched, about 8Dio Anthology strings and loading time... also tweaking of scripts


----------



## Critz (May 9, 2017)

I know, It sounds unbelievable to all of us, but that's what it seems they say here: scripting. Believe me, 400 or 600 mb seems crazy even for a dozen of pictures, knobs and sliders.


----------



## erica-grace (May 9, 2017)

That doesn't seem right.

Hey - Evil Dragon, or one of the other Kontakt gurus around here... without asking you to get into specifics, can you please tell us who dont know any better whether or not a large and in depth Kontakt script can actually take 600 MB of ram?


----------



## EvilDragon (May 9, 2017)

It's not really about the script, it's about the graphics. Graphics need to be uncompressed to bitmaps from their PNG format before they are displayed on the screen, this can take an awful lot of RAM if the animation has a lot of frames and/or has huge dimensions.


----------



## Ultra (May 9, 2017)

EvilDragon said:


> It's not really about the script, it's about the graphics. Graphics need to be uncompressed to bitmaps from their PNG format before they are displayed on the screen, this can take an awful lot of RAM if the animation has a lot of frames and/or has huge dimensions.


why would it have huge dimensions on the very tiny and size restricted Kontakt interface ?

The overhead on some of these libs is beyond crazy. Absolute amateur coders.

The other thing is - and that may be due to the way Kontakt provides the dev platform - that when one loads multiple single patches, that use 95-99% the exact same code and graphics, why the resources are being loaded again.... amateur coders. In a modular environment, each unique resource (including code) is loaded once, and then re-used where needed.

I own almost all OT stuff, and the overhead is absolutely idiotic. With absolute zero benefit. See the Spitfire stuff example.


----------



## meradium (May 9, 2017)

If it's really only about the graphics, how about an option to just throw all the GUI out the window then? Those who need fancy screens in the background can have them, those who rather want to work can stick with a basic set of knobs and a label even if it is just grey or b/w. 

If you think about it it would make sense. With all the crazy high-res Retina what not screens you probably need to provide high-res pictures in multiple ways to get a sharp looking interface independent of what the customer has (speculation!)...


----------



## Critz (May 10, 2017)

EvilDragon said:


> It's not really about the script, it's about the graphics. Graphics need to be uncompressed to bitmaps from their PNG format before they are displayed on the screen, this can take an awful lot of RAM if the animation has a lot of frames and/or has huge dimensions.



But we're not talking about 4000x3000 uncompressed tiff.. there's something deeply wrong here, otherwise every software and plugin should load on ram 400-500 mb, and we know it's not like that.


----------



## Tatu (May 10, 2017)

I often get the feeling, that developers go to great, great lenghts in making thing as complicated as possible, when it comes to scripting seemingly simple things - just so thay can say some epic words, like "1000 000 lines of code" or some such.

Maybe the next step is learning to optimize and cut out all unnecessary things, like those same built in Kontakt bitcrusher, gate, chorus etc effects - who uses these? - in each and every orchestral sample library and reduce some of that shiny graphical feedback, which apparently is one of the biggest factors in RAM consumption.


----------



## NoamL (May 10, 2017)

EvilDragon said:


> It's not really about the script, it's about the graphics. Graphics need to be uncompressed to bitmaps from their PNG format before they are displayed on the screen, this can take an awful lot of RAM if the animation has a lot of frames and/or has huge dimensions.



Hmm, thanks for letting everybody know the facts!

I just test loaded some Heavyocity Master Ensemble patches, they have large squareish GUIs and several pages, and these are one-shot percussion samples.

Kontakt 5 with nothing loaded = 157 MB
With all the M.E. libraries loaded = 1.50 GB
With all the M.E. libraries loaded but purged = 585 MB

So the total library footprint is 1.34 GB of which 0.92 GB (or 68%) is samples/scripts and the other 30% is just bitmaps?

Or another way of lookign at it, it's *~100MB *of unpurge-able data for each patch (since the ME libraries come as 4 menu patches).

The Albion and Berlin examples cited on the last page were *200-300MB* of unpurge-able data per loaded patch.

I never realized there was such a large *PER PATCH* ram hit just from loading GUIs. That kinda sucks for all of us who use templates or otherwise have workflows that involve opening up Kontakt as little as possible. In general I think time looking at a library GUI is a big waste unless you are sound-hunting inside a library like Omnisphere etc. But if you build a template where a library is loaded multiple times (one patch per artic) you're taking that RAM hit again and again....


----------



## Critz (May 10, 2017)

That's what you have when you rely on libraries developed in 1-2 years at maximun. No time for proper beta testing, no time for optimizing, no time to make it sound totally right. The work really hard for sure, but some of us do it as well. And we can't lose time with this kind of problem. 
Again, even with 96 gb of ram, I can't let berlin libraries take up to 90 gb. It's not 2025, it's still 2017.


----------



## sazema (May 10, 2017)

meradium said:


> If it's really only about the graphics, how about an option to just throw all the GUI out the window then? Those who need fancy screens in the background can have them, those who rather want to work can stick with a basic set of knobs and a label even if it is just grey or b/w.
> 
> If you think about it it would make sense. With all the crazy high-res Retina what not screens you probably need to provide high-res pictures in multiple ways to get a sharp looking interface independent of what the customer has (speculation!)...



Yes, and then we're returning again to story about GUI.
I will not be sad if Berlin strings patch looks like window from Windows 3.1 if is fast, reliable and sounds good 
Because, I'm not so mad about GUI, than about functionality.

As I saw, same thing with some Output libraries, or 8Dio.
Beside RAM hell also CPU goes to hell.

Also from my perspective, I don't like this today fashion of overusing Kontakt. Kontakt is a sampler!
Yesterday I saw again new library which has synth engine actually, I can't remember the name. Why forcing synth functionality in Kontakt over Reaktor for example? Or even independent VSTs.
Problem is you will always have lack with some automation inside Kontakt, or it will be so complicated. Modulation of some parameters with certain number of envelopes or LFOs.
If I want synth I would mess with Zebra, Massive, or ....


----------



## MarcelM (May 10, 2017)

sazema said:


> Yes, and then we're returning again to story about GUI.
> I will not be sad if Berlin strings patch looks like window from Windows 3.1 if is fast, reliable and sounds good
> Because, I'm not so mad about GUI, than about functionality.
> 
> ...



agree with the windows 3.1 look... even if it would be DOS like 

i dont need fancy gfx.


----------



## EvilDragon (May 10, 2017)

Ultra said:


> why would it have huge dimensions on the very tiny and size restricted Kontakt interface ?



Knobs usually have a lot of frames (100, or more). A 100x100 knob that has 128 frames will be 100x12800 px, now convert that to 8-bit RGB BMP and you get the RAM load for just that one image. Also libraries that have animations on the GUI will have pretty big images for that (usually).



Critz said:


> But we're not talking about 4000x3000 uncompressed tiff..



Yes, we're talking uncompressed BMP, which PNG gets converted to before blitting it on the display. And yes, some libraries do use graphics that are several thousand pixels tall (Output, 8dio, for example, but some others too).



NoamL said:


> So the total library footprint is 1.34 GB of which 0.92 GB (or 68%) is samples/scripts and the other 30% is just bitmaps?



Not quite. Some of that RAM load is for voice and object memory (see Extras->Engine tab in Kontakt). This memory cannot be shared between patches.



One possible solution for this would be Kontakt being a bit smarter with graphical resources, and sharing them if at all possible (just like how samples are shared too if they're identical between some patches). That's up to NI, though.


----------



## sazema (May 10, 2017)

Heroix said:


> agree with the windows 3.1 look... even if it would be DOS like
> 
> i dont need fancy gfx.


----------



## MarcelM (May 10, 2017)

i think the best solution would be if there was an alternative low mem gui. no problem for the developer, and good for the customer to have a choice,


----------



## Ultra (May 10, 2017)

Tatu said:


> I often get the feeling, that developers go to great, great lenghts in making thing as complicated as possible, when it comes to scripting seemingly simple things - just so thay can say some epic words, like "1000 000 lines of code" or some such.


I never heard a single dev say that (to advertise their skill). It is exactly the opposite.

If he/she did, I'd fired him on the spot. Point is the least amount of code, that uses least amount of system resources.

The "unknown" factor here is the Kontakt platform, which may be the reason why some stuff gets bloated... but the example with the images mentioned here is beyond nuts especially because none of the libs I've ever seen have anything worth of images or "animations" worth more than 20MB. That is already lossless png. If one knows how to optimize images properly. The size of the code itself is peanuts.

But since we've all used libs that do not go overboard on RAM footprint, we know it ain't Kontakt, it is the devs in question. It may be that some "advanced" features of Capsule are harder to execute within Kontakt (ergo: more code), but again, 1 million lines of code is nothing in footprint.


----------



## Ultra (May 10, 2017)

EvilDragon said:


> Knobs usually have a lot of frames (100, or more). A 100x100 knob that has 128 frames will be 100x12800 px, now convert that to 8-bit RGB BMP and you get the RAM load for just that one image. Also libraries that have animations on the GUI will have pretty big images for that (usually).
> 
> 
> 
> ...


graphics of that size are not needed, as the max size of the interface is fixed. Amateur idiots.

Regarding the knob: you need ONE image. which you then animate in angle around it's center pivot. ONE image. not 128. And you can re-use the same single image for all knobs, as they all look the same.


----------



## EvilDragon (May 10, 2017)

Ultra said:


> but the example with the images mentioned here is beyond nuts especially because none of the libs I've ever seen have anything worth of images or "animations" worth more than 20MB. That is already lossless png. If one knows how to optimize images properly. The size of the code itself is peanuts.



Just because you didn't see such libraries doesn't mean they don't exist. As already mentioned, Output, 8dio, and some others are "guilty" of these extravagant GUI shenanigans.

Optimizing PNGs won't benefit anything in the long run, because they get uncompressed to bitmaps before blitting on the screen - THIS is where the RAM load starts to get crazy, provided there are lots of big images (even if they are compressed well to PNG).



Ultra said:


> graphics of that size are not needed, as the max size of the interface is fixed. Amateur idiots.



Sure they are, because this is how Kontakt deals with animations. You cannot have this:



Ultra said:


> Regarding the knob: you need ONE image. which you then animate in angle around it's center pivot. ONE image. not 128.



Because that's not how Kontakt works. You need a "filmstrip" for each position of the knob, in order for it to be animated properly on the GUI.



Ultra said:


> And you can re-use the same single image for all knobs, as they all look the same.



You cannot, because animations in Kontakt are not resizeable. So, you need to have a separate image for a different size of a knob. Educate yourself a bit on how Kontakt scripts expect graphics to be done.


----------



## EvilDragon (May 10, 2017)

Ultra said:


> I never heard a single dev say that (to advertise their skill). It is exactly the opposite.



Eheheh, 8dio did that (advertise huge amounts of code as a "feature").


----------



## Ultra (May 10, 2017)

EvilDragon said:


> Just because you didn't see such libraries doesn't mean they don't exist. As already mentioned, Output, 8dio, and some others are "guilty" of these extravagant GUI shenanigans.
> 
> Optimizing PNGs won't benefit anything in the long run, because they get uncompressed to bitmaps before blitting on the screen - THIS is where the RAM load starts to get crazy, provided there are lots of big images (even if they are compressed well to PNG).
> 
> ...



I posted I own almost all OT stuff, so trust me I KNOW these overblown libs exist. But they are idiots who waste our RAM. That is the point. 

Regarding Kontakt - as a dev platform - that is pathetic and massively wasteful, especially in 2017, but I'll say this: since the devs know this, it is them who waste our RAM while other devs are clearly more considerate. OT has received feedback since BWW and especially BST that the footprint on a fully purged lib is way too large and have they addressed this ? No.

At the minimum, provide a secondary, stripped down interface. BBR hits 30+GB, fully purged. It is the SAME GUI for 99% of the single patches, except the runs. So you basically need TWO different GUIs for the entire lib, but it gets loaded 200 times if you include each single patch.

No excuses.


----------



## EvilDragon (May 10, 2017)

As mentioned, a simpler solution might be on Kontakt's side, by sharing graphical resources if identical files are found across multiple instruments. That alone would be a huge boon. I don't see them changing how graphics operate any time soon (backwards compatibility being the main reason).

Kontakt's not the only software plugin that uses filmstrip-based animations for knobs/sliders etc, though.


----------



## Ultra (May 10, 2017)

well, a dev NOT using an image larger than the max GUI size would also be a starting point. But Kontakt itself would def be the place to start.

You can keep full-backwards compatibility and change literally everything (going forward), not a problem. Filmstrip animations is idiotic (but can be used, if the dev decides so). But for a general purpose lib, a Kontakt GUI usually has knobs, sliders or switches in 99% of the cases. NI merely needs to provide an animation scenario for these 3 main cases (which will result in minimal footprint and many devs will be happy to use them). Done. Use the images as provided by the dev (hopefully optimized). Done. re-use already loaded resources if referenced. done.

the craziest out of all of this crap is, that I never go back to the Kontakt interface once the lib has been setup within Kontakt and VEPro and all CCs are hooked up (everything is controlled from within the DAW). It is literally wasting RAM for zero reasons. Nobody is looking at these interfaces.


----------



## Critz (May 10, 2017)

S


EvilDragon said:


> Knobs usually have a lot of frames (100, or more). A 100x100 knob that has 128 frames will be 100x12800 px, now convert that to 8-bit RGB BMP and you get the RAM load for just that one image. Also libraries that have animations on the GUI will have pretty big images for that (usually).
> 
> 
> 
> ...



Sorry but I don't agree. 
If so, a webpage would be far more heavy, not to mention social media page. But more important, we all use many other vsti and plugin with much more fancy, complex and cool-looking, and they don't take 500 mb of ram. Otherwise with a 8 gb of ram lapotop it would be impossible to open 8 istances of filter, reverbs, compressor etc. We're talking of few mb or gui.


----------



## Critz (May 10, 2017)

And 


Critz said:


> S
> 
> 
> Sorry but I don't agree.
> If so, a webpage would be far more heavy, not to mention social media page. But more important, we all use many other vsti and plugin with much more fancy, complex and cool-looking, and they don't take 500 mb of ram. Otherwise with a 8 gb of ram lapotop it would be impossible to open 8 istances of filter, reverbs, compressor etc. We're talking of few mb or gui.


We all can do test loading a new plugin on a project and see how it takes.


----------



## EvilDragon (May 10, 2017)

You may not agree, but that is how Kontakt works. You cannot compare that with websites.


----------



## EvilDragon (May 10, 2017)

Ultra said:


> well, a dev NOT using an image larger than the max GUI size would also be a starting point.



You cannot have a smoothly animating knob then... 100 frames is kinda minimum for that. So if a knob is 32x32, you will end up with 3200px in one direction for the filmstrip. It is what it is.


----------



## Critz (May 10, 2017)

EvilDragon said:


> You may not agree, but that is how Kontakt works. You cannot compare that with websites.


 I highly respect your knowledge and patience on reply, just to be clear!
What I'm saying, is that outside kontakt things can work much simply and the way we all expect. 
So my first question is why to stay in kontakt after so many huge projects and investments on orchestral library? Why not an own sampler? Cause people like kontakt and won't use another sampler? Than you are not working for professional user, and not professional user cannot have pc or mac with 128 gb of ram.

By the way I remember I found in a thread very similar to this one, in VI control, someone from OT saying that the code of capsule was the reason tor many gbs even with sampled purged.
At this point I hope some of them will reply here to clarify.


----------



## Critz (May 10, 2017)

EvilDragon said:


> You cannot have a smoothly animating knob then... 100 frames is kinda minimum for that. So if a knob is 32x32, you will end up with 3200px in one direction for the filmstrip. It is what it is.


But do you understand knowbs and sliders were used in software like C-sound too??? And there were 500mb ram pc at that time...


----------



## EvilDragon (May 10, 2017)

Critz said:


> So my first question is why to stay in kontakt after so many huge projects and investments on orchestral library? Why not an own sampler?



Because:

* Kontakt is ubiquitous and thousands of people are using it - biggest userbase for a virtual sampler
* Making a new sampler from scratch takes years and years of R&D and hundreds of thousands of $/€/whatever to invest
* Kontakt takes care of different plugin types, so sample library developer doesn't need to care about supporting VST, AU, AAX - NI did all that already


----------



## EvilDragon (May 10, 2017)

Critz said:


> But do you understand knowbs and sliders were used in software like C-sound too??? And there were 500mb ram pc at that time...



Vectors, then, perhaps? Those take next to no RAM, are resizeable, etc.


----------



## Ultra (May 10, 2017)

EvilDragon said:


> You cannot have a smoothly animating knob then... 100 frames is kinda minimum for that. So if a knob is 32x32, you will end up with 3200px in one direction for the filmstrip. It is what it is.


100 years outdated filmstrip animation would be the (unfortunately necessary) exception. I thought u said earlier that 8Dio and others used very large graphics for static backdrops, not interactive GUI elements. That what my comment was aimed at.

In any case, the devs are to blame because other devs are more considerate. But that does not look good for NI. That is bad. Real bad.

Btw, the web analogy that Critz wrote is 1000% on target. It's not how it currently works, but how it needs to work... since 2007. Oh boy.


----------



## EvilDragon (May 10, 2017)

Here's a neat infodump, created with Output Analog Strings.

First what I did is I edited the instrument down to the very bones - I removed all samples, all groups (apart from one that needs to be there), set to sampler mode, removed all modulators, removed all effects, set max polyphony to 1. This makes sure that object and voice memory is not a huge factor in the test - so all that remains are the scripts, the graphics, and base memory needed for the instrument to operate.

Numbers for this crippled patch:
Object memory total: *36.53 MB*
Sample management memory: *193.5 KB*
Voice memory total: *1 MB*

Opened Kontakt 5.6.6 standalone: *180 MB of RAM*
Opened the crippled AS patch: *587 MB of RAM
*
So about 370 MB is used for the graphics (this is for the initial view, when you go to other tabs of the interface, some other graphics get loaded, so it seems at least partially graphics resources loading is dynamic in a way).

Now, if I load that same patch again in the same instance of Kontakt, I get: *610 MB of RAM*. So it seems there is some 30 MBs of overhead, probably not for graphics, but for instrument and script data etc. It is obvious that graphics are shared between these two instruments - just like samples are. So I was wrong to assume that they aren't shared - they in fact are!

Another test - running just one such crippled AS patch in one instance of Kontakt standalone, we're at above mentioned 587 MB of RAM.

Loading another Kontakt instance and the same crippled AS patch: I get twice the RAM usage. This is because graphics are not shared between separate Kontakt processes (which is logical and how most programs operate). However let's try doing the same test in a DAW (Reaper).

Reaper fresh start: *103 MB of RAM*
Opening Kontakt plugin: *273 MB of RAM*
Opening the crippled AS patch: *691 MB of RAM*

So that is about the same as with standalone. But now, I'm gonna duplicate the track so that another instance of Kontakt is loaded with the same patch.

Duplicate Kontakt instance with crippled AS patch: *850 MB of RAM
*
This is about 60-70 MB for the second empty Kontakt instance, and about the same for the crippled AS patch. So in this case, it's not another 370 MB of RAM for duplicated graphics now. *Conclusion: identical graphics resources ARE shared between Kontakt instances as well as within a single Kontakt instance!* Which I guess makes sense because all those Kontakt instances are by default loaded within the main DAW process - not as separate processes as it's the case with standalone Kontakt.

Well I guess this goes to say that Kontakt is doing its best to be as optimized as possible - not only samples are shared, but graphics too.


----------



## EvilDragon (May 10, 2017)

Ultra said:


> 100 years outdated filmstrip animation would be the (unfortunately necessary) exception.



Well... I wouldn't call it outdated. There are some things you can do with filmstrip animations you cannot do with just a single frame pivoting around a certain point (knob) or moving along a certain axis (slider), like taking drop shadows into account (this would necessitate rendering 3D effects, which Kontakt is absolutely unsuited for), or like those fancy macro sliders that Output AS has... It would work for very crude and rudimentary knobs/sliders, which I'm not sure some/most developers would like.


----------



## Ultra (May 10, 2017)

EvilDragon said:


> Well... I wouldn't call it outdated. There are some things you can do with filmstrip animations you cannot do with just a single frame pivoting around a certain point (knob) or moving along a certain axis (slider), like taking drop shadows into account (this would necessitate rendering 3D effects, which Kontakt is absolutely unsuited for), or like those fancy macro sliders that Output AS has... It would work for very crude and rudimentary knobs/sliders, which I'm not sure some/most developers would like.



Kontakt is a 2D interface, it would need a pseudo 2D drop shadow. You can do this with basic CSS for 5-6 years now. 1 line of code.

Regarding animation: no, there are ZERO advantages to filmstrip, unless the frames actually do change in content, NOT just in positioning. Which sliders, knobs and switches don't.

You can use a modern 200KB animation framework, to do insane things. 1 billion times more what is currently being done in Kontakt.

regarding the RAM footprint example you posted: so, assuming images are shared and re-used, what is accounting for the 300MB per patch ?!? It simply cannot be scripts. That is impossible.


----------



## EvilDragon (May 10, 2017)

Ultra said:


> Which sliders, knobs and switches don't.



Sometimes they do, I've worked on some libraries where that was a necessity. So yes, there ARE _some_ advantages to filmstrips. Anyways, it's pointless to discuss this as it's extremely likely that this method of dealing with animated graphics is going to change for Kontakt. Best we could hope is support for SVG at some point... But having something like a CSS renderer in Kontakt is probably something that won't ever happen.



Ultra said:


> regarding the RAM footprint example you posted: so, assuming images are shared and re-used, what is accounting for the 300MB per patch ?!? It simply cannot be scripts. That is impossible.



Well, graphics for Output Analog Strings are around 110 MB of PNGs (over a thousand images), and I would say the rest could very well be the scripts. It is not impossible. Depends on how many variables is declared, how many of them are arrays, how big are those arrays, are they polyphonic, and how many of them are persistent...


Note that each additional patch loaded is taking some 30-70 MB (standalone vs plugin), graphics are shared so that's a one-time payload of some 300 MB (not sure how we get to that number from 110 MB of PNGs, though).


----------



## Ultra (May 10, 2017)

EvilDragon said:


> Sometimes they do, I've worked on some libraries where that was a necessity. So yes, there ARE _some_ advantages to filmstrips. Anyways, it's pointless to discuss this as it's extremely likely that this method of dealing with animated graphics is going to change for Kontakt. Best we could hope is support for SVG at some point...
> 
> 
> 
> ...



70MB of minified, compressed scripts would amount to a massive amount of code. Per patch. Doesn't make sense.

But in OT's world, that would be a small patch ))))


----------



## Critz (May 10, 2017)

EvilDragon said:


> Because:
> 
> * Kontakt is ubiquitous and thousands of people are using it - biggest userbase for a virtual sampler
> * Making a new sampler from scratch takes years and years of R&D and hundreds of thousands of $/€/whatever to invest
> * Kontakt takes care of different plugin types, so sample library developer doesn't need to care about supporting VST, AU, AAX - NI did all that already


 
And here reasons to quit kontakt:

- people crack kontakt and libraries
- kontakt is not crafted for kind of libraries like Berlin Series
- making such huge orchestral templates cost a lot of money in term of renting hall, musicians, instruments, and a lot of programming too.
- a lighter version for kontakt it's still a chance even developing a new sampler, considering the work already done


----------



## Phryq (May 10, 2017)

Tatu said:


> I often get the feeling, that developers go to great, great lenghts in making thing as complicated as possible, when it comes to scripting seemingly simple things - just so thay can say some epic words, like "1000 000 lines of code" or some such.



I read once that programmers are payed per line, and so they write as verbosely as possible.

So our problem is capitalism.

I'd also be happy with an ultra-simple, black and white GUI.

I don't think Orchestral Tools comes on here, but maybe a developer like *Chris Hein* or Embertone could try some of these ideas.

A simple black and white GUI. (Or even better, a GUI that gets _purged_ from RAM when you close it). I'm making a request on the Reaper forum, and see if it's possible on the DAW side.
http://forum.cockos.com/showthread.php?p=1842669#post1842669

Also, using VST3, is would be cool if you could control each instrument form a single GUI (e.g. I want to activate the Tree mic on *every* patch at once. Or I want to purge *every* instrument at once.) A bit off topic there.


----------



## EvilDragon (May 10, 2017)

Critz said:


> - kontakt is not crafted for kind of libraries like Berlin Series



Absolutely wrong. Spitfire is the proof the same thing can be done much more efficiently.

Piracy or not, Kontakt still has the widest userbase, which makes it the best choice for selling a library and generating meaningful income (yes, despite the cracks).



Critz said:


> - making such huge orchestral templates cost a lot of money in term of renting hall, musicians, instruments, and a lot of programming too.



This doesn't really depend on Kontakt. Same would have to be done if a library were done for any other sampler. Your arguments aren't really that good. :D



Phryq said:


> I read once that programmers are payed per line, and so they write as verbosely as possible.



Well, what can I say but this is wrong. At least as far as I'm concerned. 



Phryq said:


> Also, using VST3, is would be cool if you could control each instrument form a single GUI (e.g. I want to activate the Tree mic on *every* patch at once. Or I want to purge *every* instrument at once.) A bit off topic there.



This doesn't have to be VST3 specific, as the same kind of control is possible via VST2 as well.

Also, you can already do the same thing with Kontakt provided purge buttons are MIDI learnable.


----------



## Phryq (May 10, 2017)

Oh? I'm guessing purge buttons are midi learn-able in Reaper, and so I can create some purge action applying to all tracks at once? Or at least purge without opening the Kontakt gui?


----------



## sazema (May 10, 2017)

No, the point is - this is for me ok, you? Even this dirty white  If sounds good and if is functional. This knobs are just fine to me - native GUI. Can I add hundreds of these with no CPU/RAM impact - in purged mode? Yes you can, but it's ugly... who cares!







Just go to airport and see terminal application, is it nice? Who cares, it does the job.


----------



## Critz (May 10, 2017)

EvilDragon said:


> Absolutely wrong. Spitfire is the proof the same thing can be done much more efficiently.
> 
> Piracy or not, Kontakt still has the widest userbase, which makes it the best choice for selling a library and generating meaningful income (yes, despite the cracks).
> 
> ...



I'm not offended by what you said, really, but let me know you're not good reading between the lines: if I invest 500.000 dollars to produce 10 libraries (it's a random number), to spend 150.000 to develop my sampler has a lot of sense. And it will have more sense when I will have produced 30 libraries. Now you got it?

About spitfire, I don't buy a library from them since years, probably because I didn't like at all working with their libraries, but probably things chanced according to people feedbacks. Even if actually I can't trust that much feedbacks from this widest fanbase your talking about, that is at the 95% made of unlicensed users, that cannot really judge a library since they obviously never tried libraris from VSL or EW they cannot crack.


----------



## MarcelM (May 10, 2017)

sazema said:


> No, the point is - this is for me ok, you? Even this dirty white  If sounds good and if is functional. This knobs are just fine to me - native GUI.



you know i like pretty guis, but for an kontakt instrument id be for sure okay with it.
how often do you see it anyway?


----------



## sazema (May 10, 2017)

But, who knows, now we're in era of fancy GUIs. After 10 years we will be in era of retro - old cheap fashioned GUIs


----------



## Critz (May 10, 2017)

sazema said:


> No, the point is - this is for me ok, you? Even this dirty white  If sounds good and if is functional. This knobs are just fine to me - native GUI.



Honestely we're not talking about the most fancy user intertace (talking about Berlin Series). To me it seems already quite basic...
I have far


sazema said:


> But, who knows, now we're in era of fancy GUIs. After 10 years we will be in era of retro - old cheap fashioned GUIs



We're missing the point only OT seems to have this problem.. PLAY is even better concerning GUI (and far more handble for multitimbral purposes) and when you open it with an instrument and purging sample it takes like 150mb. And that doesn't change if you load more patches.


----------



## sazema (May 10, 2017)

Heroix said:


> you know i like pretty guis, but for an kontakt instrument id be for sure okay with it.
> how often do you see it anyway?



Heh, that's why I told you, for me even sequencer GUI is not important if I have no performance issues - who cares.
Ok, we all love to see something nice - futuristic, but almost always we also paid prices for that.

It's like - better full working and trusty web form then nice and polished form who does not save data in database.
It's benefit if you can blend everything together of course.

But, just look a little bit in past, for last 5 years only battle is with GUIs.

Battery2 -> Battery3 -> Battery4 - what is the difference? except some bugfixes...
Kontakt4 -> Kontakt5 -> what is the difference? except some bugfixes and some tiny improvements
Arturia 4 vs latest Arturia 5 ? I know users complaining about CPU usage and performance overall. And as they said even Arturia 4 worked better 
Omnisphere 1 vs Omnisphere 2 - again battle with CPU and RAM, even worse than before. Except I ran Omni1 with my DualCore machine ok and now I need i7 for Omni 2.

Isn't the goal in lowering of performance issues and needs, than in story about - buy more ram, buy better cpu.


----------



## sazema (May 10, 2017)

Critz said:


> Honestely we're not talking about the most fancy user intertace (talking about Berlin Series). To me it seems already quite basic...
> I have far
> 
> 
> We're missing the point only OT seems to have this problem.. PLAY is even better concerning GUI (and far more handble for multitimbral purposes) and when you open it with an instrument and purging sample it takes like 150mb. And that doesn't change if you load more patches.



I wanted to say it's mostly marketing problem. It's good if is nice. So with any new library you are at the thin line with this and with the existing Kontakt sampler as-is.


----------



## EvilDragon (May 10, 2017)

Phryq said:


> Oh? I'm guessing purge buttons are midi learn-able in Reaper, and so I can create some purge action applying to all tracks at once?



Depends on how they were scripted. If ui_switch was used for them, they are MIDI learnable/automatable. If ui_button was used, then no dice.



Critz said:


> that is at the 95% made of unlicensed users



Throwing random numbers out sure is fun! No, I'm talking about dozens of thousands of legitimately registered Kontakt users! NI doesn't state the numbers, but it's pretty big.



sazema said:


> Kontakt4 -> Kontakt5 -> what is the difference? except some bugfixes and some tiny improvements



VERY much disagreed there. Improvements in K5 were vast and huge. New effects and filters are great (and definitely NOT a "tiny" improvement). Also new scripting possibilities that happened during K5 time are definitely not "tiny" improvements.


----------



## Critz (May 10, 2017)

EvilDragon said:


> Throwing random numbers out sure is fun! No, I'm talking about dozens of thousands of legitimately registered Kontakt users! NI doesn't state the numbers, but it's pretty big.


I'm not denying that or the fact kontakt is the most diffused and famous sampler alive (it's at the first, with no assigned 2nd and 3rd)!
But if you have this big numbers very often means you don't have the pro. And when you ask 699 only for strings or brass, then you ask for other 299 to add an expansion, you're talkin with pro user (in theory). And honestely, at list up to few years ago, orchestral libraries for kontakt were not pro at all. It was just VSL and a bit of EW


----------



## sazema (May 10, 2017)

> Re to Kontakt is bad, Play is better

Ok, we can't control what will be bought by who 
Someone trust in EastWest, someone in Miroslav and IK stuff, someone in Kontakt.
I like Independance sampler from Magix for example, but they decided to surrender somewhere around 2013. What can I do? If Indep. is in constant development even today I will probably go with magix - who knows.
And same thing is happened to this, after a while a new sampler came out, a new hope, Engine 2 - and of course CPU hog and almost abandoned, don't know if is active development right now? Very few libraries for Engine 2, some good some bad.

Truth is Kontakt becomes widely common and trusty.

Main Kontakt feature important to me is DFD and how samples are treated. This is not available with lot of existing samplers, they just load everything into RAM. 
It's a big benefit and it was true revolutionary option (I said that before).

And now, even *NI have nothing to do with this*  Capitalism, fancy-shmensy GUIs, is good if is nice and similar obsessions 

A little digression:

- Omni 2 and Keyscape - wow, full pile of threads here also on VI, best C7 ever .... yes, but it took 5-6Gb or RAM in session, and it's not so different from some other C7 Kontakt libraries at the end. Just it has cinematic preset, wood preset, kitchen preset. Am I ready to sacrifice 5Gb or session RAM for that piano if I'm at 16Gb of total RAM, someone is with 8Gb. Yes, story about RAM is not expensive... I don't want to buy any RAM - 16-32 is ok and it should be ok. Enough.

- Just look at this Cinematic / Epic expansion right now, every 5 days new Trailer Hits, Raisers, Booms library is out with dragon GUI in background and some super fancy knob in the middle (rather big).

I want to say, shame. Some worth Kontakt library can be made even with native GUI and I believe everything will be fine. Kontakt factory library -> legacy orchestral -> flute patches 12kb no gui at all - sounds fantastic in combination with good reverb. You can add 1000 of flutes in session


----------



## sazema (May 10, 2017)

I mean, of course patch will be heavy if you decide to mimic synth in sampler.
Or, do users really need this wiggle-jiggle strings animations? And basically just 3 faders even in style of background would be enough (filter, rhythm and vibrato)






Yes, it looks nice buy their workstation and session will not be pleased  I don't have it, but what is the situation with this? CPU goes crazy I can bet in that


----------



## sazema (May 10, 2017)

EvilDragon said:


> VERY much disagreed there. Improvements in K5 were vast and huge. New effects and filters are great (and definitely NOT a "tiny" improvement). Also new scripting possibilities that happened during K5 time are definitely not "tiny" improvements.



Heh, I understand what you mean. I know that of course, but I just wanted to point that in period of latest few years we have just GUI battle in most cases and nothing more if we observe that globally.

Or even Kontakt could be stay the same as K4 with all that new improvements if that is good for performance but it's not so nice looking.
Why not optional GUI, like: Kontakt can be plain and simple or if you prefer transform it with single click to futuristic look.
If you have performance issues with Windows 10, even today you can turn off all CPU/RAM eaters and turn it into Windows 98 look.
Ok, icons are bad, menu is not so fancy but it will work just fine on some weak machine. Yupiii.


----------



## EvilDragon (May 10, 2017)

sazema said:


> This is not available with lot of existing samplers, they just load everything into RAM.



Err, which ones? Falcon - has DFD. HALion - has DFD. Independence - has DFD. Omnisphere - has DFD. Those are all the major ones. Others are more niche, and for some types of sample mangling you can't really go with disk streaming - you need to have the samples in RAM (time stretching, granular, beat slicing, etc.).


----------



## sazema (May 10, 2017)

EvilDragon said:


> Err, which ones? Falcon - has DFD. HALion - has DFD. Independence - has DFD. Omnisphere - has DFD. Those are all the major ones. Others are more niche, and for some types of sample mangling you can't really go with disk streaming - you need to have the samples in RAM (time stretching, granular, beat slicing, etc.).



I don't know for Falcon and Halion, but for Omnisphere - it's weak DFD 
Omni tend to have that option but it works in following way:

- load patch and it will show you 50Mb
- while you're playing you will notice how RAM will be filled up to 150 Mb, just how samples are loaded - same like purged Kontakt patch
- of course that additional amount of RAM depends on individual patch

So even if you tweak pre-load size in settings it's just pre-load.

With Kontakt, that is not the case, footprint loaded into RAM is defined by settings and that's it. While you play - your HDD will die.
So, by this two, Kontakt has better DFD logic.

But, no matter really. Let's get back to suspicious library


----------



## EvilDragon (May 10, 2017)

It's still DFD, even if it's done differently, but essentially Omni is not doing anything different than Kontakt there. But it's not re-loading purged samples for sure, that would produce crackles and clicks on a non-SSD drive (just like it does if you try to do it in Kontakt).


----------



## sazema (May 10, 2017)

EvilDragon said:


> It's still DFD, even if it's done differently, but essentially Omni is not doing anything different than Kontakt there. But it's not re-loading purged samples for sure, that would produce crackles and clicks on a non-SSD drive (just like it does if you try to do it in Kontakt).



Ok, then I will edit (correct) myself, I like Kontakt because most convenient DFD option in my opinion


----------



## NoamL (May 10, 2017)

ED thank you so much for your posts & investigation of this issue.

You mentioned that graphics are not shared between separate Kontakt processes (separate instances). Does that mean sample data is not shared either? So to take advantage of sample sharing between 2 patches of the same library, they have to be loaded as 2 patches inside the same instance of Kontakt?



EvilDragon said:


> Because:
> 
> * Kontakt is ubiquitous and thousands of people are using it - biggest userbase for a virtual sampler
> * Making a new sampler from scratch takes years and years of R&D and hundreds of thousands of $/€/whatever to invest
> * Kontakt takes care of different plugin types, so sample library developer doesn't need to care about supporting VST, AU, AAX - NI did all that already



Also because every dev saw how unpopular PLAY was, and also how unstable it was until the recent 5.0.


----------



## camelot (May 10, 2017)

Sorry if this was discussed before or is already available in Kontakt.

What if the data of the customized GUIs is purged from RAM, when performance mode is switched off. So we see only the instrument header, which already offers various controls. I know, any time you display the performance mode again, it would need to reload the GUI resources into RAM causing a load delay. However, one could generate an additional option/mode/button for those cases where the user is quite sure not to edit the patch anymore.
It could even leave something like the minimized header.
The actual use of GUIs should be minimal for those with templates and samples distributed over slave machines. From time to time I edit some patches on my slave machine but most of them I did not touched for some time, some of them not even for a year.


----------



## Phryq (May 10, 2017)

camelot said:


> Sorry if this was discussed before or is already available in Kontakt.
> 
> What if the data of the customized GUIs is purged from RAM, when performance mode is switched off. So we see only the instrument header, which already offers various controls. I know, any time you display the performance mode again, it would need to reload the GUI resources into RAM causing a load delay. However, one could generate an additional option/mode/button for those cases where the user is quite sure not to edit the patch anymore.
> It could even leave something like the minimized header.
> The actual use of GUIs should be minimal for those with templates and samples distributed over slave machines. From time to time I edit some patches on my slave machine but most of them I did not touched for some time, some of them not even for a year.



I asked that a few times. It would be great if Kontakt would develop it.


----------



## novaburst (May 10, 2017)

EvilDragon said:


> not really about the script, it's about the graphics. Graphics need to be uncompressed to bitmaps from their PNG format before they are displayed on the screen,



This may be the case on an on board grathics unit, but with any decent grathics card especially 4k units they do there own prossecing and have there own ram.

With an on-board grathics unit it will rely on the ram on the MB,


----------



## Rasmus Hartvig (May 10, 2017)

Critz said:


> I'm not offended by what you said, really, but let me know you're not good reading between the lines: if I invest 500.000 dollars to produce 10 libraries (it's a random number), to spend 150.000 to develop my sampler has a lot of sense. And it will have more sense when I will have produced 30 libraries. Now you got it?



You don't know a whole lot about the realities of software development, do you?


----------



## EvilDragon (May 10, 2017)

NoamL said:


> You mentioned that graphics are not shared between separate Kontakt processes (separate instances). Does that mean sample data is not shared either? So to take advantage of sample sharing between 2 patches of the same library, they have to be loaded as 2 patches inside the same instance of Kontakt?



In standalone, yes. As plugins, as long as they're under the same process (i.e. DAW or VEPro), they are shared.



novaburst said:


> This may be the case on an on board grathics unit, but with any decent grathics card especially 4k units they do there own prossecing and have there own ram.
> 
> With an on-board grathics unit it will rely on the ram on the MB,



Not quite, not in all cases. Application needs to be written with GPU accelleration in mind and using one of APIs to take advantage of it (OpenGL, Vulkan, DirectX). Kontakt doesn't use any of those.


----------



## erica-grace (May 10, 2017)

I have done some testing to see what I would find on my system. I have a Windows 7 computer with 64 GB of RAM. I tested using a brand new empty project with one instance of Kontakt 5.66, and also the Berlin Brass Horns Legato patch, with the tree and close mics loaded. This patch uses 1.22 GB of RAM, as reported by Kontakt.

OS RAM with:

Empty Kontakt: 4.30

Horn patch loaded: 5.77

Samples purged: 4.56

Reload all samples: 5.77

All zones deleted: 4.54

This tells me that the High RAM usage is due to samples, and that graphics, capsule and scripting is contributing to very little in the way of RAM usage. So, I moved CAPSULE.nkr, CAPSULE.nkc, and the nicnt file.

Horn patch loaded (no graphics): 5.77

Then, I moved those three files back, loaded the patch again, wound up back at 5.77 GB, then deleted the scripts, by way of Preset>Factory>Empty. After that, the OS RAM usage was still at 5.77 GB.

This confirms to me that the High RAM usage is due to samples - and not graphics, capsule and scripting. Unless I am missing something, perhaps?


----------



## NoamL (May 10, 2017)

Well, that's still 260MB just for one OT patch. Sure, the samples are much larger (1,100 MB) but the point of this discussion is that the two aren't correlated by necessity.


----------



## brett (May 10, 2017)

ED, you've been very patient here. Massive respect for the positive contributions. Cheers


----------



## Critz (May 10, 2017)

NoamL said:


> ED thank you so much for your posts & investigation of this issue.
> 
> You mentioned that graphics are not shared between separate Kontakt processes (separate instances). Does that mean sample data is not shared either? So to take advantage of sample sharing between 2 patches of the same library, they have to be loaded as 2 patches inside the same instance of Kontakt?
> 
> ...


Sorry, but I have to say it: bullshits. That's what people used to say, and so people start saying without having it.

Play could have been not the smartest of sampler, but I used it since the beginning being able to accomplish any kind of work. At the end of the day it always worked, and was not as much ram aggressive as kontakt is doing nowadays.
And honestly I had trouble with old libraries when I updated to Play 5 (random missing samples) and that made me angry. But still Play 3 was just fine, so Play 4.


----------



## storyteller (May 10, 2017)

I would just like to give a tremendous shout out and thank you to @EvilDragon and the other contributors that have sought to respectfully and professionally reply to all of the stirring up going on. I'm not sure what is up with VI-C (or the world, really) recently, but in no way is it respectful for anyone to carry on conversations in such a condescending manner. Passion is okay. Maybe just tame the word choices and finger-pointing possibly. I don't think that's too much to ask.

/rant over...

That said...there is a bit of a mystery to this memory footprint that is a very interesting topic to explore... which maybe the community here could find some helpful suggestions for the Devs.


----------



## Critz (May 10, 2017)

Rasmus Hartvig said:


> You don't know a whole lot about the realities of software development, do you?


Absolutely not. I don't know nothing about software development. But still I'm convinced developing stuff like capsule is a waste of time and money, that won't pay for years to come. You have to fight against a sampler it's not yours. It force you to make choices you probably wouldn't like to do, or you would like just to act differentely, but you can't. And most clearly it makes the library you are producing unusable.


----------



## storyteller (May 10, 2017)

Critz said:


> Absolutely not. I don't know nothing about software development. But still I'm convinced developing stuff like capsule is a waste of time and money, that won't pay for years to come. You have to fight against a sampler it's not yours. It force you to make choices you probably wouldn't like to do, or you would like just to act differentely, but you can't. And most clearly it makes the library you are producing unusable.



No offense at all, but this attitude is a microcosm of what is going on in the world right now and is exactly what has to change.

Respectfully, figure out a way or a method of improvement. Perhaps something new is needed. Perhaps not. But it doesn't mean that solutions can't be built or created together. You might be surprised how strong community is - and how much even the past and present developers strive to exist in harmony within this very same community.


----------



## Ultra (May 10, 2017)

storyteller said:


> That said...there is a bit of a mystery to this memory footprint that is a very interesting topic to explore... which maybe the community here could find some helpful suggestions for the Devs.



the devs are amateurs if they waste your RAM. simple as that. If the devs need "pointers" then they are no real devs.

Kontakt is outdated in usage of age-old concepts and needs to be overhauled 6 years ago. But, since other lib devs achieve to keep the footprint somewhat lower, it is amateur devs who just go through the roof with very amateur coding. And in the coding world, this is putting it very nicely.

Here's where this gets problematic: sure you could argue that buying more RAM is _*relatively*_ cheap and possibly cheaper than buying another library, so do just that. Well, I'm at 128GB max. Once you max out your motherboard you're done. Now it's a new mobo + RAM or more slaves. dealing with that hassle, plus latency etc etc etc 

and for what ? because amateurs cannot get their shit straight. You could use all of these libs plus more easily if they would know how to use resources efficiently.

Here's the irony: that money spent to constantly upgrade your workstation(s) could be spent on more libs, from that dev or others. So the devs are ultimately losing money with this approach. And, money spent on libs is a much better investment than tech. Tech is obviously needed but is outdated very quick, while peeps are sill using VSL (a very old lib, but no one is still using the same computer from 15 years ago).

I am not complaining about sample size. I want samples in 24bit 48kHz or preferably 96kHz. It's about the very inefficient handling of the GUI (or patch initiation) resources which ultimately mean nothing in creating the sound.


----------



## rocking.xmas.man (May 10, 2017)

Ultra said:


> because amateurs cannot get their shit straight.


What a cruel world you have to live in. Where 'Amateurs' make beautiful sounding tools allowing professionals to get their work done.


storyteller said:


> No offense at all, but this attitude is a microcosm of what is going on in the world right now and is exactly what has to change.


This!


----------



## Ashermusic (May 10, 2017)

storyteller said:


> I would just like to give a tremendous shout out and thank you to @EvilDragon and the other contributors that have sought to respectfully and professionally reply to all of the stirring up going on.



+1.


----------



## Ultra (May 10, 2017)

rocking.xmas.man said:


> What a cruel world you have to live in. Where 'Amateurs' make beautiful sounding tools allowing professionals to get their work done.
> 
> This!


no, musicians make the sound. Sound engineers and mixers adjust it (to taste) for the application in use. coders provide the interface implementation. It is the last part that is lacking with some devs.

The ability to differentiate (between various aspects of an application) and deal with real world scenarios is needed here, not pink bubble dreaming. But maybe you can dream of having 6 slaves run in perfect unison 

Musicians and forum members can't help coders, because they ain't coders (unless you actually are a high-end dev). You can provide feedback in regards to GUI, placement and functionality but that is UI/UX improvement and has nothing to do with resource efficiency.

what we are talking about here has to do with running shop efficiently, or with Kontakt being what it is, running shop as efficient as possible.


----------



## storyteller (May 10, 2017)

Ultra said:


> the devs are amateurs if they waste your RAM. simple as that. If the devs need "pointers" then they are no real devs.
> 
> Kontakt is outdated in usage of age-old concepts and needs to be overhauled 6 years ago. But, since other lib devs achieve to keep the footprint somewhat lower, it is amateur devs who just go through the roof with very amateur coding. And in the coding world, this is putting it very nicely.
> 
> ...


I read your first sentence and it made me not want to read the rest of your post...but I did. And I honestly get what you are trying to say. In many ways I agree. But as a parent, you would never call your child an "amateur" when they are doing the best they can. You would help them. And if you did not know how to help them, you'd find someone who could.

That said, you would also likely struggle to find a great teacher that could help AND willfully accept the job when you are name calling the people who had done the job previously. And it is very important to see every person through the eyes of a parent. It is the only way to truly understand how to positively affect change. Anything else is a massive detour into a hard lesson to be learned. If you can't see your dialogue through those eyes, then it may be better to just ask questions as you learn how to see through those eyes. Only then will you be able to positively affect change my brother.

So let's shortcut to that - since that is the passion driving this dialogue. The people you are addressing here - ED being one of them among the others here - are incredibly gifted and genuinely caring people when it comes to improvement in the technology of sampling. So ask the questions needed in order to see how and why the present situation exists, and to see what might be able to be done to improve/renovate/rebuild solutions to the problem. 

Sometimes building a bypass is more effective than attempting to overhaul a city's antiquated highway system. Sometimes not. I get that. So plan accordingly and build the relationships needed rather than being the heckler in the audience that is probably speaking many hard truths, but won't be respected.

I apologize if this comes across a little hard. But no time like the present to man the helm and continue forward on this great adventure together. No judgments. Just figuring out how to make the best outcome with those that are passionate about change.


----------



## Ashermusic (May 10, 2017)

Ultra said:


> no, musicians make the sound. Sound engineers and mixers adjust it (to taste) for the application in use. coders provide the interface implementation. It is the last part that is lacking with some devs.
> 
> The ability to differentiate (between various aspects of an application) and deal with real world scenarios is needed here, not pink bubble dreaming. But maybe you can dream of having 6 slaves run in perfect unison
> 
> ...



You want real world? Here is real world. I run Kontakt, EXS24, Play, Engine, and UVI libraries all the time composing professionally. With the exception of certain updates in either the OSes or plug-ins that have issues together, I am able to create music that my clients like with a minimum of problems fairly quickly.

By and large, the developers are more skilled at what they do than the people using their libraries are at what they do, IMHO.


----------



## Ashermusic (May 10, 2017)

Ultra said:


> no, musicians make the sound. Sound engineers and mixers adjust it (to taste) for the application in use. coders provide the interface implementation. It is the last part that is lacking with some devs.
> 
> The ability to differentiate (between various aspects of an application) and deal with real world scenarios is needed here, not pink bubble dreaming. But maybe you can dream of having 6 slaves run in perfect unison
> 
> ...



You want real world? Here is real world. I run Kontakt, EXS24, Play, Engine, and UVI libraries all the time composing professionally. With the exception of certain updates in either the OSes or plug-ins that have issues together, I am able to create music that my clients like with a minimum of problems fairly quickly.

By and large, the developers are more skilled at what they do than the people using their libraries are at what they do, IMHO.


----------



## Rasmus Hartvig (May 10, 2017)

Critz said:


> Absolutely not. I don't know nothing about software development. But still I'm convinced developing stuff like capsule is a waste of time and money, that won't pay for years to come.



Why not approach the thing with a little more nuance and humility then? A cocksure opinion based in ignorance isn't a great look.

I don't defend CAPSULE per se - it could certainly stand some thorough optimization, but the idea that companies should make their own sampler is totally misguided. Well, if you want to kill your small business, it might be a good bet.


----------



## erica-grace (May 10, 2017)

NoamL said:


> Well, that's still 260MB just for one OT patch. Sure, the samples are much larger (1,100 MB) but the point of this discussion is that the two aren't correlated by necessity.



Right - and I see that, as I think ED mentioned, the graphics ar enot shared. So you take that hit for every individual patch.

But is the hit really coming from the graphics and scripting? ie - is the large RAM usage really due to capsule?

The memory usage is the same with the graphics and scritping, as without the graphics and scripting. So I think we can conclude that OT is not doing anything wrong in this regard. No?

Also, purging samples is not the same as deleting zones. Not that you would want to delete zones, but the point is that purging does not net the same result as deleting. When you purge, your RAM goes way down. When you open the mapping editor and delete all of the (purged) zones, your RAM goes down even more.

Maybe this means there is something going on with Kontakt that is causing this issue? Something that a developer has no control over?


----------



## EvilDragon (May 10, 2017)

erica-grace said:


> Right - and I see that, as I think ED mentioned, the graphics ar enot shared. So you take that hit for every individual patch.



Nope, turns out they ARE shared. See my post where I did a test of all that. http://vi-control.net/community/thr...ulously-high-in-ram.61703/page-5#post-4087228



erica-grace said:


> But here is the thing #2- purging samples is not the same as deleting zones. Not that you would want to delete zones, but the point is that purging does not net the same result as deleting. When you purge, your RAM goes way down. When you open the mapping editor and delete all of the (purged) zones, your RAM goes down even more.



Yes, that is true. Purging samples just unloads the sample from memory. Every zone in the instrument, every group, every modulator, every effect loaded, needs to have some memory allocated for it to run properly (and by extension - every single variable and UI control declared by each of up to 5 script slots). This is what you see as "object memory" in Kontakt's Engine tab. This is the stuff you cannot purge, and this is the stuff that cannot be shared between patches.


----------



## NoamL (May 10, 2017)

storyteller said:


> I would just like to give a tremendous shout out and thank you to @EvilDragon and the other contributors that have sought to respectfully and professionally reply to all of the stirring up going on. I'm not sure what is up with VI-C (or the world, really) recently, but in no way is it respectful for anyone to carry on conversations in such a condescending manner. Passion is okay. Maybe just tame the word choices and finger-pointing possibly. I don't think that's too much to ask.
> 
> /rant over...
> 
> That said...there is a bit of a mystery to this memory footprint that is a very interesting topic to explore... which maybe the community here could find some helpful suggestions for the Devs.



Like always on VIC there are really multiple discussions taking place in this thread and you can take each post for what it's worth in terms of whether the poster is stating facts or opinions, where they're at in their careers, and whether they are able to state their ideas without attacking others.

/nuff said


----------



## Critz (May 10, 2017)

Rasmus Hartvig said:


> Why not approach the thing with a little more nuance and humility then? A cocksure opinion based in ignorance isn't a great look.
> 
> I don't defend CAPSULE per se - it could certainly stand some thorough optimization, but the idea that companies should make their own sampler is totally misguided. Well, if you want to kill your small business, it might be a good bet.



I'm not sure I understood your words. Do you mean libraries would became more and more expensive? No more affordable?
Well, I still read people complaining VSL libraries are so expensive... and they just cost as much as OT libraries! And so spitfire libraries!
The difference is that VSL is still investeing (let's look at the synchron stage) in a period where I was quite sure they were just falling a part because nowadays users completely forget about VSL.
Maybe I took what you said completely wrong, but again, if you think developing a sampler for an orchestral library would make it cost that much, I think you are wrong.
I think pirate copies are far more sharp on a library cost.


----------



## Ultra (May 10, 2017)

storyteller said:


> I read your first sentence and it made me not want to read the rest of your post...but I did. And I honestly get what you are trying to say. In many ways I agree. But as a parent, you would never call your child an "amateur" when they are doing the best they can. You would help them. And if you did not know how to help them, you'd find someone who could.
> 
> That said, you would also likely struggle to find a great teacher that could help AND willfully accept the job when you are name calling the people who had done the job previously. And it is very important to see every person through the eyes of a parent. It is the only way to truly understand how to positively affect change. Anything else is a massive detour into a hard lesson to be learned. If you can't see your dialogue through those eyes, then it may be better to just ask questions as you learn how to see through those eyes. Only then will you be able to positively affect change my brother.
> 
> ...



you seem to be misinterpreting quite a few things. And you seem to be very forgiving in some fields that are foreign to you 

I did not label all lib devs as amateurs. I labeled specifically the OT devs as that and any other dev who *mindlessly wastes my system resources*.

I never labeled ED as an amateur coder. Does he code for OT ? I would not know that he does.

Does he code for NI, specifically on Kontakt ? I would no know that he does.

If either case applies, and he has read my posts carefully which I think he has given his answers, and judging from his intellect, he is the first one to agree with me.

Things are currently the way they are (they always are ). THAT is what he explained in his posts. Which was very helpful in order to explain status quo. What things need to be is what I wrote.

WHY things are the way they are (Kontakt being 10 years behind, OT being very inefficient) he has not explained (because most likely he doesn't know, or is under NDA if he indeed works for NI), and usually with larger corporation there are a million reasons. Which I - as an user paying premium price - don't care about. Again: run shop efficiently, or at one point lose business (that is the real world). If there was a sampler that would be much more efficient than Kontakt (and the devs would develop for it), Kontakt had a massive problem (wordplay here... Massive being another NI product... thank you).

I could now go into details that I do understand that Kontakt is a sampler and running VIs with a graphical interface is one out of many things it can do, and (most likely) was not necessarily primarily built for that and that's why optimizations were not directly implemented back then.... yeah, I get that. But Kontakt's been around forever and heavy VI usage is a major feature of this sampler. It is way overdue to optimize that and/or implement direct GUI and animation features (in a framework fashion) for devs to directly utilize. You then still need the OT devs to do it properly.

All of the technologies needed to steal less RAM from us have been around for 10+ years (by that I mean commonly in use). The lib devs - who need to be aware of all the caveats of the platform they are developing for - need to code as efficiently as possible for that platform. THAT is their job !

In OT's case - which is what the OP eluded to - this is not the case. And even if it was, some peeps would still choose Spitfire over OT (because of some musical differences), but with current state they're even less inclined to buy OT.... ironically: OT loses more money.

This has been stated since BWW. This is not new. OT is not a new developer. Understand that please. Myself - and others - support OT by buying their products but they need to get their stuff straight.


----------



## storyteller (May 10, 2017)

Hopefully we can bring these posts back in line with the original topic rather than derail this any further. If you do have a further response regarding my comments, please feel free to PM me and I will be happy to continue the conversation beyond my replies below. I would just rather it not carry on in the midst of an otherwise beneficial thread for the forum.



Ultra said:


> you seem to be misinterpreting quite a few things. And you seem to be very forgiving in some fields that are foreign to you


To be honest, I think it is important to strive to be forgiving whether it is a foreign field or not. 



Ultra said:


> I did not label all lib devs as amateurs. I labeled specifically the OT devs as that and any other dev who *mindlessly wastes my system resources*.


This is one of those times where the way this post is written is probably not like it was intended, but I'll hedge a reply... Whether or not you believe the OT devs are up to your standards, OT certainly has not willfully made anyone use their products - and just as certainly, they have not created a product with the intention of wasting resources. They spent a great deal of time crafting an engine using the tools they had available to them in order to bring their vision to life at (what I imagine to be) a very small margin of profit. So, regardless where the ram culprit may lie - I think it will serve everyone in a much better way by constructively discussing and exploring solutions rather than placing accusations and judgements. 

VI-C is a wonderful community and I am sure that I can safely speak for most people when I say that the subject matter in this dialogue and suggestions are welcome and worthy of discussion. I'm just saying there are ways to do this together, and ways to create division - and no one wants the latter.



Ultra said:


> I never labeled ED as an amateur coder. Does he code for OT ? I would not know that he does.
> 
> Does he code for NI, specifically on Kontakt ? I would no know that he does.
> 
> If either case applies, and he has read my posts carefully which I think he has given his answers, and judging from his intellect, he is the first one to agree with me.


Without going down a rabbit hole here, I think it is probably better said that you never know who you may potentially be insulting - whether they are participating in the conversation, or maybe just reading these particular posts. Everyone has feelings and a sense of pride in their creations - whether they are professional or non. Part of what makes this community so wonderful is how everyone tries to make sure everyone feels like a part of a community and can seek and receive great advice when needed (_*tangent:* except the member compositions section tends to not get as much attention as it should...but that is another story_). And even if posts get a little heated from time to time, it is not uncommon to see an apology post a day or two later - like a family spat or something. Some people have bad days. That's life! But anyway... So, while you may not know who someone may be or what someone may do - the philosophy behind this forum is that it is very much like a family or a neighborhood community built on respect and acceptance of great skill and faults.

Much love brother.


----------



## C-Wave (May 10, 2017)

erica-grace said:


> I have done some testing to see what I would find on my system. I have a Windows 7 computer with 64 GB of RAM. I tested using a brand new empty project with one instance of Kontakt 5.66, and also the Berlin Brass Horns Legato patch, with the tree and close mics loaded. This patch uses 1.22 GB of RAM, as reported by Kontakt.
> 
> OS RAM with:
> 
> ...


So based on your excellent report, since OT's culprit is in the samples then I suggest we ask OT to produce a 16-bit version of their existing 24-bit samples, as Sonokinetic does with every release. This should give users a light version of their samples.


----------



## Ultra (May 10, 2017)

storyteller said:


> Hopefully we can bring these posts back in line with the original topic rather than derail this any further. If you do have a further response regarding my comments, please feel free to PM me and I will be happy to continue the conversation beyond my replies below. I would just rather it not carry on in the midst of an otherwise beneficial thread for the forum.
> 
> 
> To be honest, I think it is important to strive to be forgiving whether it is a foreign field or not.
> ...



you mean very well, but you're in a conversation about software development which I'm afraid you know little about.

also, this has nothing to do with the VIC user community because we are addressing devs selling a top of the foodchain, premium price commercial product.

But you're right... maybe if we could all get our esoteric hat on, be super naive, hold hands, smoke some weed (I'd need serious crack for this) and then just all be nice and dream of a pink bubble...

I mean, yeah... because this is how the software game works. Absolutely. It's not that companies on purpose release faulty releases with future upgrade-ability and fixes in mind. No. Never happened.

And clearly, the most popular sampler on the market with no emerging competition in sight, is fully up to modern standards and is constantly pushing the edge because that's what devs and corporations holding a monopoly or very large market share just naturally do.

Yes, just like the PT story.

Ah, good talk. Way to get things done.


----------



## galactic orange (May 10, 2017)

C-Wave said:


> So based on your excellent report, since OT's culprit is in the samples then I suggest we ask OT to produce a 16-bit version of their existing 24-bit samples, as Sonokinetic does with every release. This should give users a light version of their samples.



I wouldn't mind having that option. I like OT libraries and want to buy more of them (I have BWW and both the ARKs), but the reality is that in order to run a decent template of OT instruments I'll have to upgrade my computer to one with more RAM capacity.

As a Mac user my options are limited at the moment. And so are my funds. This puts me in the position of choosing either A) buying a new computer or B) purchasing more OT libraries. If the option is limited to one or the other then option A is the most logical, considering I can still use my other libraries on an upgraded system, but I cannot use OT libraries effectively on my current system.

How much RAM will I need when upgrading? I would hope that 64GB would be enough to get by. Like I said, I like OT products and someday hope to have a template full of them. But for now, less RAM intensive libraries that require relatively less RAM will win the battle for my wallet.


----------



## meradium (May 10, 2017)

So, would any of the devs may be share a few words about how they plan to address this or why that is not possible at the moment?

I would be really curious to know.

I myself just invested heavily into an machine upgrade because I found my RAM was not enough... I went from 32 to 64gb... And guess what... I have pretty much used it almost all up again. Going higher would require yet another new mobo etc...

Now I do run a full set of OT samples. BBW + BB incl. Ex1... Should maybe take a closer look at those...


----------



## EvilDragon (May 11, 2017)

C-Wave said:


> So based on your excellent report, since OT's culprit is in the samples then I suggest we ask OT to produce a 16-bit version of their existing 24-bit samples, as Sonokinetic does with every release. This should give users a light version of their samples.



That won't change anything, really, since once you purge the samples, it doesn't matter if they were 16-bit or 24-bit.


OT's culprit is most definitely in the way instruments are built and how scripting is done.


----------



## Critz (May 11, 2017)

EvilDragon said:


> That won't change anything, really, since once you purge the samples, it doesn't matter if they were 16-bit or 24-bit.
> 
> 
> OT's culprit is most definitely in the way instruments are built and how scripting is done.


But we don't play with all purged samples! We play with at least some samples loaded 
So for big template 16 bit samples could mean several gbs free!


----------



## C-Wave (May 11, 2017)

Critz said:


> But we don't play with all purged samples! We play with at least some samples loaded
> So for big template 16 bit samples could mean several gbs free!


This! Plus ED kindly read the post that I actually replied to.. it says differently.
Edit: Furthermore, OT USES NOT JUST 24-bit but 48 kHz, VSL for example 44.1 kHz, does that (48khz) add much to the sample size?


----------



## EvilDragon (May 11, 2017)

Critz said:


> But we don't play with all purged samples! We play with at least some samples loaded
> So for big template 16 bit samples could mean several gbs free!



Ah, you mean that. Then yes, I agree there, at least partially, see the end of this post as to why.



C-Wave said:


> does that (48khz) add much to the sample size?



Not as much as 24-bit vs 16-bit.

Compare this:

44.1k, 16-bit, one minute, mono: *5.2 MB*
48k, 16-bit, one minute, mono:* 5.6 MB
*
44.1k, 24-bit, one minute, mono:* 7.8 MB*
48k, 24-bit, one minute, mono:* 8.4 MB
*
Which is logical, because bit depth decides how many bits is used _per sample_, and sample rate decides how many samples are there _per second_. So obviously, at the same sample rate, higher bitness will take much more space than just slightly increasing the sample rate from 44.1k to 48k.


However, this doesn't mean anything to Kontakt's DFD, because it preloads samples in kilobytes, regardless of sample rate and bit depth (as opposed to, say, Falcon). The only difference would be in patches that don't use DFD, but use Time Machine (anything that loads samples fully).


----------



## C-Wave (May 11, 2017)

EvilDragon said:


> Ah, you mean that. Then yes, I agree there, at least partially, see the end of this post as to why.
> 
> 
> 
> ...


Aah, good point about time machine patches.


----------



## Phryq (May 11, 2017)

EvilDragon said:


> Ah, you mean that. Then yes, I agree there, at least partially, see the end of this post as to why.
> 
> Not as much as 24-bit vs 16-bit.
> 
> ...



Makes me think... maybe 40k, 24-bit is better for patches (I know that Kontakt will still load 6kb, but that 6kb will mean more of the same is loaded, meaning I can actually put the pre-buffer to 6kb). There should be absolutely *0* quality difference in 40k... or even 30k for most adults.

Sometimes I hear *noise* in certain samples (even O.T.). 24-bit just means slightly-slightly less noise than 16bit, and so I'd rather have a 16-bit sample recorded in a silent room, than a 24-bit sample that's not.

Maybe a program that could batch-resave samples as 16-bit, 30k. Use these for composing. When it comes time to freeze tracks, load the 24-bit 48k version (not that it would really make any significant difference).


----------



## C-Wave (May 11, 2017)

Phryq said:


> Maybe a program that could batch-resave samples as 16-bit, 30k. Use these for composing. When it comes time to freeze tracks, load the 24-bit 48k version (not that it would really make any significant difference).


Excellent idea.. why didn't I think of this before!


----------



## sazema (May 11, 2017)

Phryq said:


> Makes me think... maybe 40k, 24-bit is better for patches (I know that Kontakt will still load 6kb, but that 6kb will mean more of the same is loaded, meaning I can actually put the pre-buffer to 6kb). There should be absolutely *0* quality difference in 40k... or even 30k for most adults.
> 
> Sometimes I hear *noise* in certain samples (even O.T.). 24-bit just means slightly-slightly less noise than 16bit, and so I'd rather have a 16-bit sample recorded in a silent room, than a 24-bit sample that's not.
> 
> Maybe a program that could batch-resave samples as 16-bit, 30k. Use these for composing. When it comes time to freeze tracks, load the 24-bit 48k version (not that it would really make any significant difference).



Yes, but then your CPU will die  Because, samples are originally stored at 24, and while you playing you have to do decoding (to lose quality) in real time.


----------



## sazema (May 11, 2017)

We wish realism in our libraries, now we're paying that price  A ton lines of code just to mimic legato, divisi etc... Triple time duplicated samples for RR, and so on.


----------



## C-Wave (May 11, 2017)

sazema said:


> Yes, but then your CPU will die  Because, samples are originally stored at 24, and while you playing you have to do decoding (to lose quality) in real time.


No? This is not real-time encoding or decoding! It will be pre-rendered and stored as 16-bit 32-bit or whatever you chose!


----------



## sazema (May 11, 2017)

C-Wave said:


> No? This is not real-time decoding!



Ah, sorry, didn't notice batch resave :(


----------



## EvilDragon (May 11, 2017)

Phryq said:


> Maybe a program that could batch-resave samples as 16-bit, 30k. Use these for composing.



Except if a library is for Kontakt Player, you cannot get to the samples at all!


----------



## meradium (May 11, 2017)

We were complaining about pure RAM load here but another thing that really drives me nuts is the fact that if you use many Kontakt instances in let's say Cubase or VEP the point you save your project file it takes forever to save.

Then, when you look at the actual project file it is easily several hundred MB. Same when I save my VEP template.

It seems to be completely inefficient.

How can this be? Is this a VST issue? All it should save is a setting file which tells Kontakt to initialize in a given way... It almost seems like each project in carrying a full copy of all its Kontakt instances (except for the samples).

Hence also my need to run VEP parallel to the DAW just to get rid of the unnecessary load and save (!!) time.

I really wonder how people with large in-DAW templates survive (e.g. blakus) Saving a project with something like 128 instrument tracks takes ages. I do quite a bit of regular saving just to be on the save side. With 30s+ of wait time this is prohibitively too long to do so. And that's already on a dedicated SSD!

VEP is a lifesaver here...


----------



## Saxer (May 11, 2017)

meradium said:


> Then, when you look at the actual project file it is easily several hundred MB. Same when I save my VEP template.


If you decouple VEPro the project file shrinks immediately. It then doesn't has to carry all your template information any more. I usually save one 'big' coupled version once a day that includes the template data and work with a slim decoupled copy.


----------



## meradium (May 11, 2017)

Saxer said:


> If you decouple VEPro the project file shrinks immediately. It then doesn't has to carry all your template information any more. I usually save one 'big' coupled version once a day that includes the template data and work with a decoupled copy.



Correct. That's how I use it right now. Guess I didn't describe it well enough


----------



## Ultra (May 11, 2017)

meradium said:


> We were complaining about pure RAM load here but another thing that really drives me nuts is the fact that if you use many Kontakt instances in let's say Cubase or VEP the point you save your project file it takes forever to save.
> 
> Then, when you look at the actual project file it is easily several hundred MB. Same when I save my VEP template.
> 
> ...



1000%

an OT VEPro project file is X amount larger than any other lib from any other dev that I own... for example, I separate out just the BBR trumpet single patches (#1-#3 + a3) in its own VEPro instance and save that as a project file - samples fully purged. File size for the VEPro project for *just the trumpets*: 80MB.

Anything Spitfire, same amount of instruments: 2.6MB

Now, even if OT has much more GUI parameters and CCs etc etc etc, if the settings snapshot is saved as a XML (or whatever) there is no way this should ever be 80MB (for just the trumpets)... but every OT lib behaves like that.

But naturally, the VEPro project saves and file sizes are the least of concerns when we're looking at 30GB+ default RAM footprint for an empty, fully purged library not playing a single sound...

kids in a candy store going bonkers.


----------



## EvilDragon (May 12, 2017)

meradium said:


> Then, when you look at the actual project file it is easily several hundred MB. Same when I save my VEP template.



This is all the NKI data stored in the project file. You want this to happen, otherwise next time you load your project you would have empty Kontakt racks. It's not inefficient, it's how it has to be.


----------



## Ultra (May 12, 2017)

EvilDragon said:


> This is all the NKI data stored in the project file. You want this to happen, otherwise next time you load your project you would have empty Kontakt racks. It's not inefficient, it's how it has to be.


Why ? The only thing it has to store is a patch reference and individual settings (parameter, value). Done.


----------



## Tatu (May 12, 2017)

I suppose the question here is why a pack of data, essentialy what should be text, takes so much space? How many A4's of text could you fill to 80Mb? 115000 or so pages?


----------



## EvilDragon (May 12, 2017)

Ultra said:


> Why ? The only thing it has to store is a patch reference and individual settings (parameter, value). Done.



It's quite a bit more complex than that, as there are more factors in the play here. All engine parameters need to be stored, variable persistence, all the sample references... If an NKI has a lot of all of that, it WILL be a bigger plugin state chunk.

You don't want to have just a reference to the NKI saved, because then all hell breaks loose if that NKI is misplaced or deleted afterwards. This is much safer.


At any rate, OT libraries are unoptimized, pure and simple, regardless of how Kontakt's inner workings are. If other devs can pull off libraries of similar, if not greater complexity, it's obviously possible, but they don't seem to know how to get there :/


----------



## Ultra (May 12, 2017)

EvilDragon said:


> It's quite a bit more complex than that, as there are more factors in the play here. All engine parameters need to be stored, variable persistence, all the sample references... If an NKI has a lot of all of that, it WILL be a bigger plugin state chunk.



tbh, no. the architecture just needs to be done properly. The reason why I can tell u it is poorly done, is because all my samples were purged, and all patches were in *default state*. (only changes from default state need to be saved)

there are coding principles and obviously design patterns yada yada yada... but who knows who is coding these libs, and what their expertise is...



EvilDragon said:


> You don't want to have just a reference to the NKI saved, because then all hell breaks loose if that NKI is misplaced or deleted afterwards. This is much safer.



dialog pop-up, like Kontakt does it, with file browser to provide new path. If user changes the path to the lib, then he will have to provide new path. Again, best practice approach is to use the least amount of resources. The approach you mentioned has zero benefit, other than _*IF*_ the path changes. For all users that do not apply to that condition, their resources are wasted for no reasons. A dev should never assume. Again, best practices.



EvilDragon said:


> At any rate, OT libraries are unoptimized, pure and simple, regardless of how Kontakt's inner workings are. If other devs can pull off libraries of similar, if not greater complexity, it's obviously possible, but they don't seem to know how to get there :/



yeah, unfortunately. I love their GUI and the GUI features and obviously the sound. I just wish they would have managed in 5+ years to optimize their stuff.

Shows you again: hire expert devs, you sell more libs in the long run.


----------



## Phryq (May 12, 2017)

EvilDragon said:


> Except if a library is for Kontakt Player, you cannot get to the samples at all!



Too bad. I wish there were an open-source version of Kontakt.

Would this would though for _non_-player libraries?


----------



## EvilDragon (May 12, 2017)

Ultra said:


> (only changes from default state need to be saved)



Again, wrong, because default state for all controls when they are declared in the script is ZERO, always, until you manually change it (either via a line of code or via user input). You need persistence to store the "default state" of a patch, and this persistence is stored in the NKIs. Consequently, in the DAW project file as well. So, if there are a shitload of persistent variables, it can take quite some space, for various reasons it's not just their binary value.



Ultra said:


> A dev should never assume. Again, best practices.



Best practices are always open for discussion. At any rate, this is how Kontakt works and isn't about to change. Probably ever. Library developers have nothing to do with this.


----------



## Ultra (May 12, 2017)

EvilDragon said:


> Again, wrong, because default state for all controls when they are declared in the script is ZERO, always, until you manually change it (either via a line of code or via user input). You need persistence to store the "default state" of a patch, and this persistence is stored in the NKIs. Consequently, in the DAW project file as well. So, if there are a shitload of persistent variables, it can take quite some space, for various reasons it's not just their binary value.



load the patch (only path needed). then read the NKI (only path needed). (I assume we are now at default patch state). then only re-instate the manual changes made by the user, which is the only thing needed to be stored in a save file.

What u describe (if I understand u correctly) is massively redundant.

But of course, current status quo is what it is and the conversation here is what it should be.



EvilDragon said:


> Best practices are always open for discussion. At any rate, this is how Kontakt works and isn't about to change. Probably ever. Library developers have nothing to do with this.



Disagree. The dev knows the platform before he/she starts coding. An experienced dev working with a specific platform (e.g. Kontakt|Play|etc) knows the caveats of each platform and constructs the best possible architecture for each platform. Again, be considerate of available resources, and choose the least expensive path (expenses === resources).

Here's an analogy: video games for video game game consoles. fixed architecture. max resources are fixed, all the consoles are the same. If the max RAM is 8GB and your game can't take up 16GB. You'll have to manage within 8GB. And the really good devs excel at this. Same what happened in the 80s and 90s with computer games (Commodore|Atari|etc). Very limited resources, yet some of the devs squeezed some unbelievable stuff out of these machines, because there was no other way other than being very, very smart and efficient. Coding for the platforms.

Compared to what we have here: (some of the devs are) amateur coders like kids in a candy store going crazy. No consideration. Arguments: just buy more RAM.

If you take the small chamber OT orchestra (BST|BWW|BBR|BPC), load all single patches, purge all samples, what would be default RAM footprint. 80GB ? 100GB ? *Nobody is playing a single sound.* It doesn't make any sense. And I personally use OT mostly for layering.

The disconnect that I see with OT: I love their approach of Capsule (innovating, thinking outside the box, pushing the edge), like their GUI and for sure their lib features. Sound is great. All of this is very professional. 

The handling of resources is not. 

Get somebody who understands how to optimize your application for Kontakt. Users will love you more and you'll sell more product.

A target: BBR with all single patches loaded, all samples purged === 10GB default RAM footprint.


----------



## EvilDragon (May 12, 2017)

Ultra said:


> load the patch (only path needed). then read the NKI (only path needed). (I assume we are now at default patch state). then only re-instate the manual changes made by the user, which is the only thing needed to be stored in a save file.



After reading the NKI, you're not at the default patch state, not until variable persistence is read out! This is where you're missing the point.



Ultra said:


> What u describe (if I understand u correctly) is massively redundant.



-_- It's not redundant, it's how things NEED to be. By just loading an NKI and not taking persistent variables into account, you get a big fat nothing - all controls would be zeroed out, and what you saved wouldn't apply at all. This is why variable persistence is there - to store the scripted parameter values to the patch. They are absolutely necessary, not redundant.

You cannot just store "changes that user made" and hope for best for other parameters. ALL of them need to be saved, regardless if they were changed by the user or not.


Did you ever do any scripting for Kontakt? I get the feeling that you didn't, otherwise you'd be fairly acquainted with the concept of variable persistence and why it's absolutely necessary for a lot of KSP-releated things.


----------



## Ultra (May 12, 2017)

Ure looking at it from a different angle. Ure explaining current procedure. I'm stating one way of improving it. Clearly it would need a change in the platform and then the libs and then possibly VEPro.

But, just to be clear: when u load a patch and play with it, Kontakt loads the NKI and initiates all required variables. It does it automatically so u can use the patch. THAT is the default state. No need to save that state (!!!), if u don't make changes. Ergo...... A smart program only saves deviations from the default application state.


----------



## EvilDragon (May 12, 2017)

Ultra said:


> But, just to be clear: when u load a patch and play with it, Kontakt loads the NKI and initiates all required variables. It does it automatically so u can use the patch. THAT is the default state. No need to save that state (!!!), if u don't make changes. Ergo...... A smart program only saves deviations from the default application state.



An awful LOT of things would be broken if it was changed to work that way. It's not going to happen! And I'm going to quote explanation from the old KSP reference now, that is pretty clear cut:



KSP Reference said:


> Load the script and find a nice combination of Interval and Velocity for your upcoming musical masterpiece. Save the patch (or your project if you're working in a host sequencer) and reopen it: all your settings in the script module are lost!
> 
> How come?
> 
> ...




Bottom line. It cannot work just by storing the differences. The script needs to know WHICH variables need to be stored, and which aren't important and can just be defaulted to 0 or whatever initially defined value.


This is not a new concept really. Lots of other plugins work in much the same way.


----------



## Ultra (May 12, 2017)

sure, I never said this is not how it currently is. Like I said: current state.

point is: it is a very flawed, very inefficient concept. it does work, *at a cost*.

In an optimized system, only deviations from default are needed to re-instantiate a previous state.

And that concept, has been around for 1 gazillion years. Matter of fact, at the very latest, with the advent of XML and Json (etc) way over a decade ago everybody started implementing that.

As an evolution, this is how current web apps operate with React, Redux etc. Only deviations from current app state are pulled.

Like I stated a few pages ago: Kontakt's architecture is 10 years behind.

Which explains some devs problems with the platform, but - if the dev is not an amateur - the dev knows this, and he architects the NKI file with that in mind.......... or provide an alternative, less expensive solution (bare bones optimized patches).

If the large majority of peeps would use a Mac with a max of 64GB RAM and VEPro would not exist, then these peeps could NOT even _*just load*_ a fully purged, all single patches full OT orchestra. And obviously they could never play the orchestra.

And in that world, I guran-freaking-tee you OT would get their shit together and optimize things. THAT is the point. They are lazy and far off. And we're paying the cost for that.

Alright, as redundant as this has been stating the same thing 100 times. It is what it is, I doubt it will change with OT, and probably take 20 years for Kontakt to improve anything.

Very mindboggling though seeing people defending the current, very flawed status quo.


----------



## EvilDragon (May 13, 2017)

Ultra said:


> In an optimized system, only deviations from default are needed to re-instantiate a previous state.



Yes but what IS the default state? When you open a patch, every damn scripted variable gets initialized. Change the values, save the patch, those changes are GONE, because variables aren't persistent. Or are you implying that each and every variable should be stored, sort of automatically "made persistent"? That would be even more inefficient, because guess what - not only UI controls need total recall. Often just regular variables and arrays need total recall too. And if Kontakt auto-persisted each and every change in each and every value (as it would happen when tweaking the UI controls or playing some notes, depending on what the script does), it would blow up the persistence block even more.

Also, if Kontakt's architecture is "10 years behind", how come UVI Falcon works the same way? You need to define a variable persistent if you want to store it in the patch. It's called serialization and a shitload of programs are using it.



I think where you're wrong is, you're talking about websites and stuff. Those things rely on databases to run. Database is by its design fully persistent already - it stores EVERYTHING necessary for things to work. Of course only storing the changes is more efficient then. But, databases don't have a "runtime" that Kontakt has. So, things need to be more particular here.


----------



## Ultra (May 13, 2017)

no, the principle concept is the same.

the default state (in my example approach) is the state that the patch is in after it has loaded (instrument, NKI, all dependencies) - this loading process is always the same and results in the same state (default state of the patch). After it has loaded into default state, you could then apply the changes made by the user (which were saved), to for example change knob 1 etc.

and websites don't rely on databases, server side code can interact with a db (obviously) to pull/store data, but not required at all.

doesn't matter, fortunately there are workflows to make it work, as annoying as it can be. 


Btw, did anybody happen to hear back from nightwatch/Steve and get to know what the "extra step" is to load any lib without extra RAM allocation ?


----------



## EvilDragon (May 13, 2017)

Ultra said:


> Btw, did anybody happen to hear back from nightwatch/Steve and get to know what the "extra step" is to load any lib without extra RAM allocation ?



Use disabled tracks feature, if the DAW provides it?


----------



## Ultra (May 13, 2017)

he's using DP (so do I) so that feature is not available to us, and I interpreted it that the patch would be live (usable), but quite possible I misunderstood his post


----------



## Phryq (May 13, 2017)

EvilDragon said:


> Use disabled tracks feature, if the DAW provides it?



Good point. You could actually have every instrument you own in your template, simple disable the tracks, and enable as needed (purged).

I've made hot-keys to enable/disable FX on selected tracks. Have to wait about 10 seconds for it to load, but not too bad.


----------



## Ashermusic (May 13, 2017)

Man, in t never fails to amaze me how some people spend a whole lotta time complaining about how some things could be better, should be better, etc. when they could be making music.

Just saying.


----------



## SimonCharlesHanna (May 13, 2017)

Ashermusic said:


> Man, in t never fails to amaze me how some people spend a whole lotta time complaining about how some things could be better, should be better, etc. when they could be making music.
> 
> Just saying.


Unfortunately I can't because Orchestral Tools took all my ram


----------



## Phryq (May 13, 2017)

Ya, I'm spending too much time on here instead of making music.


----------



## C-Wave (May 13, 2017)

Ultra said:


> sure, I never said this is not how it currently is. Like I said: current state.
> 
> point is: it is a very flawed, very inefficient concept. it does work, *at a cost*.
> 
> ...


Ultra, IT IS a state of mind.. not a state of knowledge. To elaborate, see what they do with samples:
1. Berlin Strings: Basses has these known issues for ages. Can only be fixed by recording the samples, no way around it. Their reaction : we're working on it..NO YOU'RE NOT!
2. Berlin Strings: First chairs has these wrong samples that need to be re-recorded. Their reaction: we're working on it..NO YOU'RE NOT!EXIT: EDIT: yes you did update at no cost.. kudos! Looking forward to doing the same with Woodwinds exp. A; still waiting.
3. Nocturne Cello: lots of wrong samples .some of them can be fixed in editing, others need to be re-sampled. Their support reaction: yes we acknowledge them.. their support reaction few months later: what problems, no problems, Cello is perfect!
4. Ark 2: To be realistic here, I am talking about re-editing several instruments; not the noise issues; waiting for Godot.
5. Berlin Brass? Couple of months later and they fix it! they know it's crucial to their image.
So you see? In the same way they won't do anything about anything unless they can see that their image is tarnished. It's a management policy, not a technical aspect of the problem.


----------



## C-Wave (May 13, 2017)

SimonCharlesHanna said:


> Unfortunately I can't because Orchestral Tools took all my ram


Do like I did.. spend double the money by re-buying everything all over again from a reputable company like VSL; who actually trust their products enough that they allow them to be resold.


----------



## Ultra (May 13, 2017)

C-Wave said:


> Ultra, IT IS a state of mind.. not a state of knowledge. To elaborate, see what they do with samples:
> 1. Berlin Strings: Basses has these known issues for ages. Can only be fixed by recording the samples, no way around it. Their reaction : we're working on it..NO YOU'RE NOT!
> 2. Berlin Strings: First chairs has these wrong samples that need to be re-recorded. Their reaction: we're working on it..NO YOU'RE NOT!
> 3. Nocturne Cello: lots of wrong samples .some of them can be fixed in editing, others need to be re-sampled. Their support reaction: yes we acknowledge them.. their support reaction few months later: what problems, no problems, Cello is perfect!
> ...



Couldn't agree more, that is why I said what I said repeatedly 

If they'd taken the time after BWW, receiving all that feedback, to sit down and revise their lib architecture around the pitfalls that Kontakt has, and come up with an optimized system (or as I said at least provide a bare bones patch as a resource saving alternative - there's various ways of tackling this), then all libs after that (BST|BPC|BBR) would have benefited from that. And all of us.

But you need somebody who knows what they're doing as Capsule is a larger implementation.


----------



## Phryq (May 14, 2017)

Something I don't get... Chris Hein's system can do everything Capsule can do, and even more. But his instruments are not taking up these insane amounts of RAM.


----------



## SimonCharlesHanna (May 15, 2017)

Phryq said:


> Something I don't get... Chris Hein's system can do everything Capsule can do, and even more. But his instruments are not taking up these insane amounts of RAM.


That was the same issue I brought up with VSL's VIP. In fact VIP is the most full featured, most stable player on the market for a fraction of the foot print. I just don't understand.


----------



## Phryq (May 15, 2017)

SimonCharlesHanna said:


> That was the same issue I brought up with VSL's VIP. In fact VIP is the most full featured, most stable player on the market for a fraction of the foot print. I just don't understand.



Can VIP make any articulation legato? Switch articulations mid-note? Note-heads? Scripted vibrato? Body IRs?

On thing Capsule can do that Chris Hein's doesn't - 4 way articulation x-fade. Though I think it's not really that great.

I've never used VIP, but I'd be pretty shocked if it could do all that.


----------



## C-Wave (May 15, 2017)

Phryq said:


> Can VIP make any articulation legato? Switch articulations mid-note? Note-heads? Scripted vibrato? Body IRs?
> 
> On thing Capsule can do that Chris Hein's doesn't - 4 way articulation x-fade. Though I think it's not really that great.
> 
> I've never used VIP, but I'd be pretty shocked if it could do all that.


I actually have a slightly different stand with Capsule; VIP CAN save you money in hardware (Ram) while making you pay, literally, with their expensive VI's. But VSL NEVER produced an unfinished library to the market.THAT is my issue with OT; I refuse to be anybody's undeclared and unwilling PAYING beta tester.


----------



## Confuzzly (May 15, 2017)

For the sake of balanced discussion, I use OT libraries every day (except for brass which I don't own yet), and have never had an issue. I think they are fantastic and certainly wouldn't call them unfinished or anything like that.

With that said, they do use a lot of ram, and with OT having pretty much sampled an entire orchestra, I would love to see them focus on optimizing Capsule's performance.


----------



## Critz (May 15, 2017)

Phryq said:


> Can VIP make any articulation legato? Switch articulations mid-note? Note-heads? Scripted vibrato? Body IRs?
> 
> On thing Capsule can do that Chris Hein's doesn't - 4 way articulation x-fade. Though I think it's not really that great.
> 
> I've never used VIP, but I'd be pretty shocked if it could do all that.



I'd say it's not Capsule to do that things, but Kontakt. OT just came out with this capsule thing, but actually every orchestral library for kontakt has it's own scripting, even if they don't look for a cool name for it. I want to be clear, I think OT libraries are pretty amazing, the only libraries with a natural approach similar to VSL (and with a better sound for the moment). But this capsule thing is a non-sense, imho.

The 4-way articulations it's almost useless. A 2-way cross fading articulation can be done in VIP for sure. 
Switch articulation mid-note? Yes, from any articulation you can have legato switching to the legato articulation.

Could you explain the Body ir and scripted tremolo? can't find anything online, thanks!


----------



## Phryq (May 16, 2017)

Critz said:


> I'd say it's not Capsule to do that things, but Kontakt. OT just came out with this capsule thing, but actually every orchestral library for kontakt has it's own scripting, even if they don't look for a cool name for it. I want to be clear, I think OT libraries are pretty amazing, the only libraries with a natural approach similar to VSL (and with a better sound for the moment). But this capsule thing is a non-sense, imho.
> 
> The 4-way articulations it's almost useless. A 2-way cross fading articulation can be done in VIP for sure.
> Switch articulation mid-note? Yes, from any articulation you can have legato switching to the legato articulation.
> ...



I agree the 4-way articulations are pretty useless.

Switch articulation mid note, what I meant is holding a note, e.g. sustain, and press a key and it turns into a trill seamlessly, then let go and it becomes a sustain again. Christ Hein and Embertone both allow this (Capsule can do it with it's x-fade, but personally I think the Hein/Embertone works better).

So VIP allows e.g. legato transitions with the portato/tremolo/trill samples? Hein allows legato between literally *any* samples, so I think he wins here. Looking at the VSL site, it seems only certain articulations are legato.

Sorry, I meant Scripted _vibrato. _So with Embertone and Hein you can use CC to control vibrato speed/depth, and it actually sounds quite good. Hein uses sampled vibrato as well, whereas Embertone is entirely scripted (but their scripting does sound good). They also have scripted sordino (meaning *all* articulations can be sordino, without any more sample-overhead). And Embertone will allow you to change bow-position using phase-aligned samples of the bow at different positions.

Body IR - Hein has a short IR option for his strings, which changes the 'body tone'. Because his samples are ultra dry, these tiny IRs allow you to give the instruments different tones (like, a larger/darker/woodier violin, or a brighter, more nasal violin).


----------



## SimonCharlesHanna (Aug 9, 2018)

FYI I upgraded to 128gig.

My full berlin template is about 70 gig purged haha.

start utilizing all the mic positions and you're talking about a dizzying amount of ram usage. 

It's awesome having everything at your fingertips though :D


----------



## C-Wave (Aug 9, 2018)

SimonCharlesHanna said:


> FYI I upgraded to 128gig.
> 
> My full berlin template is about 70 gig purged haha.
> 
> ...


Hi,
Thanks for reporting that.
1. can you please elaborate (list) those OT libraries that used 70GB in Ram?
2. when you say purged, do you mean no mics whatsoever, or with one mic. active, if you have one mic active then which one?
thanks.


----------



## SimonCharlesHanna (Aug 9, 2018)

C-Wave said:


> Hi,
> Thanks for reporting that.
> 1. can you please elaborate (list) those OT libraries that used 70GB in Ram?
> 2. when you say purged, do you mean no mics whatsoever, or with one mic. active, if you have one mic active then which one?
> thanks.



All BS, BB, BWW, BP (perc), Harps, ARK Choirs. Tree mics originally but I've just changed so all mics are loaded but muted (for easier mixing). I'd have to check to see if the ram footprint is bigger now.


----------



## C-Wave (Aug 9, 2018)

SimonCharlesHanna said:


> All BS, BB, BWW, BP (perc), Harps, ARK Choirs. Tree mics originally but I've just changed so all mics are loaded but muted (for easier mixing). I'd have to check to see if the ram footprint is bigger now.


Sorry , more questions:
1. “..but muted”.. you mean not purged, just muted? does muting without purging affect ram load?
2. These above are just the main libraries.. no expansions, correct?


----------



## SimonCharlesHanna (Aug 9, 2018)

C-Wave said:


> Sorry , more questions:
> 1. “..but muted”.. you mean not purged, just muted? doeas muting without purging affect ram load?
> 2. These above are just the main libraries.. no expansions, correct?


Expansions included (except brass additional & winds solo 2)

*everything *is purged, but I have activated all mics (turned them on). I haven't checked the ram usage since I've done that. Next time I have a chance, ill let you know.


----------



## TimCox (Aug 9, 2018)

I'm running 32gb of ram using BB+mutes and BWW+EXP A and sitting at about 82% at all times. I'm also using CSS, LADD, and some HOP.

It can bog down occasionally when it gets heavy but I'm usually doing just fine


----------



## galactic orange (Aug 11, 2018)

SimonCharlesHanna said:


> Expansions included (except brass additional & winds solo 2)
> 
> *everything *is purged, but I have activated all mics (turned them on). I haven't checked the ram usage since I've done that. Next time I have a chance, ill let you know.


FWIW I’d like to know the RAM usage for that setup too.


----------



## jononotbono (Aug 11, 2018)

Can someone tell me how much SSD storage I would need to have the entire OT Berlin Orchestra?


----------



## meradium (Aug 12, 2018)

Just add up the numbers provided on their site.

The far bigger question would be how much RAM you would need to run it... If there is one thing I hate about any OT library I currently have (BWW Revive, BB, BB Add. Instruments) it is their ridiculous RAM usage.

They always claim its because of their amazing feature set (like what? layering, articulation blending?...) which I frankly do absolutely not use... I just want to be able to load the nice sounding patches as is. I don't need any GUI whatsoever as well.

Until that is changing I will definitely stay away from any of their libraries. They are just terribly inefficient.


----------



## jononotbono (Aug 12, 2018)

meradium said:


> Just add up the numbers provided on their site.
> 
> The far bigger question would be how much RAM you would need to run it...



Was hoping someone who owns it all could have just said by the time I woke up. I guess when I have some spare time I’ll bother to do so. Haha!

As for RAM. Just build more computers. 10 slaves each with 128gb of ram should do it. “Do it” meaning running everything decent in existence.


----------



## meradium (Aug 12, 2018)

Turning into the next HZ?


----------



## jononotbono (Aug 12, 2018)

meradium said:


> Turning into the next HZ?



That’s impossible for anyone but him. Still, I do want a few more computers!


----------



## SD (Aug 12, 2018)

jononotbono said:


> Can someone tell me how much SSD storage I would need to have the entire OT Berlin Orchestra?



Hi, 

I have all the main libraries, expansion packs and also "The Orchestral Grands" installed on one of my SSD's and they take 831 GB. 

I don't have BOI 1 or 2 though. Those add extra 10GB / library.


----------



## jononotbono (Aug 12, 2018)

SD said:


> Hi,
> 
> I have all the main libraries, expansion packs and also "The Orchestral Grands" installed on one of my SSD's and they take 831 GB.
> 
> I don't have BOI 1 or 2 though. Those add extra 10GB / library.



Do you ever have problems streaming everything from the one SSD? I was thinking of splitting the OT libraries onto different SSDs


----------



## Heinigoldstein (Aug 12, 2018)

jononotbono said:


> Do you ever have problems streaming everything from the one SSD? I was thinking of splitting the OT libraries onto different SSDs


If you're really running a dozen or more maschines (I don't want to pay your electricity bill by the way), I'ld recommand to split up the libraries on different computers. The Berlin Series is very demanding on RAM and CPU, so you can easily run into troubles, especially when you use more than one mic position. Strings on one, Woodwind on the next and so on. I'ld love to be able to do this.


----------



## SD (Aug 13, 2018)

jononotbono said:


> Do you ever have problems streaming everything from the one SSD? I was thinking of splitting the OT libraries onto different SSDs



I got most of their libraries just recently and haven't really tested yet. Actually my plan was never to install them all to just one drive but to split them as you were thinking of.
The reason they are all on one drive is that I'll soon start building a new template with VEPro. Before that I need/want to do some library reorganization. That will take time... I just couldn't wait until then to test all those OT libraries, so I got a new SSD and installed all of them there for now.


----------



## jononotbono (Aug 13, 2018)

SD said:


> I got most of their libraries just recently and haven't really tested yet. Actually my plan was never to install them all to just one drive but to split them as you were thinking of.
> The reason they are all on one drive is that I'll soon start building a new template with VEPro. Before that I need/want to do some library reorganization. That will take time... I just couldn't wait until then to test all those OT libraries, so I got a new SSD and installed all of them there for now.



Yeah, you’re gonna definitely need to split the libraries. Voice count will become a problem. Bt then that depends on how densely orchestrated a piece is of course.


----------



## gst98 (Jul 29, 2020)

Sorry for reviving an old thread but I was having some the same issues with Capsule. I've been building a big Logic template (disbaled) and so the RAM was so much of the problem, but I've found my empty template file is 800mb with 400-ish tracks (across many developers). As soon as I've saved a project I'm working on a couple times it gets to be 2-3GB's.

So I thought I would do some tests an made several 1000 track templates where there was one articulation (1mic pos) in each kontakt instrument, all purged and then disabled/unloaded with Logic, and I used the Logic clean up to minimise the fies size as much as I could. I then repeated with the mutli version.

1000xSpitfire Longs = 391 MB project file
1000xBerling Longs = 2.62 GB project file

1000xSpitfire Multi = 850 MB project file
1000xBerlin Mutli = 8.47 GB project file

1000xJXL Brass Mutli = 92 MB project file

So it seems Capsule is also the culprit for enourmous save files, but the SINE player, as well as being so much faster than Kontakt uses tiny amounts of resources. I don't have a spitfire player product but it would be interesting to see how that compares.

I think to minimise the the files size I should try to use VEPro again as to not save it in the Logic file. But I've found Logic to be so much more efficient on the CPU.


----------

