Vienna Symphonic Library Forum
Forum Statistics

183,723 users have contributed to 42,313 threads and 255,144 posts.

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

  • Render in Place (Cubase) with VEPro

    Does VSL have ongoing dialog with Steinberg about integration?? Because this is really a Cubase question but will undoubtedly disappear into a black hole if I try and ask them about this...

    Render in Place is an incredibly useful feature in Cubase when using VEpro6. The main advantages I can think of are:
    1) It prevents spurious midi parameter changes to the VSL instrument/channel from creating a headache further into the project.
    2) It commits/prints a performance so I’m less inclined to think later “oh I’ll try that differently”
    3) It frees up CPU
    4) If ultimately there is something wrong with the result it is entirely reversible.

    But there is one major flaw when doing this in a large project.
    Lets say I have a string section (VEPro Instance tab). There are separate busses for the various parts - I normally have 7:
    (Vi1; Vi2; Vla; Vc; Cb, Hp; and finally one for ensembles)
    But if I want to render a few bars of my Vi1 part I always end up with 7 new tracks with 7 brand new audio files comprising my Vi1 bounce , but also 6 silent audio files.
    I have to go in and clean up the project each time (remove track function in Cubase) and eventually clean up the audio pool and delete the unwanted audio files as well. All very cumbersome.
    The only way of preventing this seems to be to deactivate the outputs I don’t want from the Cubase rack - but if I do this and then re-instate them the routing and naming conventions have all been thrown away. So that’s a non starter.

    I know this is a Cubase issue but do the R&D guys at VSL have any clout with Steinberg to address this issue and come up with a feature request/solution?

    Or is there someone in the community who has a better workaround for this that I haven’t yet figured out?

  • FIXED !! or at least - here's a workaround.

    In the screenshot I have a short midi brass part. It’s routed to a VEPro instance which has just two sub-busses (I call them hi brass and lo brass)
    This brass part is a single midi region playing a single instrument (ie: no layers in VEPro)
    If I simply select the region and go to “render in Place” (and mix down to single audio file in settings) then two audio files are created on two new audio tracks with the buss names (ie: VSL hi brass and VSL lo brass)
    The colour coding is inherited (in my case red) and the routing is also retained (in my case the VSL brass buss)
    It makes no difference what I solo, track / folder/ sub-buss - the behaviour is always the same.

    Purely by accident (because I was rendering Dimension strings with multiple tracks playing layers in the same folder AND the same VEPro instance):

    Here’s how to change the behaviour:
    I just write a new part on a different instrument in the same group - In my example I was rendering from Player 3, so I created a completely empty region for player 2.
    Then rubberband both regions and try render in place again.
    This time it creates a SINGLE audio file and audio track with the name I stipulated in render settings - but this time it’s colour code is grey and it is routed to the stereo buss.
    So I still have to change the routing to my brass buss and change the colour code (which I do for audio anyway) but my project and audio folders are not cluttered up with lots of audio files and empty tracks that I don’t want.


  • last edited
    last edited

    Hi Richard,

    We are in touch with our colleagues at Steinberg, but mostly concerning interface improvements for our own plug-ins.

    How about the Steinberg User Forums?


    Paul Kopf Product Manager VSL
  • Thanks Paul - as you will see I managed a workaround, but the behaviour suggests that it is rather quirky - it is not intuitive, or logical.

    But as I admitted in the OP I am quite aware that this is a Cubase thing, not Vienna.