Vienna Symphonic Library Forum
Forum Statistics

194,418 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 82 new user(s).

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


  • 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


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


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


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


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


  • 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

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


  • Does anybody tested VEP with Logic, Pro Tools or anything else and had the same problem?

  • No problem with the test I have done with Logic, but I had less than 10 audio tracks, but 100 VI


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