| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| engine | ||
| packs | ||
| research | ||
| tests | ||
| ui | ||
| .gitignore | ||
| PHASE2_LOOPFINDER.md | ||
| README.md | ||
| TODO.md | ||
| autotune.py | ||
| demos.json | ||
| foundry.py | ||
| kitgate.py | ||
| kitindex.py | ||
| restage.py | ||
| server.py |
Screenshotted the Fred view instead of trusting it, and it showed two things. The transport read **133 bpm on a 132.5 bpm kit**, because selecting a kit rounded its tempo. Harmless in a display, not harmless here: the rack sets `rate = dur / (bars × barlen)`, so 133 stretches every loop in that kit by 0.4% and the mismatch goes straight into the audio. Half-integer tempos are ordinary in this corpus. No rounding, and the "match this kit" button now compares to 0.01 bpm so it stops offering a value it already has. And `fred_bighen_bass` listed three loops all labelled `bass`, two of them also both "8 bars · 132.5 bpm" — the kit is named for the stem, so the stem name distinguishes nothing. The manifest already knew `start_s`, so rows now carry `@2:14`: where in the source track this loop was cut from, which is the thing you actually want when choosing between two loops off one stem.
| Name |
Last commit
|
Last update |
|---|---|---|
| .. | ||
| engine | Loading commit data... | |
| packs | Loading commit data... | |
| research | Loading commit data... | |
| tests | Loading commit data... | |
| ui | Loading commit data... | |
| .gitignore | Loading commit data... | |
| PHASE2_LOOPFINDER.md | Loading commit data... | |
| README.md | Loading commit data... | |
| TODO.md | Loading commit data... | |
| autotune.py | Loading commit data... | |
| demos.json | Loading commit data... | |
| foundry.py | Loading commit data... | |
| kitgate.py | Loading commit data... | |
| kitindex.py | Loading commit data... | |
| restage.py | Loading commit data... | |
| server.py | Loading commit data... |