Hi DG,

• I am using Kontakt 4 within VEPro....not Kontakt Player

• I'm not doing anything else when save is happening ....in fact I had one crash when I had left the room and when I returned PT had crashed when it was doing an Auto Backup.

• Saving uncoupled is no problems at all and about 100 times faster.

In fact saving in PT with VEPro coupled is becoming a non option. Save times are up to 30 sec long and that makes things impossible in PT. You can't do anything whilst the save is happening. A real workflow killer.

So perhaps it's time to forget about coupling in VEPro as this really is not working.

We are just going to have to save the VEPro files on their own.......although I don't like working this way.

I'm with Jeremy on this. Why does VEPro have to save all that info every time it saves? Or is this a fault with PT?

I'm not sure what you mean about PPC not being supported.

Obviously we are using a version of PT that is supported (future versions are not but we have locked our systems down with this last version)

And of course VEP is supported for PPC.

All the other instruments and plugs are on our other Intel machines which are supported.

But this new version of VEP broke something in Kontakt OR the new Kontakt broke something in VEP.

Why do the sub menus disappear in Kontakt when we decouple?

And of course....why do we crash when we save in PT?

The previous version of VEP did not.

I still think you need to clarify whether it is VEP saving all that information or PT. I think that it is the host that saves plugin information, otherwise how could it be recalled when you open a new session. Obviously for you the best way is to run uncoupled.

When I say that PPC is not supported I refer to:

[Quote]Intel Core 2 Duo/Xeon with Mac OS X 10.5.7 or higher (PPC/PPC64 works but is not actively supported) [/Quote]

DG

@DG said:

Obviously for you the best way is to run uncoupled.

And in fairness to VEPro, for 10 years+, those of us with Giga slaves were essentially running "uncoupled". We were forced to save each slave machine's parameter files locally, totally unrelated to our host's session file. If we run VEPro uncoupled, that is exactly the situation. And that is a short-term solution for protools users who use large samplesets in VIs such as Kontakt4.

With that said, in my opinion, I think VSL engineering should look at the issue here (see my post above discussing how other applications use linked files) and build a better mousetrap.

As long as VEPro sends megabytes of data on every save from the server to the host, and as long as protools crashes during these saves, protools users only option is to run uncoupled IF we are to run VIs with large sample sets, such as Kontakt4. But it would be so far superior if VSL could look at the issue and try to find a better way to do this, instead of requiring that we turn the feature off if we want to work without risk of crashing at the first save.

Everyone clear about the issues and (temporary) workaround here?

Did I just miss something........?

We are now unsupported on PPC.

I thought the spec read PPC support when I bought VEPro.......I mean that's why I bought it.

But now the spec says Intel.

Did it always say that? Because I never would have bought VEPro and taken that chance. (knowing that I have a PPC non Intel)

Or have we just started to be unsupported in the last couple of versions and nobody mentioned anything?

I clearly remember telling my collegues that PPC was supported and to go ahead and purchase...............could I have really missed the spec?

Jeremy were you aware that PPC non Intel was unsupported?

Hi,

here are the system requirements for Vienna Ensemble PRO, they never changed. "PPC/PPC64 works, but is not actively supported."

There will come a point in time, when PPC computers can not be considered anymore.

Best,

Paul

I admit I fit the stereotype of the "vague musician type" and I probably missed that in my excitement to press the purchase button. Bad move on my part but at least I've had some good months out of VEPro. But the wheels are starting to fall off now. I'm having to do all sorts of work arounds to keep working.

For example I can't get PTools to connect to any Metaframe other that "new". That just loads a new empty useless instance. Even if I open the instance that I want then PTools VEPro plug will not list it. So my work around is to save a channel set and open it in the "new" metaframe.

Also in the VEPro plug window in PTools there is never shown a "preserved" instance or the Slave computer name in those 2 white squares. Now that I think about it there never has been since I started using VEPro.

Tonight I was trying to trouble shoot all this and kept thinking about PPC not being supported and it finally dawned on me. The ship is sinking and I've already run up to the highest point and still the water keeps coming.

Ok I know what you're thinking I think. "If you're a pro muso just get over it and buy another computer.

There's a catch. My PTools cards are PCIX and won't fit in a new mac (PCI Express)

Exchanging cards would cost $5000 plus $3000 for a new computer.

Or by a chassis for $4000 (in Australia) and then a new computer $3000.

Ok I could just go ahead and do that BUT I know Digidesign have some new hardware coming any week now and everything I would have just bought will be obsolete.....again.

So I'm going to keep this sytem working somehow until Digidesign plays their hand. Then I'll jump.

Just thought I'd explain why I'm using a piece of junk as my host computer.

@Another User said:

I think there is something less than perfect with how VEPro saves data back to ProTools, and this issue manifests itself when large amounts of data have to be saved from a "coupled" VE Pro instance to ProTools. Kontakt4 seems to want to save more data back to ProTools than other VIs.

The temp workaround is: UNCOUPLE. Just like in the "old days" (last year), we save our VE Pro projects and metaframes on the slave, and connect manually. This is a sure thing.

HOWEVER, as I posted earlier in this thread, I think VSL engineering should take a look at this issue and build a better mousetrap. What is VEPro sending to ProTools that causes SO MUCH data that must be stored in the host session? I DO NOT BELIEVE this is PPC only issue, as a friend with a quadcore macpro host is having the same issue. The one thing we all have in common: Kontakt4 with large sets of samples. I think we are the "canary in the coal mine". I would love to see VEPro NOT embed its data to the host, rather LINK to a saved file, just like other professional apps (photoshop, finalcut, illustrator, quark, protools, etc..). I hope VSL engineering gets to read this. I'd love to hear back from VSL on this idea as well.

In the mean time, until something changes, IF we want to use Kopntakt 4 with VEPro and Protools, we're gonna have to run the old-fashioned way and UNCOUPLE.

I worked with 6853 all day and night on Saturday without any hiccups in any way, and I SIMPLY didn't use K4, else when I need to use K4, I uncoupled. No other issues.

Hope this helps.

J

Hi,

as I´m sure that you are following other threads as well, you already know that we are talking to NI to improve this situation [:)]

Please rest assured that we are reading every post in this forum and we are considering different solution if problems occur. There simply isn´t enough time to discuss every idea and feature wish list, if we want to keep up the speed we are used to.

Some things are not as easy as it seems, and as VE PRO is a product that faces so many variables (different sequencers, plug-ins, OS´s, hardware...) all solutions also need to be tested properly.

Thanks for your input and understanding.

Best,

Paul

Phil (and VSL Engineering):

I can verify the "NO MENUS" or settings issue with K4 -- but I stumbled into a workaround.... this is clearly a bug with VEPro/Kontakt 4 combo, and not with any host. This bug is on both XP 32 server and Mac OS 10.6.4 32-bit servers.

Do this:

1. Without any host running, on either xp or mac 32-bit server, add a new empty instance.

2. Load a Kontakt 4 VI ( loaded the K4 player 4.1.1.3832, as I have not yet taken delivery of the Komplete 7 bundle)

3. Load a patch with settings or scripting, in my case, i loaded Alicia's Keys

4. Wait for all samples to load, then observe that the "settings" or "menus" tab does not function!

Here's how to make it work:

5. launch your host. In my case, ProTools 8.0.1cs2

6. Connect to the VEPro server. I used 1x buffer, but it doesn't matter;

7. Settings or "menus" in K4 now work! Yeah! :-)

8. Now, DISCONNECT from the server -- and yes, the settings/menus no longer work. :-(

Bug.

Paul, do I need to submit a formal bug report for this, or can you please forward this thread to your engineers? 

Thx

J

It looks like Kontakt 4 (or a script) somehow needs to have the internal audio engine running. When a VE Pro instance is disconnected, its internal audio engine will never be running due to the fact that it needs a master host connection for this. This is a flaw in Kontakt 4 (or a script) that I doubt we can work around. It goes unnoticed in other hosts because they usually have their internal audio engine running at all times. This would explain how everything works properly in a connected VE Pro Server instance and in a standalone VE Pro.

Hi Karel,

Thanks for jumping in on this. Of course, there is no need to ever edit or use any parameters in a VI within a server instance of VEpro if the host is not connected, but this caught Phil and I off-guard, as we were having other difficulties with Kontakt 4. No worries.

Are you able to comment on the crashes that we're having while saving the host file in protools IF a Kontakt 4 is loaded in the VEPro server (forcing us to uncouple if we want to work without crashing) ? Does the host determine how and what is saved (embedded) or does the VI make this determination?

Is this something we should bring to NI's attention, or do you have a conduit to them?

Is this a protools issue?

Do have any guesses why large amounts of data from VEPro hosting K4 crash protools? Can you suggest any other workarounds besides uncouple?

Any guidance on tis is appreciated, as we are missing out on an important feature of VEPro (the "coupling" of the server to the host) until this is sorted out.

Thx

J

I agree that the epicentre of this trouble is Kontakt.

Not to be counter productive but in all honesty I remember that these long save times were prevelant when using Kontakt as a plug inside PTools years ago. I also remember people on the DUC complaining about it.

BUT despite the long save times they did not result in a crash. That is new.

Jeremy can you explain something to me?

I agree that the way to work if we are using large instruments in Kontakt is to de couple (surely other users are using big orchestral templates in Kontakt......no?).

For this to work then we need to save our Metaframes and Instrument files on our slaves. No problems there.

BUT how do you then get ProTools to connect to your saved metaframe?

For the life of me I can't do this.

Here is what I do…

I open VEPro by double clicking on the saved Metaframe that I want to open (mframe32). This opens the server and all the instrument channels.

I then open the VEP plug on the host from withing PTools and all that is listed when I hit connect is "new". The instance that I have sitting on my slave is not there to choose from in the list.

How do I connect to it?

I have to save the channel set and bring it into the "new" instance and when I do I can be sure that some of the chanell I/O have been messed up (but I'm not concerned about that).

I'm fine with de coupling and working that way .......because I have a hugh investment in Kontakt instruments, but I need to be able to connect my saved files with PTools.

Am I missing a simple process here or is this a part of the PPC "works but not supported" funkyness?

@philco said:

BUT how do you then get ProTools to connect to your saved metaframe?

It's definitely not intuitive, nor obvious, but I stumbled upon this today while working it out...

1. Let's say your PT session is happy, and you are connected to various instances of server(s). Good. Now save PT.

MAKE SURE uncouple is selected. For me, I also have "preserve instance" UNCHECKED on each server instance.

2. Close protools session. Your server instances should close.

3. Now open the protools session. it will load EMPTY (default) server instances.

4. Now open the metaframe or projects at the server. Dialog: "Do you want to save changes to the project" - NO (this is a stupid interface design element - by default instances should be empty, without placeholders... but that is besides the point) -- and now your metaframe or projects should simply load.

Yes? Works for me, but I am only using one instance per server.

Don't forget to save your projects on each server. Just like the old days.

Please report back.

PS --  Phil, are you also saving viframes (projects) ?

I have no difficulty connecting to a single instance per host plugin.

Thanks for the reply Jeremy. I save both files. (although I still don't understand why....I just do it)

I tried your method and it does not work for me.

I decoupled in PT and saved.

I closed the session in PT.

My session in VEPro closed.

I reopened the session in PT.

As you said (and as I've seen a million times) VEPro opens a "new" project with 2 channels.

I open my metaframe in VEPro. It asks if I want to save. No I don't. My project opens.

I have to now connect in the Plug in PT. Nothing is there in the plug. It is not displaying my just opened metaframe. Only "new". If I connect to "new" I get the same two channels.

Nothing is written in the "preserved session"   box or the "salve host name" box (should there be?)

I cannot connect to this instance. The PT plug will not see it and NEVER has since the day I started using VEPro.

I thought this was normal behavior.

Something is wrong.

We have the same PPC don't we Jeremy. A dual 2.7?

Also note that when I open my saved metaframe it is automaticaly preserved.

I cannot un preseve it because it will close.......because there is no active connection.

And I cannot connect it.

@philco said:

I cannot connect to this instance. The PT plug will not see it and NEVER has since the day I started using VEPro.

I thought this was normal behavior.

Something is wrong.

We have the same PPC don't we Jeremy. A dual 2.7?

Yes. 2.7

Do you have your machines set to static IPs?

Try this. 

On the server, make a new instance, name it.

OPn the host, make a BRAND NEW protools session. Don't import session data. make a new stereo AUX (not instrument). instantiate a VEpro. Can you connect to the named server (not "new") ?

if you can't do this, you will not be successful with the uncouple workflow. Time for a new thread on this issue. 

My Ethernet Port = Ethernet 1 has a self-assigned IP address and will not be able to connect to the Internet.

So I think that is a static IP address.

I did your test and it worked.

The plug in PT saw the test metaframe and connected to it. Not only that but I was able to open a saved viframe and connect to that.

So I get it.

If I start VEPro Server by opening a saved mframe32 then I CANNOT connect to it from PRoTools.

If I just open a blank server and then connect via the PT plug to "new" I can then open my saved viframe32 within that new instance and leave PT connected.

That viframe opens INSIDE the "new" instance in the Server.

Ok I get it.

Did doing your test actually "reset" something in PTools I wonder?

More likely I have just been stumbling along and disconnecting when I shouldn't or opening the Server by opening the metaframe and wondering why it wouldn't connect.

So you have to open the server, then make a new instance, connect to PT, open your viframe inside that new instance and leave PT connected.

Can I just say with all respect to those involved how freaking confusing that is?

Oh PT just crashed again..............here we go

Thanks for your help Jeremy, I can now work decoupled.

@philco said:

My Ethernet Port = Ethernet 1 has a self-assigned IP address and will not be able to connect to the Internet.

So I think that is a static IP address.

Hmm... self assigned does not smell right. Are you using a router and/or switch? 

You should manually assign an IP to each machine on the network, with the same subnet.

Such as this:

And your slave should have a unique number, such as 192.168.0.19

IF you are using a ROUTER, it is suggested to use a switch BEFORE the router - and DO NOT use the router's built-in switch, since most routers on the market have piss-poor LAN throughput. If you don't believe me, check this out:

http://www.smallnetbuilder.com/component/option,com_chart/Itemid,189/

And visit Tomshardware.com and other hardware sites, and you'll see that consumer grade routers are a terrible SWITCH solution.

So get a gigabit switch. Put all of your boxes on it, then connect the switch to your router. Make sure you constrain the DHCP range of the router to outside the range of your static IPs. That's really all there is to it.

Thanks Jeremy, my router is an Apple Airport Extreme and I have all the house's computers plugged into that.

If you don't I mind I will do a diagram and ask you to check the system configuration as to the necessity of a gigabit switch. I better learn some more about that switch.

My slave is also on the internet..

I'll get back to you.