Custom fields to mixxx sqlite dbase and library view

[mixxxbot]

Reported by: kek001
Date: 2019-05-31T10:47:05Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1831227

---

WISH

Is it possible add Custom1,Custom2,Custom3 fields to mixxx sqliteand library view ?

Like to save more information about tracks to mixxx.

Thanks.

[mixxxbot]

Commented by: daschuer
Date: 2019-05-31T15:12:10Z

---

No ;-) 

Mixxx should give some hints how they are used.

What do you need, exactly.

[mixxxbot]

Commented by: kek001
Date: 2019-06-01T14:10:54Z

---

I would save info about timbre,color,energy,style,mood
i put lot of info to comment file, and its coming pretty full.
I also put some remarks about how to mix songs or remix them.
I have past my own brain memory capacity, cant remember how to do some complex remixes about several songs, and need to put some reminders.

[mixxxbot]

Commented by: daschuer
Date: 2019-06-01T20:44:37Z

---

OK, so we should add these columns:

timbre,color,energy,style,mood

What is the difference between timbre and color?
Is style a tag like field? Can we implement that as crate?

Spotify has:
https://developer.spotify.com/documentation/web-api/reference/tracks/get-audio-features/
Energy, Danceability, Valence, Acousticness, Instrumentalness, Liveness, Speechiness
Is that also useful?

[mixxxbot]

Commented by: uklotzde
Date: 2019-06-02T11:50:41Z

---

I would not recommend to add predefined fields for each possible property. Some of those properties might have common usage while others depend on personal habits and preferences. Such an approach is always a compromise and users will tend do re-use those fields for whatever purpose they need.

Instead of introducing a non-extensible, hard-coded, and half-baked solution I suggest to switch to a customizable tagging scheme like I demonstrated with aoide. Only some fields like artists and titles are predefined while comment, genre, grouping, all the Spotify/Echonest audio features, mood, style, etc. can be encoded by configurable "faceted tags". Some of those so called "facets" might be predefined, e.g. "genre" and "comment" with a fixed mapping to file tags.

[mixxxbot]

Commented by: daschuer
Date: 2019-06-02T15:11:05Z

---

I can't imagine how this can work.
Can we discuss this along one if these properties? For example energy. How will this work?

Here is a nice article how to use the energy:
https://mixedinkey.com/harmonic-mixing-guide/sorting-playlists-by-energy-level/

And here is an article from the producer's view:
https://resoundsound.com/increase-decrease-energy-tracks/

[mixxxbot]

Commented by: kek001
Date: 2019-06-02T20:54:51Z

---

Some of MixinKey web pages are down now.

If remember they were calculating energy as how well it suite for dance, maybe i am wrong.

What i have seen in acoustic brain and other applications which are calculating dancebility, they often produce garbage.

About timbre and color, sometimes i search similar sound songs, and sometimes the rhythm has not been similar.

I mostly play psychill,psybient,chillregressive,psydub styles, and sometimes those genres and tunes overlapping each other, and wide variety inside genre slow,ethnic instruments,and rhytmic, pscyhdelic to out of space. Comments about songs which helps me separate some of them are mostly about ethnics instrumenation or is it melodic, sad/dark or goodmood or how rhytmic they are.
When i pick songs color or timbre(similarity) helps me most along bpm and key and my comments.

No idea how many different variables or parameters other people are using. i mean example these what Daniel wrote "Energy, Danceability, Valence, Acousticness, Instrumentalness, Liveness, Speechiness" etc...

[mixxxbot]

Commented by: andrej-falout
Date: 2020-08-14T06:33:22Z

---

May I please revive this discussion - custom tags/fields are quite important for serious mixing.

I agree that predefined fields are not the best solution, however, they might be a tactical one - eg. better then none.

This feature would also enable more complete sync between Mixxx and various other apps that have fields that are missing in Mixxx

Would any of the devs please consider this feature?

Thanks,
Andrej

[mixxxbot]

Commented by: uklotzde
Date: 2020-08-14T16:10:10Z

---

See also: #2656

[mixxxbot]

Commented by: daschuer
Date: 2020-08-14T16:10:41Z

---

What is your use case? Maybe it is already covered with aoide, the future library Backend for Mixxx

[mixxxbot]

Commented by: uklotzde
Date: 2020-08-14T16:35:31Z

---

The custom tags could be made available directly in Mixxx.

But unfortunately, the legacy, database-centric table views in Mixxx are difficult to extend without major performance impacts. Performance is already an issue with large libraries. Displaying selected tags as separate columns might not be feasible with the current UI.

[mixxxbot]

Commented by: andrej-falout
Date: 2020-08-15T06:44:05Z

---

@uwe - I noticed your work on aoide (https://gitlab.com/uklotzde/aoide-rs and #2282) - thank you for your efforts on this.

Screenshot looks like what I'm hoping for, but I am not sure how it works, as I dont know how to try/enable it - is this included in current 2.4 alpha builds from http://downloads.mixxx.org/builds/master/release/ ?

My use case is similar to what OP described - managing timbre,color,energy,style,mood and similar attributes, for example, as defined here: https://developer.spotify.com/documentation/web-api/reference/tracks/get-audio-features/

Extending existing SQLite schema without impacting performance would also be relatively easy to do, by adding an additional table with a PK/FK relationship using "id" - that would be created only if user enabled a feature "Custom tags" in settings. Users that do not explicitly enable this, would not even know it's there. Performance can be further protected by adding a flag field to the "library" table, that would indicate if the track has any custom tags set. If it does, a single SQL query would be executed on the indexed "id" field when reading data for the track - with minimal performance impact. If the flag is not set (eg. the user did not enter any custom tags for particular track), no query is executed, and there is absolutely no impact on performance. It is also reasonable to expect that minority of the tracks in most users collections would have any custom attributes set, even when the feature is enabled.

I design databases for living, please let me know if I can be of assistance.

But if I understand correctly, your aoide work is intended to (one day) replace current SQLite database completely?

I agree that displaying additional/custom tags/fields as separate columns is not feasible for several reasons. Possibly showing them on mouse-over would be an option? In a window, or as an overlay over the next track in the list...?

Releted to the library work, and also custom tags, is another use-case I have as a both digital and a vinyl DJ. I have over 5000 records, that obviously don't have a audio file to be scanned. But I have almost exactly the same need to manage my collection of records. Do you see a possibility in the future to be able to add a physical media to the Mixxx library? If the custom tags are implemented, I could then manage attributes such as location, format, etc.

Thank you,
Andrej

[mixxxbot]

Commented by: uklotzde
Date: 2020-08-15T08:41:44Z

---

The custom tags PR has not yet been merged, see the open TODOs.

Internally each custom tag already a normalized "score" between 0.0 and 1.0. Currently, in Mixxx this defaults to 1.0 and is not exposed in the UI. As already outlined one could define a common "facet" named "timbre" and assign normalized scores to that. For this use case, the "label" of the tag is supposed to be empty.

I disagree with your assumption that only a few tracks have custom tags. Maybe for you, but not for others.

Custom tags are stored in a separate table, please refer to the database schema. Joining the score from selected facets into the track query might work, but I don't plan to extend the current, legacy database queries and views. Lack of time and motivation.

Managing physical tracks: aoide uses URIs to locate the actual track resource. For local files, the scheme is just "file://". It is only a database service and does not access those resources, which could also be physical records.

Any help to complete and finish this feature is appreciated.

[mixxxbot]

Commented by: andrej-falout
Date: 2020-08-16T06:26:30Z

---

Thanks for your reply, Uwe.

I'll provide feedback as soon as it has been merged & compiled for Alpha build.

'each custom tag already a normalized "score"'
Is this to say that your implementation of custom tags does not allow any values not between 0 and 1 - including alpha characters?

Regarding number of track expected to get a custom tag - I did say "minority of the tracks", not "only a few". 
In my collection is about 10000 digital media tracks; for my mixes and gigs, I plaid over the years (more then once or twice) perhaps a 1000. That is in most likelihood a maximum number of track I would ever want to custom tag. I started DJ-ing professionally somewhere around 1985 and got to know at last few hundred other professional DJ over that time. Unless there is some automated system involved in populating custom tags, I will eat my SL-1200 if more then 10 DJs I know would custom tag more then few hundred of there tracks... :) Of course, I could be wrong, but I don't think I am far off.

Looking at Mixxx 2.4 beta SQLlite db schema, I do not see any table that would hold custom tags? If you are referring to Aoide schema, keep in mind that my comments where in response to your statement that "...unfortunately, the legacy, database-centric table views in Mixxx are difficult to extend without major performance impacts". (NB - SQLite database distributed with 2.4 has no views defined).

While I do understand your motivation to create a standalone, shared and reusable repository with Aoide (that even the Traktor Product Management seems to have an interest in, see https://www.native-instruments.com/forum/threads/metadata-handling-multi-value-tags-i-e-more-than-1-genre.327465/), an API front-end on top of a RDBMS will never have performance advantage over what you call "legacy database queries" - just the opposite.

RE Managing physical tracks: you described is as I would expect it to be, and in essence similar to way Mixxx does (except that it moves all tracks it cannot find in "missing" folder, making them unusable for searching)- but how does one enter them in the db in the first place? No file, no scanning, no database entry. I currently use Bash scripts to load my Discogs tracks data directly in the SQLlite db, but they end up in "missing", and also without the custom tags they are of very limited use...

Please let me know how I can help - I'm not a programmer but have extensive experience with database design, and I'm reasonably good at scripting and testing. And I'm very keen to see custom tags implemented.

Thanks,
Andrej

[mixxxbot]

Commented by: uklotzde
Date: 2020-08-16T07:13:14Z

---

An additional network layer between the client and the server will be slower by introducing network latencies and requiring serialization, sure. That's the cost of decoupling.

The views in Mixxx I was referring to are in the UI, not the database. The main track table view always loads and displays the WHOLE database! It will no longer be possible to fetch the whole database at once, which is ridiculous. Instead, pagination and asynchronous network requests in the background become mandatory. Ever tried to fetch the whole Spotify back catalog at once? They won't let you. Is Spotify's search on millions of tracks over the network fast? I guess so.

The new database provides more appropriate materialized views (as plain tables) on the data that allow much more advanced queries instead of a single, plain table of track records.

[mixxxbot]

Commented by: uklotzde
Date: 2020-08-16T07:14:42Z

---

"Responsiveness" is the keyword. Mixxx is not responsive as it freezes the UI on every database activity.

[mixxxbot]

Commented by: andrej-falout
Date: 2021-03-05T06:26:39Z

---

Hello again - I wonder if there was any progress in enabling custom tags to Mixxx?
Thanks!

[mixxxbot]

Commented by: kek001
Date: 2021-03-19T12:01:25Z

---

I would like to know also.

for me a just simple Custom1 column or field is enough, not have to save to tags.
Adding custom1(string) field to sqlite is enough..

[mixxxbot]

Commented by: uklotzde
Date: 2021-03-19T12:25:27Z

---

I don't recommend to add any arbitrary custom fields that are not synchronized with file tags. This would be a dead end for interoperability.

[mixxxbot]

Commented by: Holzhaus
Date: 2021-03-19T12:28:42Z

---

@kek001 You can add the field using SQLite Browser. But that won't help you because it needs to be exposed by the Mixxx User Interface, and I don't think we are going to implement that because Uwe Klotz is currently working on a better and much more versatile implementation here: #2656

[mixxxbot]

Commented by: andrej-falout
Date: 2021-03-20T05:48:16Z

---

@uklotzde :

Are you working on Custom FIELDS or just Custom TAGS?

Eg. you can define a tag (say, ILikeThisTrackVeryMuch) and then tag the tracks with it.

As opposed to a FIELD, that you could add some data/text into. Such as creating a field named "DiscogsReleaseID" and enter Discogs release ID ("1234567") in it. For example.

Thanks,
Andrej

[mixxxbot]

Commented by: uklotzde
Date: 2021-03-20T08:02:33Z

---

facet = "discogs_release_id" (lower-case, ASCII)
label = "1234567"

[daryltucker]

Hey, I noticed that #2656 got closed without a merge (and the branch was deleted).

Does anybody know of any similar efforts?

[Swiftb0y]

Nothing similar as far as I can imagine, but we'd welcome a revival of the branch by someone else. Ideally in smaller steps to get it merged more easily.