Ableton Forum

What's the advice for just starting over, from scratch (Suite).
Almost wish I could just download the physical discs that come with the actual box.
In lieu of that, how would one proceed?

Funk N. Furter wrote:I'm not really sure why you feel that it's got into a mess though.

I'm amazed anyone thinks the Live 9 library & browser is in any way "OK".

it is such a fuck up that I work in Live 8, and only open Live 9 when my content is in place and only if I need to use the new compressor, EQ or dual monitors. My Live 9 browser is Live8.

All the new browser does is fuck up, hide and un-order my content for no benefit whatsoever.

Angstrom please tell us how you really feel.

I'm with Angstrom. I've been doing exactly the same thing.

I just need a quick summary/reminder

Angstrom wrote:

Funk N. Furter wrote: All the new browser does is fuck up, hide and un-order my content for no benefit whatsoever.

One thing in Live9 Browser that is a big improvement is Packs.
In Live8 I could never find where installed live pack stuff was.
Now things are easy to find no matter how many packs I install.
Because of this I use Suite content more than in Live8.

They should just add user definable tags so finding presets and samples was easier.

improvement: searching is much faster. multiple folders can be fused into the library.

step backwards: FRAGMENTED presets for devices. in other words there is no top-down view to see, for example, all operator presets (none that I can find). THIS is the part that can improve.

awkward: beautiful top level tree/folder structure for core presets, but many user and 3rd party presets get flushed into "other" folders, which almost distracts me from using that top level browser in the first place. an improvement here is some system where the user can change the folders used for all content outside of the core library.


I wouldn't call it a mess, but there are certain ideas in the design that I think even ableton understands are not finished in the way they would really want.

The problem with explaining the problem is I feel like I'm trying to explain the colour orange to colour blind people. "But the brown is great"

Firstly it's worth reiterating that the L8 browser is not good. It is a basic OS filetree browser. Filetrees are not good for discovering sounds or locating sounds for which you forgot the location, but you can at least create an arbitrary folder structure such as Synths/MySynths/pads or MySounds/pads/Vintage with some hope you learn where you have hidden things. This is not a good system, but it's personal to each user, therefore memorable, and so can mitigate the awfulness with use.

Filetrees are bad as a sole asset acquisition methodology, but are at least learnable. Additionally the L8 results list had some basic attribute columns such as Date, Location, type, etc. so a mysterious result list could be evaluated for suitability. So a search for "Ang Pad" would return results from all locations with Name, Path, Pack, Type and Datemodified all visible. The user can then say "Ah, a RackPreset created on 11/11/2013, yes that seems the one".

Bad, but personal.

Now, in L9 there is a database. This should be great for discovering sounds, It should be able to categorise and group similar sounds, or find sounds where you forgot the location, or to temporarily group sounds ("My Live Presets 2012" / "new live presets 2013") or to annotate sounds. It should prevent assets from becoming lost in filetrees like MySounds/New/Oldnew/synths/test/importantbasssound2011/

But sadly it's worse for those things. The database is actually based upon a hidden filetree, which is no longer user definable. There are meta key value pairs, but many are not (yet) implemented. There is no interface for example for the ID3 tags it stores, or for filtering on multiple attributes [Show me : Pads, Evolving, Orchestral, 2013, Angstrom]. The user can neither define an attribute, nor can the user define "MySounds/Pads/Vintage/Phat".

I'm not saying that Live 8 could do these things, I'm saying that this is the point of creating a databse system and if your database system cannot deliver on that then you probably should not be taking away any features such as allowing users to prioritise their content, or classify content, or use aliasses to their content.

The sole point of a databased asset library is to provide flexible, deep taxonomic classification and asset retrieval for a wide variety of Users and use-cases.

The idea is that different users classify, group, store, search, browse and retrieve assets differently and they also do that differently in different situations. So a Stage Performance retrieval of a Bass sound "get me the new Live Moog Bass", might be a different modality from "flipping through all my new presets on sunday".

A database library system can accomodate these different requirements because all that is required is the correct query. In a databased library the files are not locked in place in some arbitrary tree, they simply hold properties which can be asked for and the user sees what is appropriate.

Or should do.

Unfortunate Incoherence
Sadly the taxonomies (the attributes which can be applied to content) are not handled at all well. The simplest example of this is in the section "Sounds", which is in fact a set of tonality tags which can be applied to content. For example "Ambient and Evolving" is a descriptive label as is "Orchestral". Unfortunately Ableton decided to create the "Sounds" tonality tags from the OS FileTree folders in which the asset is saved, rather than simply assigning the meta-tag"Tonality" allowing multiple tonalities to be assigned to an asset.

So this is why we see the Pad : "All Alone Pad" exists only in Ambient and evolving, and does not appear at all in "pads". Ableton have a database system built on metatags, but their tags don't use it!

This is very strange, because the entire point of a database system is to be able to link multiple attributes to content. The idea is by providing multiple handles on the asset then it is more findable. If you provide only one hook then it is not very discoverable at all, in fact - you can only call on it if you know its "address". Just like our old annoying file-tree. But without the ability to put it where we want.

Imagine that we might create a new RackPreset which is a distorted slightly orchestral pad, which evolves over time and look to save it somewhere in which we can find it again. It is a Pad, Orchestral, Ambient and Evolving. These are not mutually exclusive descriptions. But in Ableton they are. So Ableton asks us to choose "where will you put this asset". This is the wrong way to do this. The location should be unimportant, the attributes are important. Providing many parallel attributes means many Users may find the asset in many Use-cases.

You see the Database is actually scanning a filetree, and mapping the OS folder names as tags in a linear cascading fashion. So each asset may only belong to one taxonomy. This is very wrong. It undermines the whole point

Well, this is pointless.
There is a LOT more I could say about this project and its implementation. I could write the same again about the meaningless "Categories" (Drums are like Max for Live, but Bass is not, and Convolution Reverb is not an Effect), I find it physically painful to look at it.

I explained all this to Ableton when they started this process. I just find it painful.

Angstrom wrote: Now, in L9 there is a database. This should be great for discovering sounds, It should be able to categorise and group similar sounds, or find sounds where you forgot the location, or to temporarily group sounds ("My Live Presets 2012" / "new live presets 2013") or to annotate sounds. It should prevent assets from becoming lost in filetrees like MySounds/New/Oldnew/synths/test/importantbasssound2011/

Agree that this is what is really needed. User definable tags is one step to this direction.

I'd like to ask: what in your opinion is the best implementation of such sound categorisation/browsing system that you've used?
I think Alchemy VST has a pretty good preset browser.

Funk N. Furter wrote:Angstrom, knowing what you know, do you think Ableton can substantially improve the Live 9 system and if so what would be the main steps?

Yes, they can improve it. In some cases the improvements are hidden under the hood already (ID3 version 1 tags are already in there) , in other cases they may have to make a bold decision ( Eg putting he headline Max Audio effects like reverb into Audio Effects).
However the things which concern me is not putingt the tonality tags (ambient&evolving, pads, etc) in the metatags section of the db . They have tables for metadata, metakeys, metavalues. These currently save things like "pack-author", "device-type" , "creation date" . All good and useful stuff. So an asset can (and does) have multiple values for a particular attribute. So it seems very odd that they used file-trees to derive the tonality signifiers.

Firstly because this is why we, the users, were forced into issues with putting our content into specific folders in specific locations, named and nested specific ways. Because thats how we tell their "tagging" system what single category our content should be in. It's an accident that has already happened.

But If Ableton had carried the metakey system into the categorisation we would have been able to keep our files anywhere and merely assign (multiple) key/value pairs to the assets to have them show up in the L9 library/browser. They would have been search/sort/filter/groupable dynamically from day one. It would be flexible and expandable, non-destructive.

So that's my biggest worry. Because they didn't implement that we now have an asset location system based on os filetrees.

I'd suggest one way forward would be detaching the assets from reliance on location, use the folder only as a key hint for initial db inclusion - then allow further attributes to be assigned by clicking tags.

I tried suggesting various solutions to ableton. They did not like it.

I'm with Angstom on this...
Quote for him "So this is why we see the Pad : "All Alone Pad" exists only in Ambient and evolving, and does not appear at all in "pads". Ableton have a database system built on metatags, but their tags don't use it!"

I've abandoned the Live 9 browser 'search', and stick to my file-trees. At least those are consistent.

If Abes want to make a browser... just hire Ang FFS.
Ill stay in the my Live 8 library.. cause at least there I can delete the crud presents easily.

Funk N. Furter wrote: I'm probably not understanding this bit right...

"..but you can at least create an arbitrary folder structure such as Synths/MySynths/pads or MySounds/pads/Vintage with some hope you learn where you have hidden things. This is not a good system, but it's personal to each user, therefore memorable, and so can mitigate the awfulness with use."

Yes, I didn't want to make my post even longer - and this is another longish issue of blurred boundaries. but I'll address this.

As you say: you can still create an arbitrary file path in the lower section named "Places" . But my point is: Arbitrary file paths are not a brilliant way to categorise or locate stuff.
If you decide to fix this by creating a database system to index everything -then the main point of doing so is to address exactly that issue - to Avoid file tree digging.


file-tree browsing in L8 & L9

In Live 8, we have a basic file tree, it's a basic representation of the OS file tree you can browse and if you add something to your OS folder structure it is immediately reflected here. It's not well suited to managing a large library of varied content.

In Live 9, we have two sections.
A new upper section which is named "categories", this is intended to represent filters on the database (EG: "Show me only items of type X further filtered by text string Y"). It is rather confused though, with some categories representing 3rd party software, some categories representing all indexed content of a type, while some categories only represent Factory content of a type (Samples).
Additionally the Categories interface has a usability issue in that it deviates from the rest of Ableton Live (EG: try to drag and drop a clip onto "Clips") in its "Affordance"


In Live 9 we also have the lower section, "Places". This appeared to be designed initially as "Places which the database will index". But certain issues were pointed out and it appeared to be hurriedly ret-conned into something able to insert user-files in the Categories section.

In L9 betas there was not a way to import user content into the Browser, Categories, and user outcry was loud and we were very confused. Very late in the beta a system was devised where : if you carefully mirrored the factory file-tree (folder structure) you could manage to get your content to appear in the "Categories" view. This was refined further several times on both sides of the 9.0 release.

Creating arbitrary file and folder structures in Live 9
such as


This arbitrary structure is indexed by the system and placed into a taxonomic context in "Categories". Not in "Sounds", but it does appear in (Instruments / Instrument Rack/ Others)

You'll notice that this sound has no taxonomic data, and we can see here two further items named "Test" which are from different locations and have no real clue about what they might be.


So what were the Browser aims and did the new browser achieve them?

What was intended
Ableton decided to fix the issues related to a location based file-tree browser, where users could make long confusing paths and lose sounds. Assets and locations had became difficult to maintain for 3rd party supplies and users, because the assets were often lost in nested locations with unpredicatable names. It was not easy to browse or discover content in this system.
So Ableton created a database system to classify the content taxonomically, to make it all findable, discoverable through elegant simple classification and flitering.

what happened
they delivered a system where we can still create arbitrary file trees, and put our files pretty much anywhere, but those files will ... uh, end up pretty much in a big pile of "Others". We can't categorise them fluidly, we can't simply say "This is Ambient so please put it in Ambient and Evolving" . We must place the item in the "Folder" named appropriately "Presets/Ambient and Evolving". Otherwise it will go into the unclassified bin of "Racks/others".

So, If you want your files appear in the virtual file tree of "Categories" you will need to follow a set of precise rules of which folder to place the asset into, the rules are not stated and may be subject to change.

Outcome of the work carried out
Ableton went to great efforts to make a system to help categorise content, but neglected to provide a robust intuitive system for users to categorise content. This led to a proliferation of uncategorised user content, which is still as hard to find, hard to browse and confusing to use as ever.

The stated work around for this uncategorised content problem is for the user to create arbitrary file-tree folders in "Places", very similar to the old file-tree system of Live 8, but this one is less well featured (single column, does not respect aliases, does not like removables drives, etc), is less responsive (slowly indexes), and does not show up in the "main" section of the browser unless certain strategies are followed.

So...
The solution to categorising your content is to make folders like in Live 8, but not quite as good. If I was bankrolling that browser project I would not be happy with my ROI

Yes, you "tag" sounds for inclusion in Categories by putting them in precise folders.
OR you can put them in arbitrary folders and they will show up in "others". This is not how relational databases should work! They should not be linear and based on file-trees to work!

It's insane and undermines the whole point of building a database of a large and disparate content library.

Metaphor time.

Lets say, an internet USER wants to find a black and white line drawing of a chicken, it needs to be over 1meg, and it needs to be recent .

Lets say that GOOGLE tells the users to "simply look in our categories - Google/images/monochrome/animals/chicken and sort by date"

USER says, "uh, OK, I guess that works, but that doesn't seem very intuitive somehow"

---

Also, a few weeks earlier an ARTIST has drawn a picture of a chicken, and wants it to be visible on Google.

GOOGLE says "simply save your art it in User library/presets/images/monochrome/animals/chicken to have it show in the google results for monochrome chickens. Or you can save it in /anything/blackandwhitechickens. And we will show it in the folder called /random/other"

ARTIST says- "really? But I also want it to show in /farmillistrations. And /vintagestyle/farms"

GOOGLE just ignores them

Now, lets say some magic happens. Google fixes their shit, realises they have been very stupid

GOOGLE SAYS "hey artist, just put your content anywhere, we have all the metadata for it anyway. No need to stress about specific folder names, or remembering to do it our specific way. No, just leave it to us. Don't worry - if anybody asks for a recent chicken, or a black and white farm, or a vintage farm illustration, or a recent vintage farm chicken illustration, they will discover your work"

ARTIST "awesome!"


---
And to the user

GOOGLE SAYS " hey User. You know how you were looking for a chicken? Well, simply look at google images and use the filters to hone in on the type of thing you want. You can discover both the type of illustration you need this time, and also you will be learning the system at the same time. This is called learnability and is a cornerstone of Usability"

Try it.

Go to google images, type "chicken" and use the search tools to select "black and white", size "large", Type "line drawing" , Time "past week"

Ask yourself how these images got here in this result set,

Do you think they are saved in library/presets/images/monochrome/animals/chicken. Or is there some other magic at work here?

I think what's happened is that Ableton designed Push, then made a database afterwards.

What they should've done is design a decent database that works well with or without Push, then design the Push to work with the database.

It seems Live is now geared around using a Push, to the detriment of everything/everyone else.

Me? I dunno, I haven't got a Push - too expensive.

I've got a Launchpad and that suits me well enough.