Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
  • This project
    • Loading...
  • Sign in / Register
T
Tidal
  • Overview
    • Overview
    • Details
    • Activity
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 0
    • Issues 0
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • PLN
  • Tidal
  • Repository

Switch branch/tag
  • Tidal
  • armada
  • tide-table
  • cosmicfest26_three_lens.json
Find file
BlameHistoryPermalink
  • PLN (Algolia)'s avatar
    feat(tide-table): three lenses, fused — and the system now finds the two tracks I got wrong · 4e9da249
    PLN corrected two rows: he played rose_rouge and livecode_parade, not blue_gold.
    The fusion now reaches both WITHOUT being told, which is the whole point.
    
    29:57 crossmatch said blue_gold at a weak 0.44 margin; tempo measured 118.1
    against blue_gold's declared 124 — a clash — and rose_rouge is declared 118,
    with locate holding `rose` at 0.602 offset consistency. Two lenses override one.
    54:59 the same shape: measured 130.0, gimme_acid declares 80, livecode_parade
    declares 130, locate had `love_parade` at 0.399.
    
    Both were only reachable because crossmatch STRUCTURALLY cannot name them.
    rose_rouge played neither reference gig, and livecode_parade's .tidal was created
    in the CosmicFest prep commit itself, so no prior render of it can exist anywhere.
    A blind spot, not a tuning failure — and the fix is one render per new track.
    
    The tempo lens took three attempts, and the first two measured nothing.
    librosa.feature.tempo returned 107-130 for every segment of an 80-170 BPM set:
    that is its log-normal prior centred on 120, not the music. Mode of inter-onset
    intervals on the full mix returned 233-648 BPM, locking onto the hats rather than
    the beat — and its apparent matches were hollow, because five octave multiples at
    5% tolerance passes roughly a quarter of random values. Autocorrelation of the
    40-120 Hz kick band works: bombe 123.9/124, punkachien 170.1/170, vague_de_crime
    120.1/120, do_it_right 178.3/2 = 89.15/89. Four exact to 0.1%.
    
    That validation is what licenses the overrides. An instrument which agrees where
    it should is one whose disagreements carry information; without those four hits I
    would be overriding a strong embedding on the word of an estimator I had not
    checked (feedback_check_the_instrument_first).
    
    I also had to fix my own fusion: counting each top-3 tempo candidate as a vote let
    cafe_bouillant beat ouais_je_funk, which measured 120.1 against a declared 120 —
    a perfect match demoted by an alphabetical tie. Tempo compatibility CONFIRMS the
    embedding's proposal; it only overrides when it clashes AND a second lens agrees
    on a specific alternative.
    
    Four rows are now marked unresolved rather than confidently labelled. That is a
    real answer: a confident wrong row costs more than a blank one.
    PLN (Algolia) authored Aug 29, 2026
    4e9da249
cosmicfest26_three_lens.json 4.29 KB
EditWeb IDE
×

Replace cosmicfest26_three_lens.json

Attach a file by drag & drop or click to upload


Cancel
A new branch will be created in your fork and a new merge request will be started.