Creating custom beats - Claude AI and Drum2Notes - Guide

BeatBuddy
1

My BB1 Drum MIDI Workflow Using Claude

Sharing this in case it’s useful to anyone else prepping custom drum parts for a BeatBuddy 1. It’s a bit involved, but once set up it’s repeatable and fast.

Before Claude: getting a transcribed MIDI file

  1. Source audio. I pull the song audio from YouTube.
  2. Transcribe with Drum2Notes [klang].[io]. I upload the audio and it produces a drum transcription. Heads up: the free tier only gives you a 20-second preview, which isn’t enough to judge or use — you need at least a one-month subscription to get the full song transcribed.
  3. Download the quantized (“DAW”) version of the MIDI file — this is the “for DAW” export option in Drum2Notes, not the raw unquantized one. I’ll sometimes preview it in BeatBuddy Manager Online (BBMO) first just to sanity-check it before going further.
  4. Upload to Claude and start with velocity shaping. Drum2Notes exports everything at a flat velocity (no dynamics at all), so my first request to Claude is always to shape the velocity — this is the point where the file stops sounding robotic.

What happens inside Claude (needs at least a Pro plan)

Project setup. I run this inside a Claude Project with a fixed set of reference files loaded, so Claude never has to guess at conventions:

  • A custom “kit reference” document covering all 12 BeatBuddy kits, confirmed against screenshots of the actual kit note maps (including my two non-standard kits — Modern Custom and Jazz Brushes, neither of which ship with a stock BeatBuddy).
  • A GarageBand note-name reference table, used as a manual cross-check tool (see below).
  • The BBMO manual PDFs, so Claude can answer questions about how BBMO itself behaves (fill types, start points, transitions, etc.) rather than guessing.
  • A custom Python-based MIDI splitting/analysis tool (skill) that does the actual bar/beat math, note remapping, and file generation.

Automatic validation pass. Before touching anything, Claude runs a full analysis of the uploaded file — checking quantization grid (including triplet/shuffle grids, not just straight 16ths), flagging implausible or silent notes, checking bar numbering, and cross-referencing notes against the target kit’s map. It reports everything it finds and waits for me to confirm before making any changes — nothing gets modified silently.

Velocity shaping + humanisation. Once I confirm, Claude reshapes velocity (using its most capable model tier for this step (Opus 4.8 currently) — mechanical extraction work can run on a lighter model (Sonnet 5 atm) , but shaping the actual musical dynamics needs the more capable one). Humanisation (small random timing/velocity jitter) is applied automatically as a final layer whenever shaping happens — I don’t have to ask for it separately, and it’s reported as its own step so I can see what changed.

Building the shaped master. The shaped, humanised file becomes the master copy. From this point on, every extract (verse, chorus, fill, outro, etc.) is cut from that master — not from the original raw file — so everything stays musically consistent.

Extracting parts — the request syntax. Once I have a shaped master, I ask for parts in plain language referencing bar numbers, e.g.:

  • “Extract bars 9–16 as the Verse”
  • “Give me the fill at bar 27” (fills are kept to one bar max, in line with BB1’s own limit)
  • “Extract the transition, bars 40–44” (transitions can span multiple bars — BB1 allows that)
  • “Suggest three outro options for the last 4 bars” — this specifically triggers a three-way outro composition (A/B/C variations for me to choose from); if I just say “extract the outro, bars X–Y” it’s treated as a plain extraction of what’s already there, not a composed one.

I determine the parts manually by listening and viewing the transcription in Drum2Notes.

Claude does the bar-to-tick maths itself, cuts the file, and — importantly — does not shift a fill’s notes back to the start of the bar; it preserves the silence before the hit so the timing feel within the bar is kept intact, unless I explicitly ask for it to be rebased.

Delivery. Everything comes back as a zip (even a single file), with a consistent filename pattern like Song Title - Verse (Bars 9-16).mid, so my library stays organised without me having to rename things.

GM preview option. After each extract is delivered, I’m offered a GM (General MIDI) audio preview of the file — a quick way to hear what’s actually on the file using a standard drum sound set, without having to load it into BBMO first. I don’t always use this myself, but it’s a genuinely useful sanity check for anyone who wants to confirm a part sounds right before going anywhere near BBMO. One caveat worth knowing: the preview is most accurate on the file’s pre-remap (GM-numbered) state — previewing after a kit-specific remap can render slightly wrong, since GM preview doesn’t know about kit-specific note substitutions.

Kit-specific handling. Because I use Modern Custom and Jazz Brushes, Claude applies kit-specific remap rules automatically — for example, Jazz Brushes has some genuinely tricky notes (one that looks like it should be a ride but is actually a long snare sweep, and one that looks like a tom but is actually the hi-hat pedal). These get flagged and handled rather than silently mis-mapped.

GarageBand cross-check (optional, on request). If a note comes back ambiguous or plays silent on the target kit, I can drop the file into GarageBand, listen to what the note actually is, read its on-screen note name off the piano roll, and report that name back to Claude. Because GarageBand and BBMO use the same octave convention (C3 = MIDI 60), the note name converts straight across to a MIDI number with no offset, and Claude reconciles that against the target kit map to decide on a manual remap. This is a manual aid for edge cases only — it never replaces the automatic validation, which is the default path for everything else.

Checks and safeguards built into the process

  • Report before acting — every analysis pass is shown to me first; nothing is changed without explicit confirmation.
  • Quantization checks include shuffle/triplet grids, not just straight-16th detection, so shuffle-feel songs aren’t misdiagnosed as “unquantized.”
  • Master-first extraction rule — if I ask for a cut/fill before a shaped master exists, Claude stops and checks with me rather than pulling from the raw file. If the master later gets re-shaped, previously delivered extracts are flagged as stale.
  • Kit hazard flags — known problem notes on non-standard kits (like the Jazz Brushes snare-sweep/hi-hat-pedal traps) are called out rather than silently mapped.
  • Velocity ceiling awareness — Claude won’t push velocities past MIDI’s max (127) to compensate for a quiet-sounding kit; that’s a BBMO mixer/volume issue, not a MIDI data issue.
  • No silent overwrites — every extract keeps its bar-relative timing unless I explicitly ask for a rebase.
  • Type 0 MIDI only — output is always single-track Type 0, since that’s what the BB1 requires.

Files I’m attaching for this project

These are the two things that make the whole pipeline actually work — without them Claude has no kit knowledge and no way to do the file maths:

BB Custom beats files.zip (22.9 KB)

  • Claude Project instructions.
  • BB1 Kit Reference. The core document. Covers all 12 BeatBuddy kits’ note maps (screenshot-verified against actual BBMO kit screens), the pipeline conventions Claude follows, and a GarageBand note-name cross-check table for resolving ambiguous notes. This is what lets Claude apply the correct remaps for non-standard kits like Modern Custom and Jazz Brushes instead of guessing.
  • bb-midi-splitter skill (SKILL.md + bb_midi.py). The actual working code — does the bar/beat-to-tick calculations, note remapping, velocity shaping, and file splitting/export. Without this, Claude would be reasoning about MIDI in the abstract rather than actually generating correct files.

Freely available resources referenced in this workflow

These aren’t included as files in the shared bundle — they’re publicly available direct from the source, so just go and grab them yourself:

  • Drum2Notes — the audio-to-MIDI drum transcription tool.
  • BeatBuddy Manager Online (BBMO) — Singular Sound’s web app for loading and editing songs/kits on the BB1.
  • BeatBuddy Manager Online Manual — official BBMO user manual, from Singular Sound.
  • BeatBuddy Firmware Manual — official BB1/BB2 firmware manual, from Singular Sound.

Happy to try to answer questions if anyone wants to try replicating this setup. (but Claude might be a better companion for hard stuff :wink: ).

2 Likes
2

And for anyone looking for custom beats I just spotted this resource: User Generated Content > Songs @persist

1 Like
3

Thanks. There are many other contributors: Guitar_Stu, Phil, Phil_Flood, Bootsy and lots of unnamed users who have shared their drum sets, songs and beats.

2 Likes
4

BB1 MIDI Pipeline — Update (6 Jul 2026)

Two rounds of changes since the version I originally posted: a compound-meter fix, and a full project audit that consolidated everything into two files.

1. The 6/8 / 3/4 meter fix. The pipeline handled x/8 and triple meters unreliably in three ways, all now fixed in bb_midi.py:

  • The grid-adherence check tested only a straight-16th grid, so genuinely quantized 6/8 and shuffle material produced false “unquantized — re-export” flags. It now tests both straight and triplet subdivisions and picks the best fit.

  • The downbeat-alignment search stepped in whole quarter notes, the wrong granularity for compound meters — it could land a suggested shift off the true 6/8 downbeat. It now steps in notated-beat units and flags non-x/4 suggestions for manual confirmation instead of auto-applying.

  • Beat-level fill extraction assumed beat = quarter note. In 6/8 the notated beat is an eighth, so “fill at beat 4” extracted the wrong slice. extract_fill now takes an explicit beat unit.

Alongside the code, the spec gained explicit feel conventions: 6/8 shaping accents the pulse eighths (1 and 4) with a wide hat spread (~38+ velocity points, or the dotted-quarter lilt collapses into straight eighths), and 3/4 is downbeat-led — neither gets a 4/4 backbeat imposed on it. Key insight for anyone building similar tooling: 3/4 and 6/8 have identical ticks-per-bar, so bar maths passes cleanly while the feel is completely wrong — the distinction lives entirely in accent structure.

2. Audit and consolidation. A full review of instructions, code and reference docs turned up several latent bugs, all fixed:

  • Groove analysis (groove_analyse/groove_report — swing ratio, density sections, backbeat share, ghost-note ratio) and the Jazz Brushes kit map are now built into bb_midi.py. All 12 BBMO kit maps live in the code, screenshot-confirmed; the separate kit-reference document is retired.

  • Zero-length notes (same-tick on/off pairs from transcription) survived cleaning and were written with note-off before note-on — now repaired automatically.

  • Writing an empty extract crashed; now either raises a clear error or writes a deliberate silent snippet.

  • Corrected a wrong premise in the Tier-1 remap rules: GM 40/41/47 aren’t silent on all six stock kits — on Jazz and Brushes they trigger native brush/foot-hat articulations, so the remaps there are wrong-sound preventions, not silent-note rescues, and must never be skipped.

  • Documented a trap where extracts ending in a silent bar came out one bar short (loops audibly wrong on the pedal) unless the bar count is passed explicitly to the writer.

Everything now lives in exactly two artifacts: the skill (code + thin interface stub) and the project instructions (the full prose spec — workflow, BB1 output rules, kit maps and remap tables, meter/feel conventions, GarageBand cross-check reference). Both are in the attached zip.

Files to delete or replace (for anyone running the previous version):

  1. Replace the bb-midi-splitter skill with the bb-midi-splitter/ folder in the zip (SKILL.md + scripts/bb_midi.py)

  2. Replace the project instructions with Project_Instructions_v2026-07-06.md

  3. Delete BB1_Kit_Reference.md / BB1_Kit_Reference_1.md — retired; kit maps and groove code now in bb_midi.py

  4. Delete BB1_Kit_Reference_Part7.md — GarageBand table now duplicated in the instructions

  5. Delete any bb_midi.py copy sitting in project files — the skill is the only home for the code

    BB1 MIDI Pipeline - Update Pack 2026-07-06.zip (25.0 KB)

1 Like
5

I am finding Drum2Notes very difficult on any rock songs that tempo drift a fair amount. I’m using Moises to separate out just the drum stem, then uploading that to D2N. Ableton live warp says the track ranges from ~90-99bpm, and it has a couple multi-beat pauses (rock band speed up to the chorus, pause at end of chorus, verse at slower tempo) which every beat detection tool chokes on. And the lack of velocity just seems dumb to me. they should easily be able to detect a least a little variation in the audio for the kick and snare.

6

I found the solution to this drifting tempo issue. Export the MusicXML rather than the midi. It’s cleaner than the midi, the tempo changes and drift in the midi are not relevant for BB, and the Claude conversion to Midi is cleaner. It even makes it easier to say which bars are quiet and which are louder for auto adjusting velocities.

7

Thanks for the feedback.

Claude has reported some tempo drifting in the songs that I’ve worked on, but that’s typically been very little, and it’s been okay to deal with. It’s been within reasonable tolerances. I’m not creating a complete end-to-end track. I’m using this to get snippets for verses, outros, etc., so that I can get the essence of the song rather than copy it verbatim. Maybe this isn’t so much of an issue for me.

My knowledge of MusicXML is even less than my knowledge of MIDI files, so I asked Claude about the benefits of using MusicXML. In summary, it says that the MIDI-first approach should remain the default, but if it has issues with identifying tempo and some other areas (I can’t remember off the top of my head), it will request that I upload a MusicXML export from drum notes so we can verify those things. Otherwise, it says that the transcript is identical; it’s just being presented in a different format. The advantage is that MusicXML has some explicit information on time signatures and timing that MIDI doesn’t.

Given the amount of long-term expertise in this forum, I was fairly hesitant about uploading this potential routine for creating MIDI files. Interested to know if you found it generally useful?

8

I had the same experience of Claude saying MusicXML was not going to be meaningfully different. But then I had it run the analysis and we determined that actually it was better to use. MusicXML contains enough information to make full music charts including timing changes would typically require a tempo map separate from the midi track. Your milage may very, but for two of my 3 test tracks, it was better. I use Claude for a ton of development so using it for this is pretty natural. The next step is to see how well it can do to identify and build the sequence splits (intro, verse, chorus, outro) automatically or with limited guidance. For example, I can import the source track into Live set that track to be the Warp “Lead” and just create markers for the sections. With the new Live API, I can have Claude read those markers and create the BB parts automatically, including transition fills.

9

BTW, the idea of using Claude for this was genuinely useful. The link to drums2notes was useful (Live does this horribly and only creates kick, snare, hats tracks). But I didn’t use anything else from your bundle. I have a music project/context set up for claude already so didn’t need any of that stuff. I’ve been writing (well, product designing) my own DSP and plugins for a year now as well as midi management. So thanks for the idea for sure!

10

All interesting stuff.

(Live is Ableton? I don’t need a DAW and Reaper would suffice for my occasional requirements).

I’ll revisit the Claude xml recommendation. Fable access had been extended and might offer a different analysis outcome.

I’m manually identifying sections atm. And if pattern is repeated (or near repeats) for a section I’m extracting a single instance of the pattern with some fills if potentially useful for feel variations.

I’m interested in how automated identification and subsequent extraction of sections might work with my goals which are process efficiency/speed, accuracy and feel (although the latter is a combination of transcription interpretation and the later velocity shaping). I’d assumed this part of the process would have to be manual.

Claude is now telling me it’s assessment of the genre before proposing a shaping approach. The former will be from web search, how the proposed shaping values are interpolated from that is anyone’s guess. It’s better than all instruments at velocity 80. In my last batch I globally reduced the snare velocity and it made a big difference to the groove.

Overall, I’m pretty pleased with this as a process to enable a non-drummer to assemble song specific beats for the BB.