A song could only be filled with sounds that were made somewhere else.
Record plays the song from the cursor and takes the input meanwhile, so
a part played along lands on the bar it was played to.
- An audio worklet takes the input's samples on the clock the song
plays on. Each run carries the frame it was taken at, so the take is
cut where the song was heard to start. The output's and the input's
latency are taken off, as far as the browser reports them.
- The take goes up as mono 16-bit WAV. Sound, a new track "Recording"
under the track clicked last and the item at the cursor are one undo
step. The sound is named "Song – Take 1", 2, 3 and so on.
- While recording the take grows red with its waveform on its track,
and a meter beside the input dropdown shows the level. The lanes take
no edits then, only a middle-drag pans.
- The loop is not used while recording. The song plays once through
and on past its end until Stop, Play or Space keep the take. Esc
throws it away and nothing goes up.
- Echo cancelling, noise suppression and auto gain are off, nothing is
played back. The input picked is kept in localStorage.
- A take stops by itself at the size a sound may have. A failed upload
offers Retry, Download WAV and Discard.
- The API takes sounds up to 256 MB and bodies of the same size. nginx
and PHP were raised to match outside the repo (body 256m, upload and
post 256M, memory_limit 512M).
- The pure rules (cut, cap, WAV header, name, track) live in
core/music/take.ts. The scheduler tells where it started on the
audio clock.
- The e2e browser gets chromium's fake microphone and skips the
permission prompt. Each run leaves its take in the sound store.
Found on the way:
- The header was too full with the new widgets and cut the track and
item count on the right. Input dropdown and meter are narrower now.
Tests:
- Unit take.test.ts: 7 new, svg-icons adjusted to 8 toolbar icons
- e2e 65 (melektaus-atx): ALL PASSED – 31 checks (+4)
- Gate (melektaus-atx): CHECK EXIT 0, 252 files, 3923 tests
- Probe on stein2: a 3 s take of the test tone, peak 32767,
285100 bytes, waveform seen in the screenshot
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
stein2 should stop carrying the full e2e run. The new runner lives in
the WSL2 distro game-maker-ci on melektaus-atx and uses the same image
and fonts. Its GPU sits behind /dev/dxg and Mesa's d3d12 driver, which
headless chromium cannot reach, so the harness gets a second way to
start the browser.
- GAME_MAKER_BROWSER=wsl starts an invisible Xvfb and an X11 chromium
on ANGLE/GL. Without the variable, stein2 keeps the headless Vulkan
launch exactly as before.
- The harness logs the renderer and stops on software rendering.
Under WSL a missing d3d12 driver falls back to llvmpipe, which still
offers WebGL 2 and would pass unnoticed.
- The CI image gains xvfb. The font set is unchanged: fc-list gives
the same 149 fonts with the same hash.
- ci.yml runs both jobs on the new label game-maker-wsl. The stein2
runner keeps game-maker-ci, so moving back is one line per job.
Findings:
- Wayland on weston reached the GPU too, but drew at about 40 fps and
let the editor clock stall in long runs (GM_STEPS=1-17: 2 failed).
- Vulkan through a self-built dzn caps ANGLE at ES 2.0 because
VK_EXT_provoking_vertex is missing, so chromium drops the GPU.
- The flaky check in e2e 41 (#282) fails more often under WSL: two of
three solo runs were red.
Tests:
- ./check.sh: 195 files, 2823 tests passed
- WSL container, GM_STEPS=1-17: ALL PASSED, 553 checks
- WSL container, full run: 1589 of 1590, the one FAIL is #282
- WSL container, smokes: 24 / 19 / 21 checks
- stein2 headless, e2e 39+40: ALL PASSED, 100 checks
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sounds follow the road fonts already paved: the file goes to the server
content-addressed under its sha256, the project keeps a named asset that
points at it, and nothing is ever re-encoded. The format is read from the
file's own signature, not from what the browser claims - the same .m4a
arrives as audio/mp4, audio/x-m4a or as nothing at all.
Playing is two nodes. "Play sound" takes the asset and may raise or lower
its volume; every call is its own voice, so two jumps in a row are two
jumps heard. Its loop input is a choice of three - from the asset, on,
off - because a checkbox has to spend one of its two positions on "not
set" and would lose a case: an asset that loops could then never be
played once.
Below the graph core stays browser-free: NodeContext hands out an asset
id, BehaviorSystem resolves it against the project and folds the asset's
own volume and loop into the call, and only viewport/SoundLibrary knows
about Web Audio. A run without a sink plays nothing instead of throwing.
The CI browser is muted, so the ear is no witness: the debug hook counts
started and stopped voices, and step 34 reads that counter.
- `.gitignore` said `index.html` unanchored, which also caught the Vite source page;
a fresh clone could neither `dev` nor `build`. Anchored to `/index.html`, page added.
- Removed GM_REMOTE (tools/remote/gm-browser.ps1 and the ssh/scp branch in browser.mjs):
the Windows test machine is gone and the only flaky check that lived on it is closed (#37).
- Removed `npm run preview`, undocumented and unused.
- Comments: wrong number in collider.test.ts (250 → 200), the "declarations used to…"
history in listItems.ts and friends, the 24 px/28 contradiction, section banners in
nodes/index.ts, node-catalog.test.ts and api/index.php, name paraphrases, and the stale
step numbers in tools/e2e/11-…23- from the old global count.
- README: asset types include `animation`, kind order Number/Text/Boolean, tagged colour
and texture items, 6/5 kinds, the `Texture` node, `./build.sh`, PROJECT_FORMAT_VERSION,
and the file tree (kinds.ts, listItems.ts, propertyPorts.ts, Breadcrumb.ts, beads.ts,
tools/assets/).
- tests/helpers.ts takes the duplicated `findObject` and `sceneWithCamera`.
Proof: ./check.sh 797 tests, full e2e ALL PASSED 633 checks against this bundle.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Split GraphCanvas (1076 -> 831 lines) into EdgeLayer and graphMenus;
the port and marker menus were the same list and are now one function.
Value specs of the inspector and the list tab share valueSpecs.ts, and
the remaining copies (compound commands, type glyphs, typed asset
lookup, name rule, play/editor world setup, marquee) are merged.
Four copies had already drifted apart; merging them fixes:
- "Disconnect N links" in the port menu is one undo step, not N
- "+ Add collider" is hidden on a placed container instance, as in
the hierarchy menu, instead of always failing
- a bool property coerced from the text "false" becomes false
- a port command on an unknown node type reports instead of crashing
Comment-only edits leave the bundle byte-identical. README corrected in
35 places (step limit, jump-run clock, suite duration, 409 body, ...).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both shutdown paths ran Get-Process chrome,msedge | Stop-Process -Force,
which is every browser on the machine. The remote host is somebody's
desktop: a test run must not close the windows they are working in. It
only stayed harmless because the test account cannot touch another
user's processes.
The launcher now writes its browser pid to %TEMP%\gm-browser-<port>.pid
and kills that pid; the job object still takes the renderer children.
Measured against the Windows desktop: five msedge processes belonging to
the logged-in user before the run, five after, and our chrome gone.
24 smoke checks ALL PASSED.
The leash that ties the Windows browser to the run never held. Three
findings, each measured:
- stdin is not a signal: only the first chunk a caller writes reaches
the remote command, so the stdin heartbeat looked like a dead caller
and killed a run at check 44.
- a dropped SSH connection does not kill the remote command; Windows
OpenSSH leaves it running. Six orphaned chrome.exe survived a
SIGKILLed tunnel -- this is what locked up the desktop.
- Get-NetTCPConnection goes through WMI, which is denied to the
non-admin test account; the broken CIM session took a browser down
mid-run.
The launcher now watches the forwarded CDP port with .NET sockets: a
connected client means the run is alive, 45 s without one ends it. A job
object with KILL_ON_JOB_CLOSE and a 30-minute cap catch the rest, and
the caller shoots the browser on the way out instead of waiting for the
idle window.
Measured: survives 80 s of an idle held connection, gone 44 s after
kill -9 on node, immediately on an ordered end. Full suite 267 checks in
128 s and 24 smoke checks in 16 s against an RTX 4070, with this machine
at load 0.04.
The harness forced software WebGL (--disable-gpu --use-gl=swiftshader) on every host.
Measured here on an idle editor page over 20 s: that costs 373% of a core at 8 fps,
while the Intel HD 630 via ANGLE/Vulkan costs 69% at 56 fps. The full suite now runs
in ~124 s. Note the app is not rendering 60 fps as previously assumed - in software
it only reaches 8, and a single frame costs more than any throttle interval would save,
which is why capping the framerate had measured no effect.
--use-angle=gl and --use-gl=egl look cheaper still but get no WebGL context at all,
so the app never renders. They are not usable and are named in the comment as such.
There is deliberately no software fallback: a host without a usable GPU should fail
loudly rather than drag the machine to a standstill. None of the 267 checks reads the
rendered image anyway - they read window.__gm.locate() and the debug hook, and the
screenshots assert nothing - but Pixi needs WebGL2 to run at all.
The browser launch moves out of harness.mjs into tools/lib/browser.mjs, which also
supports GM_REMOTE=user@host via an SSH-forwarded CDP port. That path is unfinished:
the tunnel degraded until the suite crawled at ~25 s per check, and forcing software
WebGL on a desktop with a real card brought it to its knees. README says so plainly
rather than advertising it.
Also: the jump-run HUD check asserted a fixed "Coins 1/10", which fails on a faster
host where the same walk sweeps up two coins. It now asserts the HUD against the count
the run actually reached - the real guarantee is that HUD and state agree.
Verified: npm run check green (404 tests), 267 e2e ALL PASSED and 24 jump-run checks
ALL PASSED against the GPU flags. The fallback removal leaves the flag set on this host
identical (same flags, different order), so it was not re-run.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
adminandClaude Opus 5.5