Vienna Symphonic Library Forum
Forum Statistics

194,416 users have contributed to 42,920 threads and 257,965 posts.

In the past 24 hours, we have 4 new thread(s), 10 new post(s) and 81 new user(s).

  1. Home
  2. Software
  3. Vienna MIR & Vienna Suite
  4. Audio Input Plugin Dropouts
  • Cyril BlancC
    Cyril BlancC

    You did not understant at all what mean !

    I give more details :

    On the slowest PC : PC 1 + Monitors 

    • Cubase 
    • All your orchestral VSL tracks send as midi to PC 2 (only the VST that sends midi and receive the 2 track from MIR are loaded)
    • Play send as audio to 2 (Play lib is loaded in PC 1)
    • Kontakt send as audio to 2 (Kontakt lib is loaded in PC 1)
    • ...... send as audio to 2

    It is the VSL VST that are dealing with the traffic between your 2 x PC 

    On the fastest PC with SSD : PC 2

    • VEPRO with MIR (All the VSL instruments with there samples are loaded on PC 2)
    • The Play, K5 instrument are received via audio input
    • The output of MIR send back to 1

                                                --------------------  OR ----------------------

    On the slowest PC : PC1

    • Cubase 
    • All your orchestral VSL tracks send as midi to PC 2
    • All Play, K5  instruments are send as midi to PC 2 

    2) On the fastest PC with SSD

    • VEPRO + Play + K5 + .... with MIR  (All the VSL, Play, K5 .... instruments with there samples are loaded on PC 2)
    • The output of MIR are send back to PC 1 by VEPRO
    The best solution is to have 2 or more monitors (I have 4 x on one computer) but is you dont have the money 
    You have monitors with 2 or more entries 
    Or for a few $ you buy a switch to put one monitor on 2 x PC
    You dont need remote desktop (I use the equivalent on Mac as it is not at all sluggish specialy in GB Ethernet)
  • Z
    Z

    Proposal 2 is the same way as I explained it, which won't help me because one PC is doing almost all the work and loads all the libraries. Seems I only misunderstood proposal 1. However, now that I undestand what you mean, your proposal 1 says that PC2 receives all Play & K5 outputs of PC1. That's the original problem is it not, because there are soo many outputs for Play & K5 to be sent via LAN. I'd still have to configure those outputs with VSL audio input plugins, which would throttle performance, as is the case in my original post.
  • Cyril BlancC
    Cyril BlancC

    it's really depends where you put priority,

    I am in 5.1 or 7.1 and I give all the priority to VSL instrument so they are well placed  ; Play, K5 and Omnisphere on my configurations just need a few tracks.
  • Z
    Z

    I'm only on stereo here. My VSL and PLAY tracks are all positioned completely individually in MIR, it's just my K5s that aren't, which is fine. I'm somewhat happy now with my setup, it also means my MIR isn't as cluttered as before. Thanks for your proposals & help, tho it seems everyone has a different setup, priorities and preferences (and amount of monitors haha).

    Cheers
  • civilization 3C
    civilization 3C
    last edited
    last edited

    @Zelorkq said:

    I wouldn't 'need' any outputs in Cubase anymore, except for one or two from my master VEP.

    I don't see how grouping would help here, because I want to have each instrument of my slave VEP separate in my master VEP's MIR for perfect positioning. How do you send your slave outputs to your MIR instance?

    Thanks a lot for your assistance in this matter!

    I mean grouping in terms of VEP's output. the whole point of all that is to indicate you can have all the placement onstage you want, mixed in VEP and returned to Cubase in terms of maybe even one stereo channel. When I said the power of VEP, that is what I mean, as the mixer, and in particular taking the load off of Cubase. IE: if you have a hundred channels from a plugin in Cubase, grouping does not reduce the resources used; using VEP as *the* mixer as I do means say 4 stereo rather than 32 stereo ch. for Cubase. VEP working in its process and as the handling of cores etc is much more efficient, to boot.

    Flexibility is not synonymous with more outputs, through the fact of more outputs. You have MIR Pro and all of this placement; this is not diminished by the act of grouping per se. What happens on that stage, what happens with all the pre- or post- fader FX and sends, etc, does not vanish because we, at the end of the day, reduced the number of outs. In terms of your problem, using more resources than you can manage, it absolutely helps and it does not reduce the flexibility in the mixing; it is a matter of embracing another paradigm.

    this exceedingly high # of outs is kind of novel to computers and DAWs. When it was physical, no one would want it until it's something you can't manage without.
  • civilization 3C
    civilization 3C

    I'm not conceptualizing this for MIR Pro as a plugin into Cubase, I'm just describing how it worked for me, in VEP. Hence going into the difference of resources management. To be perfectly clear, the MIR instance was the slave. Sometimes I would send from a different instance of VEP to the MIR instance via Cubase, as audio input which seemed to more or less weigh it down the same as a channel in the same instance.

    for all intents and purposes, it would be the same procedure for the 'master' or local host instance of MIR Pro in VEP. I don't think MIR Pro as a plugin in Cubase is a great idea, is the upshot, which I have yet to state bluntly. It's competing with other things inside Cubase's process, and you illustrate sending to it is more than your pretty robust system will do. Sorry I was less than clear in these senior moments I have.
  • civilization 3C
    civilization 3C
    last edited
    last edited

    @Another User said:

    I wouldn't 'need' any outputs in Cubase anymore, except for one or two from my master VEP. I don't see how grouping would help here...
    if you have decided on 'one or two from your [] VEP', that is precisely what I indicated by mixing down to groups, busses, whatever name one uses.

    Your bottleneck was largely doing things in Cubase, as all of the things are competing for priority in the process that is Cubase.
  • Z
    Z
    last edited
    last edited

    @civilization 3 said:

    if you have decided on 'one or two from your [ VEP', that is precisely what I indicated by mixing down to groups, busses, whatever name one uses.

    Yes my outputs from VEP are set up exactly like that now. My slave VEP groups its outputs and sends only selected groups to Cubase. From here only these few are re-routed to my master VEP. And I'm using MIR in VEP, not in Cubase, all working fine.

    Thanks for your clarification on the matter!
  • A
    A
    Hi there, does anybody solved the problem? I have contacted the VSL-support and they said to me to disable the "ASIO Guard" in Cubase 7. But this does not helped at all. I am totally annoyed because VSL said, that Steinberg is responsible for the problem, but Steinberg says, that they don't have any problem with plugins, except with Vienna Ensemble Pro. So who is responsible? P.S. I have tested this with 2 pc-machines: *Intel Core i7 32 GB / RME interface *Intel Core i7 Extreme 64 GB / RME interface
  • civilization 3C
    civilization 3C

    I have seen far too many reports from people that never heard of VE Pro that their {virtual instrument} performance was buggered by Cubase 7 for me to believe Steinberg's - forum's? - story.
  • A
    A
    Does anybody tested VEP with Logic, Pro Tools or anything else and had the same problem?
  • Cyril BlancC
    Cyril BlancC

    No problem with the test I have done with Logic, but I had less than 10 audio tracks, but 100 VI
  • A
    A
    I have checked it with Pro Tools 9. After 15 tracks the "CPU (RTAS)" display "explodes" and show betreen 20% - 40% and sometimes 100%. So I would say, that the Realtime Peak in Cubase depends not on Cubase itself, it depends on the "Vienna Ensemble Pro". I should ask Vienna Support for this problem again.