Thanks for testing. Have you tried to quit VEP and your DAW, and then try to open that particular project again? That's when I get the error message.

Ok, I quit out of VE Pro, saving the project with a GR4 FX in each. I get the message 'another instance is running', + 'will not save to database', which I have seen with Kore 2, but it never caused me a problem I can recall. it doesn't cause any hang here...

Both my Cubase and VE Pro projects, both servers connected to Cubase are stable with a GR4 FX plugged in to each server, and I have saved the metaframes. I loaded a cab to my GR4 in the 32 bit server it is plugged into and saved the thing in Guitar Rig. For me this is a quirk and not a problem. Technically, there *is* another instance running. I don't know about the problem of the database it indicates in either Kore or GR4. I'm not sure there is any.

From your description, it appears your PT and VE Pro are coupled... I think the difference, you having hangs where I don't, will owe to the coupling of the two. NB: I didn't quit Cubase, I believe that's irrelevant, as mine is a decoupled situation.

Also, this seems like a problem where if you have dynamic IP that would complicate things if not be a cause.

This is a problem for me. It would be unfortunate if I need to remember the songs that has multiple instances of GR spread across multiple VEP Server instances, so that I know when NOT to take a coffee break. If I'm not there, I get an endless row of error messages, and I have to force quit. And that, in my book, also involves a reboot. We gotta stop accepting software quirks. So there is another instance - why throw an error message?

Yes, I use coupled all the time, and I now use manually assigned (static) IP.

Why are you using coupled? Have you ever tried decoupled? I only have the one slave, and coupled wastes enough time for me to where I would never consider doing it again. I don't know from PT, but Cubase takes FAR more time to load VE Pro than VE Pro does, and FAR too much time is wasted saving the project, for instance 15 seconds rather than 1. Each save, you know. And you won't have this hang, unless PT has an issue Cubase doesn't.

at any rate, you might want to put this problem up to NI forums. 

I'm using coupled because it feels safer to me. The settings and plugins in VEP on the slave are auto-saved within the PT session, and each save takes about 1 second coupled.

Initially, I had to work decoupled. If I didn't, the 64-bit instance would disconnect from PT fairly often. Don't know what caused it, but it's gone now. And, I lost some work. I can't wrap my head around viframes, metaframes and that type of workflow.

For orchestral work, I might decouple, as that would for sure lead to a substantionally longer saving time. And I have asked about this @ NI forum. It's like talking to a brick wall.

@civilization 3 said:

Why are you using coupled? Have you ever tried decoupled?

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.

well, you'll get rid of this particular problem I believe. there isn't anything to the VE Pro workflow. Vi frames inside metaframes. you save the Vi frames as 'projects', you save the metaframes as metaframes. you can build new metaframes from projects. if your 'project/vi frame' isn't particularly crucial to save, all you need to concern yourself with is save the metaframe. if PTs crashes or hangs, a preserved metaframe remains unharmed. I don't know that I would trust PT more than VE Pro tbh.VEP's perfectly stable here, and I mean perfectly. Cubase rarely does anything hinky, and only if I'm in a hurry after heavily editing audio with third party direct to an audio part, but that happens and I don't have to reload any VE Pro, and Cubase automatically reconnects when I reopen that project, which reopens quickly.

I didn't learn how to do it from the manual, which doesn't read that well for me....

the disconnects may have been when you were using dynamic IP...

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