182,262 users have contributed to 42,216 threads and 254,737 posts.
In the past 24 hours, we have 3 new thread(s), 22 new post(s) and 40 new user(s).
In one project I have one Guitar Rig plugin as an insert effect in the 32-bit instance, and one in the 64-bit instance. And every time I get [url=http://imageshack.us/photo/my-images/23/gtrrigerror.png/]this error message[/url].
It causes VEP to stop loading, and it makes PT non-responsive on the master Mac, if I'm not there to click away the message. And that doesn't always work either. Sometimes I get an endless amount of the same error message, and I have to force quit VEP on the slave.
I haven't seen that one. I have seen Kore2 do that, both in [much earlier builds of] Pro and when I used it in Cubase. I just loaded Guitar Rig 4 fx in both VE Pro servers, no problem.(both connected to, but decoupled from, Cubase).
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.
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.
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.
Sweet! Thanks a lot for your time. I will use your workflow tomorrow, and let you know how I got on with it.
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].
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.
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..
.