Vienna Symphonic Library Forum
Forum Statistics

180,804 users have contributed to 42,141 threads and 254,364 posts.

In the past 24 hours, we have 1 new thread(s), 7 new post(s) and 73 new user(s).

  • Audio Input (wired as Insert) on Cubase Buses = PDC / Sync Woes

    I realize attempting to use VEP as an "external effects rack" is an "incorrect" way to use it. But that doesn't seem to stop many of us from trying. :) I'm trying "insert" on a bus to offload some processing. So, Cubase kick drum track -> Cubase Group Channel (with null output) with VEP Audio Input insert -> VEP Server Interface (to slave and back) -> new Cubase Group Channel to the right of the "sending" one that receives what comes back. The kick is completely out of sync. The PDC seems to only take into account outputting to stereo outs, not yet another bus. I can't even think of a use-case where this is helpful. Clearly, I'm missing something. Where did I go wrong? (Insert joke about trying to use VEP as an external effects rack here) I'm on day 1 of a 30 day trial. Hopefully, there is a Rube Goldberg way to get this working. Latest version of VEP Pro. Latest version of Cubase (7.5.20) x64 Windows 7 x64. VST3 x64 versions of plugin.

  • Well, I have used it with success every time. If one is using MIR Pro, this is actually a normal function. (btw, one thing you need to know is that in terms of Cubase architecture, the audio input of VE Pro is a literal send, ie., it is an external entity, so you must export in real time or you get empty files, or if a two-file the audio from the 'send' is missing.)

    You do not need this return bus at all. The instrument channel [Cubase receiving the output you have assigned in VE Pro for this FX bus] from VE Pro is sufficient, I mean it _is_ the de facto return of this send. VE Pro isn't the issue. The extra bus is internally Cubase and is not subject to PDC, so there is nothing unusual there. But it's completely extraneous. VE Pro is an instrument to Cubase here, there is already a 'return' bus as you will specify.

    BUT, it's an external instrument in terms of this particular bus, the channel connecting to VE Pro in this manner is sending to the outside world and offline renders bring back nothing.


  • Thanks very much for the reply!

    Yes, I think I do understand the full signal path it's taking with the instrument channel being the end-point for the return signal.

    It does appear delay compensated if the return, itself, is monitored directly without being injected further in to the signal path (i.e., another Group Channel). That is, if it's set to "stereo out" and not another Group Channel. But at that point it's "outside the song" and does not end up in the mix.

    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.

    My guess is that it has to do with the use-case for the Audio Input being used only as a "send" in the most traditional sense, for reverb, or something. But even there, I don't see how that returned signal can be "injected" in a way that's PDC. I need to find a return path that's not in the project's PDC path, or something. That is, I need to find a return that similar to the "stereo out" in that it has zero latency on it. Perhaps where you place it along the path, matters. Perhaps I'm trying to inject it too far towards the end of the chain.

    I know they're not going to, but I wish they'd just make an "Audio Insert" plugin that was like the Audio Input, but with a direct output on the other side. It would eliminate all the confusion, plumbing and PDC issues (for this "wrong" use-case that I am trying to wrangle VEP into).

    Again, many thanks for the assistance! I'll keep trying. I've only spent a few hours with it.

    (Also, why is this forum / website not putting my newline/carriage returns in! it makes it very hard to read -- sorry about that -- it's not me doing that. Ah, putting in BR tags does the trick. Is that how we're supposed to get linefeeds in these posts?)

  • I've connected the VEP instrument channel's output to every possible end-point it has available to it, and still, except for "stereo out," there is no way to get my kick drum test track to sync AND be in the actual mix.

    Very frustrating. Either I'm missing a major conceptual thing here, or it's just not possible.

    My attempt to do this "external summing" notion is further frustrated by the fact that PC's have no standard way to aggregate audio interfaces. And there is no way I'm using that ASIO for All thing to duct tape that together.

    Wormhole is no longer supported, nor is FXTeleport. Waves' solution is too proprietary and expensive. Reaper's Reamote would require too many moving parts if I'm to use it with Cubase.

    It seems my only sane path is to buy two 32 channel (16 stereo) audio interfaces, one for each computer, and connect them, old school, with freakin' audio cables. They still sell audio cables, right? :-)

    VEP is sooo darn close to solving this for me, if it would only keep PDC sync the way I need it to.

    UPDATE: I'm attempting to use manual delay plugins to see if I can coax a synchronized result from VEP. Cheaper than audio interface alternatives.

  • I'm trying to reproduce what you are seeing, but I'm not clear exactly how you are working. This is my understanding so far:

    1. Load VEP Server
    2. Load Cubase project
    3. Load VEP in VST rack and connect
    4. Create audio input channel and set input to 1/2
    5. Add required plug to Audio input channel
    6. Create audio track in Cubase project with an audio file on it
    7. Create Group 1
    8. Create send from audio track to Group 1
    9. Load VEP Audio Input plug as an insert and assign to 1/2
    10. Create Group 2
    11. Route VSTi Output to Group 2

    So, in my project, everything is in sync. What are you doing differently?

    DG


  • 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!


  • never mind, that was redundant, you have that much.

    I have no idea why it's out of sync actually. I was really thrown by your inject into the path business, but you appear to be doing things normally and the VEP channels are out of sync with things inside of Cubase. This should not be true. Something is basically wrong, like you are restraining PDC or something.


  • last edited
    last edited

    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.


  • Ok, towards proof-of-concept I just did this: I have an audio track. I made its output a group bus I created. The audio track itself is sent to VEP and an effect. I printed the group and the instrument channel. I made the three pieces of audio into parts and opened up the parts editor. All three are perfectly in time with each other.

    What are you doing that's essentially not this? I hope I'm not being obtuse.

    My brain does not give me any abstraction where your scenario is true. I would have to test it but I think that is that test. You seem to be saying that if there are other groups, they will be out of sync with the VEP result. I don't think that's right. So my question now is 'what is wrong with Cubase?' Have you ticked 'Constrain Delay Compensation'?


  • 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. :-)


  • So there are other plugins involved?

    Yeah, it's designed to be point A to point B and back. It's also made to rid us of the multiple soundcards thing of Giga farms in the (more and more distant :D) past.

    I think Audio Input came along later. It's not atypical to use VEP hosting MIRP purely like an effects rack, putting the players on the stage from audio after the fact of the MIDI, but this is resource-intensive as well and ought to be simple.

    So you will have to put everything on an equal footing. But 24 channels sent to and coming back is going to gobble CPU.

    I think the thing to do is to more and more make the groups in VEP and get away from Cubase as your main mixer. But if it's massive use of Audio Input your machine will know it. But Cubase may be making your machine balk in the same quality.


  • (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). :-)


  • Hello jalcide, 

    We are listening. 

    Cubase 7 and DP8 have changed their threading models, which makes it hard for the audio input and/or event plugins to operate reliably. Under certain conditions, it can cause CPU spikes.

    Our developers are working on a different solution to use VE PRO as a FX host for Audio Tracks, more like a RACK option. 

    Unfortunately I cannot give you a time-frame for this next version (VE PRO 6?), but this topic will be addressed. 

    Best,

    Paul


    Paul Kopf Product Manager VSL
  • 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)

  • last edited
    last edited

    @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.


  • last edited
    last edited

    @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.

  • last edited
    last edited

    @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).