[jonathanwardle1992-beep]

Summary

MICRO TIMING stays one module. Current main is merged. The Play Start files that this branch was also carrying are gone; they belong on #947.

It is back under sdk/drafts/micro-timing/. Current main refuses a listed module that has no qualification record and no real UI captures. The 2 November note asked for a headless ot_emu capture of the MICRO T row in TRIG EDIT, with REC.TRG at the bottom of that window. This machine has the emulator source only, not a built ot_emu, and no OS 1.40C image, so that capture was not run. Camera photos cannot be used as the module screenshots.

module:doctor -- --draft micro-timing leaves the listing, qualification, packages, USB package, native comparison and package fingerprint red. Cross-compatibility with the other active modules is clean. The behaviour is unchanged from the private MICRO T9 report, and that card is not this source.

A push does not publish it and does not email followers.

Test plan

• npm run modules:generate
• npm run module:doctor -- --draft micro-timing
• scripts/capture-module-ui.py for MICRO T in TRIG EDIT and REC.TRG, once ot_emu and OS 1.40C are available
• Qualification, a ColdFire package, and a USB install

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.

[github-actions]

This update needs owner review instead of automatic publication: This GitHub account is not a registered module author.

[jonathanwardle1992-beep]

[repeat98]

Thanks for the photos! For a module's screenshots you don't need a camera, though: your agent makes them in the emulator. It boots your own 1.40C build with the module in a headless ot_emu, steps through the pages with a short panel plan, and saves the screen's real pixels as black-and-white PNGs with a capture.json record beside them (scripts/capture-module-ui.py, described in MODULE_UI_CAPTURES.md). They go in the module's media/ folder and are listed under access.screenshots in octamod.module.json, so the module page shows them. Photos in a comment can't be used there. Just ask your agent to capture the MICRO T row in TRIG EDIT and REC TRG at the bottom of that window.

---

Generated by Claude Code

[repeat98]

Thanks for the captures. They show what I was hoping for: MICRO T under TRIGS, and REC.TRG scrolled into view.

None of this stops it going in as a draft, but it all needs sorting before it's listed:

1. uiClaims. It changes the stock TRACK TRIG EDIT window (a fifth row, the scrolling and the footer), so please declare "uiClaims": ["screen:TRACK TRIG EDIT"] instead of []. Then the gate catches a second module that changes the same window.
2. Where the remembered numbers live. mt_ensure and mt_current use a fixed address in stock's battery RAM: the magic word at 0x100f8ffc and a table from 0x100f9000. Nothing in the module declares those bytes, so the gate can't see them, and I can't tell whether stock or the base ever use them. How did you find they're free? The value is meant to be lost at power-off anyway, so it would be safer in the module's own unit, the way Track Mutes now keeps its checkbox.
3. Its size. mt_ensure clears 0x200 longs, so the table is 2 KB, not the 512 bytes the memory rationale says.
4. What it's per. mt_current indexes the table by 0x800065bd and 0x100b14d0 as well as the track. If those are the bank and the pattern, there's one number per pattern and track, not one per track number as the README says. Which is it?

[jonathanwardle1992-beep]

The draft on main is the copy this note reviewed. The headless captures are already in the merged draft under access.screenshots: media/ot-micro-t.png shows MICRO T under TRIGS, and media/ot-rec-trg.png shows REC.TRG scrolled into that window. They are emulator frames. This package has not been flashed or tried over USB.

uiClaims. compatibility.uiClaims is still []. The module takes no key gesture of its own. FUNC+BANK remains the stock way into TRACK TRIG EDIT. The code changes that window: the name table and mt_label insert MICRO T under TRIGS, the list length goes from 4 to 5 while the window stays four rows so REC.TRG scrolls onto the bottom row, and mt_footer replaces the footer while MICRO T is selected. The declaration you asked for, "screen:TRACK TRIG EDIT", is not in the manifest, so the gate still cannot catch a second module that changes the same window.

Where the remembered numbers live. microtiming.s has no .equ for these bytes. mt_ensure reads the long at 0x100f8ffc and, unless that long is 0x4d54494d (MTIM), clears the table at 0x100f9000 and then writes the magic. mt_current reads one byte from that table. Both addresses sit in battery SRAM (0x10000000–0x100fffff), which is why power-off drops the number. The source never says how they were chosen or that they were found free, and the manifest does not declare them. The base's battery records that this tree documents sit above the table: the diagnostic log at 0x100fc000, the crash record at 0x100ff800, the stall record at 0x100ff900. That leaves the gap itself unexplained. The number is not stored in the module's own unit.

Its size. The memory rationale says 512 battery bytes. mt_ensure loads 0x200 and clears that many longs, which is 2048 bytes, from 0x100f9000 through 0x100f97ff, plus the 4-byte magic at 0x100f8ffc. The 512 in the rationale is the loop count. The code allocates the 2 KB table.

What it's per. mt_current indexes by three bytes. The address is 0x100f9000 plus the low nibble of 0x800065bd shifted left 7, plus the low nibble of 0x100b14d0 shifted left 3, plus 0x100b14cc masked to 0–7. This file uses 0x100b14cc the same way to print the footer track (MT1–MT8), so that term is the track. This file does not name the other two. Elsewhere here, 0x800065bd is the current bank and 0x100b14d0 is the current pattern, the UI's project-RAM pattern rather than the sequencer pattern byte at 0x800065be. The biggest index is 2047, the last byte of the 2 KB clear, so there is one byte for every combination of those three fields: one remembered number per bank, pattern and track. The README's "one remembered number per track number" does not match that. Audio and MIDI share the byte, because the MIDI button is not part of the index. LEVEL still writes only the side on screen.

Listing still needs the screen claim filled in, these bytes given a declared home (the source does not show they are free), the rationale set to the 2 KB the clear writes, and the README set to the three-part index. I have not changed the draft.