Hi folks,
I work a lot with shared files on a Dropbox and find it inconvenient that .asd files are always created in the same directory as the original audio files. They're all uploaded to whatever shared folder I'm using and clutter it up, maybe causing confusion for any other folk we need to share those files with (often it's desk recordings from rehearsals, stems, etc. that we need to share with dep musicians, sound and lighting team etc.). I was looking for a solution for them to be kept in the Project folder or something like that but didn't find much except a thread from 2002...
I find .asd files really useful especially when working with long multitrack recordings so I don't just want to turn them off. I also don't want to be copying all the files I use somewhere else as that'll eat my hard drive space. Does anyone know a solution? If not, is there any chance of something being implemented where the .asd files could be kept in a separate directory?
I know I'm being picky here it doesn't cause me much pain but I thought, don't ask - don't get.
.asd files - any way to keep them somewhere else?
-
- Posts: 19
- Joined: Fri Jan 24, 2020 1:44 am
Re: .asd files - any way to keep them somewhere else?
This would be a nice option to have. Sometimes I import a file from my music library to use as a backing track, and I'd rather not pollute that with .asd files.
They could be saved to an alternative folder in the User Library (e.g. User Library/Analysis) or maybe along with other Ableton configuration (e.g. Library/Application Support on Mac).
They could be saved to an alternative folder in the User Library (e.g. User Library/Analysis) or maybe along with other Ableton configuration (e.g. Library/Application Support on Mac).
Re: .asd files - any way to keep them somewhere else?
Note that you can suppress the creation of .asd files by turning off the Create Analysis Files option in the File/Folder Preferences. All data (except for the default clip settings) can be recreated by Live if the .asd file is missing, however this will take some time for longer samples.
Mac Studio M2 Max and MacBook Pro M1
Genelec M030; Live 11.3.x and Live 12; macOS Sonoma
UAD Apollo Twin
Ableton Push 2
Genelec M030; Live 11.3.x and Live 12; macOS Sonoma
UAD Apollo Twin
Ableton Push 2
Re: .asd files - any way to keep them somewhere else?
Requested this for years.. Please give us a location to consolidate and store all these files instead of having them littered around the disk anytime you drag a sample into Live.
Re: .asd files - any way to keep them somewhere else?
Disabling the creation of .asd files will severely slow down Live during loading of sets or new audio files (which is like half the time you are using Live).
Having all .asd in a single folder looks like a good idea until you realize that it makes it a lot of work to locate .asd files for files you deleted/renamed outside Live (near impossible for files with similar names you may have dozens of, like "kick.wav" or "snare2.wav" etc.), and it would prevent file management of audio files outside Live, it would force you to do most (if not all) file organization tasks using only Live's Browser.
Renaming files/folders (outside Live) in particular would really break that single folder scheme.
I mean. renaming only the WAV/AIFs also breaks it in the current scheme, but at least with the .asds in the same folder it becomes instantly obvious you have to rename both .wav and .asd (or that you may want to delete the .asds and wait for their recreation, while with a single folder scheme you would have to hunt for the .asd in folder with thousands of files, millions for some people, and remember how audio files tend to have very similar names).
Same thing for an scheme using an central database. It actually forces the user to worry about micromanaging .asds or database entries if you ever use a file manager outside Live's Browser.
ASDs in the same folder are simpler and easier exactly because they are so conspicuous, what bothers people (the fact people can't not see them, can't ignore their existence) is exactly what makes it a better scheme than putting all ASDs in a single folder or databases.
Saving .asd in the Projects will result in redundant .asd files, and in extra time spent when loading files for the first time in a Project (if there are no .asds somewhere already then they obviously would have to be created from zero in the Project folder), basically nullifying the advantage of such a cache file.
Having all .asd in a single folder looks like a good idea until you realize that it makes it a lot of work to locate .asd files for files you deleted/renamed outside Live (near impossible for files with similar names you may have dozens of, like "kick.wav" or "snare2.wav" etc.), and it would prevent file management of audio files outside Live, it would force you to do most (if not all) file organization tasks using only Live's Browser.
Renaming files/folders (outside Live) in particular would really break that single folder scheme.
I mean. renaming only the WAV/AIFs also breaks it in the current scheme, but at least with the .asds in the same folder it becomes instantly obvious you have to rename both .wav and .asd (or that you may want to delete the .asds and wait for their recreation, while with a single folder scheme you would have to hunt for the .asd in folder with thousands of files, millions for some people, and remember how audio files tend to have very similar names).
Same thing for an scheme using an central database. It actually forces the user to worry about micromanaging .asds or database entries if you ever use a file manager outside Live's Browser.
ASDs in the same folder are simpler and easier exactly because they are so conspicuous, what bothers people (the fact people can't not see them, can't ignore their existence) is exactly what makes it a better scheme than putting all ASDs in a single folder or databases.
Saving .asd in the Projects will result in redundant .asd files, and in extra time spent when loading files for the first time in a Project (if there are no .asds somewhere already then they obviously would have to be created from zero in the Project folder), basically nullifying the advantage of such a cache file.
♥♥♥