You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Revert La32Ramps default on the MAME-backed core; keep it on native only
Owner's live-DAW report: D110EmulatorNative plays cleanly, but D110Emulator (MAME-backed)
sustains notes forever and freezes the LCD's part-sounding indicator, reproducible on the very
first note of a session on either Fantasy or Steel Drum, every time.
Root-caused with a new probe (plugin/mame_stuck_note_repro.cpp - fresh D110AudioProcessor
instances, matching the owner's own repro of two separate plugin launches rather than a tone
switch inside one session): 100% reproducible on the very first note-off after every cold
boot, regardless of tone or how long the plugin settles before that note. A direct control
(same boot/tone/note sequence, StuckPolicy forced to La32Stub vs La32Ramps) proves this is
caused by today's La32Ramps changes to D110Core.cpp specifically - La32Stub is clean 12/12,
La32Ramps fails only the very first note-off, consistently.
Temporary instrumentation ruled out the obvious suspect: the new dispatch-ack code added to
D110Core.cpp's midiTick() never once triggers during a failing run (the CPU never reaches
kStuckLoopPc for this note), and the ramp-landing sequence looks identical in shape between a
failing first note and a succeeding later one. The actual mechanism is not yet isolated -
likely some interaction between La32Ramps' faster/more eager EXTINT responses and the MAME
machine's own real-time boot sequence, which the synchronous, thread-free native core has no
equivalent of.
Rather than continue chasing this today, PluginProcessor::setPoweredOn() now sets La32Ramps
only under D110_NATIVE_CORE (proven clean: native_ramp_edge_stress_probe.cpp,
native_polyphony_stress_probe.cpp, and now weeks of the owner's own DAW use); the MAME-backed
core keeps the long-proven La32Stub default. Root-causing the MAME-specific regression is a
separate, not-yet-done follow-up - mame_stuck_note_repro.cpp is kept as the regression check.
Also added a guaranteed-visible mention of the 128-voice polyphony extension to the panel's
right-click options menu, alongside the existing UTILITY-tab writeup - the owner couldn't find
the original UTILITY-tab-only text (that tab has no scrolling, and it may have been clipped).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>