Ableton/Live/Instrument/Drum/Forevertron/Log/26/11/09-Mon/Plan

• 2026-11-09 Mon
  • AI/Response from Anthropic/Model/Claude/5/5/Opus
    • Plan for turning the Forevertron Ableton/Instrument/Drum Rack into a 64-pad pack in a new repo, codekiln/ableton-forevertron-pack, with releases built by CI. Background: Ableton/Live/Instrument/Drum/Forevertron/Log/26/11/08-Sun.

    • Answers

      • Where Live keeps samples that aren't private

        • User Library, ~/Music/Ableton/User Library. It holds your presets, defaults, clips, templates and samples, and Live lists it under Places. Its Samples folder is for samples referenced by saved presets and tracks; Imported and Recorded are subfolders Live writes to. A Samples/Forevertron/ folder there is a normal place for these. See Ableton/Live/UG/04 Browser/07 Places/06 User Library.
        • Packs, ~/Music/Ableton/Factory Packs and ~/Music/Ableton/3rd Party Packs. Live fills these when it installs an .alp; they aren't for hand-placed files. The one third-party pack installed here unpacked as a Project folder (wavparty - Ableton 11 MPE pack Project). See Ableton/Live/UG/04 Browser/07 Places/01 Downloading and Installing Packs in the Browser.
        • User folders in Places, added with Add Folder. Live indexes the folder where it sits and doesn't move it. A git checkout can be a user folder. See Ableton/Live/UG/04 Browser/07 Places/08 User Folders.
        • Cloud, where the samples are now. It shows Sets synced from Ableton/Note and lives in hidden ~/Library/Application Support/Ableton/Cloud Manager/, managed by the sync. See Ableton/Live/UG/04 Browser/07 Places.

      • What renaming a sample breaks

        • Each pad's SampleRef in the preset names the file in several places:
          • FileRef/RelativePath, relative to the preset's own folder. In Forevertron Trimmed.adg it is ../../../../../../Library/Application Support/... with RelativePathType 1. Presets referenced from the User Library use type 6 with a path from the User Library root. These meanings are read off the file; Ableton doesn't document them.
          • FileRef/Path, the absolute path. It contains the home folder, so the macOS user name.
          • A second copy of the FileRef under SourceContext/OriginalFileRef, and BrowserContentPath, such as query:Cloud#Forevertron:Samples:Recordings:29_06_24-R1.wav.
          • OriginalFileSize and OriginalCrc. Cropping changes both. The CRC values are below 65536, so it is a 16-bit checksum of unknown kind.
          • DefaultDuration, in samples, plus SampleStart, SampleEnd and the sustain and release loop points. Cropping shifts all of these.
          • The pad's chain Name, which is the old file name, such as 30_06_24-R9.
        • The .asd file is named after its sample (30_06_24-R9.wav.asd), so it no longer matches after a rename. After cropping it describes the wrong audio anyway. Live writes a new one the first time it loads the cropped file.
        • Other Sets that use the recordings, such as Forevertron.abl, keep pointing at the originals in the Cloud folder. The originals stay where they are.
        • How the plan handles it: analysis/selection.toml maps each source recording to its new name and pad note. A build task rewrites every field above from that file, leaves .asd files out of the repo, and a check task fails if any FileRef points outside pack/ or holds a home path. OriginalCrc can't be computed without knowing the algorithm, so the preset is opened in Live once and saved, which records the new size and CRC.

      • What the .asd file holds

        • From Ableton's manual: it improves warping quality, holds the detected tempo of long samples, speeds up waveform drawing, and stores Save Default Clip settings such as warp markers. See Ableton/Live/UG/05 Managing Files and Sets/01 Sample Files/02 Analysis Files (.asd).
        • From the files: all 76 are binary, 8–53 KB, starting 06 49. Running strings over all of them turns up the same field names in each:
          • SampleOverView and SampleOverViewLevel: the waveform overview.
          • OnSets, OnsetArray and OnsetEvent: transient positions.
          • AufTaktData: German Auftakt means upbeat, so probably where the first downbeat falls. A guess.
          • TimeSignatureNumerator and TimeSignatureDenominator.
          • Unnamed RemoteableDouble, RemoteableBool, RemoteableEnum, RemoteableInt and UserFloat values.
          • WarpMarker, only in 30_06_24-R34.wav.asd.
        • Pitch: no field is named for pitch, key, tuning, root note or tempo. The unnamed values could hold any of these, and nothing visible says they do. Treat the .asd as holding no pitch analysis. The analysis step below estimates pitch itself.
        • Outside sources: DBraun/AbletonParsing parses warp markers out of .asd files from Live 9 and 10, and doesn't mention pitch. No Ableton page lists the fields.
        • The warp settings that matter here are in the preset, under SampleWarpProperties. All 76 pads have IsWarped false.

      • Can CI build an Ableton Pack (.alp)?

        • Not with any tool found. Live writes an .alp from a Project with File Manager → Manage Project → Create Pack (Ableton/Live/UG/05 Managing Files and Sets/09 Packing Projects into Packs). Ableton publishes no format spec and no command-line packer, and Live runs only on macOS and Windows with an authorized license, so a GitHub runner can't run it.
        • kmontag/alpax, an MIT-licensed Python library marked alpha, builds directory-based packs that Live accepts when dragged into Places. Its README says generating .alp files is not supported.
        • Ableton/File/.alp says the format is a zipped archive. No .alp was on this Mac to check.
        • What the release ships instead: a zip of a Forevertron/ folder laid out like a User Library: Presets/Instruments/Drum Rack/Forevertron.adg and Samples/Forevertron/*.wav. Unzip it anywhere and add it to Places, or merge it into the User Library. The preset finds its samples by relative path either way.
        • An .alp can still be made by hand in Live from that folder and attached to the same GitHub Release with gh release upload.

      • Pads per Launchpad page

        • 64. Note Mode is an 8 × 8 surface (Launchpad/UG/06 Note Mode/01 Overview). Drum Mode shows four 4 × 4 quadrants, and the lower-left quadrant matches the 16 slots Live's Drum Rack shows; Up and Down scroll 16 slots at a time (Launchpad/UG/06 Note Mode/06 Drum Mode). The programmer's reference lays out the DAW Drumrack as two 4 × 8 halves covering notes 36–67 and 68–99 (Launchpad/PRG/05 Software Integration/06 DAW Drumrack).
        • The rack now spans notes 29–104 across 76 pads, so playing it means scrolling. The 64-pad rack goes on notes 36–99.

    • Repo layout

      • Code is MIT (LICENSE at the root). Everything under pack/ is CC BY-SA 4.0 (pack/LICENSE): samples and the preset.
      • text

        ableton-forevertron-pack/
          README.md
          LICENSE                   MIT, everything outside pack/
          mise.toml                 python, uv, node, openspec, usage
          mise.local.toml           gitignored: path to the source recordings
          pyproject.toml, uv.lock
          .gitattributes            *.adg filter, *.wav binary
          .gitignore                *.asd, dist/, .venv/
          .github/workflows/release.yml   added at packaging time
          openspec/
          mise-tasks/
            setup/git               git filter config for this clone
            analyse/features        analysis/features.json from the recordings
            analyse/rank            pad scores and attribute part-worths
            site/serve              the local analysis site
            pack/extract            crop, convert and rename the chosen 64
            pack/preset             the 64-pad preset from Forevertron Trimmed
            pack/check              paths, pad notes, licenses, no home paths
            pack/build              dist/Forevertron-<version>.zip
            test                    pytest, ruff, mypy
          forevertron_pack/         onset detection, preset XML edits, audio I/O
          tests/unit/, tests/integration/
          site/                     static HTML, CSS and JS
          analysis/
            trim-2026-11-08.json    props.json from the trim pass
            features.json
            judgements.jsonl
            selection.toml          the 64: source, pad note, new name
          pack/
            LICENSE                 CC BY-SA 4.0
            Forevertron/
              Presets/Instruments/Drum Rack/Forevertron.adg
              Samples/Forevertron/*.wav

      • Tasks are mise/Task/Files written in Python, run through uv in the project environment so they import forevertron_pack, with #MISE description and #USAGE lines.
      • The source recordings folder is set in mise.local.toml as FOREVERTRON_SOURCE, written with {{env.HOME}}, so no home path is committed.

    • Phases

      • 1. Set up the local repo

        • Create ~/ghq/github.com/codekiln/ableton-forevertron-pack with the layout above, mise.toml, pyproject.toml, both licenses and openspec init.
        • Run mise run setup:git and commit .gitattributes before any .adg (see Presets as XML in git).
        • Add a pre-commit check that rejects the home path and the user name in any staged file.
        • Carry in the trim pass from November 8: detect.py, apply.py and explore.py become modules in forevertron_pack that take paths as arguments, and props.json becomes analysis/trim-2026-11-08.json. The scripts sit in a temporary folder and have the home path written into them.
        • Done when:
          • mise run test passes and openspec list runs.
          • The ported apply step, run on Forevertron Trigger.adg with the trim JSON, gives the same XML as Forevertron Trimmed.adg when both are decompressed and compared.
          • A test commit containing the home path is refused.

      • 2. Build the analysis site

        • The first OpenSpec change.
        • mise run analyse:features reads the 76 recordings from FOREVERTRON_SOURCE and each pad's start, end and fade-out from Forevertron Trimmed.adg. It writes analysis/features.json: length played, peak and loudness, noise floor, attack time, spectral centroid, estimated pitch with a confidence value, number of hits, and 2-D coordinates for a similarity map. The recordings stay out of the repo.
        • mise run site:serve starts a FastAPI app on localhost that serves site/ and the audio and appends each judgement to analysis/judgements.jsonl.
        • Views:
          • List: play each pad, its waveform with start and end marked, its features and tags.
          • Compare: two or three pads side by side; pick one to keep.
          • Map: pads placed by similarity, to find near-duplicates.
          • Board: an 8 × 8 grid laid out like the Launchpad, note 36 at bottom left, for placing the chosen 64.
        • Playback applies each pad's start, end and fade-out so it sounds the way the pad does. All pads are at −12 dB with no transpose, so level and pitch need no adjusting.
        • Done when:
          • Every one of the 76 plays in the browser, and a handful sound the same as in Live, including the pads flagged on November 8 (30_06_24-R9, R19, R55, R71).
          • Judgements are still there after a server restart and show up in git diff.

      • 3. Choose the 64

        • codekiln tags each pad with a few attributes of their choosing, such as material, attack, length and register, then works through comparison rounds in the Compare view.
        • mise run analyse:rank fits:
          • a score per pad from the pairwise choices (Bradley–Terry);
          • a conditional logit on the tagged attributes, which gives a part-worth per attribute level. This is the conjoint part: it shows which qualities drive the choices.
        • The 64 are the top scores, subject to minimums codekiln sets per attribute level. 29_06_24-R5 is background noise with no hit and starts as a drop candidate.
        • Pads go on the Board view; the result is analysis/selection.toml.
        • Done when: selection.toml lists 64 different source recordings, uses each note from 36 to 99 once, gives each a new name, and codekiln has signed off on the Board view.

      • 4. Extract, crop and rename

        • mise run pack:extract cuts each chosen recording to the part the pad plays and writes it to pack/Forevertron/Samples/Forevertron/<new name>.wav. All 76 recordings have identical left and right channels, so mono loses nothing. Cropped, the 76 come to 201 s of audio against 414 s now.
        • mise run pack:preset starts from the Trimmed XML, keeps the 64 chains, sets each chain's note, and rewrites every field listed under What renaming a sample breaks. SampleStart becomes the pre-roll, or 0.
        • Open the preset in Live from the repo folder, added to Places, and save it once to record the new sizes and CRCs.
        • Done when:
          • mise run pack:check passes.
          • Live shows no Offline samples.
          • Several pads sound the same as in Forevertron Trimmed.adg.
          • After the save in Live, git diff shows only size and CRC lines changing.

      • 5. Play it from the Launchpad

        • Load the rack on a MIDI track, arm it, and play it in Drum Mode on the Novation/Launchpad/Pro/Mk3.
        • Change pad order or settings in Live and commit what changes.
        • Done when: all 64 pads play from one Launchpad page without scrolling, and codekiln decides the pack is ready to package.

      • 6. Package and release

        • Create the GitHub repo, push, add .github/workflows/release.yml, and tag v1.0.0.
        • Done when: the release page has the zip and SHA256SUMS, and the zip, unpacked into a new folder and added to Places, loads the rack with no Offline samples.

    • Presets as XML in git

      • The presets are gzipped XML (Ableton/File/.adg). A clean filter decompresses them when staged, so history holds XML and diffs are readable. A smudge filter compresses them on checkout, so Live gets the file it expects.
      • .gitattributes:
        • text

          *.adg filter=ableton-gzip
          *.wav binary

      • mise run setup:git sets the driver for the clone:
        • bash

          git config filter.ableton-gzip.clean "gzip -dcf | sed -E 's|<Path Value=\"[^\"]*\"|<Path Value=\"\"|'"
          git config filter.ableton-gzip.smudge "gzip -nc"
          git config filter.ableton-gzip.required true

      • gzip -dcf passes plain XML through unchanged, so staging an already-decompressed file works. -n leaves the file name and time out of the gzip header, so the same XML always compresses to the same file.
      • The sed step blanks every absolute Path, so Live's saves never put the home path into history. The relative paths stay. Because the working file is cleaned before comparison, git status stays clean after a save that only changed Path values.
      • required true makes git add and checkout fail if the filter fails, instead of storing gzip in history.
      • Tried in a scratch repo with Forevertron Trimmed.adg (Apple gzip, macOS): the committed blob starts <?xml, has no home path and 458 blank Path values; git status stays clean; a checkout writes a gzip file.
      • Untested: whether Live loads a sample from RelativePath alone when Path is blank. If it doesn't, the smudge filter becomes a short Python program that fills Path from the checkout location.
      • ableton-live-git-hooks (GitHub) doesn't do this yet. It handles .als and .alc only, with a pre-commit hook that writes <name>.als.xml next to each Set and a post-checkout hook that rebuilds the Set. Clean and smudge filters appear only in its docs, as a plan for a CLI named alhook.

    • Release pipeline

      • Runs on a pushed tag matching v*, on ubuntu-latest.
      • Steps:
        • actions/checkout. No filter driver is set on the runner, so the .adg arrives as plain XML.
        • jdx/mise-action@v5 installs the tools from mise.toml.
        • mise run test and mise run pack:check.
        • mise run pack:build gzips the preset with gzip -n, copies the samples, pack/LICENSE and a README with install steps into Forevertron/, and writes dist/Forevertron-<version>.zip and dist/SHA256SUMS.
        • gh release create "$GITHUB_REF_NAME" dist/* --notes-from-tag publishes the release, with the tag annotation as notes.
      • The README in the zip says the preset needs Live 11.3 or later, since it was saved from 11.3.

    • Open decisions for codekiln

      • When the repo is created. The analysis needs a repo before the pack is ready. Two sequences:
        • Local first: phases 1–5 in a local repo under ~/ghq with no remote; the GitHub repo and release CI arrive in phase 6. No backup and no GitHub issues or PRs until then, and the ghq address can't be read from an origin remote.
        • Private remote first: a private GitHub repo from phase 1, made public in phase 6. Issues, PRs and backup from the start; nothing is public until codekiln chooses.
      • Sample format: mono 24-bit WAV (about 29 MB for all 76 cropped, less for 64), mono 32-bit float (about 39 MB), or FLAC. The recordings are 32-bit float stereo now.
      • Pre-roll: crop at the pad's start, or keep 10–20 ms before it so the start can still be moved earlier in Simpler.
      • Names: for example Forevertron 036 Bell Strike.wav, with the pad note, or a descriptive name alone.
      • Git LFS: about 30 MB of WAVs fits in plain git. LFS helps only if the samples will be re-cut many times.
      • Where judgements are saved: the FastAPI app writes them into the repo; a purely static site would need an export button and a manual copy.
      • Day-to-day location: use the repo's pack/Forevertron/ from Places, so saves from Live land in git; or copy into the User Library and copy back.
      • Release form: the plain zip only, an alpax directory pack (adds previews and Live 12 tags, alpha software), or either plus a hand-made .alp.
      • Which presets ship: the 64-pad rack only, or the 76-pad Trimmed rack as well.