Yup - just emphasizing what @Neil_Durant is saying: when working with large samplesets live, there is only one real strategy: load all samplesets at the beginning of a set (or at least the cached part for direct-from-disk libraries) and then use routes or Kontakt’s bank feature to switch between them.
Yes, this means having oodles of RAM installed - depending on the size of your libraries - but you don’t really want to have to wait for your big studio grand piano library to load between songs. And to pre-empt any feature requests: no, you also don’t want your machine to be busy pre-loading the NEXT song whilst you need every little bit of CPU and disk performance for your glorious solo you are playing at the moment…
The only real other alternative - if your sample sets are small(ish) and you have a super-fast SSD is to actually use Cantabile’s “entire bank” state behavior and have Kontakt load the relevant sample sets for a song on “Song Load” via a state change - but again, don’t change states DURING a song - having Kontakt load a new sample set puts a non-trivial load on your system, which you want to avoid during a song.
Thank you for the tips how to optimize RAM usage for Kontakt.
In our forum I saw a video, how to Kontakt optimization…
I guess, you know the video.
Now I followed each tip in the video and made them in Kontakt under C3.
There are also included purge, reset markers and update sample pool.
I have in my test setlist 20 Kontakt instances in a linked rack.
After the optimization settings I updated directly the states. Then
I saved all before leaving/closing C3.
Then I reopen C3 and the setlist with the optimization my RAM
is as high as before the optimization even the samples are nearlly
empty on each instance.
Is it on the end the Kontakt instance itself, which needs so much
RAM unless, which patch/multi I load?
In addition to my last posting:
Then I look through the engine Memory, it seems, that the optimisation settings were successful, cause
the results you see in the screenshot are the results of preloaded 20 Kontakt instances.
Or is it from you point of view much to high?
I have no glue, why on preloading of the 20 Kontakt instances again 11GB RAM is loading (I can follow
it in my task manager, that each loaded instances causes up to 1GB RAM)…as before
without the settings.
Is my workflow in using the 20 Kontakt instances wrong in using linked racks for?
not exactly sure but as far as I understand the method he describes in the video is meant for use with defined notes playing. Kontakt simply learns which notes were not used by listenig to the midi file and kicks them out of RAM. Are you sure this is your intention here?
Another aspect that’s annoying for me (and Neil already asked this above): is it really a hundred different sample sets you are loading or could it be that the same kontakt sound is loaded several times but with differnt settings inside (f.e. EQ settings, filters, reverb,…)? If this is the case there is possibly a way to handle this more elegant:
Cantabile has the possibility to manage those parameters separated from sample content which are supported as “host automation parameters” by the plugin. So you can still turn entire banks off but activate this parameters individually if this instrument is stored inside a linked rack.
The advantage is: if you preload everything you only need to load the sample content once but can store as many diversifications of this instrument as you like.
The bad news is: it really depends on the library if and which parameters are offered by the instrument.
Anyway: if this could be a possibility to solve your problem I (or any of the other mates here) will easily describe how to do this.
I like to use original multi patches.There are different instruments behind on each Multi with different
sound settings and so on.
It would be a hard manual work to reproduce all these multis on my own including the “risk”, that
the reproduced multis are not the same as the original version.
Then on top to reproduce/collect/delete not used samples or identify, which multis have which common
sample would also be a hard work.
The only way I see so far is the workflow you decsribed already here by putting all “best of” multis/instruments
in one instance of Kontakt as own multi. But this is also a hard work…I tried that already. Here could theoretical load
"a lot" of multies/instruments.
Perhaps on the end, the only way, to make it work without invest to much effort, would be to upgrade my
RAM from 16GB to…
But I’m honest: I’m working only 2-3 weeks with Cantabile 3. I’m sure, that I never know so far all best the
workflows in using songs, rack stats and so on. Perhaps there are some opportunities in order to get near
to my wished workflows
I use in Kontakt e.g. nearlly all Epiano libraries, where I want organise the “best of” multis/instruments.
Same with e.g. orchestra libraries.
I know: this was not orginal the plan with C3
But my way of using synthesizers is mostly improvised playing and not play a fixed song.
What I do: I also combine several instances in order to have e,g, arpeggios or rhythm/beat or guitars included.
No problem, and: C3 is made for whatever you want to use it for😉 so no “no gors” or the like. In case of your personal workflow I’d suggest: get yourself a ton of RAM memory and don’t be late (as I was) as next technical generation of RAM is knocking on the door and it will be difficult to buy older ones then.
This seems to be the problem here - the multis that you are using are probably built for studio work, where you can render or freeze instruments if they become too memory-hungry. Trying to have a number of them instantly available for live work is a pretty big challenge.
Building a live set requires a different approach - managing the available resources to optimize latency, avoid drop-outs and minimize switching times. This means that you’ll have to cram a lot into your available RAM; some re-building of your setups for live use is probably unavoidable (unless you have unlimited RAM and processing power).
But let me suggest an alternative way to address your issues with sample-based instruments and Kontakt instances, which is to differentiate between the actual sample sets and their processing afterwards. Let me give you an example:
In my main piano rack, I use XLN Audio Addictive keys as my main piano. I use only one sample set with it (a studio grand without any effects or EQings added), which is loaded with the rack and never changed. But I have a powerful effects chain after it (compressor, chorus, EQ, delay, reverb), which allows me to create numerous differen piano rack patches from this same piano sound without ever having to change the sample set, simply by changing effects setting in the processing chain.
So maybe, you can reduce your live setup to a set of very few large sample sets that stay static and change their sounds by adding flexible effects processing, which can be re-configured easily. If there are some smaller song-specific samples, you can easily load those between songs via “whole bank” state behavior in Kontakt, but as long as your large sample sets stay constant, you’ll be in good shape.
But yes, this means that you’ll have to re-work your sounds - you can’t simply slap your favorite Kontakt multis together. But as I mentioned: a live VST rig is a completely different beast than your usual studio setup; investing some time to build something that works for the rigours of live work will pay back on stage! Put together something robust and easy-to manage - this will give you more peace of mind and make you enjoy playing music instead of dealing with loading times and quirky performance
And TBH: I don’t think you need such a differentiated sound palette for live use as you would want to have in your studio. Yes, I have about 10 great piano sample libraries for the occasion when I want to find just the right one for a song I’m creating - but for stage use, I’m perfectly fine with my Addictive Keys grand piano and about 10 different Comp-EQ-Chorus settings and song-specific flavoring of reverb and/or delay. Simplify, simplify…
I’m probably misunderstanding, but are you saying you’re using lots of factory multis? And potentially multiple instances of Kontact with the same multi, in order to achieve different settings/mix etc? If so, all your RAM is likely being eaten up by having the same sample sets loaded multiple times.
If so, you could consider using one Cantabile rack per Kontakt multi, and for each song that uses it, use Cantabile to automate all of the editable parameters of it, such as the mix levels, EQ, whatever else you edit. The automation could be stored in rack states, so you just choose which rack state you want, and the Kontakt multi will be reconfigured accordingly, instantly. That way you’d get lots of variations for different songs, while re-using the same underlying loaded sample set. You should also delete any parts from the multis that you know you never use.
Additionally, you should also consider using less layering at the Kontakt multi level, and handle that layering at the Cantabile level (with multiple racks). That would allow Cantabile to do more intelligent management of sample loading/re-use than Kontakt can. It would also open up more Cantabile features for handling the different parts within those multis (levels, splits, MIDI filtering, audio routing, effects etc.), which is difficult if the multis are caged up inside an instance of Kontakt.
16Gb is actually quite a lot of RAM. The songs I play with Cantabile invariably have anything up to 15-20 instrument plugins each, plus a load of effects, some very large piano sample sets, and including lots of Kontakt racks, and a typical setlist has up to maybe 20 songs. I never seem to get close to my 16Gb RAM limit.
I agree with @Torsten - if you put some work in to devise your live setup carefully, it’ll be orders of magnitude better and more flexible, than if you just throw multis together until you run out of RAM. It’ll take some work, but you’ll end up with something incredible.
In addition: today the most multies in Kontakt for me are perfect. I make only a few number adjustments on them.
Sometimes I only add a rhythm instrument or pad or Instrument.
The thing with the mulites is: there are loaded on same time up to 10 instruments, which build e.g. an
orchestra or a soundset of pads, effects, rhyhtm.
As I understood your workflow, I have to rebuild each multi on my own way in order to reduce samples.
But, if come on the end again to up 10 instruments and the next multi would use another 10 instruments,
which weren’t in the multi before, how could I reduces the no. of samples in total?
My live playing approach is not for stage. Is more, let me inspiring to play improvised by my best of multies, patches, instruments…combination of pads, rhythms and so on…depending on day, moment, mood…
…want I play today orchestra, chill out, smooth/soul jazz, rock and so on.
I had that perfect solved over the years with C2. But there I had loading times on each switch. And C2…I wouldn’t say…it’s meanwhile outdated, but more “old fashioned” And C3 has quit a lot of general improvements and is very good and clear structered.
Your sure right in: how many patches, songs, states we need really on the end!? It’s like the same with hearing music.
My collection of music is raising day by day. Not each title I like from day on, but perhaps on day two Means, I guess over all my VSTi I have estimated 20.000 presets incl. my hardware synthesizers. “Only” around 300-400 I like and play
with them around or combine them with arpreggios or rhythms.
Yes, I use lots of Kontakt factory mutlis. In my several Kontakt instances I have on each song or state different multies.
The Kontakt libraries have mostly quit a lot of different instruments. So the mutlies mostly use different instruments behind.
Yes, you’re right: this is the reason, why my RAM struggles in loading up to e.g. 20 instances. Up to 10-15 is not a problem.
Sounds interesting with the layering. So far have absolutly no experience in working with layers, how have to use/build.
So I have to find out, whats behind layering.
The thing with the RAM: I ordered so far additional RAM; comes next week. I don’t know really, what I gain on the end with the upgrade. But I want to be sure, that I did the maximum on technical issues.
Again: what me absolutly surprised is the optimatisation video (mentioned above), where I gained after “hard” work nearlly nothing in saving RAM.
Suppose as a small example, you run two multis. Multi A uses presets 1-10. Multi B uses presets 5-15.
Currently, loading both multis will load 20 sample sets (1-10 and 5-15). But if you have each preset in a separate rack, you’ll only be loading 15 sample sets. You’ve already cut down the RAM usage by 25 %, with only two multis.
If multi C uses presets 15-20, you’ll now be loading 20 sample sets instead of 30, and so on - a 33% RAM saving. If multi D uses presets 1-10, you get that for free using the rack method, whereas it’s another 10 sample sets to load in the multi method. Now you’re using 20 sample sets instead of 40 - a 50% RAM saving.
Sure, for multis that have no presets in common, you won’t save anything (although you’ll gain flexibility). But I imagine in a lot of cases, your multis have some presets in common.
It will be quite a bit of work to set up these racks, but you’ll find that once you have them set up, you can throw them together quickly in a song, just as quickly as getting a multi and customising it. And of course you can benefit from great flexibility - suppose once day you discover a fantastic new trombone plugin. You could just swap your Kontakt trombone plugin for the new one, in your trombone rack, and all your songs will immediately benefit from it - no need to go through dozens of multis, making changes.
Don’t forget also that you can select/copy multiple racks in one song, and paste them into another song. So you can effectively re-use these “Cantabile multis” quickly.
@Neil_Durant: looks like we think very much along the same lines - couldn’t have explained things better!
@Bladerunner: it looks like you are very much inspired by the multis in your Kontakt library, which I can really understand: some really creative programmers have built amazing combis for Kontakt - tons of fun to just sit and improvise with them!
If it’s too much effort for you (or just too boring and un-creative )to re-build them, then there’s probably no way around living with longer load times (unless you have unlimited RAM) - you’ll probably not be able to preload all your Kontakt setups. What you can do then to at least reduce the pain is spend as much money as you can afford on
oodles of RAM
a super-fast SSD (preferrably M.2, not SATA) exclusively for your sample libraries
Then you could just work without the pre-loading function and live with the load times between songs (and hope for the next technology innovation to come along and further reduce load times).
Slightly off topic, but hopefully relevant- shouldn’t a SSD drive be able to function as fast as RAM for all intents and purposes? I’ve never understood why it’s slower than any other solid-state memory, unless it’s a bottleneck in the interface- in which case, why not have an internal interface such that a pc just treats it as RAM. You’d think a program like Kontakt could just set a pointer saying “the data is located HERE” basically and then go get it just like fetching from RAM. What’s the deal
@Torsten: Kontakt is not the most used VSTi in my collection. I guess Kontakt has a share in my presets/patch “best of” collection about max. 20%. The other 80% are spread over around 20 VSTi. But, Kontakt is important and nearlly the one and only, then I like to play orchestra’s (beside e.g. Vienna).
un-creative is not my approach! …but, if I look through weeks of effort, I think about a workaround, before I start beginning reworking all my multies.
And yes…I know: perhaps in some weeks a come to the point in order to accept loading times then switching through Kontakt multies…(as today in C2)
yes…this is actual my plan…extend RAM and install a third SSD
The processor doesn’t see the contents of an SSD drive as an area of memory, to be accessed by a pointer etc. It appears as a disk hardware device, and needs to be accessed via code that deals with partition tables, file systems, fragmentation, and all that awful stuff. In contrast, a single CPU instruction can go straight to a memory location in RAM and pick out the contents.
But on top of that, SSDs use flash memory that is inherently slower at the hardware level than the kind of RAM you have in your PC. And for write speeds, SSDs require writes to erase an entire block at a time before writing to it, and also have to deal with wear levelling, whereas there’s no such requirement for writing to RAM. You’d need something akin to a BIOS in order to manage this, instead of being able to literally wire direct from CPU to RAM, and access each byte individually and directly.
As for why you can’t just have an internal interface that allows the PC to treat the SSD memory as RAM, processors, motherboards and operating systems all have their own limitations on the maximum addressable RAM size, which tends to be less than the size of a decent SSD.
Still, who knows what might be possible in the next few years?
It does seem that with the price of solid state memory now what it is the architecture of the pc should be changed so that large solid state storage devices appear as RAM and not a form of external storage. Even if it’s slower. Of course, I remember when 640K was the limit and being able to break that barrier and install a full Mb of RAM was a true “holy s**t!” moment lol
