SpaceAge Port Planning

Raspberry Pi / Linux Feasibility

SpaceAge can be ported to Linux and can reasonably target a Raspberry Pi, but this is a future platform project rather than current beta work. JUCE and CMake already provide the main cross-platform foundation. The remaining effort is concentrated around platform-specific audio/MIDI setup, filesystem and dialog behavior, packaging, performance tuning, and hardware validation.

Recommended First Target

• Raspberry Pi 5 with 8 GB or 16 GB RAM.
• Active cooling; sustained audio DSP should not depend on passive thermal headroom.
• NVMe storage rather than a microSD card for projects, large SoundFonts, Quasar packages, and dependable write performance.
• A class-compliant USB audio interface with a native ALSA path.
• 64-bit Raspberry Pi OS based on current Debian stable as the first supported distribution.

Raspberry Pi OS is the least surprising first target because its firmware, kernel, device support, and deployment path are tailored to Raspberry Pi hardware. Ubuntu Studio may be useful for development and comparison, but it introduces more background services and a broader desktop stack than a focused SpaceAge appliance needs.

Expected Engineering Work

1. Audit and isolate Windows-only code paths for dialogs, shell actions, process launching, preferences, paths, and installer assumptions.
2. Build the standalone application with the Linux JUCE modules and the repo's CMake toolchain.
3. Validate ALSA first, then assess JACK or PipeWire integration where it improves professional routing without complicating first-run setup.
4. Verify MIDI input/output, multi-controller timing, SysEx, clock, hardware profiles, and hot-plug behavior on the target kernel.
5. Test every internal Instrument and shared effect on ARM64, including denormal handling, SIMD assumptions, sample-rate changes, and voice retirement.
6. Profile representative projects at 44.1 and 48 kHz with practical buffer sizes. Establish a supported project complexity rather than claiming desktop parity without evidence.
7. Validate SoundFont, Quasar, imported samples, project archives, recovery, render, and removable-drive behavior.
8. Package as a native Debian application first. Consider an appliance image only after the ordinary desktop build is stable.

Important Caveats

• Large sample libraries are more likely to be limited by storage throughput and memory pressure than by the GUI.
• Some third-party libraries may need ARM64 build fixes even when their licenses permit Linux distribution.
• Future VST hosting on ARM64 depends on compatible ARM64 plug-ins; x86 Windows plug-ins do not become portable merely because SpaceAge does.
• Low latency requires a real audio interface, sensible kernel/device configuration, and measured buffer behavior. The built-in Pi audio path should not define the product promise.
• A Raspberry Pi port must retain the same project format and MIDI semantics as Windows so songs remain portable.

Staged Validation Plan

1. Compile proof: clean ARM64 standalone build with no source changes hidden outside version control.
2. Audio proof: internal Instrument, Mixer, effects, transport, render, and project round trip.
3. MIDI proof: USB and DIN-interface input/output, timing, recording, SysEx, clock, and multi-device use.
4. Content proof: large SoundFont and Quasar projects with missing-asset repair and portable archives.
5. Performance proof: repeatable CPU, xrun, temperature, and memory measurements using musical workloads.
6. Product proof: clean-device installation and first-run workflow without a development environment.

Product Direction

A successful Pi port could eventually support a dedicated SpaceAge workstation: a quiet, purpose-built composition appliance with a controller, audio interface, and focused display. That opportunity should grow out of the same portable engine and project format, not a separate fork that drifts away from the desktop product.