I'm in the process of building my new audio workstation.
I'd love to be able to take my current drive with all of my T projects on it, and just mount it into the new machine.
Of course, the drive letter will change.
Rather than go through the headache of archiving each of the projects for use in the new machine, I would love to be able to have a relative file structure in T.
I'll try to elaborate here if this isn't clear yet.
Let's say my current project/edit is in this directory:
C:\Program Files\Tracktion\Scott's Tracktion Projects\Human Beat Box Experiment
I take that drive, mount it in a new PC, and it gets a new drive letter. From my understanding, Tracktion gets lost in finding all of the associated audio .wav and .mid and such that are part of the project.
Why couldn't there be an option in T such that the path is relative to the edit's location? My understanding is that this is not the way T references files, but has just one reference: path and filename combined together into one.
If this is already implemented, I apologize. If not, and it makes sense to include it, please join in.
I'd like to be able to have my T projects portable as possible - I'm considering using a USB external drive and I'd love to be able to port projects over to my Dad's really nice Dell laptop, when I want to do some field recording every once in awhile - and to just have this drive remote mounted in a corner where it can be noisy, but I put a box over top of it to keep it quiet.
What say you to this FR?
-Scott
FR? Relative File Structure
-
- KVRAF
- 4908 posts since 10 Aug, 2004 from Colorado Springs
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
AYE!
Says I.
I'm completely into this idea... or at least make an intelligent auto-find source .wav that could work on a per-project basis...
But better, a relative file structure.
Says I.
I'm completely into this idea... or at least make an intelligent auto-find source .wav that could work on a per-project basis...
But better, a relative file structure.
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
The audio analysis software that I use at work, ArtemiS, is from a company called Head Acoustics. They are somewhat famous for their binaural microphones. Their file reference scheme is completely relative to the project. The way their process works is as such:
I have my projects on a little 40 GB USB enclosure drive. At my desktop PC, that drive gets letter G. In the subjective evaluation laboratory room, when I connnect that drive, it connects as F.
I simply do an 'update directories' in the project, point to where one of the 'lost' files is, and bingo, that relative file reference gets moved onto all of the other 'lost' files. The process takes all of 15 seconds at most.
-Scott
I have my projects on a little 40 GB USB enclosure drive. At my desktop PC, that drive gets letter G. In the subjective evaluation laboratory room, when I connnect that drive, it connects as F.
I simply do an 'update directories' in the project, point to where one of the 'lost' files is, and bingo, that relative file reference gets moved onto all of the other 'lost' files. The process takes all of 15 seconds at most.
-Scott
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
Sounds good.
-
- KVRAF
- 6740 posts since 25 Mar, 2002 from sheffield, england
I agree with the FR Scott, it makes sense.
Meanwhile, could you re-assign drive-letters so that your new drive ends up with the same letter your old one did..? Thats how I do it anyway: my audio drive is always "D", but the actual partition has changed several times..
Meanwhile, could you re-assign drive-letters so that your new drive ends up with the same letter your old one did..? Thats how I do it anyway: my audio drive is always "D", but the actual partition has changed several times..
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
Sadly, no.IIRs wrote:I agree with the FR Scott, it makes sense.
Meanwhile, could you re-assign drive-letters so that your new drive ends up with the same letter your old one did..? Thats how I do it anyway: my audio drive is always "D", but the actual partition has changed several times..
Prepare yeself for a shock - until the last month or so, I put all my projects where T defaulted to: C:\program files\Tracktion\
This old drive will not be my main drive on the next machine. In fact, I will likely put it in a USB enclosure to port around.
I probably need more piling on here for haydxn to add it to the officially unofficial FR sticky.
-Scott
-
- KVRAF
- 6740 posts since 25 Mar, 2002 from sheffield, england
Well, your boot drive doesn't have to be "C" you know.. mine is "E" at the moment. 
-
- KVRAF
- 6740 posts since 25 Mar, 2002 from sheffield, england
But frankly, I would probably go through the hassle of exporting archives rather than have a meaningless "program files" in the path.. 
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
I didn't know that - I'm a win-idiot.IIRs wrote:Well, your boot drive doesn't have to be "C" you know.. mine is "E" at the moment.
-Scott
-
- KVRer
- 3 posts since 12 Dec, 2003
Maybe it's just me being stupid, but have you actually tried this? I recently moved a bunch of projects arround and haven't had any problems yet. I also had a quick look at the project file and it doesn't look like it has any absolute paths in it. I always keep audio files in the same directory as the project file so maybe that makes a difference.
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
No, I haven't tried it. I have read threads here where folks complain that their audio clips get lost when they move projects around.Kit wrote:Maybe it's just me being stupid, but have you actually tried this? I recently moved a bunch of projects arround and haven't had any problems yet. I also had a quick look at the project file and it doesn't look like it has any absolute paths in it. I always keep audio files in the same directory as the project file so maybe that makes a difference.
I guess I will just have to give it a try when I'm finished putting the new PC together.
-Scott
-
- KVRAF
- 3364 posts since 16 Feb, 2004 from atop a katamari
Added to the list 
however, there is one thing that would definitely cause problems. If your project contains a sample from a dedicated sample resource folder (as many people would find themselves doing - for example "D:\samples\loops\drums\120bpm\mildgroove_mixed.wav") then a relative link would entirely f*Xx0r the project if they stayed relative. Thus, it should keep only relative file references if they are actually stored within the same project tree branch. Whatever happens, there may be problems.
project:
D:\AudioWork\Tracktion Projects\BigBeatstravaganza\
some files:
D:\AudioWork\Tracktion Projects\BigBeatstravaganza\recording1.wav
D:\AudioWork\Tracktion Projects\BigBeatstravaganza\recording2.wav
D:\AudioWork\Samples\instruments\jewsHarpLine1.wav
D:\Animal noises\GruntingSwan.wav
E:\Commercial samples\vocal\licensedCherEffectAcapella.wav
how would it decide which to keep as relative? obviously you'd expect a different drive's file to be kept as a strong link. a relative link would be impossible there. if you were to change the D drive, then you'd be okay with relative links for the same drive if the file structure stayed the same, provided it did indeed keep different drive files literal.
but what if you just wanted to move the project BigBeatstravaganza folder? The relative link to the sample in the samples folder would be invalid. Or if you were just to move the main projects folder, the same would be true. Perhaps it would be designed so that the folder structure would be checked too, so that if it is definitely not in the same branch (such as with the animal noises samples) then they would be literal also. but where is the line drawn? it would seem that there will ALWAYS be cases where the system will break, no matter what approach is used.
my personal solution would be to check each file when it is imported, and only keep a relative link if it is within the project folder, or any contained child folders. that is the only way that the system can work in an obvious and predictable manner - you can easily imagine it working like this. if other folder paths were considered, then moving just the project folder would destroy any of those links. changing the drive letter without moving the project would cause problems in this case too, because the samples in any OTHER folders would have their links lost.. but as i said there is no solution that will work for all cases.
the only definite "it's possible to do any kind of movement and still be able to rely on the file links being valid" solution would be to have a toggle on the files in the project, where you can specify whether it is stored as a relative path or a literal path. that would require going thru them and setting them yourself, but you can't really expect a program to be able to predict exactly what kind of strange moving-around behaviour you're going to use. you'd just set the types accordingly and then do your move, and the files would all be safe. perhaps there could be a wizard that makes it easier for you.
it would be nice to have a button called "file referencing options", which could also be used to house functions like "find orphan clips" and such. that could present you with a list of possible safeguards to apply before you move your drives/folders around.
however, there is one thing that would definitely cause problems. If your project contains a sample from a dedicated sample resource folder (as many people would find themselves doing - for example "D:\samples\loops\drums\120bpm\mildgroove_mixed.wav") then a relative link would entirely f*Xx0r the project if they stayed relative. Thus, it should keep only relative file references if they are actually stored within the same project tree branch. Whatever happens, there may be problems.
project:
D:\AudioWork\Tracktion Projects\BigBeatstravaganza\
some files:
D:\AudioWork\Tracktion Projects\BigBeatstravaganza\recording1.wav
D:\AudioWork\Tracktion Projects\BigBeatstravaganza\recording2.wav
D:\AudioWork\Samples\instruments\jewsHarpLine1.wav
D:\Animal noises\GruntingSwan.wav
E:\Commercial samples\vocal\licensedCherEffectAcapella.wav
how would it decide which to keep as relative? obviously you'd expect a different drive's file to be kept as a strong link. a relative link would be impossible there. if you were to change the D drive, then you'd be okay with relative links for the same drive if the file structure stayed the same, provided it did indeed keep different drive files literal.
but what if you just wanted to move the project BigBeatstravaganza folder? The relative link to the sample in the samples folder would be invalid. Or if you were just to move the main projects folder, the same would be true. Perhaps it would be designed so that the folder structure would be checked too, so that if it is definitely not in the same branch (such as with the animal noises samples) then they would be literal also. but where is the line drawn? it would seem that there will ALWAYS be cases where the system will break, no matter what approach is used.
my personal solution would be to check each file when it is imported, and only keep a relative link if it is within the project folder, or any contained child folders. that is the only way that the system can work in an obvious and predictable manner - you can easily imagine it working like this. if other folder paths were considered, then moving just the project folder would destroy any of those links. changing the drive letter without moving the project would cause problems in this case too, because the samples in any OTHER folders would have their links lost.. but as i said there is no solution that will work for all cases.
the only definite "it's possible to do any kind of movement and still be able to rely on the file links being valid" solution would be to have a toggle on the files in the project, where you can specify whether it is stored as a relative path or a literal path. that would require going thru them and setting them yourself, but you can't really expect a program to be able to predict exactly what kind of strange moving-around behaviour you're going to use. you'd just set the types accordingly and then do your move, and the files would all be safe. perhaps there could be a wizard that makes it easier for you.
it would be nice to have a button called "file referencing options", which could also be used to house functions like "find orphan clips" and such. that could present you with a list of possible safeguards to apply before you move your drives/folders around.
Kick, punch, it's all in the mind.
-
- KVRAF
- 3364 posts since 16 Feb, 2004 from atop a katamari
personally, i'm happy with the 'export edit' function to get all my stuff together in one place, then move it. i wouldn't dream of moving a project without doing that. so i think that it may well all be inconsequential. whatever happens, you'll have to do some kind of work before you move stuff around. it's inevitable.
Kick, punch, it's all in the mind.
-
- KVRAF
- Topic Starter
- 4908 posts since 10 Aug, 2004 from Colorado Springs
Maybe I'm making too much out of this. I haven't moved any projects yet, just have read the grief that others have gone through.
All of my projects; the edits and all related audio and midi clips are organized into folders that I have named with the project name. I don't draw samples from outside of those folders.
-Scott
All of my projects; the edits and all related audio and midi clips are organized into folders that I have named with the project name. I don't draw samples from outside of those folders.
-Scott
-
- KVRAF
- 12977 posts since 29 Sep, 2003 from Ottawa, Canada
I'd like it implemented just for consistency and thoroughness, but I also use "export edit".
Export Edit is stupid right now, too, though, if you export multiple edits that share the same clips and try to re-import them all. The Project List shows an entry for each duplicate that you re-unpack.
Doesn't happen if you just 'export project', of course, but I like to export a series of edits in order to clean stuff up, while I'm at it.
Greg
Export Edit is stupid right now, too, though, if you export multiple edits that share the same clips and try to re-import them all. The Project List shows an entry for each duplicate that you re-unpack.
Doesn't happen if you just 'export project', of course, but I like to export a series of edits in order to clean stuff up, while I'm at it.
Greg