1 session, multiple drives - help requested

[voce]

So, I've gotten away with running 50-60 tracks for years on a firewire drive on our MIX system with only a rare hiccup, but apparently HD ain't havin' none of dat. After talking with Digi, they recommended I defrag my drives ( I re-imaged all of them) , and told me I'd have to split the tracks up onto multiple drives. I know when you record, you can set it to use "round robin", where it records to mutiple drives. But I've never tried this once it's already recorded and I need to mix. Is there a particular method you (users) can suggest to cleanly do this. Everything is backed up, btw. Any specific help you can offer would be much appreciated. I'll also need to figure out hoe to get Retrospect tp properly back the new sessions up - Jeremy, any tips? (I saw a post you made @ this in a 9076 error thread)

PS - SCSI is not an option at this time - I'm not in the market for an expansion chassis right now...

Thanks in advance folks...

[Craig F]

could you put an extra internal drive in the computer to run off of?

system specifics would help

[jeremyroberts]

retrospect tricks:

1. ALWAYS use scripts
2. name your session folders on each drive EXACTLY the same (if PT is creating the folders, it will do this for you)
3. It doesn't hurt to have a "project" folder...

for example:

DRIVE_A --> project folder --> session folder
DRIVE_B --> project folder --> session folder

when you make your script in retrospect, "simply" choose the "project" folder(s)

For a restore, Retro will preserve the folder structure (all the way to the drive level) - HOWEVER, it WILL NOT put drive_a's project folder on A, and drive_B on B... you will restore to one drive, then move the B project folder to B. Then, you will tell PT (disk allocation) where new files go.

working multiple disks is nothing to worry about. try it with a test session and then back it up and restore - before you have any talent around, or do real work.

[voce]

Thanks a bunch for the help thus far...my system specifics:

HD3 Accel running 6.9.1
G5 2.5X2, w/2GB RAM running 10.3.6

So, in order to split an existing session onto other drives, should I just try moving some files, then changing allocation settings for said files? Probably seems like a simple question; just want to be sure.

Also, would a partition (on same drive) count as another drive? I am thinking not, but if so it would help a lot and reduce clutter. I've got about 6 full length CDs recorded and in the process of being mixed at any given time, all w/sessions containing 40-80 tracks, so you can see how the drives could stack up quickly...

thanks again...

[jeremyroberts]

would a partition (on same drive) count as another drive? I am thinking not, but if so it would help a lot and reduce clutter. I've got about 6 full length CDs recorded and in the process of being mixed at any given time, all w/sessions containing 40-80 tracks, so you can see how the drives could stack up quickly...

no. a partition is merely a way to organize... the drive spec is related to the size of the pipe. there is a finite amount of throughput that can travel from the drive to the cpu. doesn't matter if you're in 2 or 3 or 1 partition, the pipe is only so big. now, in the old days, a partition was used to force certain data to the "inside" of the drive platter - but with fast seek times and higher rotational speed of modern drives, there is little performance increase, so few do this anymore.

Like many of us, I am always working on 3 albums + demos for 3 more at any given time. I have at least a dozen FW drives. All labeled, and backed up. I just bought another 160gig WD yesterday at compUSA for $40 (after rebates). No reason to not have a bunch of these. I typically buy a new FW drive every time they do a crazy sale like this. At $.25/gig, drives have never been cheaper. Backup early, and often.

Final thought: run retrospect on a server (doesn't have to be a real server, but any fast computer, with gigabit ethernet) - get a gigabit switch - connect your removable media to the server. Retrospect can run in the background, unattended (except for media requests). This frees your protools rig to do protools, and retrospect can do its thing all day long and never get in your way.