@ptlover said:

You know, I'm starting on a new project tomorrow, and I'd love to be educated on your workflow. If you have the time, I'd appreciate some insight.

• Do you couple the instances before you shut down for the day?
• Do you save viframes or metaframes?
• How many instances do you typically use on the slave, and does it alter the workflow in any way?
• Do you preserve?

Thanks.

• I don't couple them at all.
• I save viframes when I think to, as chances are they will be useful; eg., the next project might be a mutation of this one and I want to have both versions saved. I also save channels and channel sets. The thing about channel sets is if you import them into an already somewhat built project the sends won't necessarily be in order, but it's not a real big deal. I always save metaframes, as soon as I've made a change. So there's saving at both ends constantly.
• typically 3 or 4, 4 more often as some things weren't x64-ready and I needed the extra instance due to memory limits. I had older projects that were all 32-bit and one of them had like 13 instances. Since Kontakt went x64 for OSX, I'll start a new instance when the channels get to where there's horizontal scrolling past my 23" display. The lion's share is VSL and Kontakt libraries, and I can add instruments until, well, I have yet to hit a ceiling. As far as the workflow, if I have say 6 instances/vi frames, that's more 'projects' to save IF I'm going to need them, and while working I won't be much concerned with that, but for later reference, you know. at this point I'm a stickler for saving when a project completes.
• in the workflow I describe, they are preserved anyway. If I decide to reconfigure the slot arrangement in the next project, for instance a 3 instance rather than 4, I'll unpreserve to rename (and represerve) so I have an easy visual (I call them 1, 2, 3, 4 corresponding to slots in the vsti rack in Cubase).

 Sweet! Thanks a lot for your time. I will use your workflow tomorrow, and let you know how I got on with it.

@civilization 3 said:

in the workflow I describe, they are preserved anyway. If I decide to reconfigure the slot arrangement in the next project, for instance a 3 instance rather than 4, I'll unpreserve to rename (and represerve) so I have an easy visual (I call them 1, 2, 3, 4 corresponding to slots in the vsti rack in Cubase).

This I don't totally get. You're saying that the instances are "preserved anyway", so from that it seems that you don't preserve? But later on you say that you unpreserve to rename, and then represerve, and this is where my little brain nearly explodes. [;)]

[:)] Just now I added an instance/vi frame to a server, which makes you name it. I called it '3'. It is preserved, apparently by default.  If I thought I wanted '4' to be '3', the only way to name it that is to unpreserve it so that I can preserve it to name it, is what I'm saying above. If I kept it and decided it must be Mr. '5', I would have to unpreserve it and toggle that back and now I get to name it some more again.

otherwise there isn't any call to unpreserve it. I don't know why you'd unpreserve it other than this, I never thought much about it. I remember it was puzzling to me so I didn't think about why, I found that unpreserving it didn't have any usefulness - until, by doing I found that's how you get a new name to happen. I haven't read the manual at all or done too much thinking is the trick. [H].

@civilization 3 said:

I haven't read the manual at all or done too much thinking is the trick. .

Cool. Then I know exactly where I've messed up. 😉

Thanks again - I'll give it a go. 

 Note to self - saving a x64 metaframe does NOT save the x32 metaframe. [:O]

here's one to watch for: if you make changes to an extant metaframe, such as you started with from the last project, save it under a new name! that's one way to deem a project finished, though, burn the bridge behind you.

@civilization 3 said:

here's one to watch for: if you make changes to an extant metaframe, such as you started with from the last project, save it under a new name! that's one way to deem a project finished, though, burn the bridge behind you.

Oh, I will never use a saved metaframe as the starting point for a new project, or preserve instances between projects. I have mostly female clients, and they seem to change their mind constantly 😉

 I'll stick to this thread, even though it stopped being about Guitar Rig a while back.

So, decouple and saving metaframes works great, but there's one thing I don't understand yet. When I close one project in PT, the metaframes also close, but the two servers (32-bit/ 64-bit) are still running, and they have the previous song name in the upper title bar. When I open the next song in PT, there's always 4 instances I can connect to. Two called "Untitled", and two called "New". The two called "Untitled" are the saved metaframes for that particular project, but where does the two "New" ones come from? Why are they suddenly there at all?

Unless there are empty new instances connected to in place of desired instances, you have no problem. The new instances (one for each VEP server) will always appear, so you can make new ones from there; once created you want to save them as needed is all...

Decoupled and preserved, the metaframes should not close automatically from closing PT. that part I don't understand, unless you are deliberately unpreserving them in favor of them quitting. 

I create, or manage (I tend to start with something I've built, as I have built a viable sounding thing I know the sound of, saving a lot of trial and error, and actually saving a lot of mixing, I'm using VE Pro as a submixer par excellence) the metaframes before I start a song and they're named at this point. So, you can create a new instance from either vantage point, PT with a project going or VEP before a (sequencer) project loads. My workflow right now is three instances I've loaded on the VEP side, but if  a fourth auxiliary instance is needed I'll instantiate VEP in Cubase, connect to 'new' and build it or instantiate something I have..

 I don't use preserve. I don't see any good reason to use it. Regarding multiple "unknown" instances - I have to pay attention to when/why the new, empty instances are connected to PT. That happens from time to time.

Thanks again.

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.

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.

@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-|]

@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]