Migrating VEPro from localhost to remote slave machine?

[jstaczek]

Hi All,

I'm a Cubase user and have so far been running Cubase and VEPro on the same machine. I've reached the point where I need to move the big instances of VEPro to a remote slave. The server is normally sitting on localhost with several preserved instances that are used across many Cubase projects.

What is the best way to migrate existing Cubase projects over to using the remote slave instead of localhost? The only idea I've been able to come up with is to keep an instance of the VEP Server running on localhost with a dummy metaframe. It would have preserved instances with all the right names, but no actual content, instruments or samples loaded. As I opened each Cubase project, I would manually disconnect the plugins from localhost then manually reconnect them to the new remote slave.

Is there any better/faster/automatic way to do this? I imagine it's a pretty common scenario, yes?

Thanks,

Jason

[jstaczek]

Anyone? I can't be the only VEPro user with this problem...

Thanks,

Jason

[DG]

I don't really understand the problem. If you load your normal Metaframe from the master PC on the slave, surely all you have to do is disconnect from the master machine and connect to the slave? Am I missing something?

DG

[civilization 3]

Yeah, what problem? If you want an automatic way to connect to what is a new address, I don't see how there is one. Once you have established a working address, the DAW host connects to those instances as you provide it, loading decoupled ones, or recalling what is coupled. In terms of actually connecting there is no difference between local host and another computer slave, but there is a different address obviously. I have no idea why you think of a dummy metaframe, you're going to have to reconnect per se.

[jstaczek]

Thanks for the replies. Hearing you guys talk about made me realize I was making an incorrect assumption. I was thinking that if I launched projects on localhost and the old VEPro instance was missing, it would try to spin one up every time I opened a new project. And that orchestral instance was huge so I assumed I would sit and wait 20 minutes each time before I could reconnect. But since it was preserved, I now see that the projects will just open with VEPro unconnected. So it's just a manual reconnect to the new slave machine.

But that does bring up a question. Is there no way to tell VEP to connect by some name or alias so that you can move these things around without having to do any reconnection?

Thanks,

Jason

[jstaczek]

Sorry for bringing this up again, but I'm running into exactly what I hoped I wouldn't. 

I've moved my big orchestral instance to the slave machine, but when I open projects on the main machine, it sees VE Pro locally, notices there's no instance of the orchestral template and tries to load it. And it's huge and takes 20 minutes to load. 

Why is VE pro still running on the main machine? Because in addition to the big orchestral instance, each of these projects also uses various other instances with special sets of instruments per project. If there were some automatica way to have them instantiated on the slave machine, that would be great, but I don't see how. 

So, I'm back to my proposed solution. Keep VE Pro running on the main machine with an "empty" version of the big orchestral instance in place. Once a project is launched and connects, disconnect it then reconnect to the "real" orchestral instance on the slave machine.

I think there's a feature request here, not unlike what happens in Kontakt if you try to load a project and it can't find samples. It asks you to locate them. VE could say "can't find XXX, do you want to use one of these we found on your local network instead"? VE could also say "this project used to use instance YYY on localhost, but we don't see VE Pro running on localhost. We noticed VE Pro is running on slave. Create and instance of YYY there?"

These would be very handy behaviors for me, at least.

Thanks,

Jason

[civilization 3]

"Why is VE pro still running on the main machine?" Well, this is not my experience. If I don't launch it, the DAW doesn't start it. I haven't run coupled in years so I checked, to be sure. I don't believe you should have it still running unless you have chosen to have it running.

So I don't get this step of an empty instance at all. You need to establish each project with the new location. There is no magic trick to get rid of this, I don't reckon.

[civilization 3]

@jstaczek said:

I think there's a feature request here, not unlike what happens in Kontakt if you try to load a project and it can't find samples. It asks you to locate them. VE could say "can't find XXX, do you want to use one of these we found on your local network instead"? VE could also say "this project used to use instance YYY on localhost, but we don't see VE Pro running on localhost. We noticed VE Pro is running on slave. Create and instance of YYY there?"

The way I see it, you want this step in avoidance of a step you don't want to take out of fear of uncertainty.
I have done the opposite, all of my VE Pro metaframes were connected to this machine here as slave. Now all the ones I have used again with no master, on this single machine, connect as local host. There is no problem, I connected to them in this state and saved the [Cubase] project as that, and saved the frames on the VE Pro side as that. I don't think your FR is less work than this, I don't see it.

[civilization 3]

Actually, going back some years, I have done this both ways. I don't get why you think this is a difficulty.

[jstaczek]

I don't think I'm explaining myself very well. And I'm actually experiencing this at the moment, so it's a real issue. Let me try to clarify:

- Correct. VE Pro Server does not launch automatically. If it's not started on the local machine, Cubase does not start it.

- Imagine Cubase project X that formerly connected to three instances of VE Pro all running on localhost. One was a large orchestral instance. Two others were specific to that project, non-preserved.

Now I want to move the large orchestral instance (LOI) to the slave machine. I start VE Pro Server on the slave machine and load the LOI. It's sitting there waiting for a connection.

- Back on the main machine, I open project X in Cubase. If VE Pro Server is not running on the main machine, I have no way to figure out what the other two instances of VE Pro were. Since I don't know what they are, I can't even manually open them on the slave machine and connect to them. But at least I can reconnect to the LOI on the slave machine.

- If VE Pro Server IS running on the main machine, it will try to load the original LOI and the two other non-preserved instances. The loading of the two others is great. That will allow me to retrieve them and possibly move them if I want. The loading of the LOI is not great. This will take 20 minutes and more RAM than the main machine has. After 20 minutes, I can disconnect the LOI and reconnect to the slave machine.

If I were talking about one Cubase project, this wouldn't be an issue. But I'm talking about many, many Cubase projects developed over several years that continue to be reused and reworked in different ways. Having the local VE Pro running with "empty" instance of the LOI is the only way I've figured out around this. 

I'm afraid I don't follow you on the fear of uncertainty part. These Cubase projects simply won't load and work without having VE Pro Server running on the local machine. 

Maybe the solution would have been to have one enormous metaframe that encompassed all possible projects, but I don't think this would have been practical. The LOI was truly the only thing shared across all projects. Everything else was very specific. 

You might ask why keep those VI's in VE Pro in the first place then, and not in Cubase? Two reasons. Cubase performs much better with them in VE Pro and, in some cases, these specific ones were shared between several related projects.

I hope this explains better. There's really no need to reply as the "empty" LOI is a reasonable workaround. I had just thought this experience could not be unique to me and perhaps someone else had another workflow for it.

Thanks,

Jason

[civilization 3]

@jstaczek said:

 Cubase project X that formerly connected to three instances of VE Pro all running on localhost. One was a large orchestral instance. Two others were specific to that project, non-preserved.

Now I want to move the large orchestral instance (LOI) to the slave machine. I start VE Pro Server on the slave machine and load the LOI. It's sitting there waiting for a connection.

- Back on the main machine, I open project X in Cubase. If VE Pro Server is not running on the main machine, I have no way to figure out what the other two instances of VE Pro were. Since I don't know what they are, I can't even manually open them on the slave machine and connect to them. But at least I can reconnect to the LOI on the slave machine.

- If VE Pro Server IS running on the main machine, it will try to load the original LOI and the two other non-preserved instances. The loading of the two others is great. That will allow me to retrieve them and possibly move them if I want. The loading of the LOI is not great. This will take 20 minutes and more RAM than the main machine has. After 20 minutes, I can disconnect the LOI and reconnect to the slave machine.

Here's your problem: you don't know what the instances are so you have to have them loaded local host. You can totally know, though. You preserve everything and save them {EDIT: in case this isn't apparent to you, save them as VE Pro metaframes and viframes, dealing with VE Pro apart from Cubase} with a name that you can rely on in future. So I'm making a point above with the striking through bit. You don't need any of this. You just do things differently*.

"I don't follow you on the *fear of uncertainty part."
"These Cubase projects simply won't load and work without having VE Pro Server running on the local machine."
They can work if you decouple them from preserved instances. This is the step you need in order to not do this other stuff. Decouple every connection and save the Cubase project(s). and have the metaframes and if needed to reconfigure, the vi frames saved in a way that signals to you where they belong as per Cubase.

Then you load everything you need in VE Pro on the slave. Cubase will want to connect to what it knows. When you do not have VE Pro running on the 'master', Cubase will not have anything to connect to. Of course you do not want to do 'no VST instrument' in F11 VST Rack, you want the channels you have defined and all intact.
Then you simply connect the 'NOT CONNECTED' slot to the established Metaframe instance you have to connect to on the slave.

I know exactly what all of my instances are. Again, I have made the move from all on one machine to a master/slave configuration [ca. 2011] and from that back to VE Pro connected all local host. There were a number of projects to reconnect to. It was hard to relate to why you think this is impossible. I guess you have Cubase loading VE Pro in a coupled situation and you're reliant on seeing that result (rather than saving everything on the VE Pro side, separately from Cubase). If you like this workaround better than no workaround, that's none of my business. But I'm here to tell you it isn't necessary if you will decouple and preserve everything in preparation for this move.

[civilization 3]

I really had quite a lot to deal with, I don't want to underplay that. I don't have any master template; I have dozens or hundreds of viframes and metaframes I can work with, in addition to channel sets.
So I developed a consistency of definitions. My metaframes have project names which refer to Cubase projects/names of pieces of music; and the slot numbers its instances connect to in Cubase are the basic names of the instance. I also name the viframes the instances contain. This does not appear in the metaframe's infos, but it's not atypical for me to reload them (which I can do while connected to Cubase with no issue) so I know exactly what they are.

Project name/"1,2,3" [description if unusual] means slot 1's instance/vi frame is named ["1" [description of unusual specificity if any]]; slot 2's is named ["2"]; slot 3's is named ["3" [unusual specifics if any]].
"1" is always going L to R: mallet and tuned percussion, hammers, then bells type; orchestra perc., typical to exotic, L-R; auxiliary [possibly described in the metaframe and/or vi frame names].
"2" is always going to be based in BFD2 or BFD3 with extra percussion I didn't think of building "1". "3" is always winds to brass + auxiliary if any; etc...

As decoupled, only the instance name (not the viframe name; instance is a container for a viframe but the latter is secondary) appears in Cubase. For me it's that simple, slot 1 is connected to instance "1". I know what '1' is pretty much going to be.

[civilization 3]

And note well, this whole 20 minutes thing is a property of coupling with Cubase, I believe.