Hi!
There are two major things that the file browser did in Live 8 and now doesn't do in Live 9, harmful regressions that I wish you'd fix:
1. See symbolic links.
This is THE deal breaker that prevents me from upgrading to 9 today. I have painstakingly organized all my samples using symbolic links, and I'd be throwing that away if I started using Live 9.
2. Have more than one info column other than the file name visible.
I want to be able to see size AND last modified date, and I switch between sortings all the time. This restriction is so arbitrary, I have not been able to come up with a rationale for it.
Please, please consider re-enabling these basic functionalities, without which the file browser is so severely hampered. This is literally the only thing that's keeping me from upgrading to 9.
I would, in addition, appreciate the option to change the default behaviour back to not automatically close the currently opened directory when you open another one. I know you can use CTRL to suppress that, but there's no way to reverse the standard behaviour, and it sucks browsing samples holding the ctrl key all the time, and you lose all your open directories if you make a mistake and forget to hold ctrl even once.
Thanks for your time!
—Please Bring The File Browser Back To Live 8 Functionality—
-
- Posts: 1205
- Joined: Thu Aug 11, 2005 12:29 pm
- Location: Norway
Re: —Please Bring The File Browser Back To Live 8 Functionality—
I didn't know you could only have one info column at the time. That's crazy! Just as pointless as no transposition of multiple MIDI clips.
As for folders closing, it would be nice to have a toggle button for the two folder modes.
I mostly like the "one-folder-only mode", but sometimes I also miss having several folders open without risking having them all closed because I forget to hold ctrl.
As for folders closing, it would be nice to have a toggle button for the two folder modes.
I mostly like the "one-folder-only mode", but sometimes I also miss having several folders open without risking having them all closed because I forget to hold ctrl.
Re: —Please Bring The File Browser Back To Live 8 Functionality—
This functionality is never coming back, is it?
So, let's perhaps talk alternatives:
Is there a way to organize samples that live in multiple directories so that they appear in one place in Live 9? Is there a way for a sample to appear in more than one place without having to duplicate it?
So, let's perhaps talk alternatives:
Is there a way to organize samples that live in multiple directories so that they appear in one place in Live 9? Is there a way for a sample to appear in more than one place without having to duplicate it?
-
- Posts: 7033
- Joined: Wed Jun 25, 2014 11:34 am
Re: —Please Bring The File Browser Back To Live 8 Functionality—
Yes, please.wayfinder wrote: 1. See symbolic links.
Actually you can have two columns. Just right-click in the column bar. Sort by clicking on the other column. I suppose up to 4 would be nice.wayfinder wrote: 2. Have ore than one info column other than the file name visible.
In addition I think arguing to go back to the previous version won't get you very far. Why not focus on the actual specific gains for the user instead of the specific implementation you are fixated on? The 9 browser certainly can be improved, but forward is where the solution is. I actually prefer it to the 8.
Make some music!
Re: —Please Bring The File Browser Back To Live 8 Functionality—
They made a big mistake when they created the L9 browser, I guess there were time pressures.
The database ought to allow any content to be situated anywhere and that the browser is merely a selection of views of that model.
It partly does this. Half of the solution is in place.
The problem is that the "tags" which you see in the browser, such as "ambient and evolving" are derived from file-tree names, folders. They are visually represented as if they are folders, so there's an arbitrary 1-to-1 connection. A file can only be in one "folder", and that's how Ableton decide its one singular attribute "this sound is a drum and it is an analog drum". So Drum hits/analog drums/ . That's not the point of databases filled with meta key value pairs (which is what they actually have in the database) . They ought to allow a many to many taxonomic classification of assets. "This sound is a drum, and dark, and analog, and metallic, and rhythmic, and ..."
The Ableton database will allow that, but there is no UI to assign attributes to assets, the attributes are assigned solely by folder and file name.
So while the rest of the computing world rejoice in taxonomic complexity, where a preset sound can be rhythmic, synthetic, metallic, orchestral and dark. In the Ableton world an asset can only reside at the end of one Hierarchic tree branch. Synths/ambient/ . So nothing Ableton can exist in two places. They told me this was intentional.
I mentioned this was crazy at the time it was proposed and got a stony silence, then an angry "so what do you want us to say?". So I really don't feel that they even understood what they had done wrong. There was a lot of dismissive talk about the uselessness of assigned tags as a taxonomic strategy. I found it very very worrying and I still do.
All objects have multiple attributes, and filtering the many attributes helps us locate candidates. This is basic. Hierarchic models are only good when we already know where something is to be found.
So when they discarded the idea that all objects have more than one attribute they ran into a wall. The user must name a hihat "hihat", or "high-hat" or "hi-hat" ... In fact they had to fill their db with alternate spellings to pattern match file tree names a user might save content as, all just to be able to taxonomically classify content 1-to-1. Leaving them with a half broken system.
Hopefully they understand and rectify this disaster in L10.
The database ought to allow any content to be situated anywhere and that the browser is merely a selection of views of that model.
It partly does this. Half of the solution is in place.
The problem is that the "tags" which you see in the browser, such as "ambient and evolving" are derived from file-tree names, folders. They are visually represented as if they are folders, so there's an arbitrary 1-to-1 connection. A file can only be in one "folder", and that's how Ableton decide its one singular attribute "this sound is a drum and it is an analog drum". So Drum hits/analog drums/ . That's not the point of databases filled with meta key value pairs (which is what they actually have in the database) . They ought to allow a many to many taxonomic classification of assets. "This sound is a drum, and dark, and analog, and metallic, and rhythmic, and ..."
The Ableton database will allow that, but there is no UI to assign attributes to assets, the attributes are assigned solely by folder and file name.
So while the rest of the computing world rejoice in taxonomic complexity, where a preset sound can be rhythmic, synthetic, metallic, orchestral and dark. In the Ableton world an asset can only reside at the end of one Hierarchic tree branch. Synths/ambient/ . So nothing Ableton can exist in two places. They told me this was intentional.
I mentioned this was crazy at the time it was proposed and got a stony silence, then an angry "so what do you want us to say?". So I really don't feel that they even understood what they had done wrong. There was a lot of dismissive talk about the uselessness of assigned tags as a taxonomic strategy. I found it very very worrying and I still do.
All objects have multiple attributes, and filtering the many attributes helps us locate candidates. This is basic. Hierarchic models are only good when we already know where something is to be found.
So when they discarded the idea that all objects have more than one attribute they ran into a wall. The user must name a hihat "hihat", or "high-hat" or "hi-hat" ... In fact they had to fill their db with alternate spellings to pattern match file tree names a user might save content as, all just to be able to taxonomically classify content 1-to-1. Leaving them with a half broken system.
Hopefully they understand and rectify this disaster in L10.
Re: —Please Bring The File Browser Back To Live 8 Functionality—
Yeah, that's why I wrote one otherStromkraft wrote:Actually you can have two columns. Just right-click in the column bar. Sort by clicking on the other column. I suppose up to 4 would be nice.wayfinder wrote: 2. Have ore than one info column other than the file name visible.
I'm not fixated on anything and I feel like you're being unnecessarily argumentative. I'm not arguing for ripping out the Live 9 browser and putting the Live 8 one back in wholesale. If the functionality can be replicated some other way, and tags seem terrific for that and much more, then cool! It's also cool that you already prefer the new browser, but that fact alone doesn't invalidate a thing I said. It also doesn't give me back the literal weeks I spent organizing my samples using aliases (a practise that is explicitly endorsed in the manual when it comes to VSTs, by the way).Stromkraft wrote: In addition I think arguing to go back to the previous version won't get you very far. Why not focus on the actual specific gains for the user instead of the specific implementation you are fixated on? The 9 browser certainly can be improved, but forward is where the solution is. I actually prefer it to the 8.