[jonathanwardle1992-beep]

Summary

This answers the pre-listing notes on #1154 (comment). The draft stays 0.1.0-experimental. The indexer is unchanged: the screen claim, the memory rationale and the player text now match the code. Author and reviewer boxes stay unticked. This does not publish the module and does not email followers.

• Screen. compatibility.uiClaims is ["screen:TRACK TRIG EDIT"]. The module takes no key of its own.
• Battery home. The magic long 0x4d54494d at 0x100f8ffc and the table at 0x100f9000 are named in the source (MT_MAGIC, MT_TABLE) and in the manifest. There is no declaration slot for a draft's battery words (Claims.sram is on-chip SRAM), so the rationale says that instead of a new scheme. The addresses are not moved. No trap document names these bytes as taken. Play Modes ends at 0x100f8f06 and the diagnostic log starts at 0x100fc000.
• Size. mt_ensure still clears 0x200 longs, 2048 bytes from 0x100f9000 through 0x100f97ff, plus the 4-byte magic. The largest index the bank, on-screen pattern and track math can form is 2047, so the clear is the size the indexer uses.
• What it is per. One byte per bank, the pattern on the screen, and track. Audio and MIDI share that byte. The pattern byte is 0x100b14d0, not the sequencer pattern at 0x800065be.

What the guides lacked: a draft has nowhere to declare battery words so the gate can see them. Nothing in the guides was edited here.

Test plan

• npm run module:doctor -- --draft micro-timing
• Qualification, a ColdFire package, and a USB install (unchanged; still a draft)

Doctor, with Python UTF-8 as CI uses it: ui claims screen:TRACK TRIG EDIT and cross-compatibility are green. Still red for the known draft reasons: catalog entry, qualification (modules:check), packages, USB package, native comparison, pair table, and package fingerprint. Those reds are the listing gaps, not this claim, rationale or README. A Windows code-page run also reports a lofi2.asm decode error inside the composition check; that file is not part of this draft, and the UTF-8 run does not.

No check can prove these, so you vouch for them:

• Changing a module someone else wrote: its author said yes before I started, and I link it here (a GitHub link, or Discord and the day). Ask the author first
• I read the guide for its category in docs/module-guides/ (and sequencing.md if it acts in time), and TESTING.md lists what I did not test.
• Source and media are mine or properly licensed, with authors and full licence texts kept. Nothing comes from Elektron firmware: no extracted code or tables, upgrade files or factory content.
• Screenshots are real captures of the current module UI. Hardware results are what a named person saw on this exact build; emulator results are labelled as emulator results.

Registered module authors can opt into automatic publication after reviewing all the evidence. An update that reaches firmware or hardware addresses the published version did not use goes to owner review instead:

• Automatically merge and publish my module update after checks pass.
• I verified the source, licences, UI and qualification reports, including instance isolation and Part/project/reboot persistence where applicable; no required acceptance check is failed or untested.

Reviewer (the owner for a first release, the registered author for their own update):

• I checked the cycle and memory reports against the worst case, the attributed hardware evidence against the submitted source and build, and the screenshots, tutorial and access steps against the current UI.

Related to #1154

[repeat98]

Thanks, the screen claim, the 2 KB and the index (bank, pattern on screen and track) all match the code now.

Two things about the battery table before it's listed:

1. Power-off. The README, the manifest and the release note say power-off clears the number. Battery RAM is the part that keeps its contents through a power cycle: the base's log, FX map and crash record from 0x100fc000 up rely on exactly that, and stock touches nothing between 0x100f859c and 0x100fff00. So after a reboot MTIM is still there, mt_ensure keeps the table, and the numbers should come back, even after the module is removed and installed again. TESTING.md lists power-off as a check that hasn't been run yet. Could you try it, on the unit or in ot_emu with the battery RAM carried over (--cs1-in), and make the docs say what really happens?
2. Where it lives. That no document names these bytes doesn't make them free. Pattern Sample Locks used 0x100f9000 to 0x100fbfff for its own records before, and nothing would warn either module about the next one. That's why I'd still like the table in the module's own unit, as I suggested on Module/midi micro timing offset per track from TRACK/MIDI TRIG EDIT (FUNC+BANK) #1154. It's 2 KB, and there it really is gone after a power cycle, which is what the README promises. If there's a reason it can't live there, tell me and I'll think about a base home for module battery words instead.

The red check isn't yours: a timing test in the site's account code ran just over its 5 s limit, and this pull request only touches the draft's folder. The two points above can come here or in your next Micro Timing pull request, whichever suits you.

---

Generated by Claude Code