-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom fields to mixxx sqlite dbase and library view #9668
Comments
Commented by: daschuer
Mixxx should give some hints how they are used. What do you need, exactly. |
Commented by: kek001 I would save info about timbre,color,energy,style,mood |
Commented by: daschuer OK, so we should add these columns: timbre,color,energy,style,mood What is the difference between timbre and color? Spotify has: |
Commented by: uklotzde 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. |
Commented by: daschuer I can't imagine how this can work. Here is a nice article how to use the energy: And here is an article from the producer's view: |
Commented by: kek001 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. 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... |
Commented by: andrej-falout 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, |
Commented by: daschuer What is your use case? Maybe it is already covered with aoide, the future library Backend for Mixxx |
Commented by: uklotzde 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. |
Commented by: andrej-falout @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, |
Commented by: uklotzde 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. |
Commented by: andrej-falout Thanks for your reply, Uwe. I'll provide feedback as soon as it has been merged & compiled for Alpha build.
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, |
Commented by: uklotzde 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. |
Commented by: uklotzde "Responsiveness" is the keyword. Mixxx is not responsive as it freezes the UI on every database activity. |
Commented by: andrej-falout Hello again - I wonder if there was any progress in enabling custom tags to Mixxx? |
Commented by: kek001 I would like to know also. for me a just simple Custom1 column or field is enough, not have to save to tags. |
Commented by: uklotzde 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. |
Commented by: Holzhaus @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 |
Commented by: andrej-falout 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, |
Commented by: uklotzde facet = "discogs_release_id" (lower-case, ASCII) |
Hey, I noticed that #2656 got closed without a merge (and the branch was deleted). Does anybody know of any similar efforts? |
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. |
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.
The text was updated successfully, but these errors were encountered: