SpaceAge Hardware Readiness

This is the compact architectural memory for portability and dedicated-hardware readiness. It records verified work and deliberately deferred scope; it does not mean that hardware implementation is underway.

Current Target

Windows x86-64 is the primary supported development and runtime target.
JUCE remains the primary application, audio, MIDI, and DSP framework.
Linux, ARM64, RK1, Turing Pi, Jetson, distributed DSP, and custom SpaceAge hardware are future possibilities, not current implementation targets.

Guiding Principles

DSP should avoid unnecessary dependencies on GUI components.
Real-time audio code should avoid allocation, file I/O, blocking operations, GUI calls, and other unpredictable work.
Project and preset state should remain independent of hardware topology.
Musical timing should remain sample-oriented where appropriate.
Platform-specific code should be isolated when doing so has a present benefit.
Existing working Windows behavior takes priority over speculative portability.
Do not prematurely introduce networking, remote DSP, cluster scheduling, or hardware-specific abstractions.
Every portability-oriented abstraction must also improve maintainability, measurement, real-time safety, testing, or behavior today.

Completed Work

2026-08-28 - Engine-neutral fixed-capacity motion curve

Files/components: Source/SpaceAgeMotionCurve.h and Tests/AudioSelfTest.cpp.
Changed: Added normalized 2-16 point MSEG storage, strict validation, and a prepared evaluator using only standard fixed-capacity data and mathematics.
Why: Establish reusable modulation mathematics without coupling it to a synth editor, destination units, project topology, or filesystem behavior.
Current benefit: One deterministic, testable curve language can serve future Redshift and app-wide modulation work.
Possible portability benefit: The core has no GUI or JUCE dependency and requires no allocation or lock during prepared evaluation.

2026-08-28 - Stateless MSEG loop and release mapping

Files/components: Source/SpaceAgeMotionCurve.h and Tests/AudioSelfTest.cpp.
Changed: Added validated loop/release indices and pure Forward, Ping-Pong, one-shot, and release-tail evaluation helpers.
Why: Keep polyphonic clock and note ownership in instrument voices while sharing only deterministic normalized trajectory mathematics.
Current benefit: Future engines can use identical loop and release behavior without duplicating state machines.
Possible portability benefit: Playback mapping remains standard-library-only, fixed-capacity, stateless, and independent of GUI or platform services.

2026-08-28 - Topology-independent MSEG route state

Files/components: Source/PluginProcessor.h, Source/PluginProcessor.cpp, and Tests/AudioSelfTest.cpp.
Changed: Added sparse immutable MSEG ownership per logical instrument slot and destination, with project and scoped lane-snapshot persistence.
Why: Establish musical ownership without encoding Mixer channels, devices, threads, or future hardware nodes into preset state.
Current benefit: Route data cannot leak between lanes or destinations and malformed curves are refused before publication.
Possible portability benefit: Saved modulation state remains independent of hardware topology and rendering placement.

2026-08-28 - MSEG patch and Motion Block persistence

Files/components: Source/PluginEditor.cpp and Tests/AudioSelfTest.cpp.
Changed: Added one validated sparse MSEG format to Redshift patches and Tone Motion Block version 5, with transactional parsing and legacy clearing.
Why: Reusable modulation must remain musical preset data rather than acquire assumptions about the machine that will render it.
Current benefit: Patch recall is deterministic and cannot inherit stale MSEG state or partially apply a malformed route set.
Possible portability benefit: The serialized curve describes only normalized musical state, not devices, threads, Mixer channels, or hardware nodes.

2026-08-28 - Redshift MSEG render integration

Files/components: Source/PluginProcessor.h, Source/PluginProcessor.cpp, and Tests/AudioSelfTest.cpp.
Changed: Connected immutable MSEG routes to Redshift Tone Motion while retaining per-voice timing and release capture.
Why: Prove that the engine-neutral curve can drive production audio without GUI dependency, mutable shared state, or topology assumptions.
Current benefit: Polyphonic MSEG motion is bounded, isolated, and continuous at note release.
Possible portability benefit: The renderer consumes prepared normalized data and explicit voice state suitable for later profiling on another architecture.

2026-08-27 - Redshift block-prepared render controls and measurement

Files/components: Source/PluginProcessor.cpp, Source/PluginProcessor.h, Tests/AudioSelfTest.cpp, and docs/Performance_Optimization_Rule_And_Impact_Report.md.
Changed: Redshift control data and source classifications are prepared once per audio block. A test-only same-process reference/optimized benchmark compares rendered signatures and timing without adding production instrumentation cost.
Why: Remove repeated real-time decisions and make DSP cost measurable while preserving exact audio behavior.
Current benefit: Lower custom-cycle CPU load, deterministic regression coverage, and evidence-based optimization decisions.
Possible portability benefit: DSP workload is expressed through prepared data rather than GUI state and can be characterized before choosing future hardware.

2026-08-27 - Hardware-readiness constraints documented

Files/components: docs/HARDWARE_READINESS.md.
Changed: Established this canonical, bounded record of current targets, verified concerns, validation, and intentionally deferred ideas.
Why: Preserve architectural intent across human and Codex contributors without expanding implementation scope.
Current benefit: Reduces contradictory refactors and documentation drift.
Possible portability benefit: Future platform work can build on recorded evidence and deliberate sequencing rather than assumptions.

2026-08-29 - Test-only portable FFT candidate

Files/components: Tests/ThirdParty/PFFFT, CMakeLists.txt, the convolution focused-test source, and third-party/performance records.
Changed: Pinned PFFFT to one audited commit and confined it to the Windows Release ConvTest target for transform exactness and performance measurement.
Why: The existing convolution profile attributes roughly 62-63% of the representative long-tail stage to FFT work, making backend evaluation more useful than speculative loop tuning.
Current benefit: Provides repeatable identical-workload evidence without changing any shipping SpaceAge binary.
Possible portability benefit: The candidate documents x86 SIMD, ARM/NEON, and scalar paths, but no non-Windows compatibility claim has been made.

2026-08-29 - Test-only portable non-uniform convolution scheduler

Files/components: the focused convolution tests and convolution, performance, and hardware-readiness records.
Changed: Completed exactness and timing gates for a 2,048-sample PFFFT tail and a combined 512-head/2,048-tail scheduler. Shipping targets remain unchanged.
Why: Validate the complete scheduling shape before introducing a new DSP dependency into production audio code.
Current benefit: The full Windows convolution suite now proves fixed, irregular, reset, stereo, and dual-room behavior for the candidate.
Possible portability benefit: The scheduler boundary can host an audited platform-appropriate FFT backend without coupling project state to SIMD details.

2026-08-29 - Explicit production convolution backend state

Files/components: the convolution DSP header, implementation, and focused host-matrix tests.
Changed: Replaced coupled selection flags with one typed JUCE backend state.
Why: Make backend ownership auditable before adding another implementation.
Current benefit: Prevents contradictory backend states and preserves exact JUCE fallback selection without changing audio behavior.
Possible portability benefit: A future FFT backend can be selected at the prepared-engine boundary rather than through platform checks in audio code.

2026-08-29 - PFFFT production source registered

Files/components: Source/ThirdParty/PFFFT, the dependency manifest, and third-party notices.
Changed: Added the exact pinned source and hash-locked every distributed file without enabling it in a shipping target.
Why: Separate legal and source provenance readiness from DSP activation.
Current benefit: Future adapter work cannot introduce an unregistered binary dependency accidentally.
Possible portability benefit: The retained upstream source includes x86, ARM/NEON, and scalar paths, while platform support remains unclaimed until built.

2026-08-29 - Dependency evidence boundary corrected

Files/components: dependency manifest and release-hygiene checks.
Changed: Confirmed canonical text hashing preserves receipts across LF/CRLF checkouts and delegated AKWF assets to their existing provenance inventory.
Why: Keep executable third-party code strict without misclassifying thousands of licensed audio assets as source-code dependencies.
Current benefit: All 21 dependency records verify and no executable third- party source is unregistered.
Possible portability benefit: Future platform builds receive an exact code dependency inventory independent of large content libraries.

2026-08-29 - Production-owned PFFFT partition engine

Files/components: SpaceagePffftBackend, convolution focused tests, and Windows shipping-target CMake integration.
Changed: Moved the validated 512/2,048 partition-history engine into the production DSP module and removed its duplicate test-only implementation.
Why: Establish one allocation-free implementation before any runtime backend can be enabled.
Current benefit: Uniform, long-tail, and combined non-uniform gates exercise production code with maximum differences no greater than 8.90e-08.
Possible future portability benefit: Transform and partition scheduling are isolated from GUI, project, and filesystem ownership behind a small DSP API.
Validation: Boundary safety and the complete Windows Release convolution suite pass. Runtime selection remains JUCE-only and preserves exact fallback.

2026-08-29 - Production-owned PFFFT combined scheduler

Files/components: SpaceagePffftBackend, combined convolution gate, and Windows Release shipping targets.
Changed: Added production ownership for the dual-room head/tail scheduler, bounded delayed-output rings, sanitization, counters, and storage reporting.
Why: Remove the final test-only ownership boundary before controlled runtime integration.
Current benefit: Production code matches JUCE within 8.90e-08 and compiles in the audio test, Standalone, and VST3 targets.
Possible future portability benefit: The complete candidate scheduler is a GUI-free DSP component with explicit preparation and bounded processing.
Validation: Full convolution suite passes; latest focused total-time ratio is 0.176. At this milestone runtime remained JUCE-only pending integration.

2026-08-29 - Controlled PFFFT runtime integration

Files/components: ConvolutionReverb, PFFFT scheduler, selector host matrix, and Windows Release targets.
Changed: Added explicit runtime selection with deterministic JUCE fallback; the default remains JUCE.
Why: Validate the complete production path before considering a default backend change.
Current benefit: Supported explicit selection renders within 4.47e-08 of JUCE and shares the same reset, diagnostics, and room-control path.
Possible future portability benefit: Backend policy is explicit and failure cannot silently replace working platform behavior.
Validation: Full convolution suite, audio test, Standalone, and VST3 builds pass on Windows Release. Saved-project profiling remains required.

2026-08-29 - PFFFT selected as supported-size default

Files/components: Reverb backend policy, saved-project CPU profiler, Audio Test, Standalone, and VST3 targets.
Changed: Supported shared-room sizes now prefer PFFFT; JUCE remains fallback.
Why: Four paired Basic Groove 5.sskit runs showed repeatable whole-project PFFFT/JUCE ratios of 0.824-0.832.
Current benefit: Approximately 16.8-17.6% lower measured project load in this fixture, with improved P95 and P99 callback costs.
Possible future portability benefit: Explicit backend policy retains a working fallback while allowing platform-specific performance validation.
Validation: Complete convolution suite and Windows Release Audio Test, Standalone, and VST3 builds pass; formats and controls remain unchanged.
Closeout: Removed the obsolete test-local scheduler so validation and runtime share one production implementation. Full release hygiene passes, including dependency receipts, notices, archive integrity, and clean-source packaging.
Profiler correction: Ordinary saved-project profiling now preserves the production backend default and records the selected backend on every row. A corrected run confirmed PFFFT (3) throughout; application behavior was not changed by this test-harness fix.

Known Portability Concerns

2026-08-29 - Production-owned PFFFT transform adapter

Files/components: PFFFT adapter, vendored source, focused CMake target, and convolution primitive gate.
Changed: Focused validation now compiles the production copy through an allocation-free prepared adapter.
Why: Prove the exact source and ownership boundary that could later ship.
Current benefit: Direct convolution remains equivalent within 1.40e-09.
Possible portability benefit: FFT setup is isolated from GUI and project state; non-Windows builds remain unclaimed.
Validation: The 512-head/2,048-tail scheduler now uses the adapter throughout; all exactness, irregular-callback, reset, and complete convolution gates pass.
Validation: Windows Release monolithic test, Standalone, and VST3 targets compile and link the inactive adapter. Standalone launch and VST3 host smoke pass.
Validation: Requesting the unavailable production PFFFT scheduler records a fallback and renders bit-identically through JUCE across a controlled impulse sequence. No platform-specific backend can silently replace working audio.
CinematicDrumsAudioProcessor currently owns or coordinates a broad range of DSP, state, assets, MIDI, project, and device responsibilities. This ownership concentration makes boundaries harder to test and extract incrementally.
PluginProcessor.h/.cpp and PluginProcessorMidiCompat.cpp contain many mutex- and CriticalSection-protected subsystems. Their presence is verified; whether each can interact with the audio callback still requires a focused call-path audit before any lock is labeled a real-time defect.
Sample, SoundFont, PCM, Quasar, Redshift-cycle, convolution, and project asset handling is spread across processor-level filesystem/state code. Portable asset identity and path assumptions need a focused audit rather than a rewrite.
Windows is the only presently validated build/runtime environment. No claim of Linux, ARM64, or non-x86 compatibility has been established.
No x86-only SIMD dependency was found in the initial targeted source search; this is not yet a complete dependency-level SIMD audit.

Deferred Ideas

Linux/x86-64 port: Deferred until current Windows architecture and tests are stable enough for a second supported platform to provide useful evidence.
ARM64 build: Deferred until after a credible single-machine Linux milestone.
Headless SpaceAge node: Deferred because application/audio boundaries have not yet been extracted or proven independently of the desktop application.
RK1 and Turing Pi support: Deferred until single-node ARM64 behavior and performance are known.
Jetson integration: Deferred until a concrete neural-audio workload exists and ordinary CPU execution has been measured.
Networked DSP and automatic DSP scheduling: Deferred until processors have stable local boundaries, identity, state, timing, and measured workloads.
Custom audio hardware: Deferred until software requirements demonstrate a need that cannot be evaluated using standard Windows audio interfaces.
GPIO and control-surface integration: Deferred until normalized control and parameter paths are mature; no hardware-specific UI is needed now.

Validation

2026-08-29

Windows Release ConvTest built with the pinned test-only PFFFT source.
Identical-buffer JUCE/PFFFT round trips remained within 4.10e-08; native PFFFT spectral convolution matched direct convolution within 1.40e-09.
The test-only 512-sample partition scheduler matched the current implementation within 1.86e-08 under complete, irregular, and reset rendering. Its focused dual-room stereo timing ratio was approximately 0.10-0.12 on Windows/x86-64.
The complete convolution suite passed, and Windows Release SampleSquadAudioTest built without linking the test-only dependency.
The test-only 2,048-sample tail matched within 1.68e-08. The combined non-uniform scheduler matched within 8.90e-08, used about 15.3-18.2% of the current scheduler's total test time, and retained lower P95 and maximum callback timings across repeated Windows Release runs.
The complete mandatory convolution suite passed. PFFFT remains excluded from Standalone, VST3, and release packages.

2026-08-28

Windows Release SampleSquadAudioTest built successfully.
MSEG endpoint, uneven-segment, curvature, malformed-input, and prepared/safe evaluator equivalence contracts passed.
The focused Redshift behavior and optimized/reference hot-path comparison remained green; no MSEG route is active yet.

2026-08-27

Windows Release SampleSquadAudioTest built successfully.
Focused Redshift gate passed all 20 waveform cases, source morph, spread, oscillator isolation, custom-cycle ownership, and reference/optimized rendered signature equivalence.
Windows Release standalone built successfully at 94,942,720 bytes.
No intended user-visible behavior changed.

Next Sensible Milestone

Audit one concrete CinematicDrumsAudioProcessor::processBlock dependency chain for allocations, blocking locks, filesystem access, and GUI coupling. Document evidence first; make only a small change that also improves Windows real-time safety or testability.