[tap]

The rest of plan item 9.0: #43 ran the spike on a Mac; this runs it on Windows and writes the results into docs/TAP-PYTHON-PLAN.md under 9.0. Every question has the same answer on both platforms, so 9.0 is ticked in both plans. Nothing is tagged, and no shipped code changes.

Where it ran

• Max 9.1.5, the same build commit as the Mac's (3db35fa), on Windows 11 Home x64 in a Parallels VM on the same Mac.
• The spike built with MSVC (Visual Studio 2026, CMake 4.3.1) with no warnings, and the glue test passes. The external was built with -DTAP_PYTHON_SPIKE=ON, which stays off by default.

What Windows showed

• Q1, finding the object: in a fresh Max, the init/ mapping finds [tap.python]; without the mapping, Max says No such object. Both objects load in either order, from the .mxe64. No stub external is needed.
• Q2–Q4 and Q6: every logged line matches the Mac's:
  • outlet insertion and deletion keep the dumpout last and every cord that stays;
  • get<attr> works with the class's dumpout method, here registered through an import stub address;
  • dispatch order, and every object_getmethod() answer, match the Mac. Max's method_false() isn't the module's own address on Windows, which 1.0.2's guard already allows for, so the guard works unchanged;
  • the string results.
• Q5, threads: the same table as the Mac, with the MME driver at 44.1 kHz. A metro-driven message runs on the main thread with Overdrive off, on the scheduler thread with it on, and on the audio thread with Scheduler in Audio Interrupt on and audio running.
• Q7, documentation: on the Mac, Max itself now shows an extras/ patcher in the Extras menu, and PythonTap in the Documentation window's Package Docs. Which tab lists which file is left to 9.4. On Windows the file database was still scanning when Max was stopped: in this VM, Windows' Documents folder is the Mac's, so Max indexes every Mac package over the shared folder. windows.txt says the query is incomplete.

In the PR

• runtime-tests/spike/run_spike_windows.ps1: the Windows counterpart of run_spike.py, which needs the macOS-only harness.
  • Each patcher runs in a fresh Max. A starter patcher waits for Max to finish starting up, opens the patcher under test, and then sends ; max clean; max quit. Without the wait, a patcher opened together with Max had its timers held for seconds after loading.
  • It reads Max's own log and writes results/windows.txt.
  • It turns off "Restore Windows on Launch" for the run and restores Max's preferences afterwards.
• The Q5 patcher now proves audio ran, using [dspstate~], and gives the audio driver time to start. A first Windows run, which didn't check this, showed no audio thread. results/macos.txt was regenerated with the same patcher.
• results/windows.txt: the evidence.
• The plan:
  • 9.0's verdicts, and "What 9.0 found" covering both platforms;
  • the init/ mapping noted as verified on both, so the stub fallback is dropped;
  • the 9.4 item updated for what Max's windows showed;
  • Windows notes for 9.5 and 9.6;
  • a revision-record entry;
  • 9.0 ticked in PRODUCTION-PLAN.md.
• CLAUDE.md: the guard note now says "on both platforms".
• The README explains the Windows runner, and why it installs into C:\ProgramData\Max 9\Packages (in this VM, Windows' Documents folder is the Mac's, and the test shouldn't touch it).

A slip in this branch, fixed within it: one commit recorded init/tap.python.txt as deleted, because it was made while the Mac runner had the file moved aside. The next commit puts it back, and the branch's diff against main doesn't touch it.

Checked

• Windows: the spike build has no warnings, and the glue test passes with support\ on PATH, as in CI.
• Mac: the full suite was rerun, and ctest passes with the shipping (spike-off) build.
• Both runners put Max's preference files back. Overdrive and Audio Interrupt are off as before on both machines.

🤖 Generated with Claude Code

https://claude.ai/code/session_019rVV9SkjkWmiBXFMT4whkz