Repository navigation
v0.7.2: GTLT, the t gate tilt (#20) - #47
Merged
Merged
Conversation
A Wakes-only parameter that tilts the HEIGHT of t1's and t3's gates around t2, which it never touches. Bipolar, 10 % centre detent = off. Just past the detent both gates ramp steeply to 50 % (SP1_GTLT_RAMP, 0.1 of each half); towards + t1 falls to 0 % and t3 returns to 100 %, towards - the reverse. Unsmoothed. ROTC returns it to the detent. Decided with Adara on the issue: - A gate stays 0 V / +5 V. +5 V is already the positive maximum of every destination a t output can reach, so no INTELLIGENT range is involved; GTLT scales the +5 V and the attenuverters do the rest. - TRIG ignores GTLT: it reads the raw gate bits, so rhythm stays predictable. Only LEVEL, FM, TIMBRE, MORPH and HARMONICS see the gain. A t output at 0 % still counts as patched, like a cable at 0 V. - MIDI: CC 89, 7-bit, centred (no 14-bit pair). CPU: the gain is folded into each route's scale in AddRoute, once per DMA block. AddRoute is now noinline: inlined, GTLT grew sp1_synth_render by ~1 KB and reshuffled its per-Plaits-block loop. As built, the render is +6 instructions, all in the per-block setup; the per-Plaits-block routing walk is the same instruction sequence as main (disassembly diff). At the detent the gain is exactly 1.0f, so the output is bit-identical to main. Image 427 260 B (main 427 644): the 28th MIDI parameter stopped GCC unrolling a loop in sp1_midi_main_tick (-672 B, main thread only); every other change is accounted for in a symbol diff against main. check_image PASS, 0 warnings, links at 0x20000. Fallback build clean. Host: routetest 12 (the curve and its continuity, LEVEL silenced at 0 %, TRIG edges identical with GTLT off and at +1 on a seeded sequence), uitest 18 (default, both ends, X SHIFT F1 still unbound, rip), miditest 16 (CC 89 both ends and back to the detent; CC 12 / 44 free). All nine suites pass. Not yet on hardware. UI-SPEC v0.17, UI-PAGES, DEFAULTS and MIDI.md updated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
firmware/VERSION, the README status line and the issue forms' version placeholder. Image 427 260 B, check_image PASS, links at 0x20000. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On the t page's track row a high gate is now lit at its GTLT height, from 5 % for a 0 % gate up to full (SP1_GTLT_LED_FLOOR), on every t output whatever it is routed to: a gate still firing TRIG at 0 % never goes dark (Adara). Low gates are off. The floor is GTLT's alone; no other LED changes, and on the detent every gain is 1, so the display is the old on/off one exactly. Same curve as the audio (sp1_gtlt_gain), so the LEDs cannot disagree with what Plaits receives. Main thread only: sp1_synth_render is unchanged in size; +208 B in the Marbles UI. uitest 19: detent = full, low gates dark, tilt +1 = 13 / 255 / 255, and t1's LED independent of its routing. All nine suites pass. Image 427 468 B, check_image PASS, 0 warnings, links at 0x20000. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Adara's updated manual. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Adara: a GTLT edit carried over into CLOK. Fader positions are low-passed (~64 ms), and when "••" came up the BASE layer took the still-settling position as its reference: the tail, plus a finger resting on the fader, was applied as catch-up movement to CLOK. Reproduced on the host: a GTLT flick then release moved CLOK by 27.8 semitones (PLAITS: a SHIFT F2 flick moved TIMBRE 0.50 -> 0.82 -- the same scheme, so the same flaw). Both UIs now lock each fader at a layer change: its new parameter takes nothing until the UNFILTERED position has moved CATCH_LOCK (3 %, Plaits' POT_STATE_LOCKING threshold) from where the finger was. Whether the fader tracks or catches up is decided at the change as before and not re-decided at the unlock (re-deciding against a moved fader left a tracking fader short of it -- caught by miditest_pickup takeover). GTLT's LED floor 5 % -> 8 % (Adara: too dim at the extremes). uitest 20: no bleed on either module, and a real move afterwards still works; it fails with the lock disabled. uitest 19 now presses "••" before moving the fader. All nine suites pass. sp1_synth_render unchanged; image 427 772 B, check_image PASS, 0 warnings, links at 0x20000. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
GTLT, the t gate tilt (MARBLES t SHIFT F1)
Closes #20. Decisions are in the issue comment.
••goes down or comes up, a fader's new parameter takes nothing until the fader has moved 3 % from where the finger is (Plaits'POT_STATE_LOCKINGthreshold). Without it, a GTLT edit carried into CLOK as••came up — the fader's smoothing tail plus a resting finger, 27.8 semitones in the host reproduction. PLAITS had the same flaw (SHIFT → TIMBRE) and gets the same fix.CPU
AddRoute, kept out of line so the render's per-Plaits-block loop compiles to the same instructions asmain; checked by disassembly diff).sp1-20261006-225513.log, v0.7.2 builds 22:21:57 and 23:06:27):rtewith Marbles running is 4.1–4.6 avg, the same as the pre-GTLT baseline (~4.2). Worst window 68.8 % avg,fail=0 rst=0throughout.pre/rte~46 %, present since v0.6.0).check_image.pypasses, links at0x20000.Tests
routetest§12: the curve and its continuity, LEVEL silenced at 0 %, identical TRIG edges with GTLT off and at +1.uitest§18–19: the fader, the rip, and the LEDs including the 8 % floor and independence from routing.uitest§20: no SHIFT → BASE bleed on either module, and a real move afterwards still registers. It fails with the lock disabled.miditest§16: CC 89 at both ends and back to the detent; CC 12 / 44 stay free.Seen in the log, not from this PR
A Marbles rip takes one block over budget: 99.25 % (
sp1-20261006-225513.log) and 105.67 % (sp1-20261006-232648.log,mrb44.7 % for that block), both on VA,fail=0 rst=0. The M4d re-seed rebuilds Marbles' generators — including 24 quantizer tables — inside the audio thread in one block. This branch does not touch that path; it is the first time a rip has been CPU-logged. Proposed as its own issue.🤖 Generated with Claude Code