Thanks for this.

Here's my setup, in a real-world project, but I'll try to reproduce your vanilla setup, as well. But for now, here's my current setup:

1) A Cubase Group Channel called KickBus has a high and low kick sent to it from two virtual instrument sources. Some inserts happen on here to glue the kicks together. This Group Channel can be considered the sound source.

2) The output of KickBus is sent to another Group Channel called DrumBusVEPOut.

3) DrumBusVEPOut has a VEP Audio Input plugin and a null output (since Audio Input terminates the signal path anyway). It's set to IN 1 / IN 2 from a VEP Server Interface instance in the Cubase Instrument Rack.

4) In the Cubase Instrument Rack there is a VEP Server Interface Plugin with its OUT 1/2 enabled and showing in the Cubase Mixer Console (I've also done the test with a Virtual Instrument Track, no difference).

5) I then route this OUT 1/2 in the Cubase Mixer to a Group Channel adjacent to DrumBusVEPOut called DrumBusVEPIn.

There we have the full insert loop.

Totally out of sync with the other Group Channel stems adjacent to it (a BassBus, SynthBus, etc.).

UPDATE / WORKAROUND: A workaround may be to have all those adjacent Group Channel stems (BassBus, etc.) also route through VEP and back. I'm still connecting them, 24 stereo group channels in total, but it looks like it may be the ticket! I'll report back. If so, I'll mark this as "solved." I would consider VEP not quite honoring the spirit of plugin delay compensation, but I'll take what I can get, since I'm using it in a sort of non-standard use-case, anyway. :-)

Thanks again for jumping in!

This is the business that confuses me, but then I read your latest reply. I'm going to leave this up just as a sort of knowledge base thing.

@Another User said:

I'm not sure where I can connect the instrument channel (a.k.a. "insert return") so that it both ends up on the proper two-bus and is PDC. It doesn't seem possible.

You do not need this step. It is connected, it is there as long as you have provided it in the outputs from VST Instruments rack. It's compensated for. You're done, you're golden.

It has a 'two-bus', in the form of, note the image 'FX Verb'. That is not in essence different than an audio channel, you can send that to whatever you like inside of Cubase (or to another VEP Audio Input or other external racks for that matter. In fact the send [to that FX bus] here is from an instrument channel in another instance.).

Thanks for the help.

I think I've got it mostly figured out. It seems VEP is only performing PDC within the "scope" of what it knows about: the slave's plugins. For things like reverb sends/returns, this works fine, as FX sends / returns always work in this basic, "single scope," asynchronous manner.

The problem arises when trying to do things where synchronicity with other Group Channels matters (such as a true Group Channel Insert). VEP only calculates the PDC it sees from the slave and back, not against other "sibling" Group Channels -- and it can't, that's the job of the DAW.

Because the VEP Audio Input plugin doesn't have an output on its other side, there's no way for Cubase to factor in the Audio Input's delay against sibling channels at the same scope. That's what get it out of sync. If VSL made a "VEP Audio Insert" (that would spit audio out the other side) the problem would be solved, as it would let DAWs do their thing at that scope.

I've solved the problem by simply making all "sibling" Group Channels also route into VEP and back. This puts them all on equal footing. The DAW still can't do PDC properly, but since they're all the same (albeit wrong) and since there is no other audio being injected (since they're all main stems), it works.

Still getting the full thing working before I mark it as solved. A few more hours here.

But 24 stereo channel audio interfaces are EXPENSIVE. And I'd need two of them. So, if this all works (looks like it will) it's gonna save me thousands. Literally.

Basically I'm using VEP, an old spare rackmounted PC, an old 20" Apple monitor (and some Sonimus and Slate plugins), to create an external, 48 (mono) channel "summing box" for 24 stereo stems. Kinda like a D-Box or Orpheus unit, but all ITB.

Sync issues aside, the workflow and sound is amazing.

I'll report back as soon as it's all working, but so far so good.

Yeah, you'll need a more complex example that has several "stages" of latency scope. "Scope," the way I'm using the term here, is created when several Groups sum into another Group -- with plugins causing latency at each stage. Also, a signal "stage" (a given scope) that has more total latency than a VEP instance at 1 or 2 buffer sizes, lower in the latency staging (earlier in the chain), would probably help to cause the situation I'm in. Not sure, I'd need a whiteboard to figure it out. :-)

This is an exercise in how much latency complexity DAWs with PDC actually hide from us.

But, bottom-line. I've got a massive project, with many buses feeding into other buses, which is why I've found myself here with VEP. So it's unlikely a simple project with just a few tracks, plugins and Group Channels is going to easily reproduce the sync issues.

(Also, no, Constrain Delay Compensation is not enabled.)

I'm still struggling, but it looks promising. VEP is really fighting me. It absolutely does not want to be used this way. Lol.

But, again, I'm to the point where VEP is really my only software-based solution to do this ambitious thing. If it doesn't work, I'll have to buy two massive audio interfaces (or even 4 ganged together, like the Focusrite line) -- which would suck. And probably will not happen for a long time ($$$$).

OS X would make the hardware path easier, as it supports aggregated audio interfaces better than Windows, but I've moved away from Mac to get into a more sustainable (cost effective) upgrade path (old PC parts find their way into slave machines, etc.).

And I just can't rest my entire workflow on ASIO4ALL (to aggregate audio interfaces, for the hardware-based solution) -- so that's off the table. I think that thing is maintained by one dude in his spare time. Lol. But I could rest my entire workflow on VEP, as it has so much support in the film industry. It's clearly a very stable, robust and mature product.

I'm just trying to use it in a way it wasn't designed for. :-)

(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