Vienna Symphonic Library Forum
Forum Statistics

182,719 users have contributed to 42,254 threads and 254,894 posts.

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

  • the only why/how of when the empty instances will connect automatically is when you load the PT project while there is an empty instance of VEP waiting that's already previously connected, such as, you're still loading metaframes when you open a PT project. IE: the M.O. of decoupling involves loading the metaframes fully first. if they're not fully loaded, the connection end of VEP believes they are empty.

    One reason I preserve is to name them, for instance they're always called 1, 2, 3, 4 corresponding with the slot in Cubase that's connected to them. I know from that what's happening. It's clearer to me to not have them quit automatically, I could screw up and lose changes forgetting to save; it forces me to decide to save or not upon quitting.


  •  Hmm...then I don't get it, but what else is new ;)

    This is my daily workflow:

    1. Start VEP 64/32-bit Servers on the slave
    2. Open a PT session on the master
    3. Load the metaframes
    4. Connect PT to the slave instances (decoupled as of recently)

    When I'm done with the open session I save the PT session and the metaframes, and close the PT session. The VEP projects will also close.

    1. Open the next PT session
    2. Load the next metaframes for that PT session
    3. Connect PT to the VEP projects, which are named "Untitled", but there are also two instances called "New".

    I'm sure it's not a big deal, but I just want to be on the safe side.


  • when you load the metaframes first, once you have saved the PT session with them connected, PT will know what to connect to the next time you open that session and connect automatically to them. IE: it knows that either way, for coupled and decoupled; but the difference is it isn't saving what there is to load on the VEP side.

    there won't be any connecting to empty new instances as long as the metaframe is fully loaded. this is as safe as it gets. the automatically created new instances are only relevant if you need a new instance.

    I haven't imagined any particular disadvantages to preserving, except that you have to manually delete the vi frames or exit out of the servers, but there is the advantage of naming them. Mine goes like this:

    1. open both VEP servers and load metaframes.
    2. I can launch Cubase at any time, but I must wait til 1. is done before opening the project.
    3. all of the instances are connected to properly and I'm ready to work.
    at the end of a project:
    1. I close the cubase project, or quit cubase
    2. I either delete the vi frames and replace them, or:
    3. I quit VEP, or:
    4. I don't.
    so, for the next project I (per 4) have the metaframes ready as a template, (per 3) I have a clean slate, or (per 2) a partial template .
    when I have a clean slate, I have, in addition to vi frames, channels or channel sets as building blocks to make the next metaframe.
    Rarely - if ever - does my next project use the same template or metaframe, but I have many options. Such as bass sounds fully produced I know all about, or kits in BFD, or a horn section, etc.
    there are the same two new instances created and available no matter what, til the cows come home, once you've used the new available ones. but the way I work, they will only get connected to by accident during loading VEP if I jump the gun opening the .cpr.

  • Trying hard to follow this thread but my brain hurts and I've lost the plot.

    I hope the guys at Vienna know just how utterly confusing the whole Meta Frame, Server, Preserve, Unpreserve, Couple, Decouple etc situation is for non orchestral template guys who work on several utterly different projects a wee (sometimes in a day).

    And it doesn't matter how many times you revise the manual. It's still confusing.

     I'll admit it's beyond me and I use it every day.

    I'm not surprised to find that Civilization doesn't really know what's going on under the hood and has experimented until he found a way to work that suited him.

    That's exactly how I work with VEP. I don't really know how it all works but I can get around it.

    The whole Decouple, Preserve and Unpreserve situation and how they effect the host's saving status is just to confusing for a mere mortal.

    I HAVE to save every project individually. I am producing 60 plus finished masters a year at at any time I need to recall and change a line in any one of those tracks going back 4 years. If the correct Metaframe (or whatever it is) does not load then I am in deep trouble.

    So Civilization let me understand something...... if you keep using the same Metaframes or Instances then what if......

    1 You used a BFD kit in a song and then a year later you changed that kit because you wanted a different sound. What happens when you load the older track?

    From reading your posts it seems you save all the Metaframes with individual project names. So you would be saving a 32bit and a 64bit for every project.....correct?

    That would explain the recall thing.

    In short I'm assuming that you always run decoupled and diligently save your metaframes.

    Correct?

    Just trying to get a handle on a better way to work.

    Thanks.


  • It isn't confusing to me, but that is because I only know from doing it. I don't like to read words on how to do something. I'll read the Cubase manual or a Reaktor manual when I must, but I'm not built to read manuals or technical writing. I had to read the Vienna Instruments manual to get any handle on dimensions, but I think a video is clearer to me, and I think the VSL tutorials are quite good.

    Here's how I use BFD in VEP: my preferences in BFD2 are 'load nothing on startup'. However, I save everything as a preset, which is mixer and mapping, everything. I let VEP remember what kit is in what project, it loads that kit. 

    (By project, or 'instance' I mean a vi frame. One or more vi frames reside in a metaframe. I definitely save the BFD2 vi frames/projects with a descriptive title that starts with "BFD". I keep BFD2 separated, it's a 32-bit and it uses memory, and it's a fancy GUI, and fancy GUIs don't play so well with other fancy GUIs inside VEP. Such as, Kore 2 and BFD2 in one vi frame is problems waiting to happen.) 

    I am using both 32 and 64-bit servers, so yes I'm saving both. I have run into trouble with older projects where I used a different M.O., VEP coupled with Cubase, and returning to remix a project (after I changed and screwed up, saved it as decoupled, now it loaded empty instances) I ended up having to find the vi frames, which fortunately I'm somewhat careful to save.

    Now, I always run decoupled, preserved and save diligently, yes. I master my own audio, and I have had to go back with say a too-hot master and sort it (and I'll come back to mixes) so I have to be observant in my methodology. I make mistakes so I have to cover myself.

    Edit: the value of decoupled and preserved shows when say, Cubase crashes or hangs and I force quit; this is very rare for me, BUT... let's say I got so involved with the thing I neglected to save on the VEP slave. It's still there, I don't have two problems but one. 

    I would advise making copies variously as you go, as sometimes a vi frame, a channel set, a metaframe even becomes corrupt, I guess from a hot computer (I'm running mine into the ground I think).


  • Thanks Civ I think I get it. PTools is fairly stable these days but it will crash perhaps once a month and I'd like to avoid having my VEP session close down when that happens. For that reason alone it's worth pursuing the decouple method.

    I'm taking delivery of a Magma Chassis in the next week so I will be no longer running a slave. Both PT and VEP will running on the same Intel 8 core and I'll move on to PT9 instead of 8.

    I will start working with the de coupled method then and see how it goes.

    My old G5 PPC is just about had it but has been a rock solid machine for at least 5 years. It is starting to play up now and the drives must surely be ready to fail.

    Time to move on.


  • last edited
    last edited

    @philco said:

    Thanks Civ I think I get it. PTools is fairly stable these days but it will crash perhaps once a month and I'd like to avoid having my VEP session close down when that happens. For that reason alone it's worth pursuing the decouple method.

    I'm taking delivery of a Magma Chassis in the next week so I will be no longer running a slave. Both PT and VEP will running on the same Intel 8 core and I'll move on to PT9 instead of 8.

    I will start working with the de coupled method then and see how it goes.

    My old G5 PPC is just about had it but has been a rock solid machine for at least 5 years. It is starting to play up now and the drives must surely be ready to fail.

    Time to move on.

     

    Phil, decouple won't keep the viframes open if PT crashes - preserve will. Decouple will greatly shorten the save time in PT, and especially with big sample streamers open in VEP.


  •  Thanks a lot for your time, Civ. It's very helpful to get some insight on how you use VEP and your DAW together.

    [8-|]


  • last edited
    last edited

    @ptlover said:

    Phil, decouple won't keep the viframes open if PT crashes - preserve will. Decouple will greatly shorten the save time in PT, and especially with big sample streamers open in VEP.

    Aha! That's the info I need to know! I'm starting to to see the way.

    Thanks Stig.


  •  Been using VEP decoupled for a couple weeks now, and I'll never go back. Thanks!

    [I]


  •  Getting even bolder these days, and have started to use saved metaframes as a stepping stone for new songs and projects.

    [:P]


  • Resistance is Futile.

    o_O


  • last edited
    last edited

    @civilization 3 said:

    Resistance is Futile.

    o_O

     

    Yeah, I see that now, but I had to take the long road for myself to get it.