# Investigating Logic + VEP ideal setup



## NoamL (Dec 12, 2019)

Hi,

To enable divisi partwriting, I need to load multiple copies of an instrument in my template.

For the sake of example let's take the Spitfire Symphonic Strings Vln1 Legato CTA, which takes *1.36GB of RAM* to load.

I believed that loading copies inside the same Kontakt instance would *save RAM* because Kontakt shares the memory between NKIs, as shown below. Notice that this Kontakt instance is reporting only 1.36GB of memory used.







However, when using the system monitor to look at VEP6's actual memory usage, it appears that VEP6 uses large amounts of RAM regardless of whether the instruments are loaded into a single Kontakt or not.

I kept track in the spreadsheet below.

In the *GREEN *method I gradually loaded more and more instances of the instrument into a single Kontakt, inside a single VEP instance (in other words, exactly what you see in the screenshot above.)

In the *YELLOW* method I split it out horizontally, creating up to ten VEP instances each of which hosted a single Kontakt, which has the instrumented loaded once.

I was expecting the *GREEN* method to be a big memory saver compared to the *YELLOW* method because the instruments are shared inside a single Kontakt, but it is not.






In both cases the system's memory usage increases by a lot for each new instrument loaded. The green method costs about 270 MB per new instance of the instrument, and the yellow method costs about 345 - in other words, the green method is only saving me *75MB* per new instrument loaded. That's not nothing, but it seemed surprisingly little.

So: is it possible that I have something wrong with my VEP setup? Or is this how it's supposed to work?


----------



## Dewdman42 (Dec 12, 2019)

makes sense. VePro has very little ability to constrain what specific plugins are loading into RAM. They are basically separate instruments according to VEPro. Kontakt itself would need to become smarter about sharing memory between Kontakt instances. If they really all need the same samples, I'm not sure there is anything you can do about that, other then try to move things into a single kontakt instance. However, you can load them all, then purge all the memory from all the kontakt instances and save the template like that..they should all be a lot less in the template and then as you play a project, maybe one instance of kontakt is only using one subset of that 1.36gb and another instance is using a slightly different subset, since its different layers or different articulations, or whatever. So maybe after doing that and play a project through, maybe each one should report less memory used then the full 1.36gb


----------



## NoamL (Dec 12, 2019)

@Paul Cardon smartly nudged me to do some sciency tests with Kontakt as a standalone.

It appears that the extra memory usage per instance of the instrument (i.e. per new NKI) is not only on the Kontakt side of things, it is also not sample memory. I suppose that it could be scripting. Notice that it is consistent per-instrument even when no mics are loaded. Also it's a different number for the Legacy legato patches that have different scripting.


----------



## Guy Rowland (Dec 12, 2019)

Keep at it Noam. I've noticed for a long time that its the NKIs themselves that are ballooning in size, while in general the sample memory taken to run them gets ever more modest with streaming on the fly from purged. The gulf between the legacy patches newer ones is I think quite indicative of this broad trend.

It's an excellent reason to move to a disabled template - actually disabling the instrument completely is the only way to jettison that vast memory overhead. This has its own costs attached, if done within the DAW the project file sizes can become an issue, especially with large numbers of autosaved versions. Within VE Pro, if running decoupled, this is a trivial concern. However its not great news for those looking to take advantage of Divisimate, which requires a lot of individual instances, though of course modelled instances help a lot in this regard AFAIK.

One more test perhaps, comparing the following:

6x legato patches with CTA mics loaded:

a) in Kontakt standalone
b) in a single VE Pro instance
c) across a single VE Pro instance but in different Kontakt instances
d) across different VE Pro instances

This will I think answer the question posed in your thread title. I would expect to see negligible difference between a and b once the empty instances are subtracted, and both being better than c or d.


----------



## Dewdman42 (Dec 12, 2019)

If the NKI's are sucking that much memory above and beyond sample memory, that is utterly ridiculous. There is no excuse for that.


----------



## Guy Rowland (Dec 13, 2019)

Curiosity got the better of me, and I did a quick test in Win 10 using Task Manager for info. Results using a Symphobia 2 legato patch whose sample memory is reported by Kontakt as 58mb (having subtracted the memory footprint each test setup when blank)

Standalone Kontakt
1st Instance = 138mb
average successive instances = 58mb

VE Pro, Single Instance, Single Kontakt
1st Instance = 129mb
average successive instances = 58mb

VE Pro, Single Instance, Multiple Kontakt
1st Instance = 128mb
average successive instances = 125mb

For the last test, I then added one more instance of Kontakt, blank:
Additional blank instance = 64mb

So this shows that a single instance of Kontakt behaves exactly the same within Standalone Kontakt as within VE Pro, as expected. Because the figure of 58mb was bang on the nose for the sample memory, and yet I thought this co-incidence because the instrument itself had to be taking up SOME memory, I repeated the standalone test with a different instrument, the Herring Clarient fully loaded, Kontakt reporting sample memory of 1.04GB. (A large sample pool, but the interface looks modest, so I suspected a relatively low footprint otherwise).

Standalone Kontakt
1st Instance = 1201mb
average successive instances = 75mb

VE Pro, Single Instance, Multiple Kontakt
1st Instance = 1189mb
average successive instances = 147mb

So this demonstrates that sample sharing is working perfectly within a single instance of VE Pro. I then wondered about doing a multiple instances test, to see if sample sharing still worked:

VE Pro, Multiple Instances, Multiple Kontakt
1st Instance = 1189mb
average successive instances = 171mb

Again, sample sharing is working correctly even across multiple instances (I've no idea how Kontakt does this btw, it's always seemed slightly miraculous to me). It also shows that the additional memory footprint for the following:

Each additional instance of Kontakt 6 = 64mb
Each additonal instance of VE Pro 7 = 24mb

Both very modest really.

So in summary - VE Pro is working exactly as we'd all hope, but nki file sizes have gotten huge. To quote a few random libraries of mine, these figures all samples purged:

Symphobia 1: Strings Sustain DYN = 24mb
Symphobia 4: Pandora Effects Horns & Hones - Suspense Bends Muted = 439mb
Spitfire Solo Strings Violin Virtuoso all artics = 308mb
Metropolis Ark 1: Schwarzdorn Horns all artics = 243mb
Realitone Hip Hop Creator = 379mb
AudioBro Modern Scoring Brass Horns 1 all artics = 1273mb

This last figure was so eye-popping I added a 2nd instance, which was a mere 544mb. I'm off to the Audobro forums...

EDIT - originally posted the MSB figure as being Full Mix only, in fact that was for all mics. The figure for Full mix only is 706mb.


----------



## NoamL (Dec 13, 2019)

Thanks for doing that Guy!  Brilliant!

So it really looks as though the developer scripting is the cause of additional per-NKI RAM, not the samples. And thank you for doing the experiment with older libraries as well. I had wondered how much of that per-NKI load was non-negotiable Kontakt-side stuff but it appears to be very small. It's all coming from the developers with their scripts (and perhaps graphics?).

The best practice would therefore appear to be running your instruments out of as few NKIs as possible... and maybe with Kontakt minimized to slot view? I'm curious if that saves RAM for graphics. Probably not but I'll test this afternoon.


----------



## Guy Rowland (Dec 13, 2019)

Sebastian has given an extremely thorough overview on the Audiobro forum on where all the memory goes. For forum members its here - https://audiobro.com/forums/viewforum.php?f=61 . Think it would be ok to post his basic summary of where the memory goes that is common to most modern instruments:



> 1. Sample preload
> 2. Instrument map (zone data, group data, routing, mods, effects, etc.)
> 3. Persistent script data + UI caching and drawing



There's a ton of info - and even a video - of how to get under the hood and get the size down if required using full Kontakt and Modern Scoring Brass. I'll be pouring over that early next year when I rejig the template.


----------



## rlw (Dec 13, 2019)

Question, @Guy Rowland , Is Kontakt Memory Server being used. When I have it engaged I use much less memory but with my large instances in VEP, I seem to have issues so I do not use it. Also, is there a difference with VSTs versus AUs. Thanks so much for your research.


----------



## laurikoivisto (Dec 13, 2019)

rlw said:


> Question, @Guy Rowland , Is Kontakt Memory Server being used. When I have it engaged I use much less memory but with my large instances in VEP, I seem to have issues so I do not use it. Also, is there a difference with VSTs versus AUs. Thanks so much for your research.



Windows doesn't have Kontakt Memory Server.


----------



## Guy Rowland (Dec 14, 2019)

Indeed, my main rig is Windows. I sorta had the impression that KMS was deprecated on Macs as well, could be wrong there.

I’ve always thought sample sharing was so clever as to be voodoo-like, and never understood how it worked. I remember for a short while - Kontakt 4 I think it was - it in fact stopped working, then it subsequently got fixed again.


----------



## Guy Rowland (Dec 14, 2019)

I looked it up - https://support.native-instruments....ow-Can-I-Optimize-the-Performance-of-KONTAKT- . It was for Mac, 32 bit only. 



> If you are using a 64-bit host sequencer or running KONTAKT in 64-bit mode, turn the *Use Memory Server* option off, since this option has no effect in 64-bit applications, and is likely to lessen KONTAKT's performance.
> Note: Further information regarding the Memory Server can be found in the KONTAKT reference manual. Please note that the *Memory Server *feature is only available on Mac systems and is not visible for Windows users.


----------



## rlw (Dec 14, 2019)

Guy Rowland said:


> I looked it up - https://support.native-instruments....ow-Can-I-Optimize-the-Performance-of-KONTAKT- . It was for Mac, 32 bit only.



I can confirm that it does cause problems but it does greatly reduce memory usage when I tried it.


----------



## rlw (Dec 14, 2019)

I use a 10 core iMac Pro with 128gb memory and I have massive libraries that I like to have on standby so I currently have one 4 core 6700K PC with 64 gb of memory and need to add one or more slaves. in VEP I build complicated Instances with Kontakt AU plugins and then I rebuild those I want on a PC to VST. Very time consuming. A couple of years ago I experimented with just using VSTs while using Logic Pro AU3 multis. I felt I had more problems with VST on a Mac but was considering trying that again. The work to build 2 duplicate Instances is a huge time consumer. I need to add 1 to 2 more slaves and wanted others experiences with using VSTs on a Mac. I use many Kontakt instruments. My decision on the slaves PC versus Mac is price. But building 2 versions of VEP projects takes enormous time. I would like others experiences of using VSTs on Mac with Logic Pro. Has it worked for you? Do you notice a performance difference?


----------



## A.G (Dec 14, 2019)

Hi guys,

Each Kontakt instance in VEP takes resources even if there are no Instruments loaded into Kontakt.
The DAWs can address the VIs to Kontakt Port A only, so you use 25% of a Kontakt instance.
We at Audio Grocery developed *VEP Multi Instance* which allows you to address a DAW software Instrument track to all Kontakt Ports ABCD. This method saves tons of Kontakt instances - respectively system resources.


----------



## jononotbono (Dec 14, 2019)

Interesting thread. I’ve always thought the samples share from the same memory pool. An Empty instance of Kontakt uses more ram though. And yes, I’ve always assumed scripting was the cause for the slight increase in memory consumption when sharing in the same instance of Kontakt.
Thanks for doing all these tests. Very interesting!


----------



## Dewdman42 (Dec 14, 2019)

scripting should not account for more than a mb or two of memory. If we're talking bout hundreds of MB's or even more than a GB of memory, than something is amiss.


----------



## Guy Rowland (Dec 14, 2019)

rlw- I don't quite understand, how are you using KMS in a 64 bit environment? NI say its never worked in 64 bit as I understand it? And it would seem redundant to me anyway, since sample sharing works perfectly. There's no more RAM to save there.



Dewdman42 said:


> scripting should not account for more than a mb or two of memory. If we're talking bout hundreds of MB's or even more than a GB of memory, than something is amiss.



I'm not sure if you clocked Sebastian-from-Audiobro's reply above. You are way, way off - it's far from a bit of scripting that takes a couple of meg, there's all the UI stuff, and especially all the internal zoning etc which can take up massive amounts of RAM on a complex instrument. I've just been under the hood in Modern Scoring Brass, following Sebastian's advice, and found the zones in Kontakt take up literally hundreds of MB in those patches.

(Slightly tangentially I also discovered there's a real problem with running those patches DFD. It does need some artics in RAM, but if you just click the sustain keyswitch it loads the whole lot right into RAM which imo it doesn't need to - this it seems to me is the biggest issue with MSB and RAM use).


----------



## Dewdman42 (Dec 14, 2019)

No I didn't read it, but thanks for reminding me I will. I was only stating an opinion. There is no reason under the sun why a script should take a gb of memory. If it does, then something is freaking wrong with the software! That is what I'm saying. And same with the background images too by the way.


----------



## Dewdman42 (Dec 14, 2019)

Actually I can't seem to read the AudioBro article without signing up on their forum, which I don't really want to because its related to a product I don't use. In any case I stand by what I said...I'm not saying the observations are wrong, I'm saying...there is no excuse for it. .There is no justifiable reason for script and background images to take up that much memory. If it does, then its either a bug in kontakt or poor design by the instrument maker.


----------



## Guy Rowland (Dec 14, 2019)

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.


----------



## Dewdman42 (Dec 14, 2019)

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.


----------



## NoamL (Dec 14, 2019)

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.


----------



## NoamL (Dec 14, 2019)

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.


----------



## Ben (Dec 15, 2019)

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


----------



## NoamL (Dec 18, 2019)

Ben said:


> 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?


----------



## Dewdman42 (Dec 18, 2019)

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.


----------



## NoamL (Dec 18, 2019)

Weird, I only see 16, even when loading a second Kontakt into the same VEP instance? Probably making a very newbie mistake here?


----------



## Dewdman42 (Dec 18, 2019)

check your preferences in VePro


----------



## Dewdman42 (Dec 18, 2019)

I should have stated correctly before. Old LogicPro had 16 stereo returns and new LogicPro supports 25 stereo returns.


----------



## NoamL (Dec 18, 2019)

Oh my goodness! That's awesome! Thank you @Dewdman42 . I'll set audio outputs to 50 (25 st).


----------



## Dewdman42 (Dec 18, 2019)

ps - it might also require you to use the AU3 VSL plugin, I'm not 100% sure.


----------



## Ben (Dec 18, 2019)

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.


----------



## EgM (Dec 18, 2019)

Ben said:


> 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:

2 threads per instance
1 midi port per instance (since I instance every instrument)
1 stereo out pair (I load multi outs directly in DAW)
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.


----------



## NoamL (Dec 18, 2019)

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.


----------



## NoamL (Dec 18, 2019)

I just found @Dewdman42 's premade template here: https://www.logicprohelp.com/forum/viewtopic.php?f=9&t=143416

If that's still the best way to get it done for Logic users, it's awesome. Has hundreds of multi port instrument tracks already all laid out. Now I just need to figure out port routing on the VEP side!


----------



## Dewdman42 (Dec 18, 2019)

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.


----------



## Dewdman42 (Dec 18, 2019)

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


----------



## NoamL (Dec 18, 2019)

Oh, damn. Yeah, loading a single Scripter instance is actually affecting all instrument tracks on all ports. No way I can use that 

I need a workflow where I can control one NKI from one Scripter on one track.


----------



## Dewdman42 (Dec 18, 2019)

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


----------



## mgpqa1 (Dec 18, 2019)

Ben said:


> 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.



Oh wow, I had no idea about this setting (and my fault of course for not RTFM). It hadn't been disabled by default in my case and was enabled this whole time. Thanks for the tip!


----------



## NoamL (Dec 18, 2019)

I think I'll just stick with one "real world" instrument per VEP instance. It makes more sense musically and it hasn't caused any problems yet on my 64gb machine. Just thinking about what might happen if something screws up technologically in the middle of working on a project... no way I'm gonna relearn & comprehend all the stuff about ports under time pressure.


----------



## jononotbono (Dec 18, 2019)

I’m a Cubase user with VEPro so cant help with the Midi Ports and Logic but my approach is...

I have each library in its own VEPro Tab. This leads to many tabs but Ihave a lot of stuff disabled and enable it as and when I use it. I also have some stuff permanently on.

So, I have every patch enabled from SSO (including SCS and Solo Strings and Ricotti). That’s over 1000 patches live.

This will therefore mean...

1 VEPro tab for...

SCS
SSS
SSB
SSW
SSSS

I have a tab for SA Percussion. In this tab I have various Perc patches from Albions, Ricotti Mallets and so on.

An example of a library that has more patches than I can load in one tab (48 ports x 16 midi tracks each) is Albion UIST. I have every patch of this library in VEPro but I have 3 tabs...

UIST Strings
UIST Winds
UIST Brass

There are a lot of patches in this library and all is disabled, until I use it. And I’ve not found a better way of managing this library other than being able to see everything on seperate tracks in Cubase. For me, that library is a “find what I like, render to audio, save the midi in duplicate disabled midi tracks and hide them - so I can always go back”. Once these parts are rendered to audio, I disabled the VEPro instruments again.

HZ Perc another tab
Strikeforce another tab

Albion Strings (all in a single tab)
Albion Brass (all in a single tab)
(These are in a single tab because I just found it to be a tad excessive to be in separate ones as there aren’t enough patches to warrant it).

I find this approach, being able to enable and disable what I want by specific libraries to be working well. Obviously the track count is ridiculous but I have a touch screen template to show and hide what I want, when I want.

Not sure if it’s more efficient to use less VEPro tabs but I’ve gone round in circles with this and just decided to give this way a go. Speaking of which, it’s probably time to put a “few more” patches in the template and have a play with JXLB 😂


----------



## Dewdman42 (Dec 18, 2019)

My feeling is that I don’t see much point to even using vepro when it’s one instance per source track. I know a lot of people do that but I don’t get why other then having a constantly available vepro template as you switch between daw projects. Which is a solid reason but not using vepro to full advantage. However as soon as you start talking about scripter it gets more complicated to have one script handle more then one instrument. It’s totally doable but at first your head will explode thinking about that aspect. But basically you just need to tweak the script a little. Thanos should work fine with only slight tweak, let me know if you want to look at that deeper


----------



## EgM (Dec 18, 2019)

NoamL said:


> I think I'll just stick with one "real world" instrument per VEP instance. It makes more sense musically and it hasn't caused any problems yet on my 64gb machine. Just thinking about what might happen if something screws up technologically in the middle of working on a project... no way I'm gonna relearn & comprehend all the stuff about ports under time pressure.



I'm working that same exact way without any issues other than RAM  I just disable the tracks I don't need. 141 instances at the moment, ~20 more to add.


----------



## NoamL (Dec 18, 2019)

Dewdman42 said:


> I don’t get why other then having a constantly available vepro template as you switch between daw projects.



Well that's the main reason I use it. To have samples loaded perpetually on an external machine while I'm flipping through 5-ish cues throughout a working day that were all written on the same template. Saves a lot of time!


----------



## NoamL (Dec 18, 2019)

btw out of respect to Vienna I've retitled this thread "Investigating VEpro+Logic" because we did find out in the end that the non-shared memory isn't really VEP's fault.


----------



## Ashermusic (Dec 19, 2019)

Dewdman42 said:


> My feeling is that I don’t see much point to even using vepro when it’s one instance per source track. I know a lot of people do that but I don’t get why other then having a constantly available vepro template as you switch between daw projects. Which is a solid reason but not using vepro to full advantage.



Also VE Pro distributes the load between the cores better than any DAW.


----------



## Dewdman42 (Dec 19, 2019)

I have yet to see any actual evidence of that.


----------



## Ashermusic (Dec 19, 2019)

Dewdman42 said:


> I have yet to see any actual evidence of that.



Based on years of observation and setting clients up with it.


----------



## Dewdman42 (Dec 19, 2019)

It very well may be that years ago logicpro had some core usage problems that vepro improved upon. This year I did that big daw comparison performance test very methodically and I did not find any such correlation, in fact logicpro ran more efficiently without vepro. Some other daws were the other way around. But the difference was very slight to the point of not being significant.

There are these rumors going around that vepro is somehow magically using the cores better but I have yet to see any evidence of that and my own tests did not show that to be the case.

there are still other very compelling reasons to use vepro!


----------



## Ashermusic (Dec 19, 2019)

Dewdman42 said:


> It very well may be that years ago logicpro had some core usage problems that vepro improved upon. This year I did that big daw comparison performance test very methodically and I did not find any such correlation, in fact logicpro ran more efficiently without vepro. Some other daws were the other way around. But the difference was very slight to the point of not being significant.
> 
> There are these rumors going around that vepro is somehow magically using the cores better but I have yet to see any evidence of that and my own tests did not show that to be the case.
> 
> there are still other very compelling reasons to use vepro!




It may depend on how much in Logic you are putting in Live mode, but with big multis of Play and Kontakt, it makes a difference here.

Admittedly though, I have not tested it both ways in quite a while, so maybe Logic has improved with this, but I have seen few Logic users say that have noticed that Logic has significantly improved with that.


----------



## Dewdman42 (Dec 19, 2019)

Well consider if you put logic into live mode without vepro and a small buffer size and then compare that to using vepro in live mode with a 2x or 4x buffer and longer latency it is not an apples to apples fair comparison. You could raise the buffer size when using without vepro to compare core use with same latency to be fair. Vepro imposes extra latency.

i am always open to hearing or seeing actual facts that might confirm vepro somehow makes more efficient use of cores In certain specific situations and would really like to know what those are if so, but I just haven’t ever seen that.


----------



## Ashermusic (Dec 19, 2019)

Dewdman42 said:


> 1. Well consider if you put logic into live mode without vepro and a small buffer size and then compare that to using vepro in live mode with a 2x or 4x buffer and longer latency it is not an apples to apples fair comparison. You could raise the buffer size when using without vepro to compare core use with same latency to be fair.
> 
> 2. Vepro imposes extra latency.
> 
> i am always open to hearing or seeing actual facts that might confirm vepro somehow makes more efficient use of cores In certain specific situations and would really like to know what those are if so, but I just haven’t ever seen that.



Unless you have a very new and/or very powerful Mac you _cannot_ "put logic into live mode without ve pro and a small buffer size" with big multis of today's demanding sample libraries without all kinds of system overload messages or crackles and pops.

And I don't know how they do it, but when I increase the VE Pro setting form None to 1 buffer or event 2, I don't feel the additional latency when I play.


----------



## Dewdman42 (Dec 19, 2019)

But that is what that setting does. You could alternatively just increase the buffer size in Logic Pro without vepro and get similar improvement.

i still see no actual facts confirming vepro is using the cores in some magical way better then all the smart programmers at Apple and Steinberg are seemingly able to do


----------



## Ashermusic (Dec 19, 2019)

Dewdman42 said:


> But that is what that setting does. You could alternatively just increase the buffer size in Logic Pro without vepro and get similar improvement.
> 
> i still see no actual facts confirming vepro is using the cores in some magical way better then all the smart programmers at Apple and Steinberg are seemingly able to do



But when I increase the buffer size in Logic I DO feel more latency.

As for the "smart programmers at Apple and Steinberg", yes they are, but they don't nail _everything_. Core distribution has long been an issue with Logic because of the way it's architecture is designed. They frankly used to believe that multi-timbral would go away as computers became more powerful, not recognizing that users simply like that workflow. And Steinbergs developers have never been able to make it load as many instruments without issues as Logic ,AND there is a discrepancy between the Mac version efficiency vs the PC, which they admitted to me.

Anyway, I don't have any interest in proving it to you, and ass I say, simply not having to wait for instruments in a large template when switching between projects is reason enough for tv/film composers especially.

And I don't like the new "load as you use" template approach personally. I want to tap my virtual baton on my virtual conductor stand and know that _all_ the players are already waiting to do my bidding


----------



## Dewdman42 (Dec 19, 2019)

Those other reasons are definitely compelling reasons to use vepro. And there are even more reasons if you use other vsl products such as mirpro or their sample libraries which have a few workflow improvements when hosted inside vepro. I personally also like mixing inside vepro also which provides a benefit of having not only the instruments preloaded in ram but also the entire orch setup completely as a mixed orchestra. These are huge workflow helpers.

If you can think of specific situations where I could expect to see improved performance with vepro I will be happy to validate it through testing. I have actually been trying to find it but so far.....that particular claim is coming up empty with no evidence to support that vepro is somehow using the cores better.


----------



## Ashermusic (Dec 19, 2019)

Nah, I am OK with leaving our discussion it where it is.


----------



## jononotbono (Dec 19, 2019)

Dewdman42 said:


> I have yet to see any actual evidence of that.



Before I used VEPro, Cubase used to have so many CPU spiking problems. I tried out VEPro as I was desperate and it fixed that for me. So much so, I got stuck in and now I'm never looking back. This is one of the reasons I use it (and not getting into all the obvious reasons) Sorry, can't provide you with any "evidence" but for me it was a dramatic change.


----------



## jononotbono (Dec 19, 2019)

Ashermusic said:


> And I don't like the new "load as you use" template approach personally. I want to tap my virtual baton on my virtual conductor stand and know that _all_ the players are already waiting to do my bidding



Yep. For me, it's just down to resources. So another 400 computers should make that dream happen.


----------



## Dewdman42 (Dec 19, 2019)

In my tests, reported already on this forum. Cubase did benefit from vepro per performance but Logic Pro did not. Later on Steinberg fixed performance and now as far as I can see there is no benefit there either. That indicates to me that in the past cubase had some severe performance problems on Mac that may or may not have been related to core utilization. It was not long after I reported my test results both here and on Steinberg’s forum that suddenly they were able to fix something in cubase that ran amazingly more efficiently. I haven’t tested 10.5 times yet so no promises.


----------



## DS_Joost (Dec 21, 2019)

Ashermusic said:


> Also VE Pro distributes the load between the cores better than any DAW.



I wanted to ask this, because I was experimenting with this in Reaper tonight and performance in Reaper seemed even better than VEPro. Can anyone confirm this or am I seeing things?


----------



## resonate (Dec 24, 2019)

Dewdman42 said:


> In my tests, reported already on this forum. Cubase did benefit from vepro per performance but Logic Pro did not. Later on Steinberg fixed performance and now as far as I can see there is no benefit there either.



Yeah, but Cubase still suffers from issues and bugs related to track disable/enable, saving track presets and re-loading them (10.5 forgets articulations for example, there is still an issue with reloading quick controls from re-enabled tracks), so ve pro is still better for modular template for now, especially now that you can disable and enable whole sections of tracks remotely from daw.


----------



## Dewdman42 (Dec 24, 2019)

VewPro has many workflow advantages even more then you are saying here. There is very good reason to use VePro regardless of performance. The tests I did and reported above were specifically related only to performance.


----------



## marclawsonmusic (Dec 25, 2019)

Dewdman42 said:


> Those other reasons are definitely compelling reasons to use vepro. And there are even more reasons if you use other vsl products such as mirpro or their sample libraries which have a few workflow improvements when hosted inside vepro. I personally also like mixing inside vepro also which provides a benefit of having not only the instruments preloaded in ram but also the entire orch setup completely as a mixed orchestra. These are huge workflow helpers.
> 
> If you can think of specific situations where I could expect to see improved performance with vepro I will be happy to validate it through testing. I have actually been trying to find it but so far.....that particular claim is coming up empty with no evidence to support that vepro is somehow using the cores better.



A few years back (2014) I spent countless hours trying different configurations of VEPro and Logic. Back then, I could not get reliable ‘live mode’ performance with NoamL’s approach - lots of multi-outs and everything crammed into as few instances as possible. I had pops and crackles everywhere. That’s why I settled on ‘one instance per track’... at which time I definitely noticed less CPU usage during both performance and playback. I spent a lot of time in Activity Monitor and checking CPU meters in Logic and VEPro and it definitely freed up CPU having things in VEPro - back then. 

A LOT has changed - the computers themselves and of course dozens of improvements in Logic performance. VEPro’s engine was re-coded at one point as well.

Jay’s approach was definitely the most effective back then, but who knows what is best now? Thanks NoamL for being the pioneer and keeping us in the loop. I am following this thread with interest.


----------



## Ashermusic (Dec 25, 2019)

What hasn’t changed however, for sure, is that my approach is the most like a score page, which is how trained guys like me are wired to think. So unless the time comes when someone can prove to me that performance is significantly _worse_ this way I will continue to recommend it.


----------



## Dewdman42 (Dec 25, 2019)

Why can’t you have multiple tracks feeding a single multi timbral instrument? How is that not like a score page?


----------



## Ashermusic (Dec 25, 2019)

Dewdman42 said:


> Why can’t you have multiple tracks feeding a single multi timbral instrument? How is that not like a score page?



Because then you have to consolidate them . I have never seen a traditional score where the first violins have several lines delineated by articulations.


----------



## Dewdman42 (Dec 25, 2019)

What do mean by you have to consolidate them?


----------



## Ashermusic (Dec 25, 2019)

Dewdman42 said:


> What do mean by you have to consolidate them?



Make them into one track. Obviously if you are not printing it out you don’t necessarily have to but if you are like me, as you compose you want to see it properly in the score.


----------



## Dewdman42 (Dec 25, 2019)

But you don’t have to make anything into one track. They are different instruments in different tracks. The only difference is they feed into one single instrument channel. But as tracks they are one track per instrument


----------



## Ashermusic (Dec 25, 2019)

Maybe we are misunderstanding each other . First violins spiccatto is not a different instrument from first violins legato. And on a score page, they don’t appear on separate lines. And so if you have three tracks flowing through one channel strip in Logic, you see three lines in the score editor.


----------



## Dewdman42 (Dec 25, 2019)

Why do you have your articulations seperated to different tracks? That is a seperate discussion.


----------



## Ashermusic (Dec 25, 2019)

Dewdman42 said:


> Why do you have your articulations seperated to different tracks? That is a seperate discussion.



Why else would you have multiple tracks going through one channel strip?


----------



## Dewdman42 (Dec 25, 2019)

You can have violin track, viola track, cello track and bass track, for example; one track per instrument like a score page. All feeding into a single vepro instance


----------



## Ashermusic (Dec 25, 2019)

Dewdman42 said:


> You can have violin track, viola track, cello track and bass track, for example; one track per instrument like a score page. All feeding into a single vepro instance



And when each had 12 articulations? I know, you like AU3.


----------



## Dewdman42 (Dec 25, 2019)

If they each have 12 articulations what is the problem?


----------



## Ashermusic (Dec 25, 2019)

Dewdman42 said:


> If they each have 12 articulations what is the problem?




Logic is limited to one MIDI port with 16 MIDI channels per VE Pro instance. So if you are using non key switch instruments, like I frequently do?


----------



## Dewdman42 (Dec 25, 2019)

Logic is not limited to one midi port. The AU3 vep plugin can handle up to 8.

It is true, however, that the articulation set editor does not appear to be port aware For channelizing by articulation id. Yet.

that is why I made my channelizer scripter which is freely available. That can channelize across up to 127 midi channels into a single vepro instance, one track per instrument like a score page.

i would hope in the future Apple will make the articulation set editor port aware for AU3


----------



## marclawsonmusic (Dec 25, 2019)

Ashermusic said:


> Logic is limited to one MIDI port with 16 MIDI channels per VE Pro instance. So if you are using non key switch instruments, like I frequently do?



In this case I would set up a single VEPro instance of ‘violins 1’, with each articulation on a separate midi channel in the same Kontakt multi. Just one MIDI channel (I know it’s pre AU3 thinking). 

In modern Logic, I can now use articulation sets, but previously I had to use separate tracks or Something like SkiSwitcher. 

I am glad I can use articulation sets (those I created) with CSS. I would never use a third party solution I couldn’t support myself.


----------



## Dewdman42 (Dec 25, 2019)

I did a performance comparison this year of one track per instance compared to many tracks into one instance. I can’t seem to find it right now it if I can find it I will repost.

The other thing is that vepro is more efficient with one instance. Each instance is internally running a completely seperate vepro server. There is overhead for that. Plus each internal vepro server is running isolated from the others, so vepro doesn’t do many optimizations that it can normally do within a single large instance/server


----------



## marclawsonmusic (Dec 25, 2019)

I am excited to hear how NoamL’s setup goes. It’s pretty much the opposite of what I have now so I’m sure there is something I will learn by watching him struggle through it (PS - thanks for the window into your process, NoamL)


----------



## Dewdman42 (Dec 25, 2019)

One final performance related comment about vepro. It has a preference parameter for number of threads per instance. The value of this preference should be vastly different if you are using one large instance vs one instrument per instance. When you use a single large vepro instance you configure that preference to a large value and let vepro manage your cores more. If you use single instrument per instance, then you set it very small to like 1-2 and basically you are letting OS X manage the core use instead of vepro. Everyone talks about how they think vepro manages the cores better but if you are using one inst per vepro instance, then it’s actually not doing anything at all to manage core utilization.

But what about in betweener scenarios? Like maybe 4-5 vepro instances with say a section on each instance? I actually prefer that workflow but what about performance?

Based on the above I feel it’s difficult to set vepro’s thread preference for this situation and not end up occasionally with under utilized cores. 

i believe the results I found in comparison were that the difference in performance between single instance and one inst per instance was negligible though and it really comes down to workflow that works for you.


----------



## Ashermusic (Dec 25, 2019)

Dewdman42 said:


> Logic is not limited to one midi port. The AU3 vep plugin can handle up to 8.
> 
> It is true, however, that the articulation set editor does not appear to be port aware For channelizing by articulation id. Yet.
> 
> ...



I don’t trust AU 3. I don’t need AU 3. And most importantly, if it isn’t broken, I don’t need to fix it.

I am done.


----------



## DS_Joost (Dec 25, 2019)

I am building sort of a hybrid setup right now, because the Hollywood Orchestra sort of demands it. As in, I have two midi tracks per instrument (not all, but with most). Basically, I have one midi track with all the main articulations, like bread and butter ones, and one with specialized articulations. All of them feed into one audio track in Cubase per instrument but they can be separately pre-mixed inside VEPro. It works really well so far.

This means I sometimes have to consolidate, but not nearly as much as with the track per articulation method, and I can still access all articulations without running into the 16 midi channel limit, which is honestly not really up to par or even useful with modern scoring instruments. Sometimes it just isn't possible to reduce an instrument's playability to 16 channels.

This way, I have a best of both. I can play in on the fly 90% of my music and the other articulations I can add manually on another track if needed.


----------



## resonate (Dec 25, 2019)

This looks interesting


----------

