[xbraindance]

Skip these:

Ignore the local service manual and header image

Ignore local Waldorf resources (Sounds, System, Tools and their zips)

[mo0kid]

The release I just published already fixed a fair few of these issues. Let me check through your work and see what you've done that I've missed. Thank you

[mo0kid]

Thanks for putting this together. I’ve reviewed it against 0.1.12, and there are several useful additions here, particularly the firmware-path guard, voice-board memory-map corrections, modulation-table details and tracing tools.

Before integrating anything, could you clarify a few points?

• Voice allocation: our audio engine already reuses released voices before stealing held notes, with a regression test covering held chords. Firmware ASIC/CV writes currently update diagnostic storage rather than drive audio voices. Have you demonstrated an audible benefit from the OS 1.700 patch in this emulator?
• Reconstruction test: your new test expects +3.66 dB at 8 kHz, but our current implementation measures −1.00 dB. The 20/30 kHz expectations also differ substantially. Was an accompanying DSP change omitted? Could you include derive_wvc_input_network.py and its schematic derivation?
• Memory map: could you provide the supporting address references and reproducible checks for the wave RAM and shared SRAM corrections? These look worthwhile, especially preventing voice-board writes from reaching master memory.
• Research evidence: could the non-proprietary specifications and oracle scripts be included or linked publicly? The document still describes the allocation bug as unlocalized, which appears inconsistent with the later patch.
• Audio Out and Start modulation: your document identifies both as remaining mismatches. Do you have focused reproduction cases or tests we could use to verify them?
• Three-bit levels: is there any hardware capture supporting the proposed gain scaling, beyond the firmware register layout?

I also noticed WaveVoiceTrace appears to return success if its script cannot be opened. That should probably report an error.

The branch now conflicts with 0.1.12 in the README, editor and core tests. Would you be happy to split the firmware fixes/tracing and tabbed interface into separate PRs against current main? We’ll skip the two ignore commits as requested.

[xbraindance]

Thanks for the careful review. Answers in order:

Voice allocation. No, we haven't shown an audible benefit and we won't claim one. The fix is a one-byte patch to find_free_voice (0x2EAC, byte 0x2EE2, 0x65→0x60). It removes the firmware-level steal bug, which the oracle script gate_f reproduces against OS 1.680. You're right that this emulator doesn't consume those writes, and that chooseVoice already prefers inactive and released voices over held ones. The patch is opt-in, off by default and hardware-unvalidated, and its only test checks that it applies and reverts. We're happy to drop it or keep it labelled experimental, whichever you prefer.

Reconstruction test. Yes, the DSP change was omitted. The test landed in 7857e34 without the rewrite it was written for, which is why it fails on current main. The rewrite and scripts/derive_wvc_input_network.py are now in a separate PR: xbraindance/wave#6 · Model the WVC input network and…. On top of main, the build and all 4 test suites pass. The script derives the response from the p.47 component values and reproduces the test's +0.26, +3.66, −1.93 and −8.05 dB at 1, 8, 20 and 30 kHz. One caveat: the p.47 scan can't settle whether R4003 is 180K or 100K. The script uses 180K. At 100K the gains become +0.06, +5.19, +0.62 and −5.29 dB, so the 20/30 kHz values move by about 2.5–3 dB. A better scan or a measurement would settle it.

Memory map. The changes are in the wave RAM and shared SRAM commits, with testVoiceBoardWaveRamDecode (about 35 lines in WaveCoreTests.cpp). Wave RAM A and B are at 0x040000 and 0x050000, with a write-both alias at 0x060000. The shared SRAM is 512 KB at 0x100000–0x17FFFF. The test checks that stores to wave RAM never reach master memory. The address references are in waldorf-wave-firmware-reverse-engineering.md, lines 53, 75 and 89–90.

Research evidence. The full firmware map and the oracle scripts are built from the firmware binaries, so we can't publish them. The "not localised" wording was stale and is fixed in xbraindance/wave#5 · Merge WDV fixes and Audio Out….

Audio Out and Start modulation. The fix is in #5. Audio Out now reads part byte +0xC instead of +8, with 0 = Aux only, 1 = main and 2/3 = sub. testPerformanceAudioOutRouting checks that only value 1 reaches the main mix. The start modulation change has no test and is checked against the oracle only. Note the behaviour change: three parts in pg.set and ultimate.set have +0xC = 0 and now leave the main mix.

Three-bit levels. No hardware capture supports it. What we have is static: the level words reach only the ASIC writer, and reg 4 carries 3 bits per level. The gain law of that 3-bit code is unknown and needs an 8-step capture of a real unit. The model stays opt-in until then.

WaveVoiceTrace. Agreed, and fixed in #5 (e9fe4af). A script that can't be opened now prints an error and exits 2, instead of returning success with empty output.

Splitting and conflicts. #5 has the firmware fixes and tracing, and #6 has the reconstruction change. Neither includes the tabbed interface, and we'll leave out the two ignore commits. Both PRs are against the current origin/main (f815546), which doesn't have 0.1.12 yet. Once 0.1.12 is pushed we'll rebase, and we expect the conflicts to be in the README, editor and core tests.

[mo0kid]

Thanks for the clarification. That explains the reconstruction-test failure and helps separate the changes we should consider.

I’d prefer to leave the firmware voice-allocation patch out of this integration, given that no audible benefit has been demonstrated with our current engine. Please keep the reconstruction/DAC changes separate too; we should resolve the R4003 value and verify the DAC interpretation before changing the released audio model.

We’ve now independently investigated the three-bit levels by executing the authenticated WDV mixer and ASIC-writing routines across 9,600 input combinations:

• The firmware adds modulation to the base mixer level.
• It clamps the intermediate result to 0–112.
• It then discards the lowest four bits, sending codes 0–7 to the ASIC.
• This applies to Wave 1, Wave 2 and Noise.

So the eight-code encoding after modulation is confirmed by firmware execution. The remaining hardware question is the gain associated with each code.

We also found a modulation-scaling discrepancy that the proposed mask alone doesn’t address. With base mixer level 2 (stored value 32), volume modulation amount +7 (stored value 120), and a positive half-scale source value of 16384:

Implementation	Intermediate level	ASIC code
Original WDV firmware	81	5
Our current calculation with your proposed mask	75	4

Could you check this case against your oracle? It suggests we need to match the modulation scaling and integer rounding as well as the final quantization, including Noise.

The memory-map corrections, missing-path guard, tracing improvements and Audio Out correction look useful. For Start modulation, please add focused tests covering free start, fixed phase, positive/negative modulation and clamping. We can use locally supplied firmware for reproducible checks without including firmware payloads.

One repository clarification: 0.1.12 is already published and pushed. Our current main is c7b0b53. The f815546 base is your fork’s main and already incorporates the original combined changes.

Could you prepare clean branches against mo0kid/wave/main and submit the separated PRs here, keeping the tabbed interface, allocator patch and reconstruction work outside the firmware-fixes PR?

[xbraindance]

Thanks, all clear on scope. The firmware-fixes branch is based on c7b0b53 and contains only firmware-derived changes; the tabbed interface is a separate branch; the allocator patch and the reconstruction/DAC work are not included.

Your 3-bit level case: confirmed, and I found where our model differs. On the oracle (WDV 0x10A6 with 0x246C and the 0x25E8 table), base stored 32, amount stored 120, source word 16384 gives an intermediate of 81 and ASIC code 5, identical for Wave 1, Wave 2 and Noise. Our model gives 75 because it works in normalised 0..112 units: the firmware's modulation word is ((src * table[amount]) >> 16) * 2, then >> 8, so a full-scale source swings the level by up to +/-127 steps, not +/-112. 32 + 0.7656 * 0.5 * 112 = 74.9 against 32 + 49 = 81 (factor 128/112). Rounding is also integer: arithmetic shift of the word (floor), 16-bit add, clamp 0..0x70, then >> 4.

I wrote that as an integer model and swept it against the oracle: 18,576 combinations (Wave 1, Wave 2, Noise x 9 base levels x 43 amounts x 16 source words), 0 mismatches. So the final mask alone is not enough; the scaling and rounding need to match too. I have not changed the level model in this PR since you want the DAC/level interpretation settled first; happy to put the integer-exact version up as its own PR when you want it.

Start modulation has tests as requested. While writing them I found the map's "clamped to 1-127" was wrong outside the nominal range: Wave 1 compares signed (8-bit wrap), Wave 2 compares unsigned (anything outside 1..126 becomes 127). The engine now uses the firmware's integer arithmetic for the phase code; one caveat remains in how the engine scales its float sources (controller words are CC << 8 in the firmware), details in the PR.