Skip to content

smart: match key rules across key notations - #98

Merged
vynulldev merged 4 commits into
mainfrom
smart-key-notation
Oct 18, 2026
Merged

vynulldev merged 4 commits into
mainfrom
smart-key-notation

Conversation

@vynulldev

Copy link
Copy Markdown
Owner

What & why

An import converts every track's key to Camelot ("8A") so the deck's KEY column shows one notation. A rekordbox smart rule on the key, though, carries the key name rekordbox showed, which in classic notation is "Am". After an import, "key is Am" therefore matched no track at all, and "key is not Am" matched every track.

The link-spec conformance suites didn't catch it, because the conformance server serves rekordbox's key names unconverted. It showed up on a CDJ-2000NXS2 with the synthetic test library, whose "Text: key is Am" playlist came up empty.

Server

  • Equality (is, is not) compares keys: a recognised key name in either notation, including rekordbox's enharmonic spellings such as Abm, is the same key as its Camelot or classic counterpart.
  • Contains, starts with and ends with test the track key's name in each notation, so "contains m" still finds minor keys stored as Camelot.
  • Text that isn't a key name (or has surrounding spaces) still compares as text, as rekordbox does, so the conformance results are unchanged.

Web editor

  • The key picker lists Camelot keys only. For an imported rule with a classic name, the browser selected the first key and the editor's sync wrote it into the rule, so just opening the playlist changed "Am" to "1A".
  • The rule's own value is now kept as a selected option (shown with its Camelot name).
  • The rule preview compares keys in either notation.
  • The key field offers rekordbox's operators (equals, not equals, contains, does not contain, starts with, ends with), with Vynull's "is compatible with" kept last. Before, it offered only equals, is not, and is compatible with, so an imported contains or starts-with key rule showed the wrong operator.
  • Equals, not equals and is compatible with keep a key dropdown, now labelled in both notations ("8A · Am", led by the key display setting). The text operators take a typed value instead, so "contains C" can find C, C# and Cb. rekordbox itself uses a text box for every key operator.
  • "Is compatible with" now reads either notation on both sides.

rekordbox compares key text against the key names it stores, which follow its Key Display Format: a classic-notation rule such as "Ab" only matched with the format set to Classic or "Display key information on the database" ticked (checked by hand in rekordbox's Preferences, View panel). Vynull stores Camelot after an import, so it deliberately accepts a key named in either notation rather than depending on a display setting.

Tests cover equality, inequality, enharmonics, contains and does-not-contain, starts with, spacing, and non-key text. Conformance against rekordbox 7.2.19 is unchanged (the smart suites stay at 743 exact).

Hardware testing

  • Tested on: CDJ-2000NXS2

Checklist

  • go build ./..., go vet ./..., and go test ./... pass
  • gofmt -l . is clean
  • New source files carry an SPDX header (GPL-3.0-or-later)
  • Tested on real hardware (deck + firmware noted above), or this change doesn't affect deck behaviour
  • I agree my contribution is licensed under the project's GPLv3

An import stores every track's key as Camelot ("8A"), but a rekordbox
smart rule carries the key name rekordbox showed ("Am"), so "key is Am"
matched nothing after an import. Key rules now treat a recognised key name
in either notation as that key: equality compares the keys, and contains,
starts with, and ends with test the track key's name in each notation.
Other text still compares as text, as rekordbox does.
The smart editor's key picker lists Camelot keys only, so a rule imported
with a classic name ("Am") had no matching option: the browser selected
the first key, and the editor's sync wrote it into the rule, so opening the
playlist changed it to 1A. The rule's own value is now kept as a selected
option (with its Camelot name), and the preview compares keys in either
notation, as the server does.
rekordbox's key conditions offer equals, not equals, contains, does not
contain, starts with and ends with; the editor offered only equals, is
not, and Vynull's own is compatible with. It now lists rekordbox's six
(keeping is compatible with last), takes a typed value for the text
operators, and previews them against the key's name in either notation,
as the server matches them.
"Is compatible with" parsed only Camelot, so a key named in classic
notation fell back to comparing text. Both sides now read as keys in
either notation. The editor's key dropdown labels each key in both
notations, led by the key display setting.
@vynulldev vynulldev added the bug Something isn't working label Oct 17, 2026
@vynulldev
vynulldev marked this pull request as ready for review October 18, 2026 00:38
@vynulldev
vynulldev merged commit 522ca8d into main Oct 18, 2026
1 check passed
@vynulldev
vynulldev deleted the smart-key-notation branch October 18, 2026 00:39
vynulldev added a commit that referenced this pull request Oct 18, 2026
An import stores keys as Camelot, but rekordbox key rules carry the
names rekordbox showed ("Am"), so imported key rules matched nothing.
Key equality now compares keys in either notation (enharmonics too),
and text operators test the key's name in each notation; other text
still compares as text. The web editor keeps an imported rule's key
instead of silently replacing it with the first listed key, and offers
rekordbox's key operators (equals, not equals, contains, does not
contain, starts with, ends with).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant