Plethora of crippling issues with VEPro5; EWQL Play, Crashing on Save, Crashing on Load, etc

[avonkorff]

Hello, my name is Aleks von Korff, and I am currently employed as a composers' assistant by a prominent film composer in Malibu CA just outside Los Angeles. I am also functioning as de facto studio manager for said composer, who owns his own high end studio space (our work environment).

Since I have started here in July (I did not install this system, nor did I assemble this template/configure VE Pro the way it is currently set up) we have had persistent issues with VE Pro, varying pieces of hardware, and numerous software (non-VSL software that is) problems. I'm posting this in hopes that I might get some help and insight into our VE Pro specific issues, and perhaps some advice on how to tackle/eradicate these issues. All pertinent and obviously important system specifications can be found at the end of this post.

We have experienced countless VEPro 4 AND 5 crashes on our Slave Computer, which is surprising considering the slave seems to be the steadier of the two machines overall. I've also had bizzare issues with eLCC and VE Pro centered around a program called "Synsopos" which I know nothing about in the Mac environment, despite incessant googling and forum hunting.

With regards to the Synsopos centric errors, I have yet to encounter the issue since replacing the backplane on our Magma PE6R4 chassis and upgrading to a Magma PE6R4-I. I seriously doubt this has any connection, but nevertheless, though I should note it considering many of these errors that were cropping up relentlessly have dissipated since the chassis upgrade, but again, I don't see a correlation between the errors not being triggered within the software on the slave, and the installation of a new backplane in the Pro Tools chassis.

Typically, errors manifest themselves upon Saving, or Loading of Meta AND vFrames. For instance, one day I might hit "Save" on a vFrame spawning an instant crash, but be able to save the mFrame without issue. The next hour I might be crashing upon saving of the mFrame yet the vFrames can be saved. The next day I might experience neither of those issues, but then crash when I try to save a multi in Kontakt within Ve Pro. It is absolutely infuriating and I cannot explain why it is happening. In addition to Save related crashes (again, virtually any "save" functionality, whether it be mFrame vFrame or instrument/plugin, has caused crashes), I have experienced crashed on LOADING after a crash spawned by Saving.

At seemingly random intervals, after a crash I am presented with this Synsopos/eLCC error that prevents me from even opening VEPro without a complete restart of the slave machine (again, this has only occured on the slave). When these issues began, we were running VEPro4, and in the process of troubleshooting and exploring options for rectifying the solution, we upgraded to 5. At first everything appeared to be okay, but then the issues resurfaced. Once again, the issues SEEM to have subsided since we installed the new backplane into the Magma chassis, but I am not sure if that truly addressed the problem and fixed it.

In addition to the above issue, I am also having significant issues incorporating various EWQL Play instances. Load times are absolutely absurd given the raw power of both of our machines, and a handful of crippling errors/obstacles have presented themselves in the last week.

We have been operating with EWQL instances running off of the Host machine since I began working here in July. I have since been informed through my tech contacts and friends that this is a horrible idea, so I'm trying to transplant our EWQL libraries (Hollywood strings, Silk, Ra, Gypsy, and a handful of others), to run exclusively off of the slave machine. I successfully installed all of our EWQL instruments we want to use onto the slave computer, I can open them up in standalone mode and load/play samples provided I move the iLok over to the slave to test, and yet when I open a vFrame in VEPro5, I cannot see 'Celemony/EastWest/Play-Stereo' as a valid option for adding a plug-in. I have cross-checked every relevant directory on the slave machine with that of the host (where EWQL instruments are working just fine) and have found 0 discrepancies. What is causing this issue? I have contacted EWQL and they told me to contact you, since this is apparently a VE Pro issue...again, I have no issues with the instruments in standalone mode.

In your experience would it be better to run these memory-intensive instruments from our slave rather than the Pro Tools machine? Won't that put additional strain on the LAN connection between Host and Slave; potentially cause a bottleneck type issue?

VE Pro has been updated to its most recent version according to the updater and eLCC. Play has also been updated, it's permissions repaired, and works just fine on the Host (but not the Slave, where I'm trying to move it to).

I thank you for your time and help, and look forward to hearing from anyone soon. I am aware that I just wrote a wall of text, but I would prefer to be absolutely complete in my explanation of issues as to avoid wasting anyones time.

Best regards,

Aleks von Korff
avonkorff@gmail.com

SYSTEM SPECS:

HOST/SLAVE COMPUTERS:
Both 12-core CPUs @ 2.66 gHz per core
64 Gigs of Ram Each
Mac OS X 10.6.8
ProTools 9.03 HD; 192 IO x 2, 96 IO, Sync IO, Big Ben Clock, Magma PE6R4-i Chassis
VEPro5 - updated etc
LASS, VIPro, Reaktor, Gplayer, Kontakt Libraries - majority of active instruments on slave
EWQL instruments, Omnisphere, FM8, Massive, Absynth, Battery, Stylus RMX, Trilian, Kontakt Libraries - majority of active instruments on host

[Ashermusic]

Aleks, what I can tell you is that I run Logic Pro 9  on my Mac and connect to my PC slave with VE Pro 5 with a metaframe containing EW's Hollywood Strings, Hollywood Brass, and Hollywod Orchestral Woodwinds from an SSD and to a VEPro 5 metaframe on my Mac with a bunch of Kontakt  stuff and it virtually never ashes. 

So your issue is system specific IMHO.

[woodsdenis]

http://www.jcdeshaies.com/

Hi I see your using Protools, if you are not doing so already download this free app from above link. Protools pref and database helper.

I would first delete all the pref files and then see what happens. If this helps I always delete com.digidesign.protools plist, Digidesign Database folders and Volume folders every day before I start work !!

This would at least eliminate a to a large extent a Protools problem. As Jay said it does sound system specific.

[civilization 3]

synopsos has to do with the syncrosoft driver I think. it may not get along with something protools installs. ie., the error probably means the OS is not accessing the process. historically pro tools drivers have been troublemakers in a sandbox. you aren't going to have much luck with a synsopos problem.

it would certainly be best to have the most robust machine as a slave and handle instruments, all instruments you can, and all FX you can. I write via mouse to certain GUIs so I don't do 100% in VE Pro but close to. I think particularly with PT, put everything you can on another machine than.

are you by chance running the network dynamically? 

the only experience I have resembling yours was when I was networking dynamically. 

there is corruption in your system, and probably more than one thing. crash on load following crash on save to me indicates corruption in the project or metaframe. It seems like this accrues when stressing an unstable situation.

[avonkorff]

Thanks for your responses.
To answer;

-Yes I used ProTools Pref and Database Helper and run it exceedingly frequently to trash digi prefs etc.

-Could you explain what defines a network as dynamically run?

-Again, crash on load after crash on save is not a consistent experience...nor is simply crashing on save. As stated, I have crashed on saving the metaframe, vframes, multis, and instrument settings. It is not consistent, and cannot be reliably triggered (making troubleshooting difficult).


** The most pressing issue is getting VE Pro on the Slave machine to recognize that I have installed the EWQL terapack libraries that we are licensed for...as stated, I can run the instruments in standalone and load up samples, but VE Pro doesn't recognize "Play" as a valid plug-in add to a vframe.

Does anyone have any advice on this? It would be greatly appreciated...

Thanks for your time and responses

[civilization 3]

dynamic as opposed to fixed/static [IP address]. if you don't know, in all probability you have settings = dynamic. all of this unpredictability IME points to that [as a primary problem]. it must be fixed, ie., you enter the address yourself, one for each machine.

go into system preferences, network > Ethernet tab > Advanced tab. 'configure IPv4 manually'.

[civilization 3]

I recommend you sort that first.

then in the VE Pro preferences > plugins, 'scan'. there is no good reason it doesn't recognize the EW stuff after that.

[William]

 This entire post is very strange.

I have a smaller system compared to this very impressive one, and yet VE Pro runs absolutely flawlessly on it.  I have never had a crash from simply loading and playing, even with large orchestral setups.

So I think this sounds like this system which is listed here is far too complex, and has some bugs in it due to conflicts between software.  Using default installations can cause problems, depending on what apps are being used. 

I would suggest totally re-formatting one slave machine and installing on it only VE Pro (and whatever audio/midi equipment you use), since this is not a money problem. Thereby create a computer totally dedicated to VE Pro as a slave.  It is far more useful than any of those other libraries you list, and so it would make sense to do that.   It is totally stable when not interferred with by other software.  I can attest to that having a system that has never had any problems such as what you report.  Then, if you use many other sample programs, install those on a separate slave(s) and let them do whatever they want to do. 

[avonkorff]

@civilization 3 < br="">< br=""> WIth regards to the dynamic network, I'll follow your suggestions here first thing tomorrow and report my experience findings here. Thanks for the heads up. < br="">< br=""> Regarding the Plug-in Scan suggestion, this was naturally one of the first things I tried when troubleshooting the issue...and (obviously) the EW libraries/plugs (Silk, Ra, etc) have not been able to be located. < br="">< br=""> @William < br="">< br=""> VE Pro, as well as the sample libraries, encompass practically 100% of the installed software on the slave computer. Are you suggesting that we would need a (or MULTIPLE) separate slave machine(s) to house our sample libraries? This is absurd and I don't think it's what you meant. < br="">< br=""> Our system is not overly complex at all...it is a very standard Host and 1 Slave set up. Our host runs the DAW, and a mildly taxing metaframe VE Pro instance, and our Slave exclusively runs a larger, more expansive metaframe VE Pro instance.

[William]

There is no instability normally.  I know from experience that various pieces of software can conflict, so that is the only thing I can suggest.  Perhaps to analyze - which of the libraries are essential, which are unnecessary, and then re-image and re-install only those that are really needed. If you look at orchestral - almost everything is VSL.   Also making sure you have the latest drivers/versions on all, though you probably already did that. 

[Gusfmm]

Regarding your issues w/ PLAY, although it may sound trivial I don't believe you have indicated this among your configuration description, so- can you confirm that the PLAY version is x64 and not x86. Likewise, that VEP5 on the slave is x64 and not x86.

[civilization 3]

@avonkorff said:

VE Pro doesn't recognize "Play" as a valid plug-in add to a vframe.

as per the most recent post but mine, if VE Pro does not see Play in its list I would question are you trying to see a x64 version in the 32-bit server also. I said there is no good reason but there is 'a reason' it doesn't see the plugin. 

and, once installed Play it runs a memory server at all times (actually if the only Play installed are versions since it went x64, I don't know why it would use one), which does not co operate with the Kontakt Memory Server if it is running in VE Pro. that combination will crash VE Pro per se.

[civilization 3]

@avonkorff said:

In your experience would it be better to run these memory-intensive instruments from our slave rather than the Pro Tools machine? Won't that put additional strain on the LAN connection between Host and Slave; potentially cause a bottleneck type issue?

I think it will be better to not run anything but Pro Tools on your master. Pro Tools in general has to be boss of the sandbox. Not that it needs very much of that 12 core machine and all that RAM though, on paper you should be able to run a lot of stuff in VE PRO by local host and devote comparably little resources to PT.

how married are you to Pro Tools? It is probably not the best host for VE Pro use; have a look around here...

  I would recommend decoupling VEP from PT.

The notion of the LAN itself being the bottleneck is based on what exactly? I think it is a bad premise. BUT as I pointed out if you are running a dynamic network, it is changing addresses on you randomly and that is more than a bottleneck, that is a situation that will never work properly.