(No, no other plugins being used for the slave functionality, just VEP.) One thing I am seeing, is that there is CPU saved going to the slave and back, vs. hosting those plugins in Cubase. So it pays, CPU-wise, to use VEP in my situation.

But, getting equal footing is proving to be harder than I thought. VEP seems to be cutting off the audio for reasons that I can't quite figure out. Maybe there's some logic that tries to avoid feedback loops, or if it gets audio from a different "stage / scope" or something.

I seem to be able to circumvent whatever this issue is, by using a new VEP Server Instance. And just when I think I've figured it out, and move forward, it stops working again.

It really is fighting me every step of the way.

All of this pain would go away if they just made a freakin' "Audio INSERT" (not INPUT). Aarrgg.

But, here are my Group Channels in Cubase that I'm trying to use VEP as an external fx rack on (each of them). It's complex, but not crazy -- 24 stereo channels in all. The arrows denote the stages / scopes (what feeds into what, at what level).

Legend:
DB1 = Drum Bus 1
PC = Parallel Compression
BA1 = Bass 1
SUB BA = Sub Bass
INSTR = Instruments (synths, pads, leads, etc. that have been dealt with earlier in the Group Channel chain within Cubase)
LDVOX = Lead Vocals
BGVOX = Background Vocals

-> BUS DB1 KIK (routes to BUS DB1)
-> BUS DB1 SNR (routes to BUS DB1)
-----> BUS DB1 (routes to BUS DB1&2 and a send on this also routes to BUS DB1 PC)
-----> BUS DB1 PC (routes to BUS DB1&2)
-----> BUS DB1 FX (routes to BUS DB1&2)
-----> BUS DB2 (routes to BUS DB1&2)
-----> BUS DB2 FX (routes to BUS DB1&2)
----------> BUS DB1 AUX (routes to DRUMS STEM)
----------> BUS DB1&2 (routes to DRUMS STEM)
----------> BUS DRUM FX (routes to FX STEM)
----------> BUS SUB BA (routes to BASS STEM)
----------> BUS BA1 (routes to BASS STEM)
----------> BUS BA2 (routes to BASS STEM)
----------> BUS INSTR FX(routes to FX STEM)
----------> BUS LDVOX (routes to VOCALS STEM)
----------> BUS LDVOX FX (routes to FX STEM)
----------> BUS BGVOX (routes to VOCALS STEM)
----------> BUS BGVOX FX (routes to FX STEM)
---------------> DRUMS STEM (routes to a stereo bus)
---------------> AUX STEM (routes to a stereo bus)
---------------> BASS STEM (routes to a stereo bus)
---------------> INSTR STEM (routes to a stereo bus)
---------------> VOCALS STEM (routes to a stereo bus)
---------------> FX STEM (routes to a stereo bus)

That's basically it.

So, since each one of these is hitting the slave PC via VEP, and since VEP doesn't provide a INSERT (just an INPUT), I have created a new VEP-bound Group Channel in Cubase for each of these. Anything earlier in the chain, in Cubase, that routed to one of the above buses, now routes to the new VEP-bound versions of them. Each of these VEP-bound counterparts (of the above) has just one plugin on it: a VEP Audio Input. Each one of them is assigned a VEP Server Interface instance that's in the Cubase Instrument Rack (this of course goes to the slave and back). The outputs of the rack then simply route back to the buses listed above -- a full loop.

However, having it routed like this, in a straightforward way, with one big 48 channel Server Instance (with IN 1/2 routed to OUT 1/2, IN 3/4 to OUT 3/4, etc.) doesn't work in all cases. VEP often halts the audio. I can't quite understand why.

It will work, for example, with the kick and snare routing to DB1, but then DB1 produces no audio. I had to create a new server instance just for DB1, then it worked.

So, then I thought it was based on the scope / stages (denoted by the arrows in my diagram), so I created a server instance matching the arrows. Basically, one for just the KIK and SNR, another for "Stage 1" buses (the next longest group of arrows in the diagram), "Stage 2" and finally Stage 3 (the final STEMS).

This is how it is wired up now -- exactly. But it doesn't work. VEP is halting the audio, for no reason that makes sense to me, somewhere.

For example, if I bypass the VEP-bound BUS DB1, then I get sound again.

It seems VEP wants a separate server instance for even more of these. Like, just one for BUS DB1. When other things, even at that same scope / stage get sent to it, it shuts down.

What's even more maddening, is that you can "trick" VEP into working by bypassing certain, "offending" Audio Inputs while Cubase is playing, and it will work! Proving that the circuit to the slave and back is connected and should work. But then as soon as you stop Cubase and start again, it stops working.

Worse still, VEP often gets into a situation where it won't play until I save the Cubase project. But this is not a 100% cure.

This is making troubleshooting even more difficult.

Anyway, I'll keep experimenting. It's gonna have to wait until next weekend, unfortunately.

I feel cautiously optimistic that I'll figure it out. :)

UPDATE: I've got the first 10 buses (above) now in sync. The solution, though I have no idea why, was to remove BUS DB2 from the Stage2 server instance and put it in its own Stage1.5 server instance. There was something VEP didn't like about that bus being enabled with its siblings. When enabled, it would completely halt the audio from VEP. Now that all the drum buses are working, I'm moving on to the bass buses. I'm in for more trouble with it, however. Enabling it, once again, cuts out all the audio from VEP. -- It's all just trial and error at this point.

Well, I seem to have it all working. However, my confidence level with the solution is not high. It feels scotch-taped together; like the slightest update from either Cubase or VEP could make it fall apart.

Here's how it all went down:

Trial and error and wack-a-mole trying to enable the rest of the buses while still keeping VEP happy enough to produce sound. The other "offending" bus that needed to be pulled out and placed in its own Server Instance was INSTR STEM. No idea why. It seems very arbitrary. There didn't appear to be anything special about INSTR STEM compared to its sibling Group Channels.

The other piece of the solution was to continue connecting Audio Inputs even as it was continuing to fail. In one case (one Server instance), no sound would be heard until all the connections were made.

In some cases, in this game of wack-a-mole, an offending Audio Input would disable all the audio. In other cases, only some of it. Again, I was not able to figure out why.

The other part of the solution was to try shutting down Cubase and reloading. In some cases, where no sound would be heard, this would restore sound. That "step forward" has in all cases seemed to "stick" and on subsequent loads; everything works.

My intuition as to when to try out this time-consuming test (the Cubase project takes around 8 minutes to load), became somewhat of a black art and I'm not sure I could reproduce it.

But now that it's done and everything is wired up, this should hopefully be a one time deal. If it survives product updates and further useage. We'll see. If the connections continue to stay solid, like they are now, it will have saved me a ton of money on hardware. If it doesn't, VEP is a relatively small price to pay and will surely find other, more normal uses (like offloading virtual instruments).

So, for now I'm going to call this "Solved, mostly."

I should also note that it is really not properly "in sync," strictly-speaking. If compared to the internal metronome track, it's off. But because all the final stems are all out of sync by the same fixed, VEP buffer amount, it's in sync for all intent and purpose. This solution would not work for someone wanting to, say, just process a drum bus. It's an all or nothing affair.

Again, an Audio Insert version of the Audio Input would likely solve these issues by allowing the DAW to do its PDC thing properly.

Unfortunately, my "scotch-taped" suspicion was true. As soon as the project is manipulated and worked with, VEP cuts the audio out, like it does during the setup.

The fix is to save the Cubase project under a new filename (just saving doesn't work), then, inexplicably, VEP restores the audio. It's a simple fix, but I'm not doing this every time I add an insert, etc. Just on principle. That's no way to work.

So, it just doesn't seem possible to use VEP as an audio insert on group buses; too unstable.

Super bummed out about this, as the only solution left is hardware and that doesn't get to enjoy the parameter "snapshot" ability that makes VEP so great.

And, it's gonna cost like 4 grand for a hardware solution.

VSL, if you're listening: I'd pay 1000 bucks for VEP if it had a working Audio INSERT, rather than just an Audio INPUT (and I'd still save money). :-)

Thanks so much for the reply, Paul.

That is wonderful news!

Hardly even a "pivot" and you should quickly own that market space, and perhaps a few ancillary markets near it. I can even envision new cottage industries orbiting your products (e.g., 2U high, rackmounted VEP-ready slaves, etc.)

Exciting times!

Also, to clarify, I'm not sure the CPU spiking issue is related to the behavior I was seeing.

At least the issues I've found are reproducible; that's a good thing.

Anyway, if you need a beta tester to put the fx rack use-cases through their paces, I'm interested. :)

Best regards,
Jim (jalcide)

@jalcide said:

(No, no other plugins being used for the slave functionality, just VEP.)

All of this pain would go away if they just made a freakin' "Audio INSERT" (not INPUT). Aarrgg.

I can't really follow most of this. The question per other plugins was, in Cubase, these busses. It appears you went to straight VEP from something that was going on in Cubase before the fact.

Also, not sure what you mean by 'insert not input'. You can connect to Audio Input by an insert rather than instantiate an FX bus for it. Sorry if that is completely clueless and I'm not following.

The remark about having to save in Cubase makes me ask, are you working coupled? A heavy use of VE Pro is best worked with uncoupled, it's more stable.

@Another User said:

...are you working coupled?

I tried it both ways. No difference.

Also, the saving of the project under a new name only restores the audio if you revert to the previous state (e.g., delete the plugin you added). So, it's not really a workaround, after all.

Also, UPDATE: I tried creating a server instance for each of the 24 stereo channels and that didn't work, either. It seemed to solve the cutting out of audio, thing, but was completely out of sync.

At this point, I'm just going to use VEP as it was mainly intended: to offload virtual instruments. Which I still have an interest in doing.

As for my need to output the 24 stereo stems for further processing, and back? I still need to find a solution for doing that while we wait for VSL to deliver their "FX Rack" solution for this.

Since my i7 4770K is already water-cooled and overclocked, I'd need to move into a more expensive processor with more cores to do what I need all in one computer. This may turn out to be a cheaper solution than two 48 channel audio interfaces. Well, for sure it would.

Then, I can move my current motherboard/CPU into a slave for other VEP tasks. This is probably what I'll do. Worst case scenario: The faster, higher core CPU is still not enough. In that case, I'll need to go the Audio Interface route and now just have a faster computer and a very fast slave. So, not a total loss, as I've just future-proofed myself a bit earlier than I need to. 😊

But the VEP "FX Rack" solution will always remain the best way, as it allows the DAW to contain all the parameters within its project. Anything else is a less than ideal solution.

@civilization 3 said:

The question per other plugins was, in Cubase, these busses. It appears you went to straight VEP from something that was going on in Cubase before the fact.

If I understand what you're saying here: It's, does the fact that Group Channels before the Group Channels with VEP, are the sound sources, matter?

I'm not sure. I don't think so. The PDC in Cubase that works before VEP and after VEP should all be okay. It's only stuff happening in parallel with VEP that causes the sync issue, I suspect.

The stuff that happens in parallel, does it involve other plugins? I don't get why 'in parallel' through itself does this.

I think you may want to consider more than one slave rather than hope there is one computer out there. It's too hot for me to try and say why though.

If you're finding saving the project under a new name does anything, I think you could be experiencing corruption of projects in Cubase (overheating).

I can confirm there's no overheating or project corruption happening. The machine runs so cool and stable it passes the "Intel Burn Test." When Cubase corrupts projects (v6.5 did that to me twice), it's easy to tell: It crashes when attempting to load the project.

VEP's audio cutting out, is very likely a coding issue between VEP and Cubase. The save acts as a sort of "reset" to a state, somewhere between the two. Since it happens during an edge-case (not typical use) of trying to shoehorn an Audio Input into doing something it really wasn't designed for, it's less a bug and more lack of a feature. :)

It may be related to the thread thing, but that seemed to be mostly CPU spiking, which I was not seeing a problem with.

As for your "several slaves" better than "one super computer" recommendation -- I totally agree.

I'm already doing that for my mastering chain via simple optical cables to a computer dedicated for just that, using Cubase's external plugin thing. It's awesome.

When I have some time, I'll try to recreate my sync issues in a simple, reproducible project. So that we can wrap our heads around it.

Thanks. Yes, I thought of that, too. It wasn't off initially (first few tests), but had been off since. No difference in behavior.

(Also, I'm using the VST3 version. Everything is x64, as well.)

VSL, it's been a year. Any progress on the "FX Rack" product you mentioned.

I'm still looking for a solution.

Hope it's going well!

Cheers.

Hi jalcide, 

Yes, time flies! Unfortunately I don´t have an update for you there, but it is on our long wish-list for VE PRO. 

Best, 
Paul