Browser woes
-
- Posts: 82
- Joined: Sun Jan 03, 2010 9:44 pm
Browser woes
I was going to post in the other browser thread, but it appears to have been derailed.
I really like the layout of the new browser with custom "places" section - this makes sense, but having it driven by it's own index is just so inelegant.
My large sample folders are still scanning and only partially showing up. Been going for hours now, and even if I drag a file I need in from the finder, then right click and "show in browser", the browser just jumps to the nearest "place" that contains the new file, but not the actual folder or file is displayed (presumably as it hasn't been scanned yet)
Not being able to use the browser to simply browse the computer's file system is a big mistake IMO and makes a new feature which *looks* very good, feel very clunky.
Surely for users' places, it would make more sense for the browser to simply show the filesystem (as in the L8 browser), with the index only being referenced for search purposes and items in the Library? If a newly added file took a while to show up in searches, that would be tolerable, but not even being able to browse to it feels really badly thought out.
I really like the layout of the new browser with custom "places" section - this makes sense, but having it driven by it's own index is just so inelegant.
My large sample folders are still scanning and only partially showing up. Been going for hours now, and even if I drag a file I need in from the finder, then right click and "show in browser", the browser just jumps to the nearest "place" that contains the new file, but not the actual folder or file is displayed (presumably as it hasn't been scanned yet)
Not being able to use the browser to simply browse the computer's file system is a big mistake IMO and makes a new feature which *looks* very good, feel very clunky.
Surely for users' places, it would make more sense for the browser to simply show the filesystem (as in the L8 browser), with the index only being referenced for search purposes and items in the Library? If a newly added file took a while to show up in searches, that would be tolerable, but not even being able to browse to it feels really badly thought out.
-
- Posts: 841
- Joined: Mon Apr 06, 2009 5:10 pm
- Location: Central Coast, California
- Contact:
Re: Browser woes
I like the fact that the index makes searching fast later, but I'd personally like some kind of indication that a given folder isn't finished yet, since I kind of worry when I can't find a file that I know exists.
Some sort of un-indexed browser view like you suggest would be cool too, although I'm not sure how to keep the interface clean.
Some sort of un-indexed browser view like you suggest would be cool too, although I'm not sure how to keep the interface clean.
-
- Posts: 82
- Joined: Sun Jan 03, 2010 9:44 pm
Re: Browser woes
I don't see why the browser doesn't just show the filesystem as in Live 8 for user places, with the indexing system running in the background for search purposes and the Library content.
This wouldn't affect the appearance of the interface at all, but would improve the experience considerably.
This wouldn't affect the appearance of the interface at all, but would improve the experience considerably.
Re: Browser woes
Hi,
We hear you. As said in the other thread, we're working on fixing the too long scanning times for folders full of samples and fixing the too high CPU usage the Indexer consumes on OSX.
Kind regards,
Amaury
We hear you. As said in the other thread, we're working on fixing the too long scanning times for folders full of samples and fixing the too high CPU usage the Indexer consumes on OSX.
Kind regards,
Amaury
Ableton Product Team
-
- Posts: 1807
- Joined: Tue Nov 16, 2004 6:27 pm
- Location: Here and There
- Contact:
Re: Browser woes
Amaury,
How about the fact that a search doesn't return results? Only the folders with the results hidden. Wouldn't it make more sense to return the results with the folders open so the user can see the results?
Cheers,
Mike
How about the fact that a search doesn't return results? Only the folders with the results hidden. Wouldn't it make more sense to return the results with the folders open so the user can see the results?
Cheers,
Mike
Re: Browser woes
I still think it's missing the point, any type of scanning will add some amount of time between items being added and being visible in the browser, similarly any amount of CPU being spent on the indexing process is taking away CPU power from the purpose of the app, making music.Amaury wrote:Hi,
We hear you. As said in the other thread, we're working on fixing the too long scanning times for folders full of samples and fixing the too high CPU usage the Indexer consumes on OSX.
Kind regards,
Amaury
Some of us don't want or need a heavily optimised hammer, we just want to access our files.
Just an option : -ExcludeUserPlacesFromIndex
thanks
Re: Browser woes
That's another topic. Currently, we filter the visible contents in a each labels when typing a search string. Flattening the results is something we hear of, of course, and consider for a later update but there is no promise at this point.mike@TrackTeam Audio wrote:Amaury,
How about the fact that a search doesn't return results? Only the folders with the results hidden. Wouldn't it make more sense to return the results with the folders open so the user can see the results?
Cheers,
Mike
Ableton Product Team
Re: Browser woes
We're aware of the goals: seeing contents as fast as possible, and not impeding music making by eating up CPU resources. We're looking into that. The solution may or may not be to not index folders. Is that what you're concerned with?mdk wrote:I still think it's missing the point, any type of scanning will add some amount of time between items being added and being visible in the browser, similarly any amount of CPU being spent on the indexing process is taking away CPU power from the purpose of the app, making music.Amaury wrote:Hi,
We hear you. As said in the other thread, we're working on fixing the too long scanning times for folders full of samples and fixing the too high CPU usage the Indexer consumes on OSX.
Kind regards,
Amaury
Some of us don't want or need a heavily optimised hammer, we just want to access our files.
Just an option : -ExcludeUserPlacesFromIndex
thanks
Regards,
Amaury
Ableton Product Team
-
- Posts: 82
- Joined: Sun Jan 03, 2010 9:44 pm
Re: Browser woes
Thanks for letting us know you're working on it Amaury, but however fast you make the scanning, it will always be clunky compared to direct access to the filesystem in certain use cases, for example:Amaury wrote:Hi,
We hear you. As said in the other thread, we're working on fixing the too long scanning times for folders full of samples and fixing the too high CPU usage the Indexer consumes on OSX.
Kind regards,
Amaury
I often collect samples I wish to use and drop them into a new folder (a subfolder of one of my "places") before even opening Live. It makes no sense that when I do open Live, I can't just browse to the new folder and start work, but have to wait for the browser to find and scan the new subfolder first.
I agree with mike about the search only returning containing folders too, rather than the actual hits - this makes the search slow to use, so still find myself just using spotlight.
-
- Posts: 1807
- Joined: Tue Nov 16, 2004 6:27 pm
- Location: Here and There
- Contact:
Re: Browser woes
Thank you for the response and apologies for sort of going OT( the topic title is a bit broad though ). I saw you post in this thread and got trigger happyAmaury wrote:That's another topic. Currently, we filter the visible contents in a each labels when typing a search string. Flattening the results is something we hear of, of course, and consider for a later update but there is no promise at this point.mike@TrackTeam Audio wrote:Amaury,
How about the fact that a search doesn't return results? Only the folders with the results hidden. Wouldn't it make more sense to return the results with the folders open so the user can see the results?
Cheers,
Mike
Just to clear up what i meant and I don't expect a response.
Im not saying a flat result, just the result the way it is now, except the folders in the path leading to the result are all open.
Thanks again
Mike
Re: Browser woes
As far as this aspect of the browser goes yes, exactly that. I know there is a trade off between using an index and the speed of searching from within the Live browser. I'm saying that i'm only concerned about my data appearing exactly as it is on disk, not about the speed of the browser search. For others i'm sure the search is more important.Amaury wrote:We're aware of the goals: seeing contents as fast as possible, and not impeding music making by eating up CPU resources. We're looking into that. The solution may or may not be to not index folders. Is that what you're concerned with?
Good luck.
Re: Browser woes
I see. The interaction of opening folders and possibly closing them again depending on the fact that there is a search string in the search field or not may be sub-optimal though. We'll see if we come to terms to address this. Again, we're focusing on speed issues these days.mike@TrackTeam Audio wrote:Thank you for the response and apologies for sort of going OT( the topic title is a bit broad though ). I saw you post in this thread and got trigger happyAmaury wrote:That's another topic. Currently, we filter the visible contents in a each labels when typing a search string. Flattening the results is something we hear of, of course, and consider for a later update but there is no promise at this point.mike@TrackTeam Audio wrote:Amaury,
How about the fact that a search doesn't return results? Only the folders with the results hidden. Wouldn't it make more sense to return the results with the folders open so the user can see the results?
Cheers,
Mike
Just to clear up what i meant and I don't expect a response.
Im not saying a flat result, just the result the way it is now, except the folders in the path leading to the result are all open.
Thanks again
Mike
Ableton Product Team
Re: Browser woes
The hope is to make files appear mostly immediately while keeping the benefits of fast search. If we can't reach that well enough then we'll see for other kind of solutions.mdk wrote:As far as this aspect of the browser goes yes, exactly that. I know there is a trade off between using an index and the speed of searching from within the Live browser. I'm saying that i'm only concerned about my data appearing exactly as it is on disk, not about the speed of the browser search. For others i'm sure the search is more important.Amaury wrote:We're aware of the goals: seeing contents as fast as possible, and not impeding music making by eating up CPU resources. We're looking into that. The solution may or may not be to not index folders. Is that what you're concerned with?
Good luck.
Ableton Product Team
-
- Posts: 1807
- Joined: Tue Nov 16, 2004 6:27 pm
- Location: Here and There
- Contact:
-
- Posts: 852
- Joined: Mon Jan 29, 2007 11:04 pm
- Location: the Netherlands
Re: Browser woes
well to be fair, you could simply add that new folder itself as a user folder under places, and it should scan pretty much instantly (unless you're talking about hundreds of gigabytes of samples), right?paulmaddox wrote:Thanks for letting us know you're working on it Amaury, but however fast you make the scanning, it will always be clunky compared to direct access to the filesystem in certain use cases, for example:
I often collect samples I wish to use and drop them into a new folder (a subfolder of one of my "places") before even opening Live. It makes no sense that when I do open Live, I can't just browse to the new folder and start work, but have to wait for the browser to find and scan the new subfolder first.