SSPACEAGEDOCUMENTATION/
Product and Design

Sample Squad SpaceAge - Feature Backlog And Maybe Ideas

Updated Aug 28, 2026   |   71.3 KB   |   docs/Feature_Backlog_And_Maybe_Ideas.md

Sample Squad SpaceAge - Feature Backlog And Maybe Ideas

This document separates unfinished work into two buckets:

  • Must happen: features needed for a serious, reliable, sellable microDAW / drum lab.
  • Maybe we'll do it: promising ideas that could create differentiation, but should be tested against usability, CPU cost, and product identity before implementation.

The central design tension is the flexibility-usability tradeoff: every new capability increases power, but too many visible controls can make the app feel less immediate. SpaceAge should stay fast and inviting while letting advanced users uncover deeper systems when they need them.

Must Happen

Project Saving And Archives

  • Add one-click import for complete project archives. First pass added in SSDL1043.
  • Remap archived sample and loop paths automatically after import. First pass added in SSDL1043 using archive_manifest path remapping.
  • Show missing asset warnings that are calm and useful. First pass added in SSDL1045.
  • Let users replace missing samples one at a time or by pointing to a parent folder. Parent-folder repair first pass added in SSDL1045; one-at-a-time picker still pending.
  • Show the current open project path when saving over an existing project. First pass added in SSDL1046.
  • Low priority: add a Load Previous Versions dialog that can browse saved project versions, recovery snapshots, and archived checkpoints without making the main save/load workflow feel heavy.

Piano Roll / Sequencers

  • Continue refining piano roll editing until it feels fluid enough for real composition.
  • Add stronger copy, paste, duplicate, slice, resize, and quantize workflows.
  • Add reliable MIDI export/import for drum and melodic patterns. First pass added in SSDL1049 with explicit import/export buttons and mode-aware import.
  • Add per-note editing lanes beyond velocity: probability, ratchet, pitch, filter, pan, decay, send levels.
  • Add a clear way to switch between drum steps, piano roll, and any future sequencer types without clutter.
  • Add MIDI step input for the Piano Roll and eventually Drum Composer: choose a rhythmic length, play pitches from a MIDI keyboard one-by-one, then advance the playhead automatically. First pass should live near the Piano Roll recording controls, probably inside Settings or behind a compact STEP INPUT button. Include a default velocity slider, with an option later to capture played velocity.
  • Add Piano Roll legato / slide-link editing. First pass should be monophonic and MIDI-safe: selected adjacent or overlapping notes can be linked so the first note glides toward the second, with lane-level pitch-bend range and clear export behavior. Polyphonic per-note bends should wait for internal per-voice support, MPE, or explicit channel-per-note routing.

Lane Arranger

  • Move the Arranger away from a single forced chain and toward a lane-based song workspace. Foundation pass added in SSDL1063 with persistent lanes/clips/sections and a four-lane visual Arranger. SSDL1067 adds a chain-to-Drums-lane bridge so current Arranger blocks are mirrored into real lane clip data for future multi-lane playback. SSDL1076 surfaces the starter lane headers and M/S scaffolding in the Arranger UI.
  • Formalize the separation between Clip Instance and Pattern Payload. A Clip Instance lives on the Arrangement Canvas and owns lane/start/visible length; a Pattern Payload owns the musical material. This must drive clone, variant, resize, paste, save/load, and MIDI export behavior.
  • Default lanes should stay simple: Drums, Bass, Harmony, Melody.
  • Display the default lanes in score-inspired vertical order: Melody, Harmony, Bass, Drums, while keeping the internal lane identities stable for saved projects.
  • When user-created lanes are added, stack them above the default four-lane score-order group by default. Later, add manual lane reordering for users who want a custom workspace.
  • Keep Arranger-level Playhead and Loop lanes visible above the musical lanes so large-scale composition has the same transport and looping affordances as the sequencers. Visual scaffolding added in SSDL1080; SSDL1087 adds live playhead/loop display and a horizontal time-based Drums lane.
  • Add a small measure-number ruler above each composition workstation: Drum Composer, Piano Roll, and Arranger. This should be visually quiet but always available so users know where they are in musical time.
  • Keep Drum Composer and Piano Roll useful as local pattern workbenches; combine material intentionally in the Arranger.
  • Add linked/unique clip behavior so repeated clips can either share edits or become independent variations. SSDL1089 adds visible LINKED/UNIQUE labels, a Make Unique command for selected Arranger clips, and fixes Clone Clip so it copies Piano Roll notes as well as drum steps.
  • Rejected: explicit Context/Isolation toggle. The simpler rule is page-local playback: sequencer pages play the selected pattern, and the Arranger plays the arrangement.
  • Keep lane ownership strict: clips should remain in the lane where they were created unless the user explicitly asks to convert them. This prevents melodic clips from silently entering drum lanes, drum clips from becoming inaudible in melodic lanes, and future hardware/VST lanes from becoming ambiguous.
  • Add a clear lane-conversion dialog later. Dragging a clip onto a foreign lane should ask what the user intends: convert clip type, copy musical content where possible, duplicate as a new lane-compatible pattern, or cancel. Until then, foreign-lane drag/drop should be blocked.
  • Keep lane instruments one-per-lane by default. Each lane should own an internal instrument, future SoundFont/VST/hardware target, and mixer channel strip. This keeps composition, mixing, project saving, and stem rendering predictable.
  • Add per-lane preset/instrument assignment polish: quick preset switching, instrument edit icon, and reset lane instrument. First guardrails added: changing a populated lane's instrument now asks for confirmation, the Instrument Bay can duplicate the current lane Instrument into a fresh internal Instrument slot, and an Instrument can launch a new lane with a starter clip.
  • Add a top Section Lane that controls visible song form and color inheritance.
  • Make Section Lane markers first-class editable song-form objects: add, select, drag, resize, and remove without depending on Drum clips. First pass added in SSDL1127. SSDL1144 fixes Duplicate Marker so it inserts immediately after the selected marker/group while shifting only later Section markers, and adds Ctrl+Shift+A to select all clips under selected Section markers.
  • Section marker resizing should default to no-ripple behavior so the Section lane remains a safe composer map. SSDL1142 made normal Section marker resizing non-destructive and added common song-form presets that replace only Section markers. Later, consider an explicit "insert/remove time" command or modifier-key ripple for users who intentionally want to push material.
  • Let users add more lanes only when they need them.
  • Next lane pass: route Piano Roll material into Bass/Harmony/Melody/custom lanes without breaking the isolated Drum Composer / Piano Roll workflow, and expand lane mute/solo beyond the first Drums-lane bridge. SSDL1087 makes the Drums lane mute/solo affect current bridged arrangement playback. SSDL1091 adds a first-pass lane selector + ADD CLIP workflow so selected patterns can be placed visibly on Bass/Harmony/Melody/custom lanes. SSDL1097 makes non-drum Arranger lane clips drive Piano Roll playback and honors lane mute/solo for those clips. SSDL1098 adds intrinsic pattern length bookkeeping so new clips draw at their true duration, plus first-pass selection/opening for non-drum lane clips.
  • Preserve timeline space when deleting clips from an arrangement lane; removal should create useful empty time, not collapse the composition unless the user explicitly chooses a future "ripple delete" command.
  • Add a true multi-lane clipboard later: lasso clips across lanes, copy/paste them as a time-aligned block, and keep each lane's material isolated so Drum clips cannot accidentally paste Bass/Harmony/Melody clips. SSDL1143 begins this cleanup by making Section markers copy/paste/duplicate independently from musical clips.
  • Add Piano Roll ghost-note display by source lane. First pass should be read-only and optional: Ghost: Off / Bass / Harmony / Melody / Selected Lanes. Use muted lane colors, thin outlines, or diagonal hatching for overlaps instead of blending colors into mud. Overlapping same-pitch ghost notes can show a tiny 2x / 3x badge later.
  • Add a future Multi MIDI / Polytimbral lane type for General MIDI, XG hardware, multitimbral VSTs, and hardware synths that intentionally use multiple MIDI channels or timbres inside one lane. This should not weaken the normal one-instrument-per-lane rule; it should be a separate advanced lane type with explicit channel/part management.
  • Consider optional Arrangement Lane background colors drawn only from curated SpaceAge swatches. Clips should remain a restrained default color so the canvas does not turn into candy-store chaos. Lane colors should be subtle, low-saturation, and useful for orientation rather than decoration.
  • Add true project transposition / reharmonized key change. This should not be a simple global semitone shove. The proper version changes key/mode, respells notes, updates chord degrees, optionally maps notes into the new scale flavor, and asks whether to transform existing material or only affect future drawing/composition.
  • Add a global drag-smoothing pass across the Arrangement Canvas, Piano Roll, Chord Engine, Drum Composer loop/step-bank loops, Section markers, and mixer/clip controls. Prefer a shared drag interaction layer that separates raw mouse movement, snap-preview position, drop target, ghost/clone preview, and final commit. This should reduce jitter, make clips feel attached to the cursor, and prevent each editor from inventing its own drag behavior.
  • Add a reusable collapse/overview architecture for dense workspaces. First Arranger pass added with Arrangement Overview Mode: lanes compress vertically, detailed lane controls hide, and the canvas becomes a broader song map. Future versions can reuse this pattern for larger waveform, spectrometer, automation, or sample-editing views.
  • Add tasteful clip-content miniatures inside Arrangement clips. First pass should be optional: Off, Modest, and Bold. Drum clips can show ghosted step hits, melodic clips can show a tiny pitch contour, and Chord Marker material can show quiet block regions. Keep this monochrome/low-contrast so it adds information without turning the Arrangement Canvas into visual candy.

MIDI Recording And Hardware

  • Improve MIDI recording latency compensation.
  • Polish MIDI input device selection and status feedback. First-pass direct physical input routing, lane input policy, diagnostics, and trust-gate reporting exist; remaining work is real-controller validation, clearer repair paths, and launch-grade onboarding copy.
  • Polish MIDI output routing so SpaceAge can sequence external synths and drum machines. First pass exists for live Arrangement drum clips, Piano Roll notes, and Chord Markers using lane MIDI channels. Next passes should harden explicit MIDI output device/port selection, bank/program handling, Hardware Passport guidance, and SysEx Vault/Librarian workflows.
  • Add per-track/per-instrument MIDI channel, output device, port, bank, and program assignment so hardware can be addressed deliberately instead of assuming one global MIDI output.
  • Add a guided Hardware Setup Wizard: detect MIDI devices, ask the user to press a pad/key/turn a knob, identify channel/note/CC/pitch/aftertouch behavior, send test notes, test clock/transport, and save a named Hardware Passport.
  • Make hardware setup unusually plain-language and reassuring: conflict warnings, "I heard your controller on Channel X", "This lane is listening on Channel Y", one-click fixes, reconnect tests, and visible Panic / All Notes Off.
  • Polish MIDI AUTO recording, editing, and playback. Shared PTN, Clip Local, and Lane Local ownership now persist, edit, play, and export through one AUTO LANES model; remaining work is launch-grade interaction polish, broader manual QA, and real-device evidence.
  • Add safe panic/all-notes-off controls.
  • Add explicit MIDI Guitar lane/profile support: per-string MIDI channels, bend-range checks, false-trigger filtering, low-velocity cleanup, fretboard/chord visualization, string-aware quantize, strum timing preservation, and pitch-bend-to-slide conversion.
  • Add explicit Wind Controller lane/profile support: breath CC shaping, velocity-from-breath options, aftertouch/bite/vibrato mapping, monophonic legato defaults, scale-safe pitch bend, and breath reset/panic helpers.
  • Polish the SysEx Vault/Librarian layer for external hardware. First-pass capture, storage, guarded recall, evidence boundaries, and reporting exist; remaining work is batch capture/save, Hardware Passport tagging polish, deeper device identity checks, ACK/NAK/WAIT/CANCEL response handling, send-rate throttling, checksum validation when available, and clearer session logs.
  • Yamaha XG editor: build a Hardware Passport-backed editor for QY-70/QY-100 and MU-series devices, especially MU1000/MU2000. Start with locked source/checklist pages, then unlock common part controls, effects, drum setup, SysEx capture/restore, and setup recall only after verified Data List tables and physical hardware receipts exist. Spec: docs/Yamaha_XG_Editor_Spec.md.
  • Add Yamaha XG / Roland GS / General MIDI hardware editors as Hardware Passport-backed instrument panels. First named targets: Yamaha QY-70/QY-100, Yamaha CBX-K1XG, Yamaha MU-family modules, Roland GS/Sound Canvas-family modules. The editor profile must come from real manuals/Data Lists and should cover part/channel selection, bank/program editing, drum maps, XG/GS effect controls, common CCs, RPN/NRPN where appropriate, and guarded SysEx recall.
  • When the Instrument Bay fully supports hardware targets, those targets should be lane-owned instruments too: MIDI device, channel, bank/program, clock/sync preferences, panic behavior, and optional SysEx snapshot should all live with the lane/instrument identity.

Sample Engine

  • Finish robust sample region editing and make it visually obvious which layer is active.
  • Add loop/cycle options for imported samples where musically useful.
  • Add clean bulk import mapping tools.
  • Add better sample replacement workflows.
  • Make archive/export behavior preserve all sample region settings.

Mixer And Effects

  • Build a shared internal effect preset browser for EchoRay, Halostar, and future effects. Preset records should include category, author, description, favorite state, A/B compare, randomize-safe ranges, and reset/apply behavior.

  • Add a dedicated Drum Composer sub-mixer for each pad that currently contains audible material. This should be a fast pad-level mix view, separate from the deeper channel strip, for balancing a 16/64-pad drum kit without leaving the composition surface.

  • Add a small mono/stereo status indicator per channel strip after the signal model stabilizes. Prefer a quiet MONO / ST badge or subtle meter/slider accent, not an overbearing color swap. Auto-detect should be smoothed over time so a temporarily mono synth patch does not flicker the UI.

  • Continue CPU discipline around per-channel compressor, saturation, and modulation effects.

  • Add clearer enabled/disabled states for anything that consumes extra CPU.

  • Add tempo-sync choices for master/return effect rates. A future UI idea is a compact circular/dropdown selector inside or near rotary rate controls so users can choose synced note divisions without losing free-rate behavior.

  • Add better metering for master and channels.

  • Add preset management for effects chains.

  • Add reusable tempo-aware clip effects, tentatively called Motion Blocks: gate patterns, fades, pan sweeps, filter moves, pumps, stutters, throws, and similar clip decorations that can be snapped onto loops, drum patterns, piano roll phrases, arrangement clips, or sections.

  • Add a CPU/performance indicator before the app grows much further.

Presets, Pad Vault, And Library

  • Add a full preset editor for viewing, renaming, moving, deleting, and tagging saved pads.
  • Add searchable categories and tags for Pad Vault items.
  • Add bank-level preset loading for 16-pad pages.
  • Add a unified preset browser built around real preset records, not raw dropdown strings. Minimum fields: ENGINE, CATEGORY, PRESET, and INFO; INFO should include authorship, human description, intended use, harmonic safety/chord-friendly status, source, version, and optional license/source notes.
  • Preset records should prominently display the engine involved and offer a direct action to launch that engine/preset as a new Instrument in an Arrangement lane through the Instrument Bay.
  • The preset browser should be reusable across synths, drum Labs, SoundFonts, Pad Vault, effect chains, and later expansion packs. It should support filtering by category, text search, favorites, audition/preview, and an obvious metadata/info panel.
  • Preset records should eventually serialize beside the patch data so factory and user presets can be moved, packaged, archived, and browsed without losing category or author metadata.
  • Add better factory melodic instruments for piano roll testing.
  • Add a SoundFont player as a native instrument option, with per-instrument preset/program selection, file path repair, lightweight voice limits, and clear CPU/memory feedback for larger fonts.
  • Treat SoundFonts as first-class workstation instruments, not just sample playback: lane-owned preset state, readable bank/program selection, project-safe path repair, archive awareness, and a clear distinction between SoundFont patch controls and mixer-channel controls.
  • Expand user-source synth import beyond the current audio-source workflow. Liftoff and Lunacy can load WAV/AIFF/FLAC/MP3 as oscillator/grain material now; a later pass should evaluate true wavetable-bank formats, automatic root-note detection, loop-point detection, transient trimming, and user-source preset packaging.
  • Improve the factory kit/pattern story so it feels intentional, not like scattered buttons.
  • Add a dedicated sample browser with user-editable metadata. It should provide fast drag-and-drop access to drums, sub kicks, melodic hits, one-shots, loops, and sound effects, with preview, favorites, tags, categories, source folder/library, tempo/key when known, root note, license/source notes, and quick import to pads, layers, one-shots, loop lanes, or arrangement clips. First pass should be local-library only; online/curated catalog integration can come later.

Instrument Bay And Lane Targets

  • Replace the current 64-pad-backed instrument selector with a real Instrument Bay. Today, melodic lane instruments are effectively limited by the 64 pad engines because pads still double as internal instruments. Long-term, lanes should target independent Instruments chosen from the Instrument Bay: Redshift/SoundFont/VST/Hardware Passport targets, each with its own preset state, mixer channel, MIDI routing, and save/load identity.
  • Keep pads excellent for drums and hybrid sample/synth pad work, but stop requiring every melodic instrument to occupy a pad slot once the Instrument Bay is fully independent. This will make VST hosting, SoundFonts, hardware, and multitimbral lanes cleaner.
  • Add migration rules so older projects that used pad-backed instruments still load correctly after the Instrument Bay lands.
  • Add SpaceAge Scenes as project-level orchestration alternatives. A Scene should save a named set of instrumentation choices for the same composition: lane instruments, presets, mixer-channel targets, Hardware Passport targets, and possibly effect-send/rack choices. It should not duplicate or rewrite the musical content by default; clips, notes, chord markers, Section markers, and timing stay intact while the user auditions "same song, different band/orchestration" ideas.
  • Quasar should become the native multisample instrument layer for SpaceAge. Current pass: capture a tonal internal patch into a .ssquasar package folder containing a manifest and rendered WAV zones, choose fast/standard/wide note ranges, choose 1-4 velocity layers, choose render length, choose auto/off/on sustain-loop metadata, optionally peak-normalize captures, load/play that package as the Quasar engine, and package/remap Quasar folders in complete project archives. Next passes: make Quasar fully lane-owned in the Instrument Bay, add round robins, editable loop points, Loop on Release behavior for release-tail/sustain-release instruments, patch metadata browsing, and one-click conversion from any tonal internal engine without exposing pad-slot plumbing to the user.
  • Instrument records should eventually answer the same basic questions: display name, engine type, preset name, mixer channel, MIDI input channel, MIDI output target, patch save/load data, archive dependencies, and whether the instrument is mono/stereo/polytimbral.
  • Patch-state display should remain unified: synth editor readout, lane badge, preset browser, and archive metadata should all agree about the current preset/package name and whether it has unsaved edits.
  • Keep lane instrument inspection and assignment at the lane head/badge. Do not recreate a top-row instrument inspector. Lane controls should eventually cover: choose instrument, choose preset, rename lane, assign mixer channel, set MIDI input/output, and open the instrument editor.

Custom Data And Housekeeping

  • Add a focused DATA or MANAGE tab inside the Create area for low-frequency housekeeping: pad display names, pad notes, pad metadata, custom section names, and other project labels.
  • Use this tab to avoid hiding important naming behavior behind fragile gestures such as double-clicking small pad text.
  • Let pad names update the redesigned pads immediately, while keeping the stable pad number visible for orientation.
  • Add custom section-name management here once the lane Arranger's section-color language is stable.
  • Keep destructive housekeeping actions grouped and clearly confirmed so the main Pads and Sequencers pages stay fast.

Release Packaging And Brand Assets

  • Final public builds should embed the curated splash-screen images into the app binary or another non-user-editable signed resource bundle. External splash folders are useful for rapid development builds, but release builds should not expose marketing artwork as loose files that end users can replace.

Redshift Quick Wins

  • Expand the new per-Tone A/B motion routes using the staged plan in Redshift_Motion_System_Integration_Plan.md: separate Cycle, Shape, Trigger, Phase, Skew, Fade In, Offset, long/odd bar durations, and truthful knob authority first; then endpoint holds, Step Motion, and a reusable MSEG.

  • Continue Redshift's model/mode/slope filter architecture from Filter_Model_Research.md: Clean, Silk, and Bite now support 6/12/18/24 dB/oct with smoothed model changes. Consider a genuinely separate ladder topology only after listening proves it adds value and dedicated stability/CPU tests exist.

  • Create the full Invader-inspired / SpaceAge VA architecture described in docs/Synth_Architecture_Invader_CSound.md.

  • Add independent oscillator waveform choices for Osc 1 and Osc 2 instead of sharing the pad's broader waveform behavior.

  • Add a simple Unison / Detune / Stereo Spread cluster for instant bigger basses, stabs, and pads. First pass added as OSC SPREAD, a lightweight oscillator-thickening control.

  • Expand Glide into the portamento system specified in the motion plan: Off, Always, Legato, and Fingered modes; Time/Rate timing; tempo sync through 16 bars; curve, direction, envelope retrigger, and polyphonic handling.

  • Add a dedicated filter envelope amount and filter envelope decay so synth patches can pluck, bark, and swell without borrowing drum-engine assumptions.

  • Add one lightweight LFO with rate, depth, waveform, and target choices: pitch, filter, pan, amplitude, or Osc 2 detune.

  • Add a disciplined cross-modulating two-LFO mode for Redshift after the basic LFO is stable. First sonic-motion pass added as bounded X-MOD, which moves pitch and filter musically without a full modulation matrix yet. Later version should be tempo-syncable with LFO A/B rate/depth routing.

  • Add more oscillator character controls. First pass added WIDTH and WAVE FOLD for pulse/shape color and harmonic bite.

  • Add chorus/widening as a low-CPU tone sweetener, ideally toggleable so it stays disciplined.

  • Add a small factory preset bank aimed at testing the Piano Roll: basses, stabs, plucks, pads, leads, simple keys, and weird SpaceAge tones.

  • Add clearer ADSR presentation and a one-click "INIT POLY PATCH" reset button inside the synth itself so melodic sound design feels intentional instead of inherited from percussion pages.

  • Later: add arpeggiator/chord-memory tools only after MIDI recording and the lane Arranger are steadier.

Library Visual Atmosphere

  • Add an optional low-CPU arcade starfield background to the Library page. This should be JUCE-drawn, not a video: a small pool of stars moves toward a vanishing point, mostly white stars with occasional larger bright stars. First pass added as a lightweight Library backdrop; second pass brightened it substantially so the theme reads without squinting. Later: add a reduce-motion setting if the animation ever feels distracting.
  • Add the same tasteful starfield atmosphere behind the Effects page once the rack/editor layout is stable. Keep it subtle enough that effect cards remain readable, and reuse the Library starfield renderer rather than creating a one-off animation path.
  • Maybe later: add a legally clean arcade-style Easter Egg inspired by vector space games. Do this as original JUCE-drawn code and original shapes/sounds rather than importing an Asteroids clone, trademarked branding, or uncertain asset packs.

CSound-Inspired Drum Synths

  • Use CSound as an algorithmic inspiration source rather than embedding the runtime in the first pass.
  • Continue refining the dedicated low-CPU drum labs: Kick Lab for sub/body/click, Snare Lab for shell/stick/wires, and Hat Lab for noise/metal/tick/open-close behavior.
  • Add a dedicated SpaceAge 808 generator / sub-bass drum engine. It should be specialized for tuned 808s and long sub tails, not a generic bass synth. Desired features: style starters, ADSR, glide, tone, keytracking, saturation, transient/click blend, pitch envelope, preset saving, render/export to sample, and a simple way to keep the 808 in tune with project key or lane notes.
  • Give the 808 generator tight Drum Lab integration: users should be able to side-chain it to selected Drum Lab kick voices, and the app should eventually offer auto-assignment from Drum Lab kicks whose generated/output frequencies fall below a user-defined threshold. Controls should include sidechain amount, speed/release, curve/shape, listen/preview, and a clear "follow this kick" target display.
  • Keep the user-facing model musical instead of raw DSP: Transient, Body, Resonance, Dirt, Motion, Output.
  • Investigate Csound's C/API and example ecosystem as a reference source for instrument-as-graph thinking, but translate useful algorithms into original JUCE/C++ modules unless there is a strong reason to ship a Csound runtime.
  • See docs/Synth_Architecture_Invader_CSound.md for the first architecture pass.

Battalion-Inspired Drum Lab Ideas

Reference: Unfiltered Audio Battalion is useful as a modern drum-machine design study, especially around modular voice design, sequencing, randomization, and performance control. SpaceAge should borrow product lessons, not implementation or branding.

  • Add per-pad/per-voice drum-engine presets that can be browsed and swapped quickly without disturbing the whole kit. This aligns with Pad Vault but should also exist inside the Drum Composer / Create workflow.
  • Expand drum synthesis as modular voice blocks: oscillator/body, transient/click, noise, FM/metal, resonator, filter, drive, envelope, and output. Keep the first UI musical rather than patch-cable technical.
  • Add controlled randomization at the pad, kit, and pattern levels: randomize selected voice, randomize only modulation, randomize rhythm density, randomize velocities, and "humanize but do not destroy."
  • Add per-voice modulation assignment as a visible but compact system: envelopes, LFOs, random, velocity, accent, probability, and step locks can target pitch, filter, decay, pan, drive, send levels, and sample start.
  • Add variation/performance macros for drums: global intensity, chaos, density, swing/humanize, fills, mute groups, and morphing between saved drum states. These should always be optional and commit-able to pattern data if the user wants permanence.
  • Add pattern mutation snapshots: generate variations from a beat while preserving the original, with undo and clear labeling.
  • Add better per-pad effect and routing templates: mono/stereo awareness, choke/mute behavior, per-pad outputs, and fast send setup.
  • CPU guardrail: modular per-pad synthesis and modulation can scale fast. Expensive blocks should be opt-in, disabled when unused, and visible in CPU/performance feedback.

Spectral / Analysis-Resynthesis Engines

  • Add a future Spectral Curiosities engine based on offline analysis/resynthesis rather than live FFT-heavy playback.
  • Use SMS-style thinking: split a source sample into deterministic partial tracks and stochastic/noise residual behavior, then expose musical controls for tone, noise, transient, smear, pitch, stretch, and metallicity.
  • Use this first for sample-to-synth starting points, percussive hybrid sounds, and strange playable approximations of imported recordings.
  • CPU guardrail: analysis can be slow and offline; playback must use cached data, bounded partial counts, and optional quality modes.

Stability And Commercial Readiness

  • Add a focused regression test for each recurring bug class: pad clear, sample layer restore, arranger slot length, piano roll selection, loop playback, and project archive export.
  • Run regular profiling passes.
  • Reduce warning noise in the build.
  • Keep old builds cleaned up or archived automatically.
  • Decide final naming, versioning, installer behavior, and default file locations.
  • Confirm destructive actions in plain language, especially controls near high-frequency buttons such as transport. First pass added in SSDL1079 for Drum Composer CLEAR NOTES.
  • Normalize popup styling so FX, Settings, Shortcuts, Favorites, and other dialogs use the same lighter border/bevel language as the Section Notes area instead of thick, disconnected borders.
  • Add an optional in-app Ask SpaceAge assistant after the core workflow stabilizes. It should answer workflow questions, diagnose project/audio/MIDI problems, and optionally guide non-destructive actions. It must be opt-in, never run on the audio thread, never upload samples/audio without explicit approval, and always ask before changing project data.

Maybe We'll Do It

Modular / Eurorack-Angled Features

  • CV-style MIDI output lanes for pitch, gate, velocity, modulation, and clock.
  • Per-note modulation shapes that can send MIDI CC curves to hardware.
  • Clocked LFO lanes per pattern or per pad.
  • Sample-and-hold, stepped random, and smooth random modulation sources.
  • Euclidean pattern tools as optional generators, not always-visible controls.
  • Pattern mutation snapshots for controlled generative variation.
  • MIDI-to-CV friendly templates for popular interfaces.

Marketing angle: modular-style sequencing without modular complexity.

Advanced Sequencer Types

  • Probability sequencer.
  • Euclidean sequencer.
  • Polymeter / polyrhythm sequencer.
  • Automation sequencer.
  • Chord lane / chord sequencer.
  • Modulation sequencer.
  • Human-led phrase tools.

These should live behind the broader SEQUENCERS page concept, not be forced into the main workflow all at once.

AI Vocalist / Vocal Lane

This is feasible, but it is a major product-class feature closer to building a focused singing workstation than adding another synth oscillator. Treat it as a future SpaceAge expansion, not a near-term sprint item.

First architectural goal:

  • Add a dedicated Vocal Lane type with clips that can store notes, lyrics, syllable alignment, phoneme hints, pitch curves, vibrato, breath markers, expression automation, and voice assignment.
  • Add a lyric-aware Piano Roll where each note can hold a syllable or lyric fragment, with melisma handling for multiple notes on one syllable.
  • Support import/export workflows first: MIDI + lyrics where practical, MusicXML later, and compatibility-minded exports for external vocal tools when formats and licensing allow.
  • Add a voice/performance editor only after the lane model is stable: voice choice, gender/formant-style controls where legally/technically appropriate, breathiness, tension, vibrato, timing, loudness, consonant emphasis, and phrase-level expression.
  • Native AI singing should require licensed singer datasets or licensed third-party voice engines. Do not clone famous singers or imply "sounds like" functionality.
  • CPU guardrail: rendering should be offline or background-worker based, never on the real-time audio thread. Cached rendered audio should play like any other clip once generated.

Product direction:

  • Short term: make SpaceAge able to compose and arrange vocal melodies/lyrics, then hand off cleanly to dedicated vocal software.
  • Mid term: add a vocal-render slot that can call a licensed external/local engine.
  • Long term: consider a curated "SpaceAge Voices" product line only if licensing, model quality, and commercial runway justify it.

Chord Engine / Songwriter Layer

The chord engine should feel like a fast sketchpad for harmonic intent, not a theory exam and not an auto-composer. The likely first version is a dedicated chord lane attached to the Piano Roll, with a larger key-family palette above it. A user chooses a key and mode, sees the available diatonic chords, drops chord clips into the lane, then resizes, slices, duplicates, and edits them with the same gestures used elsewhere in SpaceAge.

Core data model:

  • Chord clip: start step, length, root, quality, extension, inversion, optional slash bass, velocity, voicing preset, target instrument, linked/unique state, and optional humanized strum/spread.
  • Chord performance layer: per-voice velocities, strum direction, strum time, velocity tilt, humanize amount, and preserve-end behavior. This should remain separate from harmonic identity so a chord can still be truthfully labeled while having expressive timing.
  • Key context: root plus mode/scale, stored per pattern and eventually per arrangement section.
  • Scale lock: a Piano Roll option that can highlight safe notes first, then later constrain note drawing/transposition to the active scale when desired.
  • Voicing model: close, open, drop-2-ish, octave doubled, bass-friendly, and pad-friendly presets rather than forcing users to hand-place every note.
  • Arpeggiation model: chord clip can optionally output held block chords, up/down arps, broken-chord patterns, or rhythmic comping patterns while remaining editable as one harmonic object.
  • Suggestion model: optional chord suggestions should be theory-aware next-step helpers, not automatic composition. The user must audition and explicitly commit any suggestion.
  • Klimper-inspired direction: prioritize visual harmonic guidance and melody-aware chord fitting rather than auto-writing. Useful SpaceAge versions include "fit chord to selected melody notes", "suggest a likely next chord", "bright lift", "dark turn", and later "borrowed color" / "spicy outside" tiers.
  • Borrowed-chord honeycomb direction: add a Borrow From control that can expand suggestions beyond the active key while remaining human-led. First useful sources: parallel minor/major, relative major/minor, secondary dominants, modal mixture, Neapolitan color, and eventually any key. Hexes should display both chord spelling and source tag, such as V/V, borrowed from C minor, or Mixolydian color.
  • Honeycomb UX now defaults to an audition-first flow. In AUDITION MODE, clicking a hex only plays the chord and leaves the clip untouched; double-clicking commits it. In COMMIT MODE, clicking writes/replaces the selected Chord Engine marker. This gives users freedom to listen through many options before making a musical decision.
  • Per-Chord Marker playback modes are now part of the Chord Performance workflow: Chord + Arp, Arp Only, and Reference Only. Rendering an arp to Piano Roll notes automatically leaves the source marker as Reference Only, so the harmonic memory, label, length, and future editability remain intact without doubling playback.

First workflow target:

  • Add compact KEY and SCALE controls to the Piano Roll.
  • Highlight safe-note rows subtly in the grid.
  • Add a chord lane below or above the Piano Roll note grid after the scale guide is stable.
  • Clicking a diatonic chord button should audition it and optionally insert it at the playhead.
  • Dragging a chord edge changes duration; Ctrl+U slices selected chord clips using the same cut subdivision logic as notes. The practical default choices should be CUT SNAP, CUT IN 2, CUT IN 4, CUT IN 8, and CUT IN 16.
  • Selecting a chord exposes quick modifiers: triad, sus2, sus4, 6, 7, maj7, add9, inversion up/down, slash bass, and make unique.
  • Add a compact chord-properties panel inspired by Hookpad's clarity but with SpaceAge's darker, cleaner visual language.
  • Double-clicking a chord marker should open a Chord Performance panel with a read-only voicing preview and editable performance settings. Direct pitch edits should wait for an explicit Render To Notes or Make Custom Voicing action so the visible chord label stays honest.
  • First-pass suggestion control: add a compact SUGGEST workflow beside the chord controls. A suggestion creates or replaces an ordinary editable chord marker so the user can still slice, resize, render, arp, or delete it like any other chord clip.

Future direction:

  • Borrowed chords, modal interchange, secondary dominants, diminished passing chords, and chromatic mediants should be suggestions, not default clutter.
  • Chord clips should be able to generate MIDI into a chosen instrument lane, drive arpeggiators, export as MIDI, and feed future bass/melody suggestion tools.
  • Hookpad is a useful reference for song-form/harmony visibility and a real chord lane under the Piano Roll. Chordbot is a useful reference for an approachable chord-progression UX. Scalar-style chord browsing is a useful reference for speed. SpaceAge should stay darker, cleaner, more tactile, and more composition-workstation-like than all of them.

Chord / Clip Arpeggiation

Arpeggiation should become a reusable performance layer rather than a one-off synth feature. A chord marker, a selected group of Piano Roll notes, or an Arrangement clip should all be able to own arpeggiation settings.

Core arpeggiator model:

  • Pattern: up, down, up/down, down/up, as played, inside-out, outside-in, random once, random each pass, chord repeat, and custom step pattern.
  • Rate: tempo-synced values such as 1/4, 1/8, 1/8T, 1/16, 1/16T, 1/32, plus dotted values.
  • Gate: note length as a percentage of rate, including legato overlap above 100%.
  • Octave range / steps: repeat the pattern through 1-4 octaves or fixed transposition steps.
  • Order offset / rotate: shift the starting point of the arp without changing the underlying chord.
  • Velocity shaping: fixed velocity, inherit chord/note velocity, crescendo, decrescendo, random range, and per-step accent pattern.
  • Swing / groove: use project swing first, then later allow per-clip groove.
  • Retrigger: off, on chord/note start, on bar, or on clip loop.
  • Commit mode: live preview, render to notes, or export generated MIDI.

Workflow target:

  • Chord Engine: double-click a chord marker to open Chord Performance. Add an ARP section beside strum controls. The chord label remains harmonic truth; the arp is performance data.
  • Piano Roll notes: selected block chords can use the same arpeggiator as a transform tool, similar to Strum or Quantize. This writes real notes unless the user chooses a live preview mode.
  • Arrangement clip level: a clip can have an optional Arp / Motion decoration that arpeggiates its contained chord markers or held notes during playback without requiring the user to permanently alter the source pattern.
  • Later library: save named arp patterns as reusable "Motion Blocks" so users can apply common guitar picking, synth arps, trance gates, pulse patterns, and broken-chord rhythms to clips.

CPU note: arpeggiation itself is cheap because it generates MIDI/control events. The expensive part is the instrument voice count it can cause. Keep note-density warnings and sane default gate/rate values.

Traditional Score Output

  • Add a way to export selected Piano Roll material, chord progressions, or whole arrangements as traditional music notation.
  • Start with MusicXML export before PDF engraving. MusicXML can be opened by MuseScore, Dorico, Sibelius, Finale, Logic, and other notation tools.
  • Later add direct PDF score rendering if the notation layout requirements become clear.
  • First target: export melody lane plus chord symbols and optional drum staff. Full orchestral-style engraving should wait until the composition model is stable.
  • This feature can support education, collaboration with traditional musicians, copyright deposits, and printable lead sheets.

Motion Blocks / Clip Decoration System

Motion Blocks are reusable, tempo-adaptable audio and modulation effects that decorate clips without changing the source material. Think of them as musical LEGO pieces: a user can drop a trance gate, linear fade, pan pattern, filter sweep, sidechain pump, delay throw, reverse swell, tremolo, or stutter onto a clip and keep composing.

Core idea:

  • Every project, including a blank project, should have a quick place to grab commonly needed Motion Blocks.
  • Motion Blocks should be near the clip workflow but not permanently clutter the main workspace.
  • They can attach to loop clips, Drum Composer patterns, Piano Roll phrases, Arranger clips, or possibly whole song sections.
  • A clip can show compact colored tags such as [Gate 1/16], [Pan Sweep], or [Fade Out].
  • Clicking a tag opens a focused editor; dragging a tag to another clip copies it.
  • Each block should have a simple shared control language: Amount or Dry/Wet, Rate or Pattern Length, Depth, Curve, Phase, Target, Bypass, and optional Randomize.
  • Trance-style gate patterns are a strong first use case: 16/32 slice pattern grid, Dry/Wet, Attack, Release, Swing, Invert, and presets such as 1/8 pulse, 1/16 pulse, offbeat chop, dotted gate, triplet gate, rising density, and breakdown fade gate.
  • Fades should support reusable curve shapes and tempo-aware lengths.
  • Panning patterns should be tempo-locked and reusable across loops or arrangement clips.

Interface ideas:

  • Start small as a clip decoration system before building a large page.
  • Add a MOTION or M button on clips, loop lanes, or arrangement blocks.
  • Later, add a full-page X-Y/matrix browser where rows are Motion Block types and columns are musical timings, targets, or pattern families.
  • The matrix should be easy to dismiss and should feel like a power overlay, not another always-visible workstation.

Design caution:

  • This is a signature feature candidate, but it could become overwhelming if exposed too early or too broadly.
  • First pass should favor a handful of excellent, obvious patterns over a giant library.
  • CPU impact should stay low: most blocks should be gain, pan, filter, send, or playback-position modulation rather than heavy inserted DSP.

Marketing angle: clips that move. SpaceAge is not only sequencing notes and loops; it is sequencing reusable musical movement.

External Plugin Hosting

  • Host VST3 instruments as optional external engines.
  • Start with one global external plugin slot before per-pad hosting.
  • Add missing-plugin warnings for collaborators.
  • Save plugin state safely.
  • Add CPU warnings before allowing many hosted plugin instances.

This is feasible but high-risk enough that it should be staged carefully.

Smart / ML-Adjacent Features

  • Auto-tag imported samples.
  • Suggest similar samples.
  • Suggest complementary pads for a kit.
  • Suggest groove variations for explicit audition/commit.
  • Auto-gain and rough auto-mix a kit.
  • Add AI-assisted patch creation for internal synths. The user should be able to describe a sound or provide a reference example, then receive a normal editable SpaceAge patch plus plain-language notes about how it was built.
  • Reference analysis should focus on legal timbral descriptors: spectral tilt, harmonic/noise balance, transient shape, envelope, modulation, stereo width, pitch stability, filter behavior, and ambience. Do not promise direct cloning of protected commercial presets or famous sounds.
  • AI-created patches should enter the same preset browser as human-created patches with engine, category, author/source, description, and "AI starting point" metadata when appropriate.

These could be premium-feeling features, but they must not make the app feel mysterious or out of the user's control. Avoid full auto-composition as a product identity. SpaceAge should help the human composer find, audition, and refine options.

Store / Commercial Ecosystem

  • Encrypted commercial sample-pack format.
  • License-aware pack installation.
  • Third-party creator metadata.
  • Pack previews and auditioning.
  • Online catalog browser.

This could become a major business direction, but it should come after the local product feels stable and desirable.

Business Model Ideas

  • Explore a single compiled SpaceAge binary with tier-based feature unlocking rather than maintaining separate free/paid builds.
  • Possible free tier: 4 tracks, full core workflow, and a 3-month evaluation window. After expiration, projects should remain safe and readable, but editing/exporting could be locked behind a calm upgrade prompt.
  • Possible Tier 1: 8 tracks, perpetual license around $8.
  • Possible Tier 2: 16 tracks, perpetual license around $16.
  • Possible Tier 3: 256 tracks, perpetual license around $32.
  • Possible Tier 4: 256 tracks plus premium customization such as full color-scheme skinning, perpetual license around $48.
  • Keep trust central: free-tier expiration must never delete, corrupt, or hold project data hostage. Message should be plain and reassuring, such as: "Your tracks are safe. Upgrade to continue editing this project."
  • Add one central license/tier state in the app, then check that state before creating new tracks/lanes or enabling premium features.
  • Avoid relying only on the local system clock for trial timing. Later, investigate a fair, privacy-conscious approach using signed license data, periodic network validation, or cumulative app-use tracking.
  • Consider a Tier 4-only ThemeManager: all colors come from a central runtime theme rather than hardcoded values, with lower tiers limited to curated factory themes.
  • Consider a $1/month content subscription focused on low-bandwidth, high-value content: MIDI packs, chord progressions, synth presets, drum kits made with stock engines, Motion Blocks, and song-form templates.
  • Avoid streaming large audio libraries at the $1/month price point unless storage and bandwidth economics are clear.
  • Consider proprietary SpaceAge-only instruments, effects, presets, and expansion packs as backend revenue. These should deepen the SpaceAge ecosystem without preventing users from exporting their own music.
  • Compare individual add-on sales versus fixed DLC expansion packs once the core product has enough users to reveal buying behavior.
  • Marketing angle: highly accessible pricing, impulse-buy friendliness, and a generous creative on-ramp without the intimidation or cost of a full commercial DAW.

LT refinement / commercial landscape notes:

  • The low-price perpetual model could be genuinely disruptive, but it only works if support cost stays low. A $8 customer can still create $80 worth of support burden if licensing, saving, audio setup, or onboarding is confusing.
  • The free tier should feel like a generous creative sandbox, not a punishment box. Avoid nag screens during composition. Upgrade prompts should appear at natural boundaries: creating track 5, exporting after trial expiration, opening an expired project, or trying premium customization.
  • A hard 3-month lock is psychologically clear, but it can create resentment if users feel surprised. Show a quiet status such as "Free tier: 41 days remaining" in the Library/About/License area, not in the creative workstations.
  • Track limits are a better tier divider than audio-quality restrictions. Never degrade export quality by tier; that feels cheap and damages the brand. Limit scale, customization, and premium content instead.
  • Tier 1 at $8 should be positioned as the "no-brainer support the project" option. It needs enough power to make real music: 8 tracks, full save/load/export, stock instruments, and the default theme.
  • Tier 2 at $16 can be the practical songwriter tier: 16 tracks, enough for drums, bass, harmony, lead, loops, vocals/stems later, and alternate ideas.
  • Tier 3 at $32 is the serious producer tier: 256 tracks, deep arrangement scale, advanced routing, and possibly future stem/export conveniences.
  • Tier 4 at $48 should not merely be "more tracks" if Tier 3 already has 256. It needs identity features: full theme/skin access, premium factory content, advanced Motion Blocks, or included first-year content subscription.
  • Consider bundling 12 months of the $1 content subscription with Tier 4. That makes Tier 4 feel meaningfully different while preserving the possibility of ongoing content revenue.
  • Keep a "Founder's License" idea in reserve: early buyers get Tier 4 at a special price and permanent gratitude/status. This can generate early community energy without requiring the app to pretend it is finished.
  • Avoid aggressive DRM. A lightweight signed license file plus occasional optional account verification is probably a better fit for the brand than invasive copy protection.
  • The code should separate creative capability checks from licensing UI. Example: LicenseState answers "how many lanes may exist?" while the editor decides how to explain the limit beautifully.
  • All tier checks should fail gracefully. If license validation fails offline, prefer a grace period over immediate lockout. Musicians remember the one night software betrayed them.
  • Build toward an in-app "License / Account / Content" page eventually, but do not let store mechanics dominate the main workflow. SpaceAge should feel like an instrument first, shop second.
  • Expansion packs should be designed as creative worlds rather than random SKU clutter: "SpaceAge Analog Drums", "Glitch Orbit", "Cinematic Percussion", "Bass Machines", "Motion Blocks Vol. 1".
  • The $1/month subscription should probably start as "monthly creative fuel": small, delightful packs that load quickly and feel hand-curated. The danger is promising too much content and turning it into a treadmill.
  • The strongest business hook may be: a microDAW that is cheap enough to impulse-buy, deep enough to finish ideas, and weird enough to love.
  • Product-positioning question to keep chewing on: SpaceAge is probably not "another DAW." It is closer to a groovebox/microDAW hybrid with song-arrangement ambition. That gives us permission to be focused and opinionated.
  • Open-source promise if abandoned: this is brand-positive, but should be worded carefully. Possible promise: "If commercial development permanently stops, we intend to release the source in a way that gives the community a path forward." Avoid boxing the business into legal promises too early.
  • For release readiness, licensing should come late. First make the workflow so satisfying that the tier model feels like a way to support and expand something users already want.

Songwriting Tools

  • Chord chart under Arrangement blocks.
  • Section-based color themes.
  • Lyric / note lanes.
  • Song form templates.
  • Render stems by section.

These are attractive because they move SpaceAge from beat box toward songwriting environment.

Composition Intelligence

  • Keep the chord and scale tools human-led: the user chooses, auditions, commits, and edits.
  • Expand Scale Lock into a broader composition-helper system: optional scale-constrained drawing, dragging, transposition, chord suggestions, bass-follow behavior, and safe-note teaching overlays.
  • Add chord progression import/export so users can build and share harmonic libraries.
  • Add chord-performance helpers: strum timing, per-voice velocity shaping, inversion shortcuts, preserve-end behavior, and render-to-notes when the user wants fully editable MIDI.
  • Add arpeggiator pattern presets at the chord, clip, and instrument level while keeping every generated result renderable into ordinary editable notes.
  • Keep every suggestion reversible and ordinary after commitment. No mysterious locked "AI music" objects.

Power User Shortcuts

  • Add optional Shift-modified accelerators for advanced users once the core workflow is stable.
  • Candidate gesture: Shift-click the Pad CREATE control to clear/zero everything related to that pad after a confirmation or with undo protection.
  • Candidate gestures: Shift-click save/load/clear actions for batch operations, Shift-drag for duplicate/clone behavior, and Shift-modified Arranger operations for fast clip duplication or range actions.
  • These shortcuts should never replace visible controls; they should reward expert use without becoming required knowledge.

Advanced EQ

  • Evaluate replacing or augmenting the current 16-band per-pad EQ with a 64-band mode.
  • Add per-band Q controls if the interface can expose them without overwhelming the user.
  • CPU caution: 64 bands per pad across 64 pads can become very expensive if every band is a live biquad. Prefer optional activation, only process non-flat bands, and consider a shared/selected-pad editor view rather than always-active full-bank processing.
  • Consider modes: 16-Band Fast, 32-Band Detailed, and 64-Band Surgical, with clear CPU expectations.
  • Add a lightweight channel-strip musical EQ in a hidden mixer panel: low shelf, sweepable mid bell, and high shelf. This should be the everyday mix EQ, while 64-band EQ remains a later surgical/power-user feature.

Physical Bass Guitar Synth

  • First playable pass implemented as the Physical Model engine's Bass Guitar model, with five Moondagger presets available from Piano Roll presets and Physical Model starting points: Finger Bass, Pick Bass, Dub Bass, Harmonic Bass, and Growl Bass.
  • Use waveguide/plucked-string ideas as the core, with Csound-style physical modeling as research inspiration.
  • Current model uses a plucked-string delay line with pickup/bridge taps, damping, dispersion, body resonance, velocity-sensitive excitation, finger noise, fret growl, and light saturation.
  • First controls should be musical rather than academic: pluck position, pickup position, damping, body resonance, attack type, growl, glide, and velocity-to-brightness.
  • Start with monophonic bass behavior and optional legato/glide before polyphony. Bass lines usually benefit more from feel and articulation than from full polyphony.
  • Presets should cover finger bass, picked bass, muted thump, growly upright-ish bass, rubbery synth-bass hybrid, and short staccato test sounds.
  • Next improvements: true mono/legato behavior, portamento, explicit pickup/pluck controls, palm mute, fret position/noise controls, amp/cab coloration, and a dedicated Moondagger lane-instrument panel once the Instrument Bay is fully independent.
  • CPU caution: physical modeling can become expensive if every voice uses high-order resonators. Keep voice count controlled and add quality modes only after the first instrument is stable.

Arranger Snap / Grid Editing

  • Add Arranger SETTINGS for Snap to Step during group moves and pastes.
  • Add a Snap Selected command with a dropdown for grid size: step, 1/2 step, beat, bar, and possibly musical subdivisions if the timing model expands.
  • Default should probably be snap-on for most users, with a modifier key or toggle for free movement.
  • The old Selected Section | Slot X space can be repurposed for snap controls because the selection status is already visible elsewhere and consumes valuable Arranger workspace.

Arranger Trainwreck Audit

These are the failure modes to keep testing as the Arranger becomes the center of SpaceAge:

  • Same-lane overlap: a clip can appear to vanish because another clip sits on top of it. Rule: real clips should not stack unless we intentionally build a future layer mode.
  • Gap semantics: preserved silent gaps must behave like selectable timeline objects when helpful, but should disappear or split cleanly when a real clip occupies that time.
  • Drum-lane drift: the Drums lane should not depend on a different mental model than Bass, Harmony, Melody, or user-added lanes. Any old chain-slot fallback should keep shrinking until all lanes behave identically.
  • Pattern length drift: if a clip is reassigned to a pattern or resized, the canvas width, pattern length, and playback duration must agree immediately.
  • Clone/paste target ambiguity: cloning should fill obvious open space first, then push later material only when necessary. Pasting at the playhead should be explicit and predictable.
  • Selection invalidation: actions that consume gaps or rebuild clips can change clip indices. Selection should follow the user-visible clip, not a stale internal number.
  • Multi-lane group moves: moving mixed clips must preserve their relative timing and avoid creating hidden overlaps on any involved lane.
  • Undo checkpoints: every destructive or structural Arranger action needs an undo checkpoint, including lane creation, clip add/remove, length edits, paste, section edits, and future marker presets.
  • Snap consistency: playhead, loop range, section markers, clips, paste targets, and group moves should use the same snapping language unless the user deliberately enables finer behavior.
  • Section marker non-destruction: section markers are composer guidance by default. They should not rearrange clips unless a future command clearly says it will insert/remove time.
  • Long imported MIDI: Drum Composer can stay drum-machine-shaped, but long melodic clips may need a separate linear piano-roll editor path so imported phrases longer than 64 steps do not feel artificially chopped.
  • Visual feedback: when a clip is selected, dragged, cloned, made unique, or placed into a gap, the UI should communicate the result before the user lets go whenever possible.

Invader-Inspired Synth Direction

  • Study E-Phonic Invader as a workflow reference for a direct, vintage-style VA polysynth: dual oscillators, unison, noise, hard sync, ring modulation, multimode filter, envelopes, LFOs, velocity control, delay, arpeggiator, step sequencer, MIDI learn, and patch browser.
  • Build our own SpaceAge synth with original code and sound design rather than cloning protected implementation or artwork.
  • CSound algorithms are a useful research source for oscillators, envelopes, filters, FM, resonators, waveshaping, and physical-model-inspired voices, but imported ideas must be translated into original JUCE/C++ implementations.

Baked-In Instrument Roadmap

Goal: make beta testing musically rewarding before VST hosting exists, and give SpaceAge a recognizable factory sound.

  • SpaceAge VA: a fast subtractive polysynth inspired by classic virtual analog workflow. Focus on basses, plucks, pads, simple leads, chord stabs, unison movement, musical envelopes, and immediately useful presets.
  • Kick Lab: a dedicated kick synth using pitch envelopes, click/transient layers, sine/triangle bodies, saturation, soft clipping, noise thumps, and optional modal/body resonances. First pass is implemented with 24 starting points; future work should add visual envelopes, macros, and deeper sample-export workflows.
  • 808 Lab / name TBD: a tuned 808/sub generator designed to partner with Kick Lab rather than compete with it. It should generate playable long-tail 808s, expose glide/keytracking/ADSR/tone/saturation, render to WAV, save presets, and support one-click sidechain pairing with selected Drum Lab kicks or automatic pairing from low-frequency kick events.
  • Modal Objects: tuned percussion and physical-model-flavored sounds: marimba, plucked metal, ceramic hits, bells, kalimba-ish tones, bowed/struck hybrids, and experimental resonators.
    • A440 tuning must be treated as a core requirement, not a nice-to-have. Pitched physical presets should follow equal-tempered MIDI note math so they can be used in Piano Roll and Chord Engine contexts.
    • First useful set: tuned marimba, xylophone, soft bell, temple bell, glass bar, tabla dayan, tabla bayan, and tabla na/tin-style hits.
    • Future tabla work should become a dedicated loaded-membrane model rather than a generic membrane preset if we want it to feel credible to percussionists.
  • FM Percussion / Keys: compact FM engine for metallic percussion, electric-piano-like stabs, glassy tones, and strange melodic timbres.
  • DX-Compatible FM / name TBD: a six-operator FM engine inspired by the classic DX workflow, with clean-room or permissively licensed code only. Desired compatibility: load original-style DX-7 single-voice and bank SysEx dumps, map the 32 algorithms, operator ratios/fixed frequencies, envelopes, feedback, key scaling, velocity response, pitch envelope, and modulation into a SpaceAge-native instrument. Guardrails: do not copy Dexed GPL code, do not ship Yamaha-owned factory patches unless rights are cleared, and treat Dexed as an external compatibility benchmark rather than source material. This connects directly to the MIDI SysEx work because patch import/export should use the same guarded SysEx parsing, Vault, and Hardware Passport mindset instead of becoming a one-off importer.
  • Moonshadow: first playable pass implemented as a focused spectral-modeling instrument, using original additive partial synthesis rather than copied analysis/resynthesis code. It has spectral models, brightness, stretch, inharmonicity, tilt, motion, noise, width, attack character, amp ADSR, spectral ADSR, filter/vibrato/gate, chorus, and reverb sends. Future work: partial visualization, more factory presets, sound-import analysis, and performance profiling before expanding into full SMS territory.
  • Spectral Toybox later: use STFT/SMS-style ideas for tonal/noise balance, spectral filtering, inharmonic stretching, and resynthesis-inspired manipulation. This should wait until Arranger stability is higher because it is more CPU and complexity sensitive.
  • Factory preset standard: each engine should ship with musically named starting points, gain-matched output, no surprise clipping, and a few “wow immediately” patches for first-run delight.
  • CPU rule: every expensive mode should be opt-in, selected-pad focused where possible, and measured against the current 5-12% baseline so SpaceAge does not become a bloated instrument.

Chord Engine Expansion

  • Keep expanding the Chord Engine as a theory-aware composition helper, not an auto-composer.
  • Scale vocabulary should include common Western modes, pentatonics, blues scales, harmonic/melodic minor modes, diminished scales, whole-tone scales, Hirajoshi-style pentatonics, Phrygian Dominant, Neapolitan, Double Harmonic, Persian, Enigmatic, Romanian, Hindu, and other accurately defined interval collections.
  • Chord vocabulary should include diatonic triads/sevenths, sus chords, add chords, sixths, ninths, altered dominants, diminished/half-diminished/augmented chords, quartal voicings, power chords, and special sonorities such as Promethean/Mystic-style chords.
  • Chord marker editing should eventually support drag-resize from either edge, right-click paint-delete, Ctrl+U slicing, strum, arpeggiation, velocity shaping per voice, import/export of chord progressions, and suggestion workflows based on selected melody notes.
  • Chord detection from imported MIDI is feasible as a "detect and suggest" workflow. Analyze notes in time windows, collect pitch classes, infer root/quality/inversion, choose likely harmonic boundaries, then write editable Chord Engine markers. It should allow manual correction because MIDI harmony is often ambiguous.
  • Current Chord Engine direction: suggestion hexes should behave like a human-led theory assistant. They should rank candidates from selected melody notes first, then notes under the playhead, then nearby pattern material. Hexes should explain themselves with small tags such as SAFE, COLOR, TENSION, and melody-fit counts.
  • Initial borrowed-chord support is now architectural rather than cosmetic: Chord Markers can store a root semitone offset, so borrowed-key, secondary-dominant, and chromatic-mediant honeycomb candidates can play, export, save, reload, and display with the intended non-diatonic root. Future work should expose a fuller "Borrow From..." interface rather than making the user infer the source key from individual candidates.
  • Chord Engine MIDI export should remain first-class. Pattern MIDI export and full Arrangement MIDI export should include Chord Engine markers as normal MIDI notes so collaborators can use the harmonic work outside SpaceAge.
  • Near-term Chord Engine work: progression import/export, strumizer-style batch transforms, chord voicing preview, ghost harmony from other lanes, and melody-fit hex suggestions with more relevant substitutions. Recent pass expands multi-selected chord marker transforms: Ctrl+U chopping and quality/inversion dropdown edits now work across selected chord groups.
  • Chord inversion display should use slash-bass labels (C/E, Dmin7/F, Cmaj11/E) rather than inv1-style labels. Upper-extension inversions are theoretically possible but should stay advanced/hidden until there is a clear workflow reason to expose them.
  • Future Chord Engine analysis helper: detect and explain contextual 6/4 triads as cadential, passing, or pedal/neighboring when enough surrounding harmony exists. Keep the normal marker label simple (C/G) and make the functional explanation optional.

Reverb / Delay Aux Roadmap

  • Current architecture already uses shared reverb and delay returns fed by per-channel sends, which is the correct CPU-friendly foundation.
  • Next expansion should add named aux return slots such as Reverb A, Reverb B, Delay A, and Delay B, with channel strips choosing send levels into each slot.
  • Keep all extra aux returns opt-in. Multiple reverbs and delays can become expensive if every return is active by default.
  • UI should expose common sends in the mixer first, then hide advanced aux routing in a clean popup or hidden channel-strip panel.
  • Long-term: allow clip-level "delay throw" and "reverb bloom" Motion Blocks without forcing permanent mixer-send changes.

Cassette Outlander

  • Future tape simulation effect concept: saturation, bias, wow/flutter, head bump, tape age, hiss/noise, dropout, dulling, and unstable transport movement.
  • Keep it permissive/original: no GPL DSP, no copied tape-machine code, and no external assets unless their licenses are documented.
  • Good home: hidden channel-strip panel first, then a future Orbit/effects rack if the effect grows into a character processor.

Internal Instrument Professionalization

  • Keep docs/Internal_Instrument_Audit.md current as the product-readiness map for built-in synths, samplers, and drum labs.
  • Finish patch-save/load parity, factory presets, init patches, dirty-state display, and preset metadata for every public engine.
  • Keep mixer sends out of instrument patch identity. Instruments should not silently change channel-strip sends when a preset loads.
  • Give every tonal engine A440 verification, chord-safe preset QA, pitch-bend/mod-wheel behavior, panic reliability, and CPU-safe quality settings.
  • Give every sample-based engine missing-file repair, archive awareness, root-note/tuning helpers, and metadata.
  • Give every drum/lab engine render-to-sample, level normalization, transient safety, and Flux Nodes compatibility where useful.
  • Add preset save/load inside the Flux Nodes popup so users can reuse detailed per-hit variation setups across sounds and projects.

Redshift Maturity Roadmap - 2026-08-27

  • Maintain docs/Redshift_User_Manual.md alongside every user-visible Redshift change.
  • Finish Tone Motion trigger semantics, live arcs, reusable Tone Scenes/Motion Blocks, and expanded portamento.
  • Single-cycle waveform sources are now independent for Oscillator 1 and 2. They reuse Prismatic Temple's broad library/category concepts and asset provenance where appropriate, but use an oscillator-native, anti-aliased mipmapped renderer.
  • Built-in AKWF and User Library categories, direct dropdown selection, previous/next source browsing, deterministic import cleanup, portable archive collection, explicit missing-file repair, and bounded background preparation are implemented. Recents and persistent favorites are also implemented; add phase-start controls next. Text search by cycle name or category is implemented. Independent phase start, key reset, bidirectional source morph, octave/semitone/fine tuning, and tempo-synchronized A-to-B pitch motion are implemented independently for both oscillators.
  • Later candidates: oscillator-level waveform-position or morph modulation and optional dedicated morph-target slots if sound design proves the shared two-source workflow too limiting.
  • Redshift Pitch Motion setups can now be saved and loaded as narrowly owned .ssmotion files. Keep these synth-level blocks distinct from future clip-decoration Motion Blocks even if both later share a browser vocabulary.
  • Keep table import optional and CPU-bounded. Do not turn Redshift into a fifth sample layer or allow table assets to carry Mixer/lane ownership.

Design Guardrails

  • Keep common actions one click away.
  • Hide advanced power behind clear buttons, tabs, or popups.
  • Avoid adding visible controls just because the engine supports them.
  • Prefer a small number of excellent workflows over many half-finished options.
  • Any CPU-expensive feature should be opt-in and clearly marked.
  • Every advanced feature needs a fast escape hatch back to simple beatmaking.
  1. Stabilize lane-owned instrument workflow: lane instrument selector, preset readability, mixer ownership, MIDI input lane clarity, and save/load recall.
  2. Formalize clip instance versus pattern payload behavior so clone, variant, resize, paste, delete, and MIDI export stop relying on fuzzy assumptions.
  3. Continue Chord Engine composer tools: honeycomb audition/commit, borrowed-chord UI, chord progression copy/paste, and render-to-notes workflows.
  4. Make SoundFont feel like a first-class workstation instrument: preset state, repair paths, archive awareness, and meaningful controls.
  5. Continue piano roll polish and MIDI export/import.
  6. Add automation/Motion Blocks only after the timing/snap vocabulary is shared.
  7. Improve Pad Vault editing and tagging.
  8. Add MIDI output/hardware sequencing with lane-owned Hardware Passport targets.
  9. Revisit VST hosting after the Instrument Bay and lane ownership model are solid.

Lane Audio Stem Export - Implemented Foundation (2026-08-02)

  • RENDER now offers a time-aligned lane-audio package: one stereo 24-bit/48 kHz WAV per Arrangement lane and a manifest describing lane, Instrument, Mixer, route, mute/solo, and silence state.
  • Future refinements: pre/post-Master choice, dry-versus-return separation, selected-lane export, render-in-place/freeze, Scene comparison packages, optional archive ZIP, and collaborator-facing package import/relink.
  • Preserve the current foundation: Arrangement-lane isolation before Mixer processing, one captured project state, explicit hardware-MIDI suppression, progress/cancellation, and atomic package publication.