I still assign static IPs to all music computers. I have two rigs are on the same (LAN) network, so the additional fear I have is that opening up a session on one rig will try to attach to a VEPro slave on the other. Static IPs seems to work for me and I haven't had any reason to change. That said, to know from VSL what they say "best practices" are, would be very helpful.

Came up against this same problem again. This time I fixed with the following steps.

1. Saved the "project"
2. Deleted the aux and therefore the old instance of VEP
3. Created a new aux and instantiated a new instance of VEP
4. Loaded my project in the server
5. Reconnected all my auxes and midi in Pro Tools. Audio is back.

Investigated this further with Synthogy (Ivory). Ivory will run in standalone mode, and as it is using the AU plugin to run in standalone, this is obviously verifying that everything is good. Attempting to instantiate in VEPro gives me an error, which points me to some troubleshooting I need to do in VEPro. 

Thoughts anyone? Thanks.

Before trying to recreate the problem I deleted tracks from my session one by one. Turns out deleting my "main auxes", the ones I use to bus stems, were the culprits. Once I deleted those the audio immediately fed from VE PRo. Many people have been having problems with routing in the newer versions of Pro Tools, so I should have known to look there first.

I think it might be difficult to reproduce as I don't quite know how I did it. Will post with my progress.

In attempting to create and use a template of VIs for VE Pro in Pro Tools, I ended up with two instances of the same project (vframe) open at the same time. I closed one, and the other, which had loaded from the host session, I kept open. But try as I might, although the instance could see midi and produce audio in VE Pro, that audio was never passed to the Pro Tools aux inputs. The plugin was appearing correctly as a Pro Tools aux input, but not receiving any level. It looks like they got "disconnected" somehow, but restarting/rebooting would never get them communicating properly again. I can open up another session and everything works fine. I'd like to know what's going on, and if there is a fix, so if it happens again (which is perhaps likely) I can correct it.

Thanks

Kevin

[COLOR="Navy"][FONT="Arial Narrow"][SIZE="2"]Pro Tools 9.0.2 | HD3 PCIe | 192 i/o C|24 Mac Pro5,1 (mid 2010) Westmere 3.33 GHz Hexacore | 16gb ram | OS X 10.6.6 | VEPro 4.1.7846 MacMini3,1 (late 2009) Core 2 Duo | 4gb ram | 10.6.6 | VEPro 4.1.7846[/SIZE][/FONT][/COLOR]

[COLOR="Navy"][FONT="Arial Narrow"][SIZE="2"]Pro Tools 9.0.2 | HD3 PCIx | Apogee Rosetta 200 | Magma PE6R4-I MacPro5,1 (mid 2010) Westmere 3.33 GHz Hexacore |16gb ram | OS X 10.6.6 | VEPro 4.1.7846 MacMini2,1 (mid 2007) Core 2 Duo | 4gb ram | 10.6.6 | VEPro 4.1.7846[/SIZE][/FONT][/COLOR]

I've never tried to host Ivory in VE Pro prior to 4.1.7846, but thought I'd give it a go to try and get all my VIs out of Pro Tools. Ivory II (2.01) wouldn't instantiate as an AU in a 32-bit instance and produced the error "Could not create plugin Synthogy | Ivory." Am I missing something peculiar to Ivory, not found in Kontakt 4.2, Omnisphere, Trillian, Massive, Reaktor and Battery, which all load find in VE Pro?

Thanks

Kevin

[COLOR="Navy"][FONT="Arial Narrow"][SIZE="2"]Pro Tools 9.0.2 | HD3 PCIe | 192 i/o
C|24
Mac Pro5,1 (mid 2010) Westmere 3.33 GHz Hexacore | 16gb ram | OS X 10.6.6 | VEPro 4.1.7846 MacMini3,1 (late 2009) Core 2 Duo | 4gb ram | 10.6.6 | VEPro 4.1.7846[/SIZE][/FONT][/COLOR]

[COLOR="Navy"][FONT="Arial Narrow"][SIZE="2"]Pro Tools 9.0.2 | HD3 PCIx | Apogee Rosetta 200 | Magma PE6R4-I
MacPro5,1 (mid 2010) Westmere 3.33 GHz Hexacore |16gb ram | OS X 10.6.6 | VEPro 4.1.7846 MacMini2,1 (mid 2007) Core 2 Duo | 4gb ram | 10.6.6 | VEPro 4.1.7846[/SIZE][/FONT][/COLOR]

In my short search I couldn't determine if the PCI was connected to north bridge on the PCI-x G5. I've assumed that PCIx is older than PCIe therefore likely to be my bottleneck. Other people seem to have had very good success with their G5s; PCIx and PCIe, so I'm going to continue on the understanding that it's an error in my set up, not a shortcoming of my hardware, unless I can determine otherwise.

The reason for each pair of macs having their own gigabit switch is so that I can easily isolate them from the LAN by yanking the physical cable out of the back, disconnecting completely. If I do physically isolate the pair with issues, I still have the problem, so I can say, in my case, that as the PCIe G5 pair are not physically connected via the LAN, they are not a contributing factor. But, as you rightly remind me, I am intending to switch the properly performing G5 pair to static IPs, once this gig is delivered.

Thanks.

Normal is our "default". When you posted, I was laying down something, with a dropout every other pass. So I switched to "Large (Improves Performance)"... but it didn't improve performance. So I switched back.

Interesting that the machine still stuck on "dynamic" is the one not having the issues. 

Regarding north bridge, a term I was unfamiliar with, I couldn't find any documentation in a search, that said one way or the other in regard to the PCI-x G5. 

Again, thanks for the thoughts.

Do you mean in Pro Tools? I've tried Normal and Large (Improves Performance). Is there a VEPro cache I've overlooked? Would be great if I had overlooked something rudimentary and fundamental! 

We will swap Mac Minis in the coming days to see if the jumbo frames and network are the true bottle neck.

Thanks for the input.

Two people in two rooms. 

I thought that by subdividing/isolating each rig on its own switch on the network (LAN), it would direct the traffic between each pair, and perhaps keep them away from other LAN chatter. I'm not a networking specialist, but from what I've read, it seems like a reasonable (although very possibly erroneous) approach.

Nice suggestion. I will try it over the coming days, when the current delivery schedule permits and report back.

Many thanks. 

We have two mirrored rigs running Pro Tools on the master and VEPro on the slaves. The rigs have minor, but perhaps significant differences. One (the PCIx rig with the mid 2007 mac mini slave), I get audio drop outs. The other, a PCIe rig plays back fine. Any pointers as to who or what could be the culprit? I do notice that the cpu % meter in the bottom right hand corner of the VEPro screen will dive to zero when I get the audio drop out. The drop out is only momentary.  Happening randomly. I can lay down a one minute mix with three drop outs and the same pass again straight away will perform with no drop outs.

rig 1

master: g5 2.3dp PCIe

slave: mac mini (early 2009 2ghz intel core 2 duo)

rig 2

master: g5 2.3dp PCIx 

slave: mac mini (mid 2007 2ghz intel core 2 duo)

Both masters have

hd3

OS X 10.5.8

PT 7.4.2cs4

Both slaves have

VEPro 4.1.7043 (downloading 4.1.7384 but just delivering on a gig so not in a rush to install)

VEPro plug in, set to "two buffers"

VEPro (32bit) server: 

Multiprocessing - 2 threads

Audio ports - 32

Midi ports - 16

Both rigs are connected via their own Netgear GS605 gigabit switch.

The obvious difference between the two set ups is that the g5 PCIx doesn't do jumbo frames and the g5 PCIe has two gigabit ethernet ports.  

Pro Tools Playback engine

H/W buffer size 512, 1024 or 2048 (tried them all)

Cache Size - Large

Any thing that would point me in a new area of investigation would be much appreciated.

I am moving to static IPs, but until I fully make the transition, this ugly kludge is the best I've come up with.

So after some investigation and trial and error, the work around I've found is to set up an identity in "Mac OS > System Preferences > Network" for ethernet "OFF". Before I load a foreign session (ie one that was not created on this computer pairing), I switch the ethernet off (better than yanking the cable, as that puts the mac in a tail spin) and then load the session. The plug in can't find anything, but the session still loads. Then I switch ethernet back on in the preferences and, after waiting for the computer to populate on the LAN, clicking on the plug in, pulls up a list of whatever machines (servers) are on the network. I can then chose which to connect to.

Perhaps this brings us back to your original question, Jeremy. If you haven't set up static IPs, if you switch your ethernet off before you load a session, does this routine then solve your problem too, by your being able to then manually select your slave/server?

I always save both a viframe (project) and an mframe (whatever an mframe is) before closing each session in case something can't remember what it's supposed to be doing.

K

Good to at least know I'm not missing the patently obvious. I want to be able to pick the machine on which I want to load the session, not have it picked for me. As long as I have my projects saved, I should be able to point my VE Pro rtas at the proper server and connect, or so my thinking goes. I've read yours and others discussions on the DUC about decoupling/preserving, but it's still hurting my head. Perhaps there is some magic in there that reveals a proper level of control.

This question is just as relevant for someone who has a set of machines and wants to layback at an outside facility. How do they reconnect their farms over a strange LAN? Would they have to bring their router with them so there was no mess? Many thanks for your thoughts so far.

K 

Jeremy,

One of the rigs is sort of on it's own dedicated switch, but a C|24 sort of messes with that. But good points to be aware of, although our problem isn't speed, that will become a factor soon enough. I had already done some research on jumbo frames and it was only a few months after we pulled Cat5e that someone pointed out that we should have pulled Cat6. I think Cat7 is in my future!! 

Jeremy, Thanks for the further words, but "No" to what exactly?

I have my insulated network; my DHCP begins at 192.168.1.2 and I set it to end at 192.168.1.100, my static IPs will be at 192.168.1.101 and 192.168.1.102. So I think I'm all good. Gives 99 addresses for the various desktops, wireless devices etc. My static IPs I will then assign from 192.168.1.101 upwards.

But that does't help me with what VE then does with that info. I have two HD3 rigs each with a mac mini farm attached. If I move a PT session from "room 1" to "room 2", the session in "room 2", through the LAN, will still load my VE project on the mac mini in "room 1".

Or are you saying No, I haven't even configured my network correctly yet? Or no, VE Pro will never give me the choice to select which mac mini so I better get it right now? I think that was your original problem when you changed your router, you couldn't de/reselect your slave.

Many thanks,

Kevin

Never having properly understood or set up ranges of or static IPs, after Jeremy pointed this out I went away to do my research. The following article at least pointed me to the fact that I needed to set up the range within my router, an Airport Extreme Base Station (yes, rudimentary stuff).

http://discussions.apple.com/message.jspa?messageID=11562585 

I actually connect to the internet using PPPoE, but the settings were similar enough to help me. So I left my range on the "DHCP Beginning Address" (AirPort Utility > Manual Setup > Internet > DHCP) as is, and set the "DHCP Ending Address" to 192.168.100, assuming that I would then set my VE slave machine static IPs to 101, 102 etc

But, I can't follow your suggestions to the letter as both of our rigs, being on a shared network, would be trying to access slave machines with the same static IP.  

So if I assign whatever static IP I want, will I be given the option to find the correct static IP when launching the session? VE Pro is so "clever" it will just reconnect to the machine it wants (ie the slave it was last connected to) before I have the chance to say stop and have it connect somewhere else. Maybe if I understood the VE Pro server better, this might be obvious, so any words of wisdom would be appreciated.