Tempo based key normalisation

[bvh]

Hello

I would like your feedback on this. I haven't found software that does this, but i think it can make a huge improvement to the array of available tracks and it may also help avoiding key-lock (sound detoriation).

I requested an article about this as well, but i can well imagine that would require a more elaborate explanation.

Quick introduction after the fact: I'm Bob, I've been djing for techno/electro/house on and off the last 15+ years, and lately I'm just mixing at home having fun with traktor's keymatching assistance.

The outlines are currently to be found here: https://bitbucket.org/hoovebobvan/next-track


N100_BPM - Tempo based key normalization

Assumed is familiarity with: djing, dj software, musical keys, the circle of fifths, some leftover high-school math

this is a first draft

The basic idea
Given 2 tracks that have compatible keys **after** you have pitched them to have to same tempo, you can change the common tempo and they will still sound key-wise compatible.

Based on that principle, it may be useful to calculate keys relative to a norm BPM rather than it's actual bpm. This will yield more results than searching the current tempo for compatible keys.

The name N100_BMP reflects that 100 bpm is chosen as norm tempo, and that the normalized keys are relative to that tempo.


How it works
The following example demonstrates how tempo change relates to note-distance.

Beatmatching: tempo change -> pitch change
When a dj transitions one of the common approaches is to do beatmatching. Most songs have different tempo's, in order to beatmatch dj / his software has to change tempo's for the beats to align.

Changing tempo of a song also changes it's pitch. That means that the root note of the song will change, and so will it's key. Here's s small example

Example: +3.00 pitch
What happens if you pitch a song +3.00 percent in order to get the beats aligned? How does that affect the pitch?

````{.console}
    >>> import os, math
    >>> delta_per_cent = 1.0 / 100
    >>> delta_pitch_factor = 1.0 + 3.0 * delta_per_cent
    >>> delta_pitch_factor
    1.03
````

Now we have a pitch factor. Factors are linear. Note distances, when expressed as frequencies, are not linear: the base frequency of the next octave is always a doubling of it's predecessor.

Assuming [equal temperament](http://en.wikipedia.org/wiki/Equal_temperament) we can use the semitone factor to calculate semitone change relative to the tempo factor

````{.console}
    >>> def get_semitone_factor():
    ...     # in equal temperament, the semitone steps all have the same
    ...     # factor to the next semitone
    ...     return 2.0**(1.0 / 12.0)
    ...
    >>> semitone_factor = get_semitone_factor()
    >>> semitone_factor
    1.0594630943592953
    >>>
    >>> delta_semitone = math.log(delta_pitch_factor, semitone_factor)
    >>> delta_semitone
    0.5117320489019243
    >>>
````

Normalizing to 100_BPM
The same maths apply. So given a tracks tempo factor to 100 BPM, you can also calculate it's root note at that tempo. This root note will be on a continuum, they don't adhere to A4 = 440hz. Hence the term float_note

````{.py}    
    def normalize(self):
        factor = 100.0 / self.bpm
        normalized = PitchedKey(self.common_key, tempo_factor=factor)
        return normalized
````

````{.py}
        offset_in_semitones = (
            math.log(tempo_factor, semitone_factor))

        origin_root_note_as_float = float(key12.root_note.number)
        float_note = (
            (origin_root_note_as_float + offset_in_semitones) 
            % DODECA
        )
````

## How to use it
After normalizing you use the same principle from the circle of fifths to find matching keys. Note distances to check out are plus or minus 7 semitones, in some cases plus or minus 2 semitones. In order to find these notes quickly, some indexing may be necessary. As simple range 120 based index may suffice to find tracks that are on the same semitone-offset band at a favorable distance. The semitone offset band could simply be defined as the the range 120 based index % 10.

*this is a work in progress, more to follow*

[bascurtiz]

I'm not sure if this will help ya, but I've made this Traktor/VDJ chart to see which (other) Keys u can get your track in, by altering the Key-knob accordingly:
UPDATED LINK 18-8-2017:
https://mega.nz/#!IEoATD5A!9PL1vbXeQ...KkpjO9Pc6clbjk
Camelot-Key-Chart-Traktor-VDJ-v2-preview.jpg

UPDATE 4-5-2014:
Since ppl like it, I've made a DJ-friendly version of the wheel, which u can print out on A4 (and plastify for +/- €1,50) and place under your DJ-gear so u can see the chart in front of u while you're in da mix:
UPDATED LINK 18-8-2017:
https://mega.nz/#!FB41RCRL!26lczDMhp...bSinXX-sqD6jYs
Camelot-Key-Chart-Converter-preview.jpg

[Patch]

Nice, bascurtiz!

[bvh]

I should draw up a mockup of the gui. As an end user, you need not be aware of the normalized key, you'll just get some suggestions, some of which indicication that they're from 'a distant tempo'

I'm currently working on the query / index. So given a track, you will get harmonic matches. You might want to set a limit to how many semitones pitch diference is sensible to you (unless you like happy hardcore).

I'll keep you updated.

[Daniboy]

I'm not sure if this will help ya, but I've made this Traktor/VDJ chart to see which (other) Keys u can get your track in, by altering the Key-knob accordingly: https://dl.dropboxusercontent.com/u/...raktor-VDJ.pdf

Cool, works great!

[bvh]

Ok so the wheel by Bacurtiz is a helpful tool. But I'm gonna try and drag it back on topic

Are the outlines of the N100_BPM concept clear?

Do you realize that I'm trying to avoid key-lock alltogether?

Is avoiding key-lock an issue to you guys?

[bvh]

I've made an excel sheet just to show what the data looks like. On a range of 0,0 - 11,99 you'll see songs of varying bpm together. The same overview could be used by people playing from vanilla Sl1200's.


http://4grabz.courier10pt.com/willyw...ollection.xlsx

[bvh]

Also here's is my second attempt at explaining what I'm working on:

How did I get here?
After playing with the key matching features of my dj-software i realized I was hard to find the 'would match' tracks that are a semitone apart tempo wise. Eg. it's quite common for djs to pitch a track by plus or minus 6%. That happens to be rougly a semitone. So I set out to find a way to make them available.

Tempo normalisation
The technique that is used is recalculating all detected keys pretending the record would be played at 100 bpm. If they are a match at 100 bpm, they wil be a match at other (common) bpm.

Avoiding keylock / master tempo
Most music is tuned to a4 = 440 Hz. When you calcute meeting a norm, the result key will have an offset. This is simply a decimal fraction for the note number.

The decimal fraction is useful if you like to avoid using keylock or master tempo. As long as you make only little deviations you will need no timestretching techniques like key-lock or master tempo

Current state
I just started. There is classes to read your traktor nml, to enrich the data with normalized keys and there is a script that will output this data. My implementation is not yet ready to use, but having outlined the idea i'd say anyone is welcome to use it for their purposes.

[Sambo]

I like your traktor key knob wheel, it's a nice way of displaying the outcomes, but doesn't mention the simple formula that it works on.

Every semitone equals a shift of +/- 7 in the number on the key. So if your track is in 1, and you put they key knob up +1 semitone, then the track is now 8, put it up by two and it is now 3 (since it maxes out at 12 and starts again).

I use this frequently when messing with samples for the remix decks. The problem is that although Traktor's keylock is decent enough at keeping quality when you alter the pitch slightly, when you actively change it with the knob it absolutely destroys the track.

[031999]

this makes sense, because i have alot of songs that are at like 120 but i play them at 125, and the keys dont work anymore unless i have keylock on. But i'd rather not use the keylock, due to the unneded stress on my CPU.

I know everyone says "just use your ears" but when your playing brand new tracks sometimes its hard to do that on the fly.