.asd files - any way to keep them somewhere else?

[anguswalk]

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.

[spiritofeden]

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).

[cids]

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.

[cotdagoo]

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.

[pottering]

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.

[Hammy Havoc]

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.

What probably makes the most sense is allowing users to choose what works best for them. I can appreciate that what works varies drastically between people—it's as polarizing as the Session View for a lot of folks, I'm sure.

For me, I'd rather have file-paths centralized within a database, then, if I do make any changes to files beyond the browser, I could either remap the file-path ala Native Access, or it could figure it out through any matching file hashes. Where the `.asd` files become annoying is when you're dealing with data in other DAWs, and it doubles the amount of scrolls you need to go through, thus browsing takes 2x the time. "Don't use other DAWs then" you cry, but some workflows aren't that simple and likely never will be when it comes to audio middleware, Atmos et al. It's not a deal-breaker, it's just messy, IMO.

[benmuetsch]

+1, seperate folder for asd files would be excellent.

Also, why not store all preferences, collections and places in a cfg file inside the user library? Right now they are somewhere in the system files.