Large Template Sluggish

[eoinrussell]

I am having very sluggish saves (15-30 seconds). Sometimes Record is sluggish too. And then random 'beach ball' waits as I select new instruments for playback (this seems to be an initial loading issue with Record enabling).

Context:
I've made an orchestral template. It has about 100 VIs speed over 7 instances of Kontakt. Each instance of Kontakt is bussed independently to the main outputs. Mac 5,1 OS 10.12.6. I have 64 gigs of RAM and a 2x 3.3 6 core processor. Samples are streaming from an SSD that gets about 530MB/sec throughput. DP is using 46GB of RAM. Total RAM usage is 53GB. Kontakt is using 29GB for samples. I'm working at 48k with a 512 buffer. Kontakt preloading 60kb, multi-processor support set to off (this seems to be the DP recommendation).

Playback is fine with pretty dense orchestrations. But I'm having sluggish interface issues. I save compulsively and waiting for DP to catch up is breaking my workflow.

DP is pretty snappy when I don't use this template and Kontakt doesn't seem to be the choke point. Looking at the Kontakt processor usage it never goes above 50% (this seems to be less than 50% of ONE processor but I'm not sure how these things report).

When I save, the CPU usage in activity monitor shows DP spiking above 100% for the save, turns red and reports DP not responding. Same thing happens when I record enable a new track, although it only lasts about 5 seconds. (Is this 107% of all processing power? Huh? How does that work?)

Any thoughts? It seems like I have plenty of memory and processor capacity. What can I do to make DP happy?

thanks!

[FMiguelez]

Except for the spiking, that sounds exactly like what I see when I use VE Pro. The reason it takes so long to save in my case is because everytime I do so, VE Pro transmits and stores the full VI Pro and VE Pro settings into DP.

In my case, the remedy is to use Decouple in VE Pro, and voilá.... It stops sending all the info on each save, and you get instant saving times again. BUT that means I need to remember to manually save the VE Pro sessions locally on each slave computer. Then, at the end of the day, I re-engage Decouple mode and let it save everything in DP, so it learns all this and transmits it automatically back to the slaves by simply turning the relevant V-Rack on. This is so awesome!

See if Kontakt has something similar... There must be a way to stop it from sending all its info to DP upon every save.

OR... Use VE Pro to host your VIs. I regard it as the 7th wonder of the world. That's how happy I'm with it.
I think you can try it for free for some time.

[mikehalloran]

What is your hardware including number of cores and processor, version of DP and OS? There may be some suggestions once we know.

[eoinrussell]

Sierra 10.12.6
Mac Pro (early 2009) - firmware upgrade to 5,1
2 x 3.33 Ghz 6-Core Intel Xeon
64 GB 1333 DDR3

DP version 9.5 73657

I will try VE Pro. Is there an automated way to convert my template to a V-Rack, or does that need to be done manually?

[mikehalloran]

Sierra 10.12.6
Mac Pro (early 2009) - firmware upgrade to 5,1
2 x 3.33 Ghz 6-Core Intel Xeon
64 GB 1333 DDR3

DP version 9.5 73657

I will try VE Pro. Is there an automated way to convert my template to a V-Rack, or does that need to be done manually?

A number of posts over the years from MOTU techs have said that Kontakt utilizes one core per instance in DP. Reducing from 7 to 6 and re-balancing the load may help. I never run more than 4 for that reason.

I don't know if 9.51 (released a couple of days ago) will help but large files in High Sierra with AFPS are faster for read/write to disk (SSDs only). If you have a number of older 32 bit apps and aren't sure whether they'll work in OS 10.13.1, you might want to try it on another drive first.

I'll assume you are running SSDs except for Time Machine, right? I would expect slower performance if you weren't. If you haven't enabled TRIM, run the following in Terminal: sudo trimforce enable and enter your Admin password when asked. This enables Apple's garbage collection. Never, ever run so-called "disk maintenance" utilities on an SSD — the good ones won't let you.

I don't use VE Pro and will let someone else answer that.

[FMiguelez]

Sierra 10.12.6

I will try VE Pro. Is there an automated way to convert my template to a V-Rack, or does that need to be done manually?

You can easily port your VIs into new or pre-existing V-Racks. Simply select the VIs in the TO window, right click and choose "Move selected tracks to V-rack”.

Once you have Kontakt in VE Pro, reassign MIDI inputs and audio outputs back to DP as desired. You catch them back in DP via Aux tracks or regular audio tracks with input monitoring (my preferred method by far).

Really check on the Decouple function to make VEP behave as I described in my 1st post.
But be careful! You really need to understand how it works with DP and how this mode affects the regular behaviour. It affects both, DP and VEP. Otherwise, it's easy to mess things up, even lose a VEP project.

[FMiguelez]

Before you start changing your template, I suggest you try it first in a simple session. Make sure you like it and that you're satisfied with Decouple mode. Porting your template to VEP requires lots of changes in the template, but for me, it was the best thing I've done in a long time.

[eoinrussell]

Thanks guys!

I updated the template to V-Racks (Remap MIDI Devices to the rescue) but there was no performance improvement.

For VEP do I need to buy a dongle first? The process is confusing on their site. I doesn't seem that I can demo it before buying a dongle. Not a big deal.

[dreamuse]

I'm having what sounds like a similar problem with just a couple of instances of Kontakt running inside DP 9.51. Specifically, selecting between instances takes enough time that the mac throw the spinning beachball on screen. I originally thought this was potentially a VEP problem, and so I moved all instances inside DP to see what would happen. Alas, it's still going on. Switching between instances of other, non-Kontakt VI's presents no wait. It may have to do with how many patches are loaded within kontakt, as one of my instances has only 5 patches, and seems to switch more quickly in and out than the one with 16.

I'm running the latest version of Kontakt, though this was happening with 5.6.8 as well.

Len

[dreamuse]

Some more potentially useful info:

I just got off the phone with MOTU tech support, and found this out: Apparently, there's some complexity with Kontakt whereby switching into and out of pre-render mode can be quite time consuming. As such, if you open up an Kontakt instance, and select "Run instances of this plug in in real time", the problem goes away. Of course, you loose the pre-gen savings, but MOTU didn't have any other workaround at this point.

If someone else has advice on handling Kontakt with less of a blunt-edged tool, it'd be great to hear.

Len

[eoinrussell]

I took a while but I got Vienna Ensemble running and it works very well on my system. I can get a 30+ gig template sitting crash free for weeks at a time without a restart. Good stuff.

I have a new set of problems.

1. With a large template in DP, a couple hundred tracks, the screen scrolling is sluggish and of course, that's the workflow: scroll around to the right track. Is this a GPU issue, will a better GPU upgrade this performance? I've tried using search and track folders but that just makes for more clicking.

2. Is there an alternative method for record enabling tracks? Selecting the little red dot is tedious. Is there a way to trigger record enable from selecting the track, name or MIDI data? I couldn't find a command or preference related to this.

Thanks