Skip to main content


Please be aware that much of the software linked to or mentioned on this forum is niche and therefore infrequently downloaded. Lots of anti-virus scanners and so-called malware detectors like to flag infrequently downloaded software as bad until it is either downloaded enough times, or its developer actually bothers with getting each individual release allow listed by every single AV vendor. You can do many people a great favor when encountering such a "problem" example by submitting them to your AV vendor for examination. For almost everything on this forum, it is a false positive.
Topic: [SMP] Music Graph development (Read 3995 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: [SMP] Music Graph development

Reply #25
Continuing with the Graph Scripts, I'm now working on MusicIP functionalities:
-Recipes should be fully covered with current weigh/tag/queries options, since you can check any tag, set of tags, TF expressions, etc. And also pre/post filter the pool. (I would say the script gives even more possibilities)

-Moods are trivial to replicate using a set of songs as reference. The missing 'part' would be storing those reference internally (json) instead of having the tracks on a playlist. Also I'm using only 1 track as reference, but it should be easy to 'merge' the output from a set of tracks, and only send to final playlist those which are more similar to all selected references.

-Right now I want to integrate some of the advanced playlist creation features. The current graph scoring method is more advanced than MusicIp similarity method, but it could improve on other aspects (UI, pre-defined options, etc.).
  • Scattering vocal & instrumental tracks, breaking clusters of instrumental tracks.
  • Progressive lists and intelligent list ordering, saving moods and genre/styles not in common. Can be replicated with probability of picking, since pool is ordered by scoring... so every time a track is skip , the next one has more differences compared to the reference.
  • Progressive playlist creation feature which used one track as reference, and then used the output tracks as new references, and so on.

I would appreciate some ideas or comments on the last points, now that I consider adding them.

Re: [SMP] Music Graph development

Reply #26
Last changes implemented: added the 3 features I mentioned about MusicIp.

   - Scattering vocal & instrumental tracks, breaking clusters of instrumental tracks.
   - Progressive list ordering, having more different tracks the more you advance within a playlist (using probPick < 100 && bProgressiveListOrder). Can be combined with any weight/filter preference, to suit anyone's need.
   - Progressive playlist creation, uses one track as reference, and then uses the output tracks as new references, and so on... takes more time than standard search, since it performs recursive calls...

The last feature is working pretty great, using an acoustic stoner rock song, creates a playlist which starts with stoner/hard rock tracks and then progressively changes to folk-rock tracks and psychedelic. And since it can be merged with any of the other options, you can pretty much create smart playlists in any imaginable way. With blues, it goes from blues to jazz, jazz vocal, blues, etc. Only downside is calc time, but it can be made shorter using WEIGHT method instead of GRAPH, which takes less time. Also using queries to prefilter library.

Re: [SMP] Music Graph development

Reply #27
Pardon me for asking but do you have plans for a public beta?
Quis custodiet ipsos custodes?  ;~)

Re: [SMP] Music Graph development

Reply #28
Of course, as as soon as I see it's stable enough :) (which means, not susceptible to fundamental changes) I'm changing files every day, so it makes no sense to me publishing them right now publicly... that's all (since I may break how things worked 3 days ago.) I have time to code, but not for support and/or explaining every change right now. It's not like I can upload them to github and done, since I would have to change the documentation every week.

But drop me a line and I will give you (or anyone) the current version.

Re: [SMP] Music Graph development

Reply #29
Someone asked me about the key notation I used for similarity matching and at some point Camelot Wheel was mentioned, I have been working on it and have translated that logic (the rule of fifths) into scripts.

DJs use it to create mixes/playlists with tracks which are considered 'harmonically compatible'. Usually traveling the wheel following horizontal or vertical lines in +1 steps. (there are other complex movements too). Have added that to the GRAPH script, now when using a track as reference, the key is converted to camelot system notation and it checks for all tracks with keys within that cross in a range (set at properties). Therefore creating playlists the same a DJ would do.
Obviously, that is just the key weighting... so it can be used standalone or along genre, style, dyngenre weightings,  graph method, etc.

      - Keys are supported using standard notation (Ab, Am, A#, etc.) and flat or sharp equivalences (both are translated to the same values). This standard is according to the tags acousticBrainz, piccard gives you... and the one used universally  inmusic.
      - Key matching is done using camelot wheel logic, allowing similar keys by a range using a 'cross' (changing hour or letter, but both is penalized).
      - For other key notations simple string matching will be used. That means I don't support abstract notations, like Camelot or open keys for the 'wheel logic'.(*)

(*) The reason is simple, I have no way to know if 1A, 3B, etc. is following Camelot or Open Keys notation, and since there are already scripts to convert tags to one or other system... that's user responsibility and I just use universal notation. Anyway dynamic tags can be used to create a converted key tag and I may remap the tag to add TF support too.

      - Add key logic to 'search_similar_by', to create compatible queries instead of similarity checks. (a simplified version of the graph scripts with just queries)
      - Use current progressive list logics to create intelligent playlists with incremental keys, complex movements, etc.

Below is an example of how to set the properties to check for all tracks on library with similar genre/styles, using simple weight method and only allow those with similar Keys (on cross with 1-range).


As shown on the properties panel, the keys of the tracks in the output are: Am, C, Em. Right considering I used a track with C key as reference.

-Moods are trivial to replicate using a set of songs as reference. The missing 'part' would be storing those reference internally (json) instead of having the tracks on a playlist. Also I'm using only 1 track as reference, but it should be easy to 'merge' the output from a set of tracks, and only send to final playlist those which are more similar to all selected references.
And this is postponed until foobar native playlist format becomes public or SMP (@TheQwertiest ?) improves foobar playlist saving/loading via native methods... since I can not save a group of tracks as a mood and then load it without user intervention or loading the playlist on UI to get the handle. And it would finally make the playlist manager fully functional, supporting the native foobar playlist.

PD: I don't answer PMs here, I have given an email for a reason ;)


Re: [SMP] Music Graph development

Reply #30
New update:
-  New Option: DJ-like playlist creation with key changes following harmonic mixing rules. The entire pool (according to configurable weights, etc.) is considered, instead of using the standard playlist selection (randomly, by similarity score, etc.).

An explanation of how harmonic mixing works can be found here:

An example would be having a track with key 7B as reference then the next 5 tracks on the playlist would have keys:
8B, 8A, 9A, 9B, 8B
And that would continue until it reaches the desired playlist length.

Harmonic mixing is usually done following 9 possible 'key movements', so I have added methods to describe things like  'Energy Boost' which is equivalent to moving up 1 hour in the Camelot Wheel, etc. Everytime you want a new playlist, a new pattern is created. Instead of presetting a series of movements, they are chosen randomly according to a given proportion. The result is a new playlist not only with different tracks but with its own structure everytime (so you don't expect a mood change, or a boost always at X track).

For people who like electronic music, this could replace having someone choosing the next tracks, as long as you choose an electronic track as reference (or using 'forced query ' option to only consider that genre). Anyway,it works for any genre, creating natural progressions between tracks.

So let's resume the current implementation of the Weight/graph script:
- Creates a playlist with similar tracks to the currently selected one according to genre, style, key, etc or following special rules.
- The tags to check are associated to a weight, currently they are: genre,  style, dynGenre, mood,  key,  $year(%date%), bpm, composer, customStringTag, customNumTag
- Tags can be remapped: genre ->allmusic_genre, my_genre_tag
- There are 3 methods to calculate similarity: WEIGHT, GRAPH and DYNGENRE.
- WEIGHT and DYNGENRE assign scores based on tag comparison, checking numbers within a range or complex logic comparison (i.e. keys using camelot wheel).
- GRAPH assigns genres/styles a place in a graph based on their relations, and calculates similarity by the shortest path which links them. Classifying all known musical genres is required, pretty computational expensive and is an ongoing work. (there are multiple images on the thread)
- Tracks are added to a pool if they pass the score/distance check. (i.e. score >= 70%)
- There are complex settings to filter, force queries, remove duplicates or allowing only X tracks per tag on the pool.
- Finally, tracks are selected from the pool to create a playlist. This can be done randomly, following strict scoring order, or starting with highest scored tracks but with a probability of being chosen.
- Apart from that, there are 2 more special playlist creation rules: Harmonic Mixing (previous explanation) and Progressive List Creation (recursive calls to playlist creation using new similar tracks as references) .

SimplePortal 1.0.0 RC1 © 2008-2021