Opening songs from a set list is getting slower over time

Cantabile
#1

I think I know where the problem is, but hoping that someone can confirm.

Recently (the last 3 months) songs within sets have taken longer to load as a whole. Even ones that I think are simple (e.g., VB3) are taking time. I’m thinking that there’s some interaction between the hogs (Omnisphere and Kontakt).

  • It’s a relatively large setlist (usually @30 songs). We usually play 90-120 minute sets, and with the extra songs (just in case they get called up) it’s around 30 tunes. I don’t want to break it up if I don’t have to.

Things I’ve already done:

  • I preload all the songs in the setlist
  • I am using linked racks to keep the number of instances of plug ins down
  • I do use the media play for some introductory parts(though I don’t think those preload as they are stream from disk)
  • I have about 13 plug ins across all songs
  • Everything is running from an M.2 SSD (2TB ) on a Lenovo, i7 1.8 ghz 4 core processor and 16GB memory
  • I have a couple “go to’s” for often used sounds (Sonivox orchestral strings) that stay loaded with the same sample set and used across multiple tunes.

The most likely subjects?
I have Kontakt and Omnisphere, and while I have them in linked racks, the load time for them leaves something to be desired

Here’s what I’m thinking my next steps are

  1. In a perfect world there might be some sort of diagnostic that runs to capture load times. Especially helpful would be a pointer to the plug in that is taking the longest.
  2. Remove Omnisphere and see if is the culprit
  3. Remove Kontakt to see if it is the culprit

I was thinking that I could preload the most used Kontakt libraries (Session Horns) and Omnisphere patches but I don’t know if updating one slot will cause everything to reload (which could make things worse).

Any other guidance would be helpful

Thanks to the big Cantabile brain
Pat

#2

Hi Patrick

Have you tried using the Profiler under view? Activate it before pre-loading, and it will show you what is hogging the CPU and RAM. An outside program could be active as well, so you can use Windows Resource Monitor to check for that.

Hope this helps

Corky

#3

I haven’t tried the profiler yet, but i will and update the thread.

1 Like
#4

I think you’re right regarding the likely suspects: since Kontakt and Omnisphere are sample-based, it takes some time for them to switch sounds (purge the old samples from RAM, load new ones and configure the patch). Using pre-loaded linked racks is of limited use for this kind of instruments - the main effort isn’t loading the plugin itself (which is addressed by pre-loading) but it is loading the actual samples, which Cantabile can’t do anything about when you change the sample set during a performance.

There are only two directions to make things better:

  1. replace Kontakt and Omnisphere with other, more live-friendly instruments. I use the Korg romplers (M1, Triton, Triton Extreme) for a lot of my bread & butter sounds. Switching sounds is pretty much instant for these instruments.

  2. For those sample-based instruments you reeeeeally can’t do without: load them into individual instances of Kontakt / Omnisphere (in pre-loaded racks) and NEVER change patches on these instances. The overhead of having multiple instances of Kontakt should be manageable compared to the sample sets. As long as you have sufficient RAM to cover all these Kontakt racks in parallel, you should be good.

I use all my sample-based instruments that way - I have individuals rack for Session Horns, for Ravenscroft piano, 300 Grand piano, etc. In all these racks, I keep the instrument instance completely unchanged, so no loading times during performances. The rack states I have may change EQ or effect settings (other plugins inside the rack), but nothing ever touches the sample instrument. Makes for very snappy song changes.

Hope this helps!

Cheers,

Torsten

#5

BTW: my live setup runs at 163 plugins, > 100 songs, with a memory footprint of ca 9 GB. And song changes are at around 1-2 seconds. So, with a bit of careful optimization, it’s possible to have very smooth operation with short switching times.

Cheers,

Torsten

#6

Quick Update:

It is as I assumed - The big ones seem to be Kontakt and Omnisphere loading large samples/patches:

  • Kontakt “Session Horns” (used in 5 or 6 songs)
  • Omnisphere with a couple of common pads

I’m going to do some auditing of them and possible create a second linked instance with multi’s for the most used patches/sample sets. Once I do that I’ll look at the RAM load and determine whether I can live with the overhead for these.

Torsten - Are all of those instrument plug ins? Or are there effects too? Sample players? I’m wondering what the RAM load is with the samples…

#7

Omnisphere is a huge drag on resources. If I can find an alternative for a song I will.

#8

I have Session Horns in my setup as well. Sure, it needs loading when starting my session (needs to load the sample set), but - since I never change the sample set in this Kontakt instance - it doesn’t slow down my song switching (noticeably). So as long as its internal state isn’t changed, Kontakt has been manageable for me.

This is a mix of instruments and effects. A ton of instances of FabFilter Pro-Q 3 - I have an EQ in most of my instrument racks to shape the sound. A number of pure effects racks with reverb, delay, combinations of both, and some utility plugs (stereo width, limiter, metering, tuner). Also guitar amp sims and stomp pedal VSTs that I use in my guitar setup.

The main RAM load comes from sample-based plugins (Addictive Keys, Addictive Drums, Kontakt-based, UVI-Workstation-based) that I use for specific high-quality sounds that I can’t (or won’t) cover from my rompler estate. All loaded on startup and left alone afterwards - except Addictive Keys that I use with multiple sample sets (Grand Piano, Upright, CP-80). But Addictive Keys loads pretty quickly (<1 sec on my system), so I make an exception here.

Cheers,

Torsten

#9

Same here :+1:

I avoid sampled plugs as much I can, because playing “live” is a completely different experience from recording. As Torsten described,I use Korg Triton and M1 for many sounds. I do have Omnisphere on one song, and it works very well, but the quality diminishes while playing in mono with other musicians, and the venues do not mix in stereo. I found similar, less cpu hoggish vsts fit just fine.

1 Like
#10

I agree, and try to avoid the samplers, but didn’t think Omnisphere would be so damn hoggish. I’ll see what I can find.

A few things (already making a difference:

  1. I use many of the sounds built into the MOXF8 (the second keyboard is a controller only), and can probably get away with many pads, etc. from that board to thin out the Omnisphere requirements. However, the patch changes are made on the laptop through Cantabile, and they don’t propagate to the MOXF until all the soft synths / plugs are loaded, otherwise about 90% of the sounds could be started from the MOXF.
  2. Samples are used for two things in the rig:
  • Horns (Session Horns) that can’t be achieved with the MOXF. With two saxes in the band I find that synthy horns just wreck what I’m trying to do making the “horn section” sound bigger - it actually sounds worse with synth horns - samples are the way to go.
  • Specific instruments or effects (vibes, wind chimes, etc.). I can swap some of these
  1. Longer term This band may be moving toward some fly gigs. If that’s the case I may end up reducing the MOXF sounds, which makes the load time/optimization even more important (e.g., pianos, Rhodes). Ideally I’d have backline with a weighted 88 and unweighted 61 controller and be good to plug in and play with the laptop.

I obviously have more work to do here, and appreciate all your help.

1 Like