[proposal#2] Track Similarity Column #5
Conversation
|
|
||
| We also get a delta/detune value to find out how off tune the tracks will be in cents. | ||
|
|
||
| TODO: The algorithm needs to be able to take in tuning information, for non 440Hz tuning standards. |
There was a problem hiding this comment.
I think this is something we can consider out of scope for the first version. As always, we can take it into account so that a future version could possibly handle it, but I think trying to support this from the start will add a lot of unnecessary complexity.
There was a problem hiding this comment.
All the tracks are analyzed with 440 Hz. A 432 Hz Track is "just" a slightly pitched track compared to others. Since the algorithm needs to deal with pitched tracks anyway, this part comes for free. We just must not prevent it artificially.
The missing bit is to define the library storage format and add a GUI to enter the tuning info. This is out of scope of this project.
We can already read Tracks annotated with keys like "A#m +50" but we discard the tuning info currently. Once this is "fixed" we can support tuning: https://github.com/mixxxdj/mixxx/blob/3d8e7fec8ba03fac34769bb2de6e863fd67b3efa/src/track/keyutils.cpp#L329
| * **Other docs or links:** | ||
| * [GSoC Proposal](https://docs.google.com/document/d/1QAe8mvZFKkFnG--02kuzSagzea6_ed5g3VfjuSyAY7w/edit?usp=sharing) | ||
|
|
||
| > Proposal to add a column in the Track Library that shows how harmonically close each track is with a Target |
There was a problem hiding this comment.
Based on the discussion and confusion about how to tell which track is being considered for similarity, I don't think it's enough to just have a new column. There needs to be a new UI element that clearly indicates what track is the reference point. The source for how that UI element is populated can be the Sync Leader, or an explicit selection, but we will need a way to communicate the reference track.
We could do something like: put the reference track at the top of the library, highlighted in a special way. Sort operations would not move this special track, it is always at the top.
There was a problem hiding this comment.
I am afraid this whole feature is a rats nest which need some experiments and POC. If we heading for a perfect solution, this 90 hour GSoC project will be over without and mergeable outcome.
So let's use only the Sync Leader for picking the current BPM and Key.
Once the have this Proposed Track Similarity Column merged we can adjust the magic algorithm as we like.
| * **Other docs or links:** | ||
| * [GSoC Proposal](https://docs.google.com/document/d/1QAe8mvZFKkFnG--02kuzSagzea6_ed5g3VfjuSyAY7w/edit?usp=sharing) | ||
|
|
||
| > Proposal to add a column in the Track Library that shows how harmonically close each track is with a Target |
There was a problem hiding this comment.
I am afraid this whole feature is a rats nest which need some experiments and POC. If we heading for a perfect solution, this 90 hour GSoC project will be over without and mergeable outcome.
So let's use only the Sync Leader for picking the current BPM and Key.
Once the have this Proposed Track Similarity Column merged we can adjust the magic algorithm as we like.
|
|
||
| ### Finding the target track | ||
|
|
||
| This is still an **Open Question**. Here's where we are at right now: |
There was a problem hiding this comment.
Let's postpone the Question and use only the Sync Leader for reference for the first version. That works already perfectly when "testing" transitions at home.
| If the user does not explicitly select a target track, Mixxx may automatically select a deck, based on the | ||
| algorithm for choosing the Sync Leader. | ||
|
|
||
| We can provide context menu options to target other decks, or tracks from the library. |
There was a problem hiding this comment.
I wonder how this will interact with the "find similar feature". I think both target the same use case, one will filter, and the other will populate the new Track Similarity Column. If we sort by it, the "filter" nature becomes probably obsolete, because with the similarity, we also see close matches that would be normally hidden.
There was a problem hiding this comment.
I use the Preview deck to listen to candidates. We can also use this for a "revese" lookup, how does the candidate Track match to the cued tracks in AutoDJ. At which position should I place it.
There was a problem hiding this comment.
I think the Preview deck would actually be an elegant solution to this. Maybe something like this:
if track in preview deck:
target = track in preview deck
else if sync leader present:
target = sync leader
else:
no target, leave similarity blank
I don't listen to the Preview deck, but I am cool with putting tracks in it. It will also let us easily see which track is being used as the target.
There was a problem hiding this comment.
Ok, nice. We can change it at any time later.
|
|
||
| def compatibility(pitch_difference): | ||
| rounded_pitch_diff = round(pitch_difference) | ||
| delta = abs(rounded_pitch_diff - pitch_difference) |
There was a problem hiding this comment.
Is this the cents value of difference? Maybe we should format it actually as cents.
The compatibility is than a kind of sinus curve with a tip at a full match and at compatible keys and dips where the key is out of tunes at the 50 cents region at least.
There was a problem hiding this comment.
I think most of the math is already there:
https://github.com/mixxxdj/mixxx/blob/1f85c9c4502e42e744a1797c85c2b1343f5d3609/src/track/keyutils.h
|
|
||
| We also get a delta/detune value to find out how off tune the tracks will be in cents. | ||
|
|
||
| TODO: The algorithm needs to be able to take in tuning information, for non 440Hz tuning standards. |
There was a problem hiding this comment.
All the tracks are analyzed with 440 Hz. A 432 Hz Track is "just" a slightly pitched track compared to others. Since the algorithm needs to deal with pitched tracks anyway, this part comes for free. We just must not prevent it artificially.
The missing bit is to define the library storage format and add a GUI to enter the tuning info. This is out of scope of this project.
We can already read Tracks annotated with keys like "A#m +50" but we discard the tuning info currently. Once this is "fixed" we can support tuning: https://github.com/mixxxdj/mixxx/blob/3d8e7fec8ba03fac34769bb2de6e863fd67b3efa/src/track/keyutils.cpp#L329
|
|
||
| **Open Question**: It may be possible to combine the information of the detune column into the similarity column. | ||
| Either by creating a formula that combines the two values, | ||
| or by encoding it in some other way (like opacity, or another icon). |
There was a problem hiding this comment.
Since the Detune value destroys the assumptions in the similarity column, it should be directly considered in the value of the similarity column. We may consider to add controls to see the detune in the decks to all skins not have a Shade Skin only feature. Putting this into the similarity column as an extra value is probably confusing.
Discussion on Zulip