Hey Tim,

To answer your second question about the iLok transition VSL are making. Yes they are moving away from Steinbergs eLicenser (aka Vienna Key). These keys will still continue to function so long as Steinberg keep up their servers, and after that point they should continue to work so long as you can continue to run the eLicenser manager (or at least that is my understanding). The Vienna Key is actually just a rebranded eLicenser from Steinberg and with their transition to a new online licensing system and the deprecation of the eLicenser system VSL needed to make a choice about how to protect their IP and they decided to switch to iLok about a year ago now (at least that is when the public announcement came). Of course with PACE hard at work rewriting (from the ground up I imagine) their iLok system and ensuring it is secure it has taken them quite some time to do that. PACE recently told the folks over at ProTools Experts that they finally have a version for developers to start working with but it isn‘t quite ready yet and so we are still waiting (as are quite a few other vendors AVID comes to mind) for PACE to officially release their Apple Silicone native application so they can start their final re-write of their code that relies on PACE. 

From my understanding (and in practical experience). The slave computers will act in parallel. So whether you have 1 slave, or 20, the amount of latency that VEPro needs will remain the same, given all other variables remain the same. I currently have 2 salve machines, and I started with 1 slave machine, and my latency has always remained the same (buffer size of 2, adding 2x my DAW buffer size). Or at least my buffer size that worked. What will be a larger factor is how low can you push the buffer size before VEPro can’t handle the real time requirements, and how well the sampler can handle the real time load as well. Kontakt seems to do well, EW Play (old version) has had issues for me. And finally if you are running your samples off of a SSD or HDD will make a substantial difference in how low you can push the buffer size. Use an SSD, but you don’t need a super fancy and fast SSD, most any SSD will do, just so long as it’s from a reputable manufacturer it will perform just fine. You are mostly loading samples into RAM, and that just needs to be done in an efficient manner, which HDDs aren’t great at doing. 

Originally Posted by: murphy761

Mine is only creating a new blank VEP7 slot next to the pre-loaded/preserved orchestra template. It only works with Pro Tools and Logic X when running everything on a single machine.

Hey Murphy, I would suggest to also try manually reconnecting the instances rather than relying on the automatic method. However in your case I might have some guesses as to why this is happening. First I would guess that the name of your instance has changed. And I would guess that you changed the name of your instance in VEPro after closing your session. If you changed the name of the instance after you closed/saved your DAW session then when the session is opened again from its last saved state it tries to find the instance it was last connected to but can’t since the name was changed. So instead it makes a new instance with the name it last remembers on the same IP address that it did successfully connect to VEPro on. I had a similar issue when I discovered a space at the end of one of my instances, removed it and then tried to open a session only to have a new instance show up with what looked like the same name. I was confused until I figured out the names for VEPro must be exactly the same on the DAW and VEPro side of things otherwise they will not reconnect properly. This actually is the only logical explanation I can think of why an instance wouldn’t reconnect if saved properly. Hopefully this helps you figure what is going on when your issues.  

Originally Posted by: Gone To Lunch

I am setting up VEPro7 for the first time with DP 9.52 on my mac.

I set up the first instance, called Bass, put in four bass libraries, connected them to the VE Pro MAS instance in DP, connected the outputs in the Bass instance in the Server to the aux channels in DP, and success! Upon testing I got the right sounds in the right place coming out in my DP.

Then I switched off and shut down.

Later I tried to set up a second instance in my server, AcGtrs, but when I went into my DP to allocate the VEPro MAS instance, In the DP invitation to connect window, no server instances are shown?

I checked on the first Bass instance, and the connection was all as it should be?

So what have I missed in connecting my second instance?

Have you tried to manually reconnect your instance? Does it work fine if you do? My understanding is that the servers displaying in the DAW plugin is handled through DHCP broadcasting. And I have seen (and personally have) computers just not want to broadcast their DHCP information meaning the DAW plugin cannot find the server instance. When this happens for me I just manually enter the information. But I usually don’t have problems because I have a template that seems to be very robust about reconnecting my instances. So long as I don’t try to open the project/template when the VEPro projects aren’t open. And I think so long as you aren’t trying to connect the instances every time you open a project then it shouldn’t be too big of an issues when they don’t occasionally connect.

If I understand your questions correctly. Sort of. It may not be the way you are thinking of, but can’t you just load a bunch of different patches as separate VIs and then have those separate VI’s (effectively all of your patches) as different channels? 

For example this is what I did with Heavocity’s Gravity. There are 100 or so patches and I just loaded 100 different Gravity “instances” (VIs?) and then assigned them all to separate MIDI inputs. Et viola, I have instant access to all of Gravity’s patches without having to load anything (sort of).

Yep I would say your last sentence is your culprit. iMacs are notoriously noisy under load. And since your CPU is staying at 4.4GHz the entire time while your DAW is connected to your VEPro session that would be why the fans are spinning up. To prevent the CPU from thermal throttling. If they didn’t spin up that loud you’d likely be stuck at a CPU clock speed that is below base clock rather than the turbo you have now. I am not aware of a setting that could help reduce the turbo under load but. Then that would likely cause other issues if you were able to disable turbo.

All that to say, I think you have found the “problem” but I am not sure there is actually a problem. It sounds like the computer is behaving normally. And if you are not having any issues with VEPro and playback (pops, click, dropouts, etc) then I would say that this is just he way the computer functions. Maybe try networking your VEPro machine and sticking it in another room? Fingers crossed that it isn’t your DAW causing the permanent Turbo boost.

Hello lupine,

Have you had this working in the past without this behavior? 

Without knowing more precisely what is in your VEPro session etc I do find a few things odd.

1. If your DAW is set to it’s maximum buffer size (either 1024 or 2048? I’m assuming?) then having such high CPU usage is strange indeed.

2. 626% out of a 1000% right? To be honest that doesn’t completely impossible but hard to know with the info you gave. 

3. Are you running your VEPro session locally on your DAW machine or is it on another computer? Do you have another computer to test with if the former?

4. I would say when you have stopped playback 275% seems normal. But only if your buffer size was something in the 256 samples neighborhood (@ 48k) not at maximum buffer settings.

5. What is the sample rate of your project? 

6. What is your RAM usage? 

And finally I am sadly not familiar with VSL sample libraries so they may be more CPU demanding, I just don’t know as I don’t own/use any of their libraries in my work. I do find it possible that they could be more CPU intensive and that the behavior you describe could be normal for VSL’s libraries but I suspect not. If you are running your DAW on the same machine, and depending on what is in your DAW the 600% CPU usage could be absolutely normal. It’s impossible to give you a definitive answer with out more specific information. And even then you’ll need to do some more troubleshooting to figure out if maybe it’s your DAW causing the high CPU usage or VEPro, or even a background takes in Windows (well I’m assuming your are running Windows… is that correct?) If your are running OSX then maybe you are thermally throttling if you are on a Laptop? If you are on a desktop, (i.e. 2013 MacPro) then maybe the CPU is inefficient and what you are trying to run needs a newer more efficient CPU? (Although I find that unlikely). Maybe faster RAM would help, what is your RAM specs? Maybe you are trying to load too much into RAM and that is causing problems? Conversely maybe you are trying to stream too much from disk and that is causing problems? Maybe if you are running VEPro locally your DAW is hogging RAM causing a RAM shortage in VEPro even though it looks like it should be fine. I’m literally grasping at straws here, but all of that to say, troubleshoot some more, and provide some more details and hopefully you can find your problem. I realize it can be frustrating, but unfortunate there is not magic solution or guide I can give you to solve your problems. My own year and a half of Troubleshooting ended up with me realizing that I needed A LOT more RAM than I had. And the 256GB+ that I have is still not quite enough for what I would like to do. But I have made it work. 

Hello michaelft77,

Your initial setup question by using the old 2013 Mac Pro as a VEPro slave should be easily doable. The only “issue” would be connecting the two computers via Ethernet which is only a slight pain with the MacBook Pro as you’ll need a USB-C to Ethernet adapter if you don’t already have one. You’ll also need to either assign each computer a static IP address or have your router assign each of the computers a static IP (leaving the machines to get their IPs via DHCP).

The only complication here I can foresee is if you wanted to skip the router part of the equation and just directly connect the two computers via Ethernet. This can fairly easily be done but you’ll need a “special” Ethernet cable (or a normal one with an adapter). And what you need to get is either a crossover Ethernet cable or a normal Ethernet cable with a crossover adapter on one end. This will allow the two computers to talk to each other without needing a router/switch between the two handling traffic. In this setup you must set up the two computers manually with static IPs and manually assign subsets, but nothing to complicated (a google search should answer any questions to may have).

And then as far as seeing what is on the other computer (and remote controlling it), that also should be fairly easy once the two computers are connected on the same LAN. Apple has a built in utility to remotely connect and control another Mac on the same network. You’ll just need to set this up and then connect. Unfortunately I haven’t used this feature in quite some time so the particulars of setup I can’t really walk you though but this, again, should be something that is moderately well documented and should show up in a google search. And if you choose this route you won’t need an additional monitor/keyboard/mouse to control the remote (slave) computer as you will be controlling/viewing/inputting it with your host (DAW/MacBook Pro) machine. 

To your final question. Depending on your DAW running VEPro locally on your machine can significantly improve RAM usage (in my experience) when compared to loading down your DAW with a template (like you would run in VEPro). Additionally you would only need to load the VEPro template once and then you could switch between many projects without having to wait to let the VI’s load into RAM each time (beneficially if you are using the same template for your sessions). So even if you were using something that is more VI friendly like Logic Pro I would still recommend running VEPro locally on the machine as it can greatly reduce the time needed to switch sessions/projects. This may not “conserve” RAM but it could use it more efficiently. 

Originally Posted by:

i searched the forum but so far i could only see a solution for windows users.

SOME of my waves plugins show up as VST versions (v12) but the V9 ones are not on the list. If i go to AU and insert studio rack than i see the v9 versions under studio rack but the interface gets after opening and closing the window all blank so you can neither see studio rack nor the plugin inside it.

any ideas?

Did the older versions get placed somewhere else? Are you on OSX? Can you find documentation where the plugins go installed and if they maybe were placed in an additional folder. The only other thought I have is maybe they are old enough that there could be a 32 v 64 bit problem and that is why they aren’t showing up. Can you check in the 32 bit versions of VEPro and see if they show up there? 

Originally Posted by: Adia

Hello, I will have a bigger Mac for my DAW and I want to work sometimes on this bigger Mac and sometimes on my current MacBookPro. I am investing in new computer so this is why I need to know what I can expect.

Is there any quick way to not have problems to switch between external VEP IPs for Logic so it can understand what I want to do:

1. Current scenario: I use my MBPro 255.255.1.6 and connect to the external Windows MAchine that has IP 255.255.1.7. All my projects since a few years open with this configuration

2. Scenario 2: I I want to work on my new DAW Machine with the IP 255,255,1,5. and still connect it to my 255.255.1.7 Windows Machine. There will be difference in DAW IP,  does it matter? Or my projects will open correctly in spite DAW IP has changed?

3. Scenario 3: I want to use the VEPServer on the same DAW Big Machine 255.255.1.5  What can I do so my old projects open and I can work the way I choose?

The IP of the VEP is somewhere encoded in the Logic file? Is there a way to have a control over it? I do not want to change IPs of current computers to not to have conflicts (there is a time machine backup etc)  but please focus on reply on my 1.2.3 scenarios. Thank you

Hey Adia,

Sorry no one got back to you sooner. And it would be a good idea to get in touch with official VSL support on this. But the way I understand your scenarios whatever your DAW machine’s IP is shouldn’t matter, just so long as you are on the same subnet, VEPro will find the instances that you previously connected to. Especially since it seems you have them setup as static which certainly helps. And switching which DAW machine you are using shouldn’t effect the connection. If it were the Slave machines that were changing IP then you might have an issue but I think VSL has done some work so that even if your Slaves have DHCP assigned addresses they are still “re-link-able” if they can be discovered (which would again require you to be on the same subnet).

In your third (3) scenario that is a bit more difficult to be precise about. Assuming you only have one Slave machine then that would actually be a relatively easy change to make, just open up the Slave VEPro project on your local DAW machine and connect to the local instance. You’ll need to delink your old project the first time you open them but after that they should remember the new instance locally on your DAW machine and not the remote Slave version. If not you’ll just need to re-link it properly as required. If you have more than one slave then you’ll need to combine the multiple projects wich will be tricky. I would suggest creating channel sets and importing the project that way as there is no good way I know of to do this. But maybe there is an import project functionality that i am not aware of. I did this when I was still in VEPro 6 so things could have changed or been updated since I last needed to do this. 

Hey Alan,

So while I haven’t experienced this exact issue I have experienced a similar one with crackling and popping while Google Chorme is running at the same time ProTools is. Especially when using VEPro inside my ProTools orchestration template. I found the culprit to be Google Chrome and so have stopped using it for the most part (completely stopped using it while running ProTools). I found Firefox to be a viable alternative that didn’t exhibit the same behavior. I’d be curious to know if you find the same thing to be true in your situation.

I wanted to drop in here and see if anyone has had a similar issue to me. I am running a rather large (at least for ProTools) template and ever since I started working with it back about a year ago I have been solving all of my issues slowly and resolving them. But one that has been hanging around since the beginning is a rather large delay in pressing start/stop and the ProTools GUI freezing then about 3-5s after starting the GUI catches up. Audio does playback during this but it also causes issues when recording midi information and it makes it hard to quickly reset and try a take again or just to simply start and stop playback quickly without interrupting workflow. Right now I have it narrowed down to a few instances in my template which makes me think its the VIs and not VEPro, but i was curious if anyone had any further suggestions. Here is a youtube video of what is going on. I have also tried stripping out all unnecessary tracks (leaving just the VEPro audio tracks) with the same results. So I feel fairly confident that ProTools is not the culprit here.

Thanks for your help.

What is your VEPro plugin in Logic set to for its buffer? I have had trouble when I set mine below 2 (i.e. crackling, and "distortion" in playback). I would suggest that the ideal settings are 256 buffer size for your host (Logic), and a 2 buffer for the VEPro plugin. 

First off I know, not the best DAW.

Is anyone else experienceing a sever amount of lag/unresponsivness when starting/stopping playback/record in ProTools Ult 2019.6? My template is in the neighbourhood of 600 midi tracks 200 audio tracks. Starting and stopping playback/recording is very delayed and always freezes teh GUI for a few seconds before it catches up, and sometimes ProTools will become unresponsive. 

I'm on a Windows Machine with a 7920X, PTU 2019.6 and VEPro 7. My two slave machines are hardwired into my main gigabit network (I have tried running them on a seperate physical network with no change in behaviour) with Static IPs (both machines are windows machines, one a Threadripper, and one an intel 7820X, each with 64GB of RAM). 

Let me know if I can provide anymore information or if you have any ideas. 

Thanks,

- Walter

Hey everyone,

So I wanted to chime in here. In building my own template in ProTools I have found out many things and I ran into problems like this as well. First to respond to the OP Julian, since its working some of the time I would guess that this is CPU bound. And since you are running VEPro and PT on the same computer I would guess that your computer can't handle the load at reasonable buffer sizes. Also since you can disconnect/turn off plugins and it works would also indicate that your CPU isn't able to handle the whole template you are trying to use. To add to this you are running all of your samples off of one drive, which yes I can hear you furiously typing, is SSD but remember that the SATA interface on what I assume is a 2012 MacPro 5,1 is 3 Gb/s add to that (depending on the quality of your SSD) delays in the response times of the SSDs and you just add more stress to your CPU which is trying to do this with the "DAW-that-wins-the-award-for-not-playing-nicely-with-others". I do have a question for you though, you said you have a dual CPU Cheesegrater with 2 3.33GHz CPU's... I couldn't find that as a shipping system built by Apple from the 5,1 lineup. Did you put in "aftermarket" CPU's or is this a stock config? Are you sure that is your base clock or is that the turbo clock speed? I would also be slightly concerned about RAM speed, but I haven't really looked into what speed causes bottlenecks. But its low enough that I would look into it. And finally, I would try setting up your template at 48kHz, in fact I would guess this might solve half of your problem since at 96k you have half the time you would at 48k putting twice the strain on your CPU. The higher your sample rate the less time your CPU has to do the same amount of work, the less time your SSD has time to respond, the less time your RAM has to respond. // Oh and in regards to your follow up post. Were these channels virtual instruments? Reverbs? Any correlation to what you disabled? And what if you started using those VI's, plugins again? Did CPU usage increase? Maybe something in Kontakt is loading, and when you turn it off and then on again it isn't loading until its used? Or maybe its something to do with ProTools and Dynamic Plugin Processing? Do you have that enabled? Maybe try disabling it and seeing what happens?



Jan - I saw this same behavior (if not so extreme) when I was troubleshooting VEPro and PT. And I still do see this uneven core usage reported by PT today when everything is working. However when it didn't work it was because PT was unable to handle the Project I was trying to playback. But since you said that it doesn't matter what VEPro buffer you set I would guess that your slave machine is hitting above 80% CPU usage? Or maybe higher? Whenever this happen for me (i.e. I put a synthetic load on my slaves and run an active VEPro project) I hear dropouts of instruments, pop and clicks, or a playback error, combine with high CPU spikes reported by PT. And its always because my slave CPU usage is too high. Also if you are also running a 5,1 MacPro then I would guess in addition to high CPU usage slow 3Gb/s SATA interfaces, and a single SSD for samples as contributing factors to inoperablility. But a few questions for you as well, are you running 5,1 MacPros? What are their specs (especially CPU)? Dumb question, but are you running a gigabit network on all machines (built in NICS on 5,1 MacPros are Gigabit, just want to make sure you aren't running through a 100 Mbps switch or anything like that causing a bottle neck)? The lowest setting for VEPro I would set is project at 48kHz sample rate, VEPro at buffer 2, ProTools at buffer 256. Anything lower I have found to be unstable or unusable. And finally remember that AVID/ProTools doesn't play well with others, so maybe this is a PT glitch, have you tried the standard trouble shooting steps? Trashing Prefs, rebooting? Uninstall and reinstall? I'm having no problems here running 512 MIDI tracks and 250 voices on my system, so it does work... but it can be a pain to get it to work.

Sorry for the long post, hope it was helpful.

-Walter

Hello all, I have been working on building my template in ProTools (PT) and VEPro for a while now. It is currently functioning however I have more latency than I'd like for playing parts in real time. (2 buffers, at a hardware buffer size of 256 for PT). So my question for you all is does anyone have experience with PT and VEPro? And does the fact that PT isn't terribly stable and is giving me an error message about PT running out of CPU resources, mean throwing more cores into my computer would solve the problem? 

Session specs: 512 midi tracks, 256 audio tracks (or near enough). I konw I am at the max system specs for PT without cards... maybe this is part of the problem too?

Computer specs: DAW system - Trashcan Mac Pro Quad-Core Xeon 3.7 GHz 16GB ram. 

Let me know if I can provide any more information! And I appreciate your help!

-Walter

Hey Lior, did you ever figure out what was going on? I seem to be having a similar issue.

-Walter