Vienna Symphonic Library Forum
Forum Statistics

194,415 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).

  • last edited
    last edited

    @Zelorkq said:

    the "one mixer solution" that I was keen on using...
    means you aren't taking advantage of the power of VE Pro. While I used the term 'submixer', it is the mixer. I reckon 'groups' mixing is a better way to put it.

    but you're stymied by needing Steinberg's proprietary plugins somewhat.


  • I seem to have phrased the insert effects priority a bit wrong, sorry about that. I wanted to put emphasis on third part insert effects, Cubase insert effects being secondary. But I have just now found out why my third party plugins did not work in VEP: 32 vs 64bit incompatibility, but I've solved that issue now, so I can use those in VEP. I can live with not being able to use Cubase insert effects, I'll just abandon them I guess. This way I would be able to use my master VEP as my main mixer. Thus I can remove the master VEP outputs that went to Cubase, which will definitely speed things up.

    I'll then have to see how to set up the reverbs in VEP with buses. MIRacle versus Vienna Suite's Hybrid Reverb, no idea which would be better. At the moment I was using Hybrid Reverb sections for strings, brass etc. which each only had the early reflections, and the main output channel which only had the tail (so grouping of some sorts).

    Back to the routing: However, even if I change the above, I'm still sitting in front of my main problem: the audio input plugins for my slave VEP. I'm not 100% sure I understood your setup. Is there a way other than audio inputs via Cubase to get the individual outputs of my slave VEP to the master VEP? Because as I understood the VEP master/slave principle, the slave VEP outputs go into Cubase, from within Cubase you route these outputs to the master VEP inputs (via audio input plugins, which is killing my asio performance - according to Dietz optimisations of Cubase that interfere with VEP). Once I change the above-mentioned, 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!


  • It looks like you did not understand why you have drop outs !

    You have them because there is too much to do !

    You have a bottle neck in your configuration !

    Up to you to find it !

    My guess is your 200/300 audio tracks !

    Start with 20 tracks and see if it is working ok !

    What hell are your 300 tracks ?

    Use articulation switching and the VST Expression Maps 


  • I do understand why I have dropouts, I'm asking for too much. The thing that bothers me is that I can receive way more outputs from my slave VEP (over LAN) to Cubase, with no problems whatsoever, than I can re-route with audio input plugins. That's many outputs going through LAN, so for some reason there is no bottleneck here, even though this is the actual network communication of so many audio streams. The only problem is the re-routing of Cubase to master VEP, which is localhost. My guesses are, that the re-routing is kind of 'outside' of Cubase, and every audio input plugin between the two VEPs is continuosly sending data, just to keep its link open, or the optimisations of Cubase, as mentioned by Dietz, are interfering.

    I am already using Expression Maps for as many instruments as possible. To roughly some up my 300 outputs, these are 300 Mono outputs, VEP always grouping them in pairs, so it's 150 instruments basically. On that slave VEP I've got all my Berlin Woodwinds (14 instruments), all of my percussions (easily 30 instruments), Piano, Harpsichord, Harp, Organ, Choir and the lot, Guitars, Cinematic Soundscape stuff, Heavyocity patches etc., which sums up to 100-150 instruments. My master VEP basically has Hollywood Strings + Brass, Dimension Strings + Brass, which is also 60 instruments (with place holders for Dimension Strings Violas and Basses). I cannot swap these to the slave VEP, because especially PLAY loading times needs my SSD.

    The only solution I can see is grouping my slave VEP instruments in a slightly unflexible way, e.g. grouping all Berlin Woodwinds into one woodwinds output section, grouping the entire Percusion into one output section, etc.. Then I'd have my 20 outputs at max which should work for 'audio input plugin' effects. Disadvantage is that every Oboe, Clarinet, Flute etc. is placed at the same MIR position. But if that's the only way around, then I guess I'll have to do a compromise. (which is what I'm going to try out and post my results) Maybe if I get myself a new soundcard at some stage (with proper drivers), this issue might be resolved, but I wasn't planing on doing that for some time.


  • Well I've changed my template and grouped all of my outputs of my slave VEP to 20 or so outputs and routed these to Cubase, re-routed via audio-plugin to my master VEP and then MIR. This setup works fine with the asio limits not being reached, its just not as flexible as could be, because for eg. my Woodwinds are all grouped as one instrument in MIR. But that's a compromise I took into consideration. A single PC solution would've been easier, but then I'd need an insane machine.


  • Why dont you try the solution I have proposed :

    1) On the slowest PC :

    • Cubase 
    • All your orchestral VSL tracks send as midi to 2
    • Play send as audio to 2
    • Kontakt send as audio to 2
    • ...... send as audio to 2

    2) On the fastest PC with SSD

    • VEPRO with MIR 
    • The output of MIR send back to 1

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

    1) On the slowest PC :

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

    2) On the fastest PC with SSD

    • VEPRO + Play + K5 + .... with MIR 
    • The output of MIR send back to 1


  • Reducing the number of outputs was your advice I followed, which is working much better now. The way I grouped it was the only solution that was plausible for me.

    Your proposal 1 would be to load all sample libraries on 1), the slower PC (if I understood that correctly). And your second proposal would be to load all sample libraries on 2), the fastest PC. I can see how this would work and better performance (especially proposal 2 which has less network send, being only midi). But for me there are two drawbacks: a) Your proposals are both solutions for loading only one PC with sample libraries, and b) both would have Cubase run on the slower PC, the one I only connect to via Remote Desktop.

    a) I thought I had posted this as well, but reading back it might have slipped me. What's important to me is that I can utilise as much RAM as possible, thus using RAM of both PCs to their fullest extent (I'm already purging quite a few instruments). So I have to split my sample libraries, meaning (as far as I know) I will need VEP on both PCs and I will have to use many outputs with audio input plugins.

    b) Running Cubase via Remote Desktop is sluggish and I'd have to fix my soundcard, speakers and midi controller to that PC as well.

    The way I've currently set things everything's working alright. I 'benchmarked' my MIR yesterday and the grouping doesn't seem to be that bad, because I could never have used so many ungrouped outputs in there, not by a long shot. MIR is amazing, but hungry.


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

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


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