skatr2 wrote:I haven't read everything through this thread, but I think a lot of whats happening with these moves is how hard it is to deal with how things are changing. One of my hardest sells on iTunes and similar programs when it first came out was "where the hell is it stored"? It was a hard transition going to mac as well; the thought of using a program to access content rather than directly looking for the content first. I got so used to knowing what folder held which song and navigating via that method that I said "I don't need a program to organize for me, I have my own organization".
As computers and the like evolve, they are moving away from our own forms of organization and going with the computer doing the task while we focus on what we need to focus on. Once your stuff is integrated, you can narrow down your search easier. The tough part is the integration process...which will likely be a hiccup in any system. Now I use iTunes to simply sort by genre, then artist and I just narrowed things down just as well as if I was navigating folders. Point being these changes are adaptable and so long as you take a moment to incorporate them, you will be infinitely more up to the change. If you are that locked into your original method, why bother upgrading in the first place? You clearly didn't need the change.
As I have played with live9 trial, I have liked the browser so far, albeit I have not attempted to throw in extended libraries into the mix...and likely won't on the scale that the original posters of this thread are stating. If anything I want to consolidate my library at this point.
I disagree. There are two issues.
#1 the indexing system currently has some issues so that large directories, removable drives, etc. are added too slowly
#2 the categorisation does not match user expectations
regarding issue #2 , you say that it's something that the user must get used to . That the chosen categorisations are something which should be accepted. I would say that every user thinks of every item of content differently, and differently dependent on context of requirement.
An example I've used before is shown in the categorisations "Ambient and Evolving" and "Pads". Now, we have a Rack Instrument preset called "All Alone Pad". which category would you say that this should be in? Which of the two?
Answer: it actually resides in "Ambient and Evolving", and I say that this is
not wrong, it is obviously correct for
whoever put it there. It's simultaneously not right, because that's not where anyone else would look for it.
Categorisations of multi-faceted objects should not be mutually exclusive. However, in this system they are.
Mutually exclusive categorisation
A real world object might be defined as having many properties, such as [flat, hard, shiny, static, reflective, breakable], that's a mirror. I can categorically find it by filtering for breakable flat things, or reflective hard things. I would get a group of objects in a contextual family. A mirror, a chrome sphere, a glass picture frame. All contextually useful results.
Now how about we define an object with one property [Flat] ?
Is that a success? What sort of results might we expect from this?
How about [bass] ?
This system only allows single category parents, an arbitrary hierarchic tree. So you cannot claim that it is better than a file-system derived hierarchic file browser. Because in a file-system hierarchic browser we can use parent folders as taxonomic indicators, and in this system we cannot. It has the same tree-like restrictions of an OS file system, but the only benefit delivered is "fast text filtering". Actually browsing is less functional.
tldr;
there are two issues. Indexing, and categorisation.