[synth × mute-modes] FM Synth plays muted trigs in DT-T / OTFX-T (reproduced): synth starts notes from the START bit before Mute Modes' trig gate

@repeat98

@repeat98 @timhastie: Mute Modes author here. Several Modwerk reports (#746, #419, #418, #407, #671, #673) say a muted FM Synth track keeps playing in Mute Modes' trig-mute modes. I've reproduced it in the emulator and traced it to how the two modules meet. Neither module is wrong on its own, but the fix needs one of you. Details and two fix options below.

Result

octabam port (ot_emu), remix MUTE_MODES + SYNTH MACHINE + SCALE QUANTIZER on stock effects (octabam 4781ca40; synth v2.9, mute-modes 8e00275). T1 = FLEX, FMSYNTH marker in slot 1, trigs on steps 1/5/9/13 with ATK 0 / HOLD 20 / REL 20 locks, nothing else playing. T1 muted at frame 2600 (MUTE_STATE 0x8000000a = 1); MUTE MODE poked per run. Peak level after each trig:

after the mute	FM Synth on T1	control: plain sine sample on T1
not muted	−21.0 dBFS every trig	−23.4 dBFS every trig
DT-T	−21.0 dBFS on every muted trig	silent
OTFX-T	−21.0 dBFS on every muted trig	silent
OT	silent	silent
OTFX	silent	silent

Each muted trig is a new note: the track falls to −100…−120 dBFS between trigs (HOLD 20 / REL 20 end each note), then comes back at full level.
Mute Modes does drop the trigs: its dispatch gate (dt_silence) fired on all 4 muted trigs in both trig-mute modes.
The synth starts a note anyway: sy_cold ran 6 times in every run, muted or not (once per trig).

Why

Every sequencer trig ORs the START bit (0x10) into the live byte 0x46104d15[t] at stock 0x4000b9bc. The frame builder copies it to the packer's event byte 0x46104d0c[t] at 0x4000c642.
Mute Modes' trig-mute modes (DT-T, OTFX-T) leave that bit alone. They block what stock does with it later in the frame: the per-machine trig dispatch jsr (a0) at 0x4000d49c, the voice bind / FUN_4000672c start in 0x40006820 / 0x40006844, the DSP trig-flag word at 0x40004c72, and the arena rebind at 0x4000f4dc. That's enough for every stock machine.
FM Synth's sy_render is the renderer the packer calls at 0x4000d43e, which is before the dispatch at 0x4000d49c. It tests NIBBLE bit 4 itself and starts a note (sy_cold / po_start). Since 2.9 the engine also holds the DSP voice open (ATK/HOLD/REL forced to 0/INF/INF), so the new note is heard. The stock path never gets that far on a muted track.

OT and OTFX are unaffected because they cut gains rather than block trigs.

Fix options

A. Synth side (preferred). Before sy_cold / po_start act on a START, ask whether the trig was suppressed. On Modwerk the hook already exists in spirit: Mute Modes answers ev_voice_bind with "drop" (mm_voice_bind) for a muted track in DT-T/OTFX-T. Jannik, you know best whether the synth should raise that event, or whether a small dedicated "is this track's trig suppressed?" event is cleaner. I'm happy to have Mute Modes answer whatever you define. This keeps the mute rule in one place, and covers any future machine that reads the START bit.

B. Mute Modes side. Clear bit 4 at its source for a silenced track in DT-T/OTFX-T, so every reader sees no START. This touches several writers (0x4000b9bc, plus the frame builder's 0x10 | n posts around 0x4000bd74 / 0x4000bdc0), and the copy at 0x4000c634 is exactly where po_retrig is detoured. It would also change behaviour Mute Modes has confirmed on hardware, so it means re-validating every mode, plus re-pins in KYOTI, octabam and Modwerk. Possible, but heavier.

Related, not yet tested: for a muted track in DT-T/OTFX-T, Mute Modes skips stock 0x40006820 (voice reset/kill) entirely. That also skips the synth's po_kill at 0x4000685c. It didn't matter in this test (finite HOLD), but STOP on a muted synth track at HOLD INF is worth a check whichever fix lands.

Meanwhile

I'm telling reporters to use OTFX or OT on FM Synth tracks until this is fixed. I can re-run the repro on any candidate fix. The fixture recipe and emulator command lines are below, and I can share the scratch scripts.

Repro recipe

Fixture: any 1.40C project; FLEX slot 001 PATH=../AUDIO/FMSYNTH.WAV (4 s of silence), T1 FLEX slot 1 in every Part, pattern A01 T1 trigs 1/5/9/13 with locks ATK(12)=0 HOLD(13)=20 REL(14)=20, all other trigs and locks cleared (tools/hw/ot_bank.py / ot_project.py layouts); stage_card.py ... --audio "FMSYNTH.WAV:AUDIO/FMSYNTH.WAV".
Run: ot_emu --image <remix> --card <card> --set OCTABAM --project <name> --sequencer --internal-clock --dsp --main-level 64 --load-ms 90000 --audio-out <boot> --watch-pc <sy_cold>,<dt_silence> --scenario "<log> --step -:poke:0x800000df=<0..3> --step 2600:poke:0x8000000a=1 --frames 7000 --audio-out <prefix>". MUTE MODE word low byte: 0 OT, 1 OTFX-T, 2 DT-T, 3 OTFX.
Note: calling 0x40083ab4(0x10,1) does not set 0x80000008 in the port; poke the mute byte directly.

Confirmed. The FM synth makes its own sound, and the mute only stops the sample player, so the FM voice keeps playing. The fix is to make the synth engine obey the track mute. I will build it when Modwerk confirms the new Octatrack base and how it handles mute, so it is done once and in the right place.

Thanks both. Tim: nothing changes in how FM Synth registers with the base, so build against the current beta base the way 0.1.2 does. For the mute: Mute Modes already answers the base's ev_voice_bind, but the synth starts its note before stock gets there, so it can't use that as is, and a module can't ask another module directly. I'll add a small base query, "is this track's trig muted?", that Mute Modes answers and any machine can ask. I'll tag you both on that PR so FM Synth can use it.

Thanks both! I've answered on #912: FM Synth 0.1.4 will use ev_trig_muted once it lands.

Improvement: Octatrack base answers "is this trig muted?" for machine…

@timhastie

@timhastie @Zac-Kyoti the base query is live in today's beta base (c1ae2ee9): ev_trig_muted at hook index 35, as described in #912. FM Synth can ask it and Mute Modes can answer it; with either one missing nothing changes. I'll close this once both releases are out.

Thanks Jannik! FM Synth 0.1.4 will raise it, and I'll test the pair against today's base.

A finding from the USB beta base, not yet reproduced: a beta tester reports that a muted FM Synth track still sounds with MUTE MODE OTFX (27 Oct 2026, FM Synth 0.1.2, Mute Modes 0.2.1). The table above, measured on a card build in the emulator, had OTFX silent.

How OTFX mutes: it doesn't drop trigs. Every frame it zeroes words +6 and +10 of the track's DSP record (p1_otfx in patch_softmute.s).
What FM Synth writes: words +0 to +5 of that record (ATK/HOLD/REL), so the two don't overlap, and the leak isn't explained yet.
What that means for the fix: ev_trig_muted alone won't cover OTFX.

The workaround until then is MUTE MODE OT.

I checked this on the emulator with my FM Synth card build plus Mute Modes 0.2.1 installed. OT and OTFX both silenced the FM track: every post-mute trigger window measured digital zero. With DT-T and OTFX-T, sound came back on all four post-mute triggers once the previous sound had decayed.

I also tried the OTFX mechanism directly on a plain FM image, zeroing the VOL/XVOL halfwords at byte offsets +6/+10 every frame. That cut the sustained FM output to digital zero apart from a short onset transient, so FM does not bypass those words. FM's only direct writes to the parameter record are the envelope fields at byte offsets 0/2/4, and it publishes an ordinary source header.

So I have not reproduced the OTFX leak on the emulator. The retriggering in the -T modes is the known trig-mute gap that 0.1.4 closes by raising ev_trig_muted, with Mute Modes as the responder; these are measurements of the current 0.1.2-era behaviour, not verification of that fix over USB or on hardware.

Was the tester using OTFX or OTFX-T, and was it the 0.1.2 USB package? If you can point me at the USB build, I will test it.

Thanks Tim, that's a careful check, and it matches Zac's table: OT and OTFX silent, the -T modes retrigger until 0.1.4 asks ev_trig_muted.

The tester's report was from the USB beta: FM Synth 0.1.2's USB package with Mute Modes 0.2.1, on a beta base from 27 Oct, and they said OTFX. I'm checking with them whether it might have been OTFX-T, which would explain it. You can test the same package by syncing FM Synth and Mute Modes from the Octatrack page on modwerk.app to a unit on the current beta base (9b7e0eb3). Until we know more, the workaround stays MUTE MODE OT.

@timhastie

@timhastie, @Zac-Kyoti, one catch I missed: ev_trig_muted is a base event, and card builds have no base events (#912), so it only works over USB. But FM Synth's USB package stays at 0.1.2, as I said on #555, so as planned 0.1.4's ask reaches nobody. The same goes for the LFO 3 fix (#932) and the envelope fixes (#883): they would reach card builds only.

Tim, could 0.1.4 also ship a slim USB package: 0.1.2 plus the ev_trig_muted ask and the stock LFO 3 depth read, without the new lock tables? Zac, Mute Modes still has to answer the event: could your next version add the handler, using the same per-track test as your ev_voice_bind handler? sdk/machines/octatrack/HOOKS.md has the contract. On card builds the -T modes still need a native answer, so that half stays open here.

Thanks Jannik. I'd be OK with a slim USB package, 0.1.2 plus the ev_trig_muted ask and the stock LFO 3 depth read, if the site makes clear that it isn't the same as the card build. Could the module page and the sync dialog say when the USB package is an older version than the card build, with the lagReason? Otherwise USB users on FM Synth 0.1.2 will read 0.1.4's description and expect the step and scene locks on every FM control, the chord and envelope fixes and the rest of 0.1.4's changes.

I'd still like the full 0.1.4 over USB. On #555 you said that the loader won't get multi-MB DRAM regions for now, and that FM and SY DRUM could share one lock table later. I'm happy to do the base work for the memory when you're ready for it: the loader's own note says arena pages once the OS's page allocator is audited, and I could take that audit and the PR, or a fixed reserve at boot if you'd rather. Just say which, or if you'd rather do it yourself. The lock-table merge and the fm_runtime.py update for 0.1.4's sources are mine either way.

On the muted trigs, agreed: Mute Modes answers the event over USB, and the card half stays open here.

Improvement: say when a module's USB package is older than its card b…

Hi Tim, #1133 adds that: the module page and the sync dialog now say "Over USB this installs : ". So the slim USB package can go ahead, with lagsBehind set and a lagReason written for players.

@Zac-Kyoti

A second report, #1177, settles the OTFX question: on a card build with FM Synth 0.1.2 and Mute Modes 0.2.1, every mute mode except plain OT lets FM Synth's notes through, so OTFX leaks as well as the -T modes, and on card builds as well as over USB. @Zac-Kyoti @timhastie, since card builds have no base events, ev_trig_muted alone won't cover them.

Right, ev_trig_muted can't reach card builds. On my own line (2.19 onwards, in v2.21) the engine handles this natively when Mute Modes is in the build. It reads Mute Modes' MUTE MODE word and mute state, drops the note in DT-T and OTFX-T, cuts a sounding note at the OTFX-T edge, and ends voices at STOP. FM Synth 0.1.4 leaves that code out on Modwerk because of the rule that a module may not read another module's code or data. On a card build every trig therefore still plays.

I see four ways to close the card half:

FM Synth's card build reads Mute Modes' two words directly, with my existing code. POLY8's composition recipe already does something similar with Mute Modes. This needs your ruling under the no-dependency rule, and Zac's agreement that those words are a stable interface.
A card-build counterpart of ev_trig_muted in the shared SDK, which Mute Modes answers and FM Synth calls. That means one SDK PR plus a release of each module. I can write my side.
Mute Modes clears the trig's START bit itself in the -T modes. Only Zac's module changes, but every mode needs re-testing.
Ship 0.1.4 as it is and document MUTE MODE OT for FM tracks for now.

I'd suggest 1, or 2 if you'd rather keep modules apart. Which do you prefer?

On #1177's OTFX leak: in my emulator tests OTFX stays silent on my line, so I'd like to reproduce it with the reporter's exact module set first.

@Zac-Kyoti

Thanks Tim, four clear options.

Option 1 is out, sorry: under the no-dependency rule a module can't read another module's words, even stable ones. Let's take option 2: a card-build counterpart of ev_trig_muted in the shared SDK, in its own SDK pull request first, the same way as the shared scale file on #1145. Mute Modes answers it, FM Synth asks it, and with either one missing nothing changes. If you'd like to write the SDK part, go ahead and tag me.

Meanwhile 0.1.4 ships as it is (option 4), with a note that FM tracks on card builds need MUTE MODE OT for now.

@Zac-Kyoti, are you OK with Mute Modes answering it, on card builds through the SDK and over USB through ev_trig_muted? And Tim, reproducing #1177's OTFX leak with the reporter's set first sounds right.

@repeat98

@repeat98 @timhastie Yes, Mute Modes will answer it: on card builds through the SDK counterpart, and over USB through ev_trig_muted. Three things from my side:

The same test as mm_voice_bind. The answer will be exactly the per-track test Mute Modes' ev_voice_bind handler makes (fresh_bind): muted or soloed-out tracks in DT-T and OTFX-T, less a SIDE-CHAIN key track (KEYMASK/KEYHOLD). That way the two can never disagree about which trigs are dropped.
One Mute Modes release with Octatrack base: PERSONALIZE rows as a base table (ot_personalize_rows), so table owners no longer pin package hashes #1023. Octatrack base: PERSONALIZE rows as a base table (ot_personalize_rows), so table owners no longer pin package hashes #1023 also changes Mute Modes (its PERSONALIZE row contribution), and until it lands every Mute Modes source change means a new table-owner declaration and base. I'd like to ship the ev_trig_muted handler and Octatrack base: PERSONALIZE rows as a base table (ot_personalize_rows), so table owners no longer pin package hashes #1023's row in one release (0.2.3), so there's one declaration, one base and one review. I'll write our side once the card-build SDK contract is up; please tag me on that PR.
It covers DT-T and OTFX-T, not [mute-modes] Mutes dont work with fm synth tracks #1177's OTFX leak. In OTFX, Mute Modes doesn't drop trigs; it zeroes the track's gain words every frame. So its answer for those tracks is "not dropped", and the leak [mute-modes] Mutes dont work with fm synth tracks #1177 reports needs its own explanation. Tim, once you have the reporter's exact module set I'm happy to run the same emulator check as the table above on it. Also still open from the first post: with a muted track in DT-T/OTFX-T, stock's voice reset at 0x40006820 is skipped, and the synth's po_kill with it. So STOP on a muted FM track at HOLD INF is worth a check with the fix.

Until both releases are out, MUTE MODE OT remains the workaround for FM tracks.

Thanks both. I checked #1177 with the reporter's exact set: my build matches their fingerprint, 9de69b8c…. I ran it in the emulator on an MKI, on FM Synth 0.1.2 and 0.1.4, muting an FM track and a Flex track with FUNC+track while playing.

OT and OTFX: the FM track goes silent at the mute in every run, including with a delay and with an LFO on AMP VOL. Delay tails ring out the same as on the Flex track.
OTFX-T and DT-T: every muted FM trig still plays at full level. In OTFX-T, a note already sounding at the mute also keeps ringing, while the Flex note is cut.

An image with only Synth 0.1.2 and Mute Modes 0.2.1 behaves the same. So I can't reproduce the OTFX leak, which matches Zac's point 3. My guess is that the reporter was in OTFX-T (the menu order is OT, OTFX, OTFX-T, DT-T) or was hearing FX tails. Jannik, could you ask them which mode it was and which FX are on the FM track?

The SDK part is up as #1312. Zac, there's one thing in it for you. Dropping new trigs doesn't end a note that is already sounding at an OTFX-T mute, so the PR adds a second byte for "cut the sounding note now". I'd like your OK on that. On your STOP point: with prototypes of both sides, a muted FM note at HOLD INF ends at STOP.

Navigation Menu

Repository navigation

[synth × mute-modes] FM Synth plays muted trigs in DT-T / OTFX-T (reproduced): synth starts notes from the START bit before Mute Modes' trig gate #777

Result

Why

Fix options

Meanwhile

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

[synth × mute-modes] FM Synth plays muted trigs in DT-T / OTFX-T (reproduced): synth starts notes from the START bit before Mute Modes' trig gate #777

Description

Result

Why

Fix options

Meanwhile

Activity

timhastie commented on Oct 24, 2026

repeat98 commented on Oct 25, 2026

timhastie commented on Oct 26, 2026

repeat98 commented on Oct 26, 2026

timhastie commented on Oct 26, 2026

repeat98 commented on Oct 27, 2026

timhastie commented on Oct 28, 2026

repeat98 commented on Oct 29, 2026

repeat98 commented on Oct 30, 2026

timhastie commented on Oct 30, 2026

repeat98 commented on Nov 1, 2026

repeat98 commented on Nov 3, 2026

timhastie commented on Nov 6, 2026

repeat98 commented on Nov 7, 2026

Zac-Kyoti commented on Nov 7, 2026

timhastie commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions