Add real-time octave transpose

[appdess]

What changed

• adds an open-source real-time transpose stage from -12 through +12 semitones
• preserves the existing parameter order and saved-session compatibility by appending the 0.2.0 Transpose parameter
• adds the large minus/value/plus control and host automation support
• integrates the processor into the standalone app, Audio Unit, and VST3
• records MIT lineage, rejected-prototype evaluation, and exact local validation evidence

Why

Guitarists can play along with songs in another tuning without retuning the instrument. Zero semitones returns to
the exact dry path after the short transition.

Validation

• core/model suite
• malicious/truncated WAV parser suite
• 0.1/0.2 state migration suite
• transpose tests across every semitone, 44.1/48/88.2/96 kHz, automation, block sizes, onset behavior, exact-zero
  dry output, and zero render-thread allocations
• unsigned universal APP/AU/VST3 package from clean feature commit 0b6cca8
• strict and stress AU validation plus offline render
• Steinberg VST3 3.8 extensive validator: 537 passed, 0 failed
• exact staged AU byte-matched the AU exercised in Logic Pro
• Logic save/quit/reopen persistence at +12, playback at both octave extrema, and final project state reset to 0

Security-gate demonstration

This is intentionally a ready PR so the trusted pull_request_target dispatcher can invoke the protected Codex
Security workflow through GitHub OIDC/WIF and upload SARIF to the PR merge ref.

The security result is deliberately part of the merge decision rather than a detached report. A valid scan uploads
SARIF first so any finding remains visible in GitHub, then enforces the configured policy. A scanner, authentication,
or result-integrity failure also fails closed. Do not merge while a blocking alert or required result is unresolved.

Merge acceptance criteria

• Open-source/original transpose implementation covers every integer step from -12 through +12.
• Zero semitones returns to an exact dry path after the transition, with no render-thread allocation or added
  look-ahead latency.
• APP, AUv2, and VST3 builds are universal and expose compatible 0.2.0 state/automation.
• Legacy 14- and 20-parameter sessions migrate without changing existing parameter IDs or the hidden amp alias.
• The exact staged AU byte-matches the AU exercised in Logic Pro.
• Logic playback is finite and non-silent at both octave extrema, and +12 survives save, quit, and reopen.
• The untouched Logic original and the DessMetal demo copy remain side by side.
• MIT lineage and the full upstream notice are included; rejected prototype code is not shipped.
• Attach a privacy-safe Logic/DessMetal screenshot showing the working plug-in and transpose control.
• Render the same solo-guitar excerpt through the exact Logic-hosted AU at 0 semitones and at the selected shifted
  value; attach both audio files to this PR.
• Verify both renders are finite, non-silent, unclipped, equal in duration/sample format, and measurably shifted
  by the requested interval without changing tempo.
• Record the exact project copy, track, region, plug-in hash, transpose values, and audio SHA-256 values in the PR.
• Both required macOS CI jobs pass for the final head.
• Codex Security scans the generated PR merge commit through the protected OIDC/WIF workflow and publishes its
  SARIF result under the Codex Security tool identity.
• Review every Codex Security alert raised on the current head and preserve the native blocked-merge evidence.
• Remediate blocking security findings in a separate commit, add focused regression coverage where applicable,
  and prove the alert fixed rather than dismissed through a clean SARIF rescan.
• No Code Scanning alert introduced by this PR remains open, and the native security gate is green on the final
  head.
• Rebuild and verify the unsigned APP/AU/VST3 package from the exact final clean commit after all documentation
  and remediation changes.
• Owner performs the final subjective listening check for tone, feel, and mix translation before merge.

This PR must remain unmerged until every unchecked item above is resolved or explicitly accepted by the owner.

[appdess]

Logic end-to-end acceptance evidence

Recorded with Logic Pro from the exact project copy:

• project: melodic-core-DessMetal-0.2-demo.logicx
• source: soloed audio track lead1, bars 1–41
• plug-in: installed Audio Unit, byte-identical to staged 0.2.0 AU
• AU executable SHA-256: 0b0c37436e79e0af3ae8e2e49abf62f60ed319386462df99112d2e77c74b051d
• render: Logic offline bounce, 48 kHz, 24-bit stereo WAVE, normalization off
• comparison excerpt: the same source interval, seconds 12.000–24.000
• settings compared: Transpose 0 and Transpose -4; amp/drive/cabinet and all other settings unchanged
• after capture: Transpose restored to 0, track solo removed, project saved

Objective checks

Check	Transpose 0	Transpose -4
Duration	12.000000 s	12.000000 s
Sample format	48 kHz stereo	48 kHz stereo
Finite/non-silent	yes	yes
True peak	-20.1 dBFS	-19.0 dBFS
Integrated loudness	-31.7 LUFS	-31.5 LUFS
MP3 SHA-256	2557d74445586f14ec1cb1cf3f426bb1d7f0c33732a5cc6ffc0e982b197fc8b6	2ca1161ea4a300ebd7883f6de7e26e1d0e28292e0e7c6a45223b7d9096824027

Both PCM excerpts are finite and unclipped. Their amplitude-envelope correlation is 0.863296 with best lag 0.000000 s; both produce the same 127.840909 BPM analysis estimate, so the event timing did not move. Chroma comparison selects -4 semitones (the equivalent modulo-octave rotation is +8) as the strongest match with score 0.943762.

The screenshot is limited to the Logic plug-in window and visibly records the -4 state. These measurements establish correct signal, interval, timing, and headroom; subjective tone/feel remains the owner listening gate.

[DessMetal-Logic-lead1-transpose-0.mp3](https://github.com/user-attachments/files/30664177/DessMetal-Logic-lead1-transpose-0.mp3) [DessMetal-Logic-lead1-transpose-minus-4.mp3](https://github.com/user-attachments/files/30664178/DessMetal-Logic-lead1-transpose-minus-4.mp3)

[appdess]

Controlled Codex Security canary — failing gate captured

The isolated canary has produced the intended native blocking evidence before remediation:

• PR head: f50edc9fed1585703104c6d592c5b230e60523f9
• generated PR merge commit scanned: b161a58d4dde608afe9a2d5f1bb6abd149126e33
• protected scan: run 30818994013
• native alert: Code Scanning alert #6
• rule: unsafe-deserialization.pytorch-checkpoint, severity Error
• affected code: trainer_source/remote_checkpoint_summary.py:18-22

The trusted workflow first passed its immutable-input checks and GitHub OIDC/OpenAI WIF proof. It then completed the
report-only scan, validated the sealed output, exported SARIF, and uploaded the Codex Security result to
refs/pull/7/merge. Only after retaining that evidence did enforcement fail with POLICY_RESULT=fail and
BLOCKING_FINDINGS=1.

GitHub now shows the Codex Security check as failed and explicitly says Merging is blocked because one alert is
blocking the PR. The two required macOS jobs remain green, which isolates the block to the security finding.

Remediation choice

The remote-checkpoint summary utility was introduced solely as the controlled canary and has no product requirement.
The smallest and safest fix is therefore to delete that unnecessary remote-download/deserialization surface in a
separate commit, rerun regression tests, and let the protected scanner prove the alert fixed and the native gate green.

[appdess]

Superseded by #8 so the current feature and merge-gate validation run in a fresh pull-request analysis context. PR #7 remains closed as audit evidence; it was not merged.