PDA

View Full Version : AAX VEPro Unstable?


txshonk
12-16-2012, 08:10 PM
I was wondering if anyone else was finding the AAX version of VEPro 5 seems to cause instability?

Since I starting using it: I will add it to a project and get a "not enough Memory" error, R6025 runtime errors, and even BSOD.

I will be going back to RTAS, and hopefully the issues will go away, But I was just wondering if it was only me.

meech
12-16-2012, 08:35 PM
I noticed that the multiple outputs of the aax version weren't actually transmitting any audio, so I was just sticking to the rtas version for now. VSL seems to update VEP pretty often and fix these bugs pretty quickly.

brianjanthony
12-17-2012, 06:35 AM
I don't own PT 10 but I've been reading that a lot of folks have issues like this if they keep both the RTAS and AAX plugins in their respective plugin folders. See if you still have RTAS installed in the plugins folder. If so, remove it and see how it goes.

I'm anxious to make sure VEPro works in AAX well because all my sessions require it.

txshonk
12-17-2012, 06:22 PM
I tried dumping the RTAS versions from the PT RTAS plug in folder. I still had issues so on a problematic session I swapped back the RTAS version and it ran just fine.

I personally will hold off til the next release from VSL before I try AAX again.

Jon_Atkinson
03-18-2014, 05:14 AM
Been a few updates to VEPro since this thread was started...

Any improvement to the AAX version?

Last time I tried it it seemed pretty flakey (but that was a few months back)

Anyone taken the plunge with it more recently?

suicune
03-18-2014, 06:29 AM
Well I've run it a lot, and it's been fine for the most part. I've had a few crashes on the computer running the server (not the one running PT) but the crash report clearly indicated Kontakt was responsible for those. I haven't had any issues with sessions not running Kontakt. I've used up to 8 audio outs with no issue. I haven't removed the RTAS version from the folder, and I've installed all the updates as they've come out. I don't seem to have the problem where the server refuses to connect any more either.

I'm running PTHD (TDM) 10.3.8 on a 2007 MacPro with a 2012 MacBookPro i7 as the slave machine, both running Lion latest version. I also sometimes run it internally - i.e. both PT and VEPro running on the MacPro. I mostly host LASS, Vienna Instruments and Ivory II in VEPro.

Does that help?

John_Toolbox
03-18-2014, 06:54 AM
VEP is relatively stable for me, but does occassionally get weird. I'm using it mostly with kontakt, PLAY and lexicon pcm reverb. I have one slave pc running windows 7, and also use it on my main machine running 10.8.5 and PT 11.1.2.

Jon_Atkinson
03-18-2014, 07:54 AM
Thanks for the replies chaps...

I'm on 10.3.6 on OS 10.8.4... Been fairly stable using VEPro on the host machine, mostly with Kontakt, Vienna Dimension Brass, the odd Omnisphere, and a couple of NI synths... That's with VEPro RTAS.

If I try and instantiate VEPro AAX (latest version) I get a hard quit out of Protools 100% of the time. No spinning wheel of death, just instant quit.

It's obviously hard to narrow down issues with VEPro, as there are so many plugins involved, but presumably if it's been stable with the RTAS version then probably the server is not at fault here, it's the AAX plugin..?

I'm rubbish at reading crash logs (actually I should probably learn how to do that) so can't be more specific, but it's totally repeatable...

Just out of interest, was something improved or changed in the nature of AAX after 10.3.6? Just wondering if a newer version of PT might behave differently with VEPro AAX, as you guys are on newer versions.

As it stands I'm staying with the RTAS version till I get some downtime...

John_Toolbox
03-18-2014, 08:59 AM
Your system is running the plugin as AAX-32bit since you are on PT10. You could try updating to PT 10.3.8 to see if that improves things, but that still won't be an apples to apples comparison, since I'm running PT 11, which uses the AAX-64bit architecture. The AAX version of VEP is a dual purpose build, which will work as AAX-32 or AAX-64, but my guess is it's optimized for 64-bit use.

I dont think there's much (if any) advantage to running AAX-32 vs RTAS, but I haven't tested them either, I went from PT9 directly to PT11.

Jon_Atkinson
03-18-2014, 09:04 AM
Thanks so much for your thoughts John.

I was perhaps coming from this from the wrong angle: I was thinking that as the AAX version seemed buggy (at least on my system) then I probably should wait until it was stable before making the move to PT11.

But you're probably right (and I think the fact that you and others are running it well reinforces this), that I'm not really doing the AAX version justice by running it on PT10.3.6.

As it stands I'll stick where I am at the moment until I finish this project, then probably move to PT11 then and see how I get on.

Really helpful info everyone. Thanks again.

suicune
03-18-2014, 10:34 AM
I'm on 10.3.6 on OS 10.8.4... Been fairly stable using VEPro on the host machine, mostly with Kontakt, Vienna Dimension Brass, the odd Omnisphere, and a couple of NI synths... That's with VEPro RTAS.

If I try and instantiate VEPro AAX (latest version) I get a hard quit out of Protools 100% of the time. No spinning wheel of death, just instant quit.


Just to stress again, I'm running AAX on 10.3.8 with no problems, so if it is an AAX-32 bug it doesn't seem to apply to all systems. I think I used it in 10.3.6 also but can't absolutely swear to that. I am on Lion though so can't rule out it being a ML issue.

Are you saying that if you instantiate AAX VEPro it quits, even when trying to connect to an empty project? Or are you trying to connect it to an existing session with the plugins you mentioned? Can you post the contents of the crashed thread in the crash report?

Jon_Atkinson
03-18-2014, 10:44 AM
Just to stress again, I'm running AAX on 10.3.8 with no problems, so if it is an AAX-32 bug it doesn't seem to apply to all systems. I think I used it in 10.3.6 also but can't absolutely swear to that. I am on Lion though so can't rule out it being a ML issue.

Are you saying that if you instantiate AAX VEPro it quits, even when trying to connect to an empty project? Or are you trying to connect it to an existing session with the plugins you mentioned? Can you post the contents of the crashed thread in the crash report?

Yeah, too many variables..!!!

At the moment if I try and load VEPro AAX plugin into PT under *any* circumstances I get a hard quit instantly, irrespective of what's loaded in the server.

This has been the case with every version of VEPro I try, but I'm fully accepting that this might be system specific to something in my setup... Which was why I posed the question really... If someone else was running AAX with no problems at all then I know it's be my setup...!
I've not had a chance to properly troubleshoot as yet (and as the RTAS version is behaving I've sort of left it alone)...

I'm right in the middle of it at the mo, but I'll post a crash log this evening.

Jon_Atkinson
03-18-2014, 11:35 AM
If anyone can decipher here's the crash log...

https://www.dropbox.com/s/1q2n6srh5vhf9h9/Crash%20Log.pdf

The log was too long to post as a reply, so I pdf'd it...

So this is with the latest VEPro (last couple of days update..), but has been the case for me since the AAX version was released.

ronwasserman
03-18-2014, 02:54 PM
I'm running it with no problems whatsoever. Your problem must be system specific.

PMF Media
03-18-2014, 08:06 PM
Same here. Running PT11 & MacOS 10.8.5 on a Mac Pro 3.1 with 8gb ram, works like a charm!

goshalev
03-19-2014, 12:21 AM
PT 11.1.2 on Mac 10.9.2 and
PT 11.1.2 on Win 8.1
VE PRO 5.3.13151
running with no problems whatsoever

suicune
03-19-2014, 07:50 AM
If anyone can decipher here's the crash log...

https://www.dropbox.com/s/1q2n6srh5v...rash%20Log.pdf

The log was too long to post as a reply, so I pdf'd it...

So this is with the latest VEPro (last couple of days update..), but has been the case for me since the AAX version was released.

Well I'm sure there are people around who are better than me at reading them, but it doesn't seem to be indicating a specific plugin is responsible. I suppose I'd start by trying it in an empty PT session, see if it still crashes there.

Jon_Atkinson
03-20-2014, 02:17 AM
Ok, so had a spare hour last night...

Cloned my drive, and then upgraded to 10.8.5 and PT10.3.8 (clean install)

I'm actually getting pretty similar behaviour, in that I get a hard crash out of PT when installing the AAX version, but now if I instantiate VEPro in a new session it's fine until I try and connect it to the VEPro server... Then I get a crash...

Not sure what else to try here...? I've checked that the eLicence drivers are all up to date (they are)... Done all the usual other troubleshooting stuff.
The current (until yesterday) build of my system was done on a new HDD, and everything was re-downloaded fresh.

It's no major issue I suppose, as the RTAS version is running fine for me, and on a plus side 10.8.5 and 10.3.8 are running very smoothly, and load times are significantly quicker...

If anyone can think of anything I've not tried then do shout... Otherwise I'll leave it till later in the year and do a new total clean install and go to PT11.

Jon_Atkinson
03-26-2014, 02:51 PM
So, been fiddling about with this a bit....
Seems like my issues might be RAM related.
I've gone back to setting Disk Cache to 'normal', and I've also gone back to using Kontakt memory server...
I stopped using the memory server after someone at VSL forum suggested there was now no need for it with the 64 bit VEPro server... Which makes sense... But to be honest I've run much bigger templates without issue using KMS...
I wonder if KMS just releases the RAM a bit more elegantly than using the RAM allocated within VEPro...?

Anyway, I was wondering what settings you guys who are running VEPro are having for your thread allocations?

I have a 6 core Westmere Mac, and allocate 5 in PT, and have had it at 8 in VEPro.... Any thoughts on that, and whether there are 'best' settings here...?

John_Toolbox
03-26-2014, 05:56 PM
I have not done any testing for a few years, but I have found that every combination is completely different on different systems. KMS was always too CPU intensive on my old system when compared to 64bit Vep or to hosting directly in Logic. PT11 doesn't have a setting for number of cores, and I haven't done any large projects since I switched.

Jon_Atkinson
03-27-2014, 01:51 AM
I have not done any testing for a few years, but I have found that every combination is completely different on different systems.

Yep, you're absolutely right…! Which I guess is why it seems to be so hard to come up with the 'magic numbers' for best performance!


KMS was always too CPU intensive on my old system when compared to 64bit Vep or to hosting directly in Logic.

That's interesting… I'm seeing the opposite! With the same template, I've dropped from around 35% to around 20% just from reverting back to KMS.
Again, too many variables, and dependent entirely on the plugins you use… I'm a very heavy Kontakt user, but obviously others may not be… I only use Dimension Brass as my only VSL instruments…
I also think that Omnisphere has a role to play here in how nicely the system behaves..!

PT11 doesn't have a setting for number of cores

Indeed..! And it must be a great help to at least remove that variable and let PT take care of that…

I'm seeing an upgrade to 11 in my near future..!

John_Toolbox
03-27-2014, 06:08 AM
Kms may have improved recently. Last time I tested it was with PT9, logic 9, and kontakt 4 on snow leopard. The best setup on that machine was to use 4 cores in kontakt, and 4 cores in pro tools... Using VEP.. Or 4 and 4 in logic 9,

Jon_Atkinson
03-27-2014, 06:14 AM
Thanks…

How each app fights for the rights to each thread may be an issue here… For instance if you assign 6 threads for VEPro and 10 for PT (of an available 12 on my machine), do the apps argue over the threads which overlap..? :D

Troubleshooting this is such a slow process (mostly because of the insane loading times for big templates, which are needed to cause the problem)

One thing I have noticed, is that the VSL 'uninstall VEPro' application does not remove any preference files… It only appears to move the app itself to the trash (which anyone can do…!)

I've now properly trashed all the preferences I can find… I'll see how I get on over the next few days...

John_Toolbox
03-27-2014, 08:13 AM
Thanks…

How each app fights for the rights to each thread may be an issue here… For instance if you assign 6 threads for VEPro and 10 for PT (of an available 12 on my machine), do the apps argue over the threads which overlap..? :D

Troubleshooting this is such a slow process (mostly because of the insane loading times for big templates, which are needed to cause the problem)

One thing I have noticed, is that the VSL 'uninstall VEPro' application does not remove any preference files… It only appears to move the app itself to the trash (which anyone can do…!)

I've now properly trashed all the preferences I can find… I'll see how I get on over the next few days...

If you look in activity monitor, VEP and PT will likely have way more threads active than you set Kontakt to use. The number of threads setting in Kontakt is per instance. The host program then decides how to prioritize these threads. My guess is if you have lots of NKIs in a single instance of Kontakt, that setting it to more threads might be better, where if you have lots of instances which have one or two large NKIs, a lower number might be better. But this is just a theory, and as we have both found, all bets are off until you test with your specific configuration. If you put all of the samples in your template on an SSD, the load times will significantly improve. most modern SSDs read at over 500MB/s, where a spinning disk only does 100-150. So if it takes 10 minutes to load your template right now, you could probably shave that down to 3 minutes or so by loading them from an SSD. The only caveat to this is if you are running the tower version of the mac pro, the internal SATA ports are SATA II (3.0Gb/s), so they will not be able to take full advantage of a 500MB/s SSD.