What's new

Investigating Logic + VEP ideal setup

Dewdman - I don't wish to be too blunt, but you are really not getting this. The short Sebsastian part I quoted above lays it out pretty well, and I did expand on it already.

It's not about a few lines of script, and if it doesn't come under 3mb someone is doing it wrong. I don't pretend to know the full inner workings of Kontakt, but I do know that very large complex instruments require lots of groups and zones. That takes up memory - lots of memory with lots of groups.

Anyway, I think I'm kinda done with this thread here - thanks to Noam for starting it and setting me off on a useful path of fact-finding.
 
There is no excuse to use that much memory, sorry that is simple truth. Something somewhere is being implemented stupidly if it is. And that includes all the mapping and groups too by the way. I'm not missing anything.
 
I kind of see both points of view. It's a shocking amount of memory, but I don't know all the details that might justify it (I as well can't see the AudioBro thread).

Anyway to keep this thread productive - I took everything we discovered together this week, and started setting up my 2020 template, starting with Spitfire Symphonic Strings. Wanted to make a note of what I've done in case anyone using SSS under the same conditions (Logic with a Windows VEP machine) could benefit.

Some of this stuff is probably pretty elementary but it's a big improvement in workflow and RAM savings over the way I was fumbling through it before.

1. Only 5 VEP instances: On the VEP side I only have 5 instances: Violin I, Violin II, Violas, Cellos, Basses. Each VEP instance hosts a single Kontakt instance. Looks VERY nice & tidy! I hope it will not cause CPU problems (more on that later).

2. Streamlining Tutti & Divisi: Next I loaded the Legacy Legato Performance patch for each instrument. I limited myself to a single instance of legato for Vln I, two for Vln II, three each for Violas and Cellos, and one for Bass. In the past I had a dedicated Tutti patch for each instrument and several more for Divisi. The Divisi patches had their volumes reduced by 3dB inside Kontakt. For this template, I instead plan to use CC11 on the fly to achieve the same result. This lets me use the first copy of each instrument as either a Tutti or Divisi simulation, as needed. So instead of 3 Violin II patches (Tutti and two Divisi) I can just load 2 instead.

3. Single Performance Legato Next I loaded a single Performance Legato instance for each instrument. It's loaded onto MIDI channel 4 for all instruments to be consistent, and will share samples with the legacy Legatos. I also unloaded the Runs from the Legacy Legatos because I'll use the Performance Legatos for that kind of writing.

4. Economic Longs and Shorts. Next I loaded an Economic Longs and Economic Shorts patch on channels 5 & 6. These patches save quite a bit of RAM (about 2-3 gig across my template!) relative to loading two instances of the Core Articulations patch and purging them to create a longs-only and shorts-only patch. I'm not sure why but I guess it might be that they use fewer samples (which is fine, I'll use them less often) and they also have completely disabled even the possibility of loading the unneeded articulations. Perhaps that saves scripting RAM. In any case, working with these patches is saving me gigabytes so... highly recommended.

5. Forego Surplus Articulations + Client-Side Kontakt Placeholder. With this setup so far, I am still missing some relatively important articulations (trills, tremolos, trem sul pont) and all the decorative artics like molto-vib. I've decided this is where the compromises have to start. Instead of loading them into VEP, I've created an empty Kontakt instrument on the DAW side which has its outputs routed correctly. If I need these articulations in a particular cue I will use this placeholder Kontakt instrument to load them. It means slightly longer load times for cues that use these articulations, and it also means using RAM on the DAW side (which I plan to eventually use as well). However, this oughta work okay. It's basically a reasonable compromise from the platonic ideal of loading everything and having it at your fingertips.

6. Separate Busing of Shorts & Longs. For the project I'm working on this spring, I know we'll have to deliver dub stems separating string longs and shorts. Therefore, in each VEPro I have six audio returns: C, T, A for longs and C, T, A for shorts. Since VEP & Kontakt can both handle that many audio streams, there's no need or reason to load the Shorts inside another Kontakt or inside another VEP.

7. Multitimbral Addressing. On the DAW side, I have a VEP 6x multitimbral and 16x multioutput instrument for each of the string sections. The multi-output is so I can load six aux tracks (CTA/CTA) catching the VEP audio returns. The multitimbral is so I can load up to 6 MIDI tracks addressing the loaded patches. For example for Viola: Legacy Legato (1), Legacy Legato (2), Legacy Legato (3), Performance Legato (4), Economic Longs (5), Economic Shorts (6). Vln I, II, and Bass use fewer MIDI tracks because they have fewer divisi instances of Legacy Legato loaded up.

8. CPU Concerns. The main concern I have with this setup is that everything is so concentrated. It's both refreshing and slightly weird to see VEP take up so little space visually especially because I was always told that Logic works best with VEP spread across many instances. What I was told (which is way beyond my ability to test if it's true) is that each VEP instance is dedicated to a core in my computer, so if one VEP instance becomes "super busy" then it can overload a core. I will have to road test this template and see if it actually holds up. However, the way I'm justifying it right now is that each VEP faithfully represents a single instrument which will have a single part to play in the rather traditional orchestral music this project needs. Apart from writing 2 or 3 part divisi using the Legacy patches, I'll probably never address multiple channels in Kontakt simultaneously, or ask for audio returns from the Shorts and Longs simultaneously. Thus, I hope the CPU can handle it okay.
 
Last edited:
Should've mentioned the most important part! This totals up 17.5 gb in VEPro. I have 64 to play with so 25 is probably the practical limit for strings. :)
 
Hi,
I want just chime in to give you some background on how VEP handles these things.

1. All plugins are responsible on how they share memory, or how they don't share it.
For example our player instances do all share as much memory as possible, things that can't be shared are GUI related as well as the instance settings.
You can test it by checking the memory difference when adding a second instance of the VI or Synchron Player and load the same instrument (if you don't have any VSL libraries to test it yet, there is a free version of the Big Bang Orchestra available ;)).
But as soon as you add an additional instance in your DAW and load the same instrument, the memory can't be shared (at least on Windows with Cubase, it may work with other configurations, have not tested it yet).

There are also other players that also can use memory sharing and this feature should also work in VEP (for example: Play 6 does this if I remember correctly). You may have to test if this will still work if you host the same instrument on different VEP instances...
As far as I know current versions of Kontakt (5, 6 on x64) do not share memory.

2. It's always a good idea to have as few VEP instances as possible! Check if the thread count setting in VEP is set correctly (I have 6 CPU cores, I use between 3-6 VEP instances for comfort, thread-Count is set to 4 per instance, no performance issues).
If you use only one VEP instance you should set the thread count equal or almost equal to the core count. If you are using more VEP instances I would suggest to set the thread count to at least 2.
In case you are using only one instrument per VEP instance, set the thread count to 1; but this is really bad practice, so you should not do this (most users in support that complain about performance issues have this kind of setup).

3. You should disable the muli-processor setting in the Kontakt plugin, in case you have enabled it. By defaut it is disabled, the Kontakt manual suggest to disable it, we suggest to disable it. This setting can interfere with the multi-core / multi-thread optimization of VEP.

4. You can use Kontakt multis to save RAM, but design it in a way, so that you don't put CPU intense articulations / instruments in the same Kontakt instance. Each virtual instrument instance on gets processed by only one thread. In most cases this is fine because there is not much that can be processed in parallel within one instance.
If you are using multiple Kontakt instances to separate the CPU heavy things, VEP's thread optimizations work and will distribute the load optimaly on your CPU cores.
As long as you would not use a lot of Kontakt instances (hard to find an exact number, let's just say less then 50-100...), the better CPU performance is more important then the additional RAM usage.

5. It takes a lot of time to find "the perfect" setting for your system and your workflow. So don't try to get the performance up to 11. 80-90% optimizations will just take, let's say, ~20% of the time. Do more useful things with your time ;)
If you have a decent system, stick to the recommended defaults and tweak a little bit here and there, make use of the instance disable feature on big templates, you will have good performance and a good time working with virtual instruments (there are always exceptions).

Bonus chapter: It is always good to know what your system is capable of. There are limits, but "upgrading" to the most expensive rig does not always make sense.
You will get a great complete system for about 1000€-2000€ (Windows machine, Mac is a little more complicated) that would be enough for almost all people here.
Sometimes we get support requests from users complaining about bad performance on their new machine with one or two CPUs which cost each ~2000€. If I look up what CPUs they have bought, mostly it is some kind of high core, low clock CPU for special web-server uses. These CPUs are good for a special thing, but not for DAW workloads. (Multi-CPU setups are generally a thing I would suggest to stay away from...)
So if you don't know what hardware will fit best for your use-case, contact a specialist. Even if you pay him, you will probably get a better system for your needs at a lower price compared to just getting "the best on paper and most expensive I can efford".

Best, Ben
 
2. It's always a good idea to have as few VEP instances as possible! Check if the thread count setting in VEP is set correctly (I have 6 CPU cores, I use between 3-6 VEP instances for comfort, thread-Count is set to 4 per instance, no performance issues). If you use only one VEP instance you should set the thread count equal or almost equal to the core count. If you are using more VEP instances I would suggest to set the thread count to at least 2. In case you are using only one instrument per VEP instance, set the thread count to 1; but this is really bad practice, so you should not do this (most users in support that complain about performance issues have this kind of setup).

Hi Ben, thanks for the reply straight from VSL!

Could you explain what you meant in #2 a little further if you have time? I assume that your 3 to 6 VEP instances are one each for Strings, Brass, Winds, Perc, etc. How then do you work around VEP's limitation of returning only 16 stereo audio returns per instance? Are you doing all your mixing inside VEpro?

The way I've been setting it up, I'm routing Close, Tree and Ambient returns from every instrument section (v1/v2/va/vc/cb) and also separate C/T/A returns for the short articulations. I need that because 1) I'm gonna eq each instrument differently, 2) I need to route short and longs separately for dub stems, 3) I need to split close and ambient in case I get asked to pull up close mics to feature a particular string part.

Just wondering if there's a better way?

Screen Shot 2019-12-18 at 2.06.15 PM.png
 
Last edited:
VEP isn't limited to 16 returns. LogicPro was limited to 16 returns prior to 10.4.5. Now its limited to 50 returns. FWIW.
 
Weird, I only see 16, even when loading a second Kontakt into the same VEP instance? Probably making a very newbie mistake here? ;)

Screen Shot 2019-12-18 at 2.20.49 PM.png
 
I should have stated correctly before. Old LogicPro had 16 stereo returns and new LogicPro supports 25 stereo returns.
 
Hi @NoamL, as already mentioned you can increase the number of channels in the settings. But be aware that some hosts will stop working if the size is too high.

Maybe you have not discovered this feature yet: You can add aux channels as well as bus channels in VEP. This way you can route all the different mics to the different groups and add plugins to them, then mix them down to stems and return only these to the DAW. This way you avoid all the problems that come with routing that many channels in the DAW, and lower the CPU consumption.

My template is set up to have one class of instrument per VEP instance (strings, brass, ww..), then I premix everything to stems and send these to the DAW.
 
2. It's always a good idea to have as few VEP instances as possible! Check if the thread count setting in VEP is set correctly (I have 6 CPU cores, I use between 3-6 VEP instances for comfort, thread-Count is set to 4 per instance, no performance issues).
If you use only one VEP instance you should set the thread count equal or almost equal to the core count. If you are using more VEP instances I would suggest to set the thread count to at least 2.
In case you are using only one instrument per VEP instance, set the thread count to 1; but this is really bad practice, so you should not do this (most users in support that complain about performance issues have this kind of setup).

I've always used close to 100 to 150 instances using one instrument per instance containing all articulations without issues, I choose the absolute minimum for my work concerning midi ports, audio outputs and inputs. details are as such:
  1. 2 threads per instance
  2. 1 midi port per instance (since I instance every instrument)
  3. 1 stereo out pair (I load multi outs directly in DAW)
  4. 1 stereo in pair
I then route my submixes in the DAW as well as FX.

Surprisingly I have no issues :) BUT don't take this reply as a green light to go full on stupid using one-instrument-per-instance like me but it may work for you if you're adventurous, haha.
 
Alright! So it's ideal to load all the strings into one VEP instance, and ideal/necessary to have one Kontakt instance inside that VEP for each string section, so that I'm not asking a single Kontakt instance to process V1+V2+VA+VC+CB legatos all at the same time. Makes sense...

So what's the current best practice for setting up a multiport VEP on the DAW side in Logic? Because surely one needs more than 16 tracks to address all the strings in a big template (currently thinking about 37 different NKIs, each of which will need their own MIDI channel in VEP and their own track in Logic, and it's a must that each Logic-side track can have an independent instance of Scripter and writable CC automation).

I found this tutorial but it seems to be from a while ago, and also External MIDI tracks appear not to be able to host Scripter.

 
:) AU3. up to 8 ports. Note that scripting can get a lot more involved when you’re doing that because one script has to process multiple input tracks.
 
Ps i don’t know whether is the “best” way or not everyone has their own opinion but I think that’s the best way to have bigger vepro instances. Don’t mess around with any of the old environment macro approaches. That is the old way
 
Oh, damn. Yeah, loading a single Scripter instance is actually affecting all instrument tracks on all ports. No way I can use that :rofl:

I need a workflow where I can control one NKI from one Scripter on one track.
 
Well you can but the scripting gets more complicated. Events have a port parameter by the way. But one track per vepro instance was a easier for the scripting it’s a big motivation to use that approach
 
Top Bottom