Answers for Shane

2026-07-14 - How Automation Ownership Works Now

Automation can edit three real ownership scopes. Shared PTN belongs to the reusable pattern, Clip Local belongs to one Arrangement clip, and Lane Local belongs to the Arrangement lane. During playback and Arrangement export, SpaceAge layers Shared PTN first, Lane Local second, and Clip Local last. That makes the most specific musical context win when the same controller appears at the same time. Shared edits still warn when several linked clips will change; local owners do not need that warning.

Where MIDI 1.0 Stands Right Now

The MIDI 1.0 backend foundation is in the high-90s: SpaceAge can recognize, preserve, route, import, export, and safely classify most of the protocol families that matter for a DAW. That includes notes, velocity, pitch bend, pressure, controllers, program/bank data, channel-mode messages, RPN/NRPN review, SysEx storage/recall scaffolding, timing, hardware routes, and owner-scoped Automation editing.

The remaining work is not mostly "can we parse the bytes?" It is "can the user trust the visible workflow?" That means finishing the Automation editor polish, MIDI Learn polish, hardware setup/test receipts, bend-range trust for external gear, SysEx validation on real hardware, import/export edge cases, and clear guidance for hardware users.

For Yamaha XG / Roland GS style editors, the correct path is now explicit in the model. Hardware templates can say "Yamaha XG editor profile" and list what must be verified before controls unlock. Until a Data List or MIDI Implementation chart confirms model id, SysEx addresses, ranges, labels, checksum rules, and safe queue behavior, SpaceAge may show a locked editor plan but should not send deep parameter edits.

The newest pass makes that lock visible in MIDI SETUP and in copied template previews. That matters because a hardware editor should feel like a deliberate, trustworthy promise, not a hidden engineering note.

Library Starfield Background

Yes, the arcade-style "moving through a starfield" background is absolutely feasible in JUCE. The clean version would be a custom lightweight Component painted behind the Library controls, not a movie or bitmap sequence.

The implementation would keep a small array of stars with x, y, z, size, and brightness values. A timer advances the stars toward the viewer, projects them around a vanishing point, and resets each star once it passes the camera. Most stars should draw as single-pixel white or gray dots; a few rare stars can be 3-5 pixels. With roughly 80-160 stars and simple rectangle/ellipse drawing, CPU cost should be tiny.

The important product guardrails: keep the alpha low so it does not compete with Library buttons, pause the animation whenever the Library is not visible, and later add a Reduce Motion option in Settings for users who dislike animated backgrounds. This is a good fit for SpaceAge because it adds atmosphere without adding interaction complexity.

Current Architecture Recommendation

The most important next architectural move is to formalize lane-owned instruments and the difference between Clip Instance and Pattern Payload. The Clip Instance lives on the Arrangement Canvas and owns lane, start, length, and timeline behavior. The Pattern Payload owns musical content: drum steps, Piano Roll notes, Chord Markers, automation, and future Motion Blocks.

This distinction explains a lot of previous Arranger bugs. If a user shortens a 16-step clip to 8 steps and then clones it, the app must know whether it is cloning an 8-step clip instance, a 16-step payload, or creating a new 8-step variant. The correct user-facing behavior should be obvious, and the code should not guess silently.

The next best sequence is: stabilize lane instrument identity, formalize clip/payload behavior, keep expanding Chord Engine workflows, then polish SoundFonts as workstation instruments. That order gives SpaceAge the most architectural strength while still making the app more fun to test.

How To Capture A Quasar Instrument

Quasar is SpaceAge's proprietary multisample format. It turns a playable tonal patch into a folder package containing rendered WAV zones plus a manifest. The practical value is that a beautiful but CPU-heavy patch can become a lighter sampled instrument that still feels integrated with the rest of SpaceAge.

The capture workflow is:

1. Start with a tonal source engine such as Redshift, Physical Model, SoundFont, Propulsion 1, Liftoff, Glass Moon, Moonshadow, or Lunacy.
2. Load or design the patch you want to capture.
3. Audition it in a few registers and with a few chords if it is meant to be chord-friendly. Quasar captures the patch honestly; it will not magically fix bad tuning, hidden oscillator offsets, or inharmonic chaos.
4. Open the Synth Engine editor for that instrument.
5. Go to the Quasar page.
6. Click BUILD QUASAR.
7. Choose the Quasar capture settings: range, root spacing, velocity-layer count, round-robin count, render length, loop policy, and whether to peak-normalize the generated samples.
8. SpaceAge opens a progress window and renders the patch using the selected root spacing across the selected range, velocity layers, and round-robin count. Minor-third roots are the balanced default; whole-tone roots are smoother and larger; fourths or octaves build faster with fewer samples. Round robins capture multiple versions of the same note/velocity so repeated notes can rotate instead of feeling static. Long captures are expected to take a while; the progress window exists so the app feels alive instead of stuck.
9. SpaceAge writes a .ssquasar folder package into the Quasar Instruments folder. The package contains manifest.json, a Samples folder, rendered WAV files, source engine metadata, source parameter metadata, and the capture settings used to make the package.
10. When the build succeeds, SpaceAge automatically loads the new Quasar package onto the same instrument, switches the editor to Quasar, and refreshes the lane/instrument labels so it can be played immediately.
11. Use REVEAL PACKAGE to inspect the generated package folder, or LOAD QUASAR to load a saved Quasar package later.

The current capture spec is intentionally practical: selectable root spacing, selectable ranges, 1-4 velocity layers, 1x/2x/4x round robins, deterministic ASCII filenames, optional peak normalization, and selectable sustain-loop metadata. Future passes should add editable loop points and a dedicated Instrument Bay browser.

DX-7 Compatible FM Synth Feasibility

A DX-7-compatible internal FM synth is technically feasible. The original DX-style architecture is well understood: six sine operators, 32 algorithms, operator envelopes, ratios/fixed-frequency modes, feedback, velocity scaling, keyboard scaling, pitch envelope, LFO/modulation routing, and SysEx patch/bank formats. The hard part is not mystery; the hard part is exact behavior, tuning, envelope response, patch import fidelity, and avoiding code/licensing traps.

The safest SpaceAge product path is a clean-room or permissively licensed implementation that can import original DX-7 .syx single-voice and cartridge/bank dumps, then map those parameters into our own engine. That would let users bring classic public-domain or personally owned DX patches into SpaceAge without us shipping Yamaha factory banks or copying another plugin's protected code.

Dexed is useful as a reference and compatibility benchmark, but its main project license is GPL, so we should not copy Dexed code into proprietary SpaceAge. Dexed credits the Music Synthesizer for Android FM engine, which is Apache-2.0 and therefore potentially more compatible, but any direct use still needs a commit-level license audit. My recommendation is: build a SpaceAge-native FM engine, use public DX architecture/SysEx documentation for compatibility, use Dexed only as an external behavior comparison, and ship no Yamaha-owned patch banks unless their rights are explicitly cleared.

SoundFont Direction And Workflow

SoundFonts should become first-class lane instruments, not just a hidden kind of sample playback. The E-mu / Creative lineage matters here: the SoundFont idea sits much closer to hardware-sampler/workstation thinking than to a random folder of WAV files. That makes it a strong fit for SpaceAge because it gives the app immediate piano, bass, strings, brass, percussion, and General MIDI-style testing power while we continue building our own native instruments.

The best workflow is lane-owned: a lane chooses a SoundFont file, a bank/program/preset, and a few meaningful patch controls. The mixer owns gain, pan, sends, EQ, compressor, saturation, and output routing. Duplicating mixer controls inside the SoundFont patch page will create confusion, so the SoundFont page should focus on sound-source behavior: preset, tuning/transpose, ADSR, filter/resonance, velocity response, vibrato, pitch bend range, and maybe modulation controls that genuinely belong to the instrument.

Large General MIDI SoundFonts are especially useful, but they also push us toward a cleaner Instrument Bay and lane-owned Instrument model. A GM SoundFont can technically contain many instruments, yet normal SpaceAge lanes should still behave as one lane = one chosen instrument/preset. Later, a dedicated polytimbral lane can handle deliberate multi-channel General MIDI, XG hardware, or multitimbral VST workflows.

Why MIDI Can Still Feel Late

SpaceAge can minimize its own MIDI scheduling, but the total feel of a played note is bigger than the MIDI event itself. Host/plugin MIDI keeps JUCE's in-block sample positions before voice rendering. SpaceAge-opened physical MIDI devices use the earliest drain-block monitor path for notes and controllers, and external live-thru now goes straight into the hardware router instead of waiting for the generic pending-output flush.

SpaceAge now tracks that hardware-output handoff, too. If external hardware feels late, MIDI Health can distinguish direct input queue age from hardware output queue age. That tells us whether the controller side is late, the output router is backing up, or the delay is probably outside SpaceAge in the audio driver, interface, synth response, monitoring path, or buffer size.

If live playing still feels late, the first suspects are audio buffer size, audio driver/interface latency, controller/device response, duplicate host/direct routing, SoundFont or instrument voice-start cost, and external hardware monitoring. Recorded-timing alignment is a different tool: it helps recorded events land where the performance intended, but it should not be sold as a cure for live controller or audio-monitoring lag.

Are We Implementing MPE In This MIDI Pass?

Not true MPE yet. This MIDI pass is making SpaceAge strong at MIDI 1.0: notes, channels, controllers, pitch bend, pressure, poly aftertouch, program/bank data, RPN/NRPN, SysEx storage, timing, routing, import/export, diagnostics, and shared-PTN Automation automation.

SpaceAge can already preserve and report MIDI that looks MPE-like, meaning expressive MIDI spread across channels with pitch bend, pressure, poly pressure, and timbre-style controller data. That is valuable because imported or recorded expressive performances should not be flattened or thrown away.

But true MPE is a bigger promise. It needs explicit zone setup, master/member channel ownership, per-note channel allocation, per-note bend/timbre/pressure rules, instrument response, import/export validation, and hardware/plugin verification. Until those parts exist, SpaceAge should say "MPE-like MIDI 1.0 expression preserved" rather than "MPE supported."

MIDI 2.0 is also future work. UMP packets, Profile Exchange, Property Exchange, higher-resolution controller domains, and device negotiation should be designed as their own protocol layer after the MIDI 1.0 hardware workflow feels trustworthy.

Are Effects Applied Per Pattern?

No. Halostar, EchoRay, Reverb, Chorus, Flanger, Phaser, Tremolo, and Octave are still shared send/return effects, not per-pattern inserts. A pattern stores musical material such as drum steps, Piano Roll notes, Chord Markers, and shared PTN MIDI automation/expression data. The effects rack is closer to a shared studio rack: pads, mixer channels, and loop processors can send signal into those shared returns, and the active return settings live at the project/mixer level.

The distinction matters because if Pattern 12 plays through Lane 5, it inherits whatever Lane 5 / Mixer channel is sending into Halostar or EchoRay at that moment. The pattern itself does not carry a private Halostar or EchoRay instance. Future Motion Clips or clip decorations may create clip-local effects behavior, but that should be a deliberately labeled feature, not a hidden change to ordinary patterns.

There is one implementation nuance: EchoRay has shared global character/return controls, but its delay histories are per pad/channel. That means it is still not per-pattern, but it also is not one identical global delay memory for every sender. Loop tracks also have their own Halostar/Reverb/EchoRay send amounts.

Halostar And EchoRay Sends

Halostar, Reverb, EchoRay, and the other shared rack effects are send/return effects. A channel or pad has to send signal into the return, and the return effect has to be active. To avoid dead-feeling sends, SpaceAge now auto-enables the shared return when a send is raised above zero from either the Mixer strip or the Effects page selected-send bank.

On project restore, SpaceAge also checks saved pad/channel sends and loop sends. If a saved send is already above silence, the matching shared return wakes up so the project does not reopen with visible send values feeding a dead effect path.

How To View Automation Today

The automation-row work is not a full Arrangement-style automation lane system yet. The current user-facing doorway is Automation, which is reachable through the AUTO button and visible Automation strip in the Piano Roll, through MIDI TASKS > Automation (CC / Bend / Pressure)..., through SETTINGS under the sequencer/MIDI tools, through the Arranger lane SIGNAL / MIDI menu, and from the Arranger lane badge labelled AUTO. The badge stays deliberately stable: it can mean existing Automation data or a ready doorway for the selected lane/clip context, while the opened editor reports the exact target owner. Empty Arrangement lanes do not show the automation doorway, because there is no pattern context to edit yet.

Important ownership rule: Automation edits the owner named in its selector. Shared PTN changes every linked clip using that PTN and retains the VARIANT / ACK SHARED guard. Clip Local changes one Arrangement clip. Lane Local changes the lane overlay.

Clicking an Arranger AUTO badge opens Automation using a predictable target order: selected real clip on that Arrangement lane first, clip under the Arrangement playhead second, and the first real clip on that lane only as a fallback. It focuses that clip's pattern/source context, but it still edits shared PTN automation/expression data such as CCs, pitch bend, channel pressure, poly aftertouch, sustain, and similar performance rows.

To create automation today: select or create the clip/pattern you want to edit, open Automation, choose the controller type in the create strip, then use ADD POINT or DRAW RAMP at the playhead. Imported or recorded CC, pitch bend, pressure, and sustain data will also appear there as rows. The Piano Roll's direct AUTO button lights blue when the current pattern already has Automation. If an Automation row is selected, the create strip targets that selected row until CLEAR TARGET is clicked; after that, the dropdowns create or target a row. Protected setup messages such as Bank, Program, RPN, NRPN, and Data Entry belong in MIDI PATCH, not the performance automation row editor.

Automation now supports Shared PTN, Clip Local, and Lane Local ownership. Motion Clips remain future architecture, but clip/lane-local MIDI expression is implemented, visible, persisted, played, and exported.

Effects CPU And Wet Sends

The safe assumption is: enabled shared effects may have a small baseline CPU cost, but the larger musical cost appears when channel strips actually send audio into them and the return path has work to do. SpaceAge should continue moving toward bypassing or sleeping expensive processors when their return is disabled, their send levels are effectively zero, or no audio is reaching them.

The current channel-strip sends for reverb, delay, chorus, flanger, phaser, and tremolo should all bind to one shared set of per-pad/channel parameters. If the same send appears on the Effects page and in the Mixer, both controls must represent the same value rather than creating parallel hidden states.

VIB SYNC is intentionally a rate-sync option only. Vibrato depth remains a normal depth amount for now; syncing depth would imply rhythmic modulation of modulation depth, which is a different feature and should be handled later as a Motion Block, LFO routing, or modulation-lane idea.

SysEx Dumps And Hardware Presets

SysEx should be treated as a hardware librarian feature, not as ordinary note data. A SysEx dump can represent a preset, bank, device setup, or performance state, and sending it casually during playback could overwrite hardware or create confusion.

The safer SpaceAge model is:

• Capture SysEx dumps explicitly from a Hardware / Librarian panel.
• Name and tag them by Hardware Passport.
• Store them in projects and complete project archives when the user chooses.
• Send them back only after an explicit confirmation.
• Use device identity checks when possible.
• Throttle transmission so older hardware is not overwhelmed.
• Validate checksums when the format supports it.
• Keep a plain-language session log of what was sent and when.

This keeps hardware support powerful without creating invisible danger. Preset-loading SysEx should feel like recalling a hardware snapshot, not like a mystery packet flying out of the DAW.

The most important trust distinction is this: stored bytes, queued sends, device responses, and manual verification are not the same proof. Stored bytes mean SpaceAge has captured or imported a framed SysEx dump. A queued send means SpaceAge sent or scheduled bytes after confirmation. A device ACK/NAK/WAIT/CANCEL response is hardware-originated evidence when the device sends a recognizable reply. Manual verification means the user checked the external synth and confirmed the patch, bank, sound, or device state. SpaceAge should never flatten those into one vague "restored" claim.

MIDI Guitar And Wind Controller Users

MIDI guitar and wind-controller players are a strong niche for SpaceAge because they often feel underserved by DAWs. The opportunity is not just "accept MIDI"; it is making expressive MIDI feel safe, readable, and musical.

For MIDI guitar, the best features are per-string MIDI channel support, bend-range checks, false-trigger filtering, low-velocity cleanup, string-aware quantize, strum timing preservation, fretboard/chord visualization, and pitch-bend-to-slide conversion. The goal is to preserve the human gesture without letting tracking artifacts turn into messy editing.

For wind controllers, the important features are breath CC shaping, velocity-from-breath options, aftertouch/bite/vibrato mapping, monophonic legato defaults, scale-safe pitch bend, and a panic/breath-reset helper. Wind players need SpaceAge to understand that breath is part of the instrument, not just an extra CC lane.

My recommendation is to create lane profiles later: MIDI Guitar, Wind Controller, MPE Expressive, and Standard Keyboard. These profiles would set sane defaults for recording, quantize, pitch bend, expression display, and cleanup without hiding advanced controls from power users.

Physical Modeling And A440 Pitched Percussion

The Physical Model engine should treat pitched models as equal-tempered instruments when used melodically. The clean internal rule is: MIDI note 69 is A4 at 440 Hz, MIDI note 60 is C4, and the Physical Model Tune control offsets from C4 in semitones unless an incoming Piano Roll note supplies the pitch.

That means a physical marimba, xylophone, bell, or tuned tabla-inspired hit should be testable with ordinary musical expectations. If a pad says A4, it should be close to 440 Hz. If a Piano Roll lane plays C4 to E4 to G4, the physical model should follow those notes rather than only changing timbre.

Tabla can be approximated with physical modeling, but a truly convincing tabla is its own serious project. Tabla drums have loaded membranes and complex inharmonic modes that still create a recognizable pitch center. For SpaceAge, the practical first step is tabla-inspired: dayan, bayan, and na/tin-style starting points that are useful in electronic patterns. Later, a dedicated tabla model could expose stroke types, pitch bend, pressure/tension modulation, sympathetic body resonance, and realistic damping.

The Puget Sound music theory text is a good reference source for theory sanity checks: scale spelling, roman numerals, cadences, figured bass, mode mixture, modulation, and general convention. We should use it as a cross-check, not as a substitute for our own tests and musical listening.

Chord Inversions And 6/4 Labels

For customer-facing labels, the cleanest path is slash-chord notation. Instead of showing inv1, SpaceAge should show labels such as C/E, F/A, Dmin7/F, or Cmaj11/E. This is familiar to songwriters, jazz/pop musicians, DAW users, and theory-aware users without forcing them into classical figured-bass notation.

Extended chords technically have more possible inversions: 9th in the bass, 11th in the bass, and 13th in the bass. Those are mathematically valid, but they can become ambiguous or muddy quickly. For the current UI, root through third inversion is a sensible default. Upper-extension inversions can become an advanced voicing feature later if users need it.

A 6/4 chord is just a second-inversion triad in surface labeling, such as C/G. The deeper theory is contextual: cadential 6/4, passing 6/4, and pedal or neighboring 6/4 all describe how the harmony behaves around that chord. That should become a future Chord Engine analysis/suggestion feature rather than cluttering the basic Chord Marker label.

Implementation direction: store inversion as a bass-voice choice, display it as slash bass, and reserve classical/functional naming for an optional helper layer.

Chord Marker Editing Direction

Chord Markers should behave as much like Piano Roll notes as possible. The current direction is:

• Ctrl+A selects notes and Chord Markers.
• Ctrl+C / Ctrl+V copies and pastes notes and Chord Markers together.
• Ctrl+D or Ctrl+B duplicates selected notes and Chord Markers.
• Ctrl+U chops selected notes and Chord Markers using the same cut subdivision.
• Delete / Backspace removes selected notes and Chord Markers.
• Shift-drag a selected Chord Marker clones it, matching the note workflow.

This keeps the Chord Engine from feeling like a separate awkward tool. It should feel like another musical lane inside the same editor.

Battalion Reference Takeaways

Battalion is worth studying because it treats drum-machine design as modular, performable, and mutation-friendly. The useful SpaceAge lessons are not visual imitation; they are workflow and architecture lessons.

Most relevant ideas for us:

• Fast per-voice drum presets, so a user can swap one kick/snare/hat voice without loading a whole kit.
• Modular drum voice design: body, transient, noise, FM/metal, resonator, filter, drive, envelope, and output.
• Controlled randomization that can target a narrow area instead of wrecking the whole kit.
• Per-voice modulation that is easy to assign and understand.
• Performance macros for intensity, density, chaos, fills, humanization, and variation.
• Pattern mutation snapshots that create new ideas without destroying the original.

This reinforces our existing direction: Pad Vault, Motion Blocks, Drum Composer variations, and a future deeper drum-synthesis lab should share a single architecture instead of becoming separate one-off systems.

Nomenclature note: the clip-like object in the Chord Engine lane should be called a Chord Marker. The little ARP label on it is best called the ARP Badge or ARP Indicator.

Cross-Modulating LFO Synth Direction

Yes, SpaceAge can support cross-modulating LFOs. The practical first home is Redshift, because it already has the melodic lane workflow, filter movement, ADSR, presets, and enough musical context to make the feature immediately testable.

The first version should be disciplined: two LFOs, normal tempo-syncable rates, waveform choices, target choices, and a Cross Mod amount where LFO A can influence LFO B rate/depth and LFO B can influence LFO A rate/depth. The control ranges should be bounded so ordinary patches stay musical and predictable.

The more chaotic/audio-rate side should probably become part of a future, more experimental SpaceAge instrument rather than the default Redshift personality. That gives us both outcomes: Redshift gets organic evolving motion, while a later synth can lean into metallic, unstable, generative, modular-flavored sound design without confusing the main instrument.

CPU note: LFO cross-modulation is generally cheap if it stays control-rate and per-voice behavior is controlled. Audio-rate cross-modulation is more expensive and should be opt-in.

Arranger Step Status hext

The ARRANGER | STEP X style text exists for visibility of system status: it tells the user where the playback engine currently is in arrangement playback. Earlier in development it mattered more because the visual playhead, time counter, and bar/beat counter were less developed.

Now that SpaceAge has visible transport counters and a stronger Arrangement Canvas, that text is probably becoming redundant. The better long-term version is likely a clearer PLAYHEAD | BAR:BEAT:STEP readout, or removing that status text when the transport boxes already communicate the same thing.

True Project Transposition

True key transposition should arrive after the Chord Engine and scale model settle enough that the operation can be musical rather than mechanical. A simple semitone shift is easy, but it is not enough for SpaceAge.

The correct version should:

• Change project key and/or mode.
• Respells displayed note names and chord labels correctly.
• Move Piano Roll notes intelligently, with an option to preserve exact intervals or remap notes into the new scale flavor.
• Update Chord Engine markers by degree where possible, so a I-vi-IV-V idea can survive a key change as a harmonic idea.
• Ask whether the user wants to transform existing clips, selected clips, the whole arrangement, or only future drawing/composition.

My recommendation is to make this a Chord Engine / Project Key feature soon, but not before the current chord-marker, suggestion, and lane-instrument behavior is stable.

Honeycomb Hex Legend

The honeycomb legend groups chord suggestions by harmonic role:

• SAFE: strong in-key choices that are unlikely to fight the selected scale or melody. These are the dependable chords a songwriter can grab quickly.
• BORROW: chords whose actual root has been shifted outside the current key/scale grid. These are now stored with a real root offset, so playback, MIDI export, spelling, and project reloads all keep the borrowed root instead of merely pretending the chord belongs to the original scale degree.
• SPARE: leaner, more open choices such as suspended or less-defining chords. They avoid overcommitting to a strong major/minor emotional color and leave room for melody, bass, or arrangement to define the mood.
• COLOR: richer choices that add flavor, extension, or a slightly more characterful harmonic shade without necessarily becoming highly tense.
• TENSION: denser or more dramatic choices, including altered, extended, diminished, quartal, or otherwise spicy chords. These can be excellent, but they ask for more taste and context.

The color differences can change depending on which clip or melody context opened the honeycomb, because Melody-Fit suggestions are generated from the active notes, selected chord, key, scale, and playhead context. That means one clip may mostly show SAFE chords while another produces more COLOR and TENSION.

MIDI Export Process

The current MIDI export workflow has two scopes:

• Pattern export: the EXPORT MIDI action inside the sequencer/MIDI tasks area exports the currently selected pattern. It is not based on selected Arrangement clips. It includes Drum Composer steps, Piano Roll notes, and Chord Engine chord markers as MIDI notes.
• Arrangement export: the RENDER / arrangement MIDI path exports the whole Arrangement Canvas. The full MIDI option includes drum, melodic, and chord-engine material. The drums-only option limits the export to drum material.

SpaceAge does not yet have an explicit "export selected clips only" command. That would be a useful future option, but it should be labeled directly so the user always knows whether they are exporting a pattern, selected clips, or the whole arrangement.

After MIDI import or export, SpaceAge stores the latest MIDI receipt in memory for quick troubleshooting. MIDI TASKS can copy the latest MIDI import receipt and latest MIDI export receipt. The Arranger RENDER menu can also copy the latest MIDI export receipt. These copy actions are cold: they do not send MIDI, change routing, change project data, write files, or touch external hardware.

Fit Shortcuts

F and Shift+4 both mean fit the current composition view. In the Piano Roll, the command fits the selected notes or Chord Markers first; if nothing is selected, it resets the view. In the Arrangement Canvas, it fits the arrangement timeline into the visible window. Shift+4 is included because it matches common FL Studio muscle memory, while F remains a quick SpaceAge-native shortcut.

MIDI Velocity Display

Internally, normalized velocity values are convenient for DSP and UI math. Externally, musicians think in MIDI velocity values from 1 to 127. The bottom Piano Roll/Drum Composer Velocity control should therefore display 1-127 while the engine continues converting that value to normalized gain/velocity internally.

The selected-note and selected-step readouts should also speak this language. When a note or drum step is selected, SpaceAge now reports VEL N in the editor label so the user can see the MIDI-facing value without mentally converting from a normalized decimal.

Borrowed Chords In The Honeycomb

Borrowed chords should stay human-led. The useful SpaceAge version is a Borrow From mode in the honeycomb, not an auto-composer. Good first sources are parallel minor/major, relative keys, modal mixture, secondary dominants, Neapolitan color, and eventually Any Key.

Each borrowed hex should show its source plainly: examples include V/V, borrowed from C minor, or Mixolydian color. This keeps the feature educational and avoids turning the honeycomb into a mystery box.

Legato And Slide Links

The right first version of legato/slide in the Piano Roll is not a casual note flag. MIDI 1.0 pitch bend affects the whole channel, so bending one note inside a chord is only truly safe if the lane is monophonic, the instrument is internal and supports per-voice bends, or the app uses MPE/channel-per-note routing.

My recommendation is a first pass called Slide Link: select two adjacent or overlapping notes in a monophonic lane, create a link, and SpaceAge generates a controlled glide from the first pitch to the second. The lane should expose a pitch-bend range so MIDI export and hardware playback can stay honest. Later, the same concept can grow into true MPE support and per-voice internal synth slides.

Reverb And Delay Aux Direction

SpaceAge already has the correct CPU-friendly foundation: shared reverb and delay returns fed by per-pad/channel sends. That is better than giving every channel a fully independent always-on reverb and delay. Arrangement lanes do not yet own separate effect-send fields; they currently reach the effects through the instrument/pad/mixer channel they are routed through.

The next meaningful expansion is multiple named aux returns:

• Reverb A: default room/space.
• Reverb B: optional larger or special effect space.
• Delay A: default tempo delay.
• Delay B: optional throw, dub, or texture delay.

Each return should be bypassed when unused. This keeps SpaceAge from feeling bloated while still giving producers multiple spaces and delays when they need them.

Chord Detection On Imported MIDI

Yes, chord detection from imported MIDI is feasible. The correct product framing is not "SpaceAge knows the one true chord," because real MIDI harmony can be ambiguous. The better workflow is "SpaceAge detects likely chords and writes editable Chord Engine markers."

Recommended first architecture:

• Collect MIDI notes into harmonic windows, starting with measure-sized or beat-sized windows.
• Group notes by overlap and duration so passing tones do not dominate the detected chord.
• Normalize pitches into pitch classes.
• Compare the pitch-class set against a chord dictionary: triads, sevenths, sus chords, add chords, diminished, augmented, altered dominant, quartal, and special sonorities.
• Infer the likely root, quality, inversion, and confidence.
• Create editable Chord Engine markers aligned to the detected windows.
• Show uncertain detections with a softer visual state or a "review" indicator.

This will be especially powerful when importing MIDI song fragments from other DAWs. It also supports the educational side of SpaceAge because users can see what the system thinks the harmony is, then correct or refine it.

Source Code Safety

The active source code is local in the Codex workspace, currently under:

C:\Users\immor\Documents\Codex\2026-06-05\can-you-access-and-read-this\outputs\old builds\CinematicDrums

I should not assume the Codex chat or service is a complete source-code backup. The safer product-development workflow is to keep this folder under Git and regularly copy or push it to a place Shane controls, such as a private GitHub repository, private GitLab repository, external drive, or a carefully chosen Google Drive backup folder.

Important privacy note: if Google Drive is used, only the project source/backups should go there. The app should never reference or expose Shane's broader personal Drive folders in release builds.

Yamaha XG / Roland GS Hardware Editors

This is very feasible, but the right way to do it is profile-driven. SpaceAge should not hard-code guesses for a Yamaha QY-70, QY-100, CBX-K1XG, MU module, or Roland GS/Sound Canvas unit. We create a Hardware Passport first, then attach a device editor profile built from that device's actual manuals.

What I need from you for a specific hardware editor:

• Owner's Manual.
• Data List / Voice List.
• MIDI Implementation Chart.
• Bank/program tables, including variation banks.
• Drum kit maps and per-drum note assignments.
• Effect parameter tables.
• SysEx parameter-change format, device ID/model ID, and checksum rules.
• Bulk dump format, if the unit supports dump/restore.
• A little real-hardware testing from you once the editor exists, because old boxes can be charmingly literal about timing and message order.

The SpaceAge process should look like this:

• Create or choose a Hardware Passport for the device.
• Choose the device family: Yamaha XG, Roland GS, General MIDI, or a named model.
• Map parts/channels, usually channels 1-16 with channel 10 as drums for GM/XG/GS convention.
• Convert the manual tables into a Parameter Registry: each knob/dropdown knows its CC, RPN, NRPN, SysEx address, value range, text labels, default, and safety class.
• Build editor pages such as Parts Mixer, Voice Select, Drum Map, hone, Effects, System, and Librarian.
• Keep risky setup messages behind confirmed sends. Notes, bend, modulation, and normal expression are performance data; XG reset, GS reset, bulk dumps, and deep parameter writes are setup/recall data.
• Store recalls in the SysEx Vault with receipts so a user can see exactly what SpaceAge sent and why.

For QY-70/QY-100 specifically, the first useful editor would be a friendly 16-part XG mixer: part name, MIDI channel, bank/program, volume, pan, reverb send, chorus send, variation send, transpose, drums-on-channel-10 awareness, and a SysEx snapshot lane for "make the QY sound like this project expects." The deeper dream is a QY librarian/editor, but the first marketable win is making old XG hardware feel understandable inside SpaceAge.

Polytimbral Lane Direction

Normal lanes should stay one instrument per lane. A future Multi MIDI or Polytimbral lane can be a separate advanced lane type for General MIDI, XG hardware, multitimbral synths, or hosted plugins that intentionally expose many parts/channels.

That lane should have explicit part/channel management, not hidden magic. For example: Part 1 on MIDI Channel 1, Part 10 drums, bank/program selection, output routing, and clear panic/all-notes-off behavior. This supports hardware and GM/XG workflows without weakening the clean lane model used by ordinary SpaceAge projects.

Mono / Stereo Channel Indicators

Mono/stereo detection is feasible, but it should be quiet and stable. A tiny MONO / Sh badge or small meter accent is better than changing a major slider color, because many sources can temporarily become mono even if the lane is conceptually stereo.

If we add it, the detector should smooth over a short window and compare left/right correlation and level difference. That prevents the UI from flickering when a stereo instrument briefly plays centered material. The feature is useful, but not urgent until the mixer matures.

Ghost Notes Across Lanes

Ghost notes should be optional, lane-sourced, and read-only. My first recommendation is a Piano Roll dropdown such as Ghost: Off / Bass / Harmony / Melody / Selected Lanes. The active lane stays visually dominant; ghost notes appear as muted outlines or translucent blocks behind it.

For overlapping ghost notes on the same pitch, I would avoid color blending at first because it can become visually muddy. A better first pass is a tiny 2x or 3x badge, or a subtle diagonal hatch, to say "more than one lane has a note here." That makes doubling visible without turning the Piano Roll into a paint spill.

This feature is musically important because it lets a composer write bass, chords, and melody with awareness of collisions, doubling, and counterpoint while still preserving the one-instrument-per-lane architecture.

Lane-Owned Instruments And Clip Boundaries

The one-instrument-per-lane rule is the right default for SpaceAge. It matches how Logic, Cubase, GarageBand, and many other composition environments keep the user's mental model clean: one lane is one musical role, one instrument, one mixer path, and eventually one predictable stem.

This does not prevent advanced workflows. It simply means advanced workflows should be explicit. If a user drags a Bass clip into a Harmony lane, SpaceAge should not silently allow a confusing or silent result. The correct long-term behavior is a conversion dialog: convert the clip, duplicate it as a lane-compatible pattern, copy only compatible musical material, or cancel.

For now, clips should be blocked from previewing or dropping into foreign lanes. That keeps the app honest while we build the conversion workflow deliberately.

Context-Local Clear

CLEAR should only clear the sequencer the user is currently viewing. In Drum Composer, it should clear only the current pattern's drum steps. In Piano Roll, it should clear Piano Roll notes and Chord Engine markers, because those are part of the same melodic/harmonic sequencer workspace.

This follows the safety/usability principle we keep returning to: destructive commands should be local, explicit, undoable, and named in terms of what the user can currently see. A hidden global clear would be faster only until the first time it erases something the user did not expect.

Physical Bass Synth Direction

For a physically modeled bass guitar, the best first architecture is a plucked-string/waveguide model rather than a huge sampled instrument. Csound's plucked-string family, especially wgpluck, is a useful conceptual reference because it models plucked strings with interpolating delay lines and exposes musical ideas like excitation, pickup position, and reflection/loss behavior.

SpaceAge's first bass model should expose musician-facing controls:

• String hension / Tune
• Pluck Position
• Pickup Position
• Damping
• Body Resonance
• Finger / Pick Attack
• Growl
• Slide / Glide
• Velocity to Brightness
• Optional fret noise

Implementation recommendation: build it as a lane instrument first, not a Pad-only sound. Bass is usually composed in the Piano Roll/Arranger, so tying it to lane instruments will make the workflow feel much more natural.

Current code status: the Physical Model engine now has a first Bass Guitar model type. It is a lightweight waveguide/pluck branch with MIDI-note tracking, damping/loss, pickup coloration, body response, and growl. It is not yet the final dedicated bass instrument UI, but it gives us an audible model to refine while the lane-instrument architecture matures.

Channel Strip Musical EQ

The new hidden channel-strip EQ should be treated as a musical tone-shaping EQ, not a surgical analyzer-style EQ. It uses the classic RBJ/W3C biquad cookbook family of filters: low shelf, mid peaking bell, and high shelf. That is a good fit because it is fast, stable, familiar, and easy to bypass when inactive.

Current concept:

• Low Shelf: broad low-end weight/cleanup around the bass foundation.
• Mid Bell: sweepable problem-solving or character boost/cut.
• High Shelf: brightness, dullness, air, or softening.
• Enabled toggle: the EQ does no extra per-sample work unless the user turns it on.

CPU note: this is much lighter than running a 64-band EQ on every channel. The 64-band idea should remain a selected-channel/power-user tool later, while this strip EQ becomes the everyday mix-shaping control.

Instrument Selector Limit

The instrument selector is currently limited to 64 because it is still backed by the 64-pad engine. That was useful while SpaceAge grew out of a drum-machine architecture: every melodic instrument could be represented by a pad engine and therefore reuse existing synth, sample, mixer, and preset code.

That has now become the Instrument Bay direction: lanes target independent instrument instances rather than pad numbers. Pads remain great for drums and hybrid pad work, while lanes can host Redshift, future Moondagger/Solar Siren instruments, SoundFonts, VSTs, or Hardware Passport targets without consuming one of the 64 pads.

The registry will also make stem rendering, lane mixer assignment, VST hosting, and hardware MIDI routing cleaner because each lane has a clear instrument identity instead of borrowing a pad slot.

Drag Smoothness

Yes, SpaceAge can make dragging feel smoother across the app. The right fix is not simply "animate more." The deeper fix is to centralize drag behavior so raw mouse motion, snap previews, ghost/clone visuals, auto-scroll, and final commits all follow the same rules. That would make clips, notes, chord markers, loop ranges, section markers, and future browser items feel more physical and less twitchy.

The first pass should prioritize the Arrangement Canvas because it is becoming the heart of the app. The same pattern can then be reused in Piano Roll notes, Chord Engine markers, Drum Composer loops, and drag-and-drop sample browsing.

Chord Marker deletion / legacy-memory idea: my recommendation is not to create a separate dummy clip when a rendered arp has already been pushed into the Piano Roll. Instead, each Chord Marker should eventually have a playback mode: Chord + Arp, Arp Only, or Reference Only. That preserves the harmonic label and memory, keeps the marker editable, and lets the audio engine skip the block-chord voice when it is no longer wanted.

Hardware Hand-Holding

Hardware control should become a first-class SpaceAge advantage rather than a checkbox. The goal is a guided Hardware Setup Wizard: detect MIDI devices, ask the user to play a key/pad/knob, identify the note/channel/CC/aftertouch/pitch-bend data, send test notes back out, test MIDI clock/transport, and save a named Hardware Passport.

The product opportunity is plain-English diagnosis. Examples: "I heard your controller on Channel 10, but this instrument listens on Channel 1" or "This knob is already assigned to Pad 03 LPF." Many DAWs expose the plumbing; SpaceAge should explain it and offer one-click fixes.

Ask SpaceAge Assistant

An in-app UI helper is feasible, but it should be optional and carefully scoped. The best version is an Ask SpaceAge panel that can answer workflow questions, diagnose MIDI/audio/project-state issues, and guide users through hardware setup or missing-asset repair.

The assistant should receive only a sanitized snapshot: current page, selected clip/pad, visible settings, error states, MIDI device status, and project metadata. It should not upload samples, loops, or private project audio unless the user explicitly approves that specific action. Any destructive or project-changing action should require confirmation.

Commercially, the cleanest public model is probably built-in offline help for everyone, plus a cloud assistant as part of a paid tier or support subscription. Bring-your-own API key can be a later power-user option, but it is less friendly for ordinary customers.

Klimper-Inspired Chord Suggestions

Klimper's strongest lesson for SpaceAge is not artificial composition. It is visual harmonic guidance: keep the user inside a musical key/scale context, make useful chords obvious, and help match chords to melody notes without forcing the user to become a theory professor first.

SpaceAge's version should stay human-led:

• Melody Fit: look at selected Piano Roll notes and suggest a chord that contains or supports those pitches.
• Next Chord: use simple functional-harmony movement from the selected or previous chord.
• Bright Lift: offer a more open, optimistic color such as a IV/VI-family add9 gesture.
• Dark Turn: offer a moodier seventh-color move.

The crucial product rule is that suggestions become normal chord markers. They are not locked UI objects. Once committed, the user can slice them, resize them, change quality/inversion, render them to notes, arpeggiate them, or delete them. That keeps authorship with the composer.

Latest implementation note: the suggestion hex panel now scores selected Piano Roll notes first, then notes under the playhead, then notes inside the candidate chord span. Each hex gets a small detail tag such as SAFE | 3/4 FIT, COLOR | KEY, or TENSION | 2/3 FIT, so the user has a reason to audition it rather than just seeing chord names. Pattern MIDI export and Arrangement MIDI export now include Chord Engine markers as normal MIDI notes.

Honeycomb legend: SAFE means the chord belongs closely to the current key/scale and should feel stable. COLOR means it is still musically friendly but adds a richer extension or tone color. TENSION means it intentionally pulls harder and may want resolution. SPARE means open or skeletal harmony such as sus, power, quartal, or low-third-ambiguity sounds that leave room for melody. BORROW means the chord is reaching outside the current key through mixture, secondary-dominant logic, or another chromatic source.

Wingman Research Takeaways

Mixed In Key's Wingman is useful to study mainly as a workflow reference: fast musical auditioning, DAW-friendly MIDI output, and low-friction idea movement. The product lesson for SpaceAge is not "copy Wingman" and definitely not "auto-write songs." The useful lesson is that users like tools that keep them in motion and make musically valid options easy to audition.

For SpaceAge, the strongest translation is:

• Chord lanes that know key/scale and present accurate harmonic options.
• Bass lanes that can optionally follow committed chord clips after the human composer has chosen them.
• Fast MIDI export/drag from generated ideas.
• An audition-before-commit workflow so the user feels guided rather than trapped.
• Clear editability after any suggestion is committed. Suggested material should become normal clips, not mysterious locked objects.

This fits the product better than a large UI prompt box. SpaceAge should feel like a groovebox/microDAW with a serious theory-aware chord library, not a machine that tries to take credit for the user's taste.

Glossary

• Arranger Loop: the loop range drawn on the Arranger canvas. It controls repeated playback across the lane-based song workspace and is separate from Step-Bank Loops in the Drum Composer.
• Step-Bank Loop: a loop selection inside the Drum Composer, usually one or more 16-step banks such as Steps 1-16 or Steps 17-32.
• Hybrid Pad: a pad that blends internal synthesis with one or more sample layers.

Chord Engine Direction

The chord engine should start as a songwriter layer attached to the Piano Roll, not as a giant theory page. First we need key and scale awareness, then a chord lane that can hold chord clips with start, length, root, quality, extension, inversion, and voicing information.

The first code foundation is now in place: the Piano Roll has compact KEY and SCALE controls, and the grid subtly highlights safe-note rows for the selected key/mode. This is intentionally visual-only for now. Later we can add actual scale locking, chord insertion, chord slicing, inversion buttons, sus/add/extension choices, and MIDI generation into instrument lanes.

My recommendation: keep the chord engine fast, tactile, and human-led. A user should be able to pick a key, see diatonic choices, click a chord to audition it, drop it into a chord lane, drag its length, slice it with Ctrl+U, and then make it richer with sus2/sus4/7/maj7/add9/inversion controls. Borrow the usefulness of Hookpad's chord lane and Chordbot's approachable workflow, but keep the SpaceAge interface darker, cleaner, and more direct.

Important product boundary: SpaceAge should not become an UI auto-composer. A limited Chord Suggestions feature is acceptable if it behaves like a smart theory assistant for unsticking a human composer: suggest likely next chords, borrowed chords, inversions, or substitutions, then let the user audition and explicitly commit. The app should never imply that it is writing the song for the user.

The chord lane should eventually sit near the Piano Roll as a real harmonic timeline. Chord clips should be resizeable, sliceable, copyable, and editable like notes or arrangement clips. Selecting a chord should expose a compact chord-properties panel: quality, inversion, extensions, suspended tones, slash bass, voicing, and optional arpeggiation.

Current code status: the first visible chord-engine pass now stores chord clips per pattern, saves/loads them with projects, draws a dedicated CHORDS lane above Velocity in the Piano Roll, and provides seven diatonic "safe chord" buttons based on the selected key and scale. The first edit model is intentionally simple: click a chord block to select it, click a degree button to replace it, or right-click a chord block to delete it. Quality and inversion dropdowns are in place as the first compact chord-property controls.

Follow-up chord-engine edit pass: the Piano Roll now spells scale-tone note labels according to the selected key and mode instead of forcing every black key into sharp names. That means keys with flats display flats, and keys that theoretically require double-sharps or double-flats can display ## or bb spellings. Chord markers are now easier to create and edit: click the CHORDS lane to add a marker, click an existing marker to select it, drag it to move it, drag the right edge to resize it, right-click/Delete to remove it, and use Ctrl+U to chop a selected chord marker into smaller one-step chord blocks.

Scale Lock direction: the Piano Roll can now optionally keep newly drawn, dragged, cloned, and transposed notes inside the selected key/scale. This should remain off by default so SpaceAge never feels bossy, but it gives beginners and theory-focused users a fast way to stay in a chosen harmonic world. Longer term, Scale Lock should connect to chord suggestions, chord voicing tools, bass-follow behavior, and any future "safe notes" teaching mode.

Chord performance direction: a chord marker should remain the harmonic truth, while performance data sits on top of it. That means a marker can still say Cmaj7 while remembering per-voice velocities, strum direction, strum time, velocity tilt, humanize amount, and preserve-end behavior. Direct pitch edits should wait for a deliberate Render To Notes or Make Custom Voicing action, because otherwise the label stops being trustworthy.

Arpeggiator workflow: the chord-performance panel now remembers the last arpeggiator recipe used in the session. New chord markers inherit that arp mode, rate, gate, swing, octave, velocity-shape, and enabled state, while preserving their own chord degree, quality, inversion, start, and length. This makes it practical to render a string of matching 8th-note or 16th-note arp patterns without re-dialing the panel every time.

Chord Marker playback modes: the Chord Performance panel now has Chord + Arp, Arp Only, and Reference Only. Chord + Arp is normal playback. Arp Only keeps the marker as the harmonic source but suppresses the block chord so only the arp can speak. Reference Only keeps the chord visible/editable as a silent harmonic reminder, and it is skipped during MIDI export so it will not sneak into collaborator files.

Latest chord-suggestion pass: borrowed-key suggestions now include a broader modal-mixture set, including bII / Neapolitan color, bIII, iv minor, bVI, bVII, leading-tone diminished color, and a few mediant turns. Honeycomb categories now come from one shared classification path, and hover spellings use the selected key/scale spelling rather than generic MIDI note names.

Sequencer playback simplification: the old Context/Isolated toggle was removed. Drum Composer and Piano Roll now behave as local pattern workbenches, while the Arranger plays the lane-based song canvas.

Cut subdivision direction: CUT SNAP should follow the current grid. The normal musician-facing choices should be CUT IN 2, CUT IN 4, CUT IN 8, and CUT IN 16, meaning the selected note or chord marker is divided into that many equal pieces. This is much easier to reason about than "fractions per step" language.

Reverb And Delay Aux Plan

The right long-term design is shared aux buses rather than separate reverbs and delays baked into every instrument or pad. That keeps CPU sane and matches studio workflow: each pad, loop lane, and melodic instrument sends some amount into one or more global returns.

The first proper reverb implementation should create named returns such as ROOM, PLATE, and SPACE, each with its own algorithm/settings and return level. Channel strips and instruments should get send controls to those returns. This avoids bloating every lane with duplicate reverbs while still letting a user put drums in a tight room, synths in a plate, and special effects in a huge space.

Delay should follow the same philosophy. A small set of shared delay returns, such as SLAP, ECHO, and PING PONG, should expose tempo division, feedback, filter/darken, width/ping-pong, saturation, and return level. Every pad, loop lane, and instrument can then send to those delay returns without creating redundant delay processors everywhere.

CPU note: multiple global reverbs and delays are reasonable if they are shared and can be disabled. Per-pad reverbs would get expensive quickly and could make SpaceAge feel heavier than it should. Per-pad simple delay can be affordable, but shared delay returns are still cleaner for workflow and mixing.

MIDI Step Input

MIDI Step Input now lives inside the MIDI TASKS menu on the Piano Roll. When it is on, playing a key on a MIDI controller places a note at the current cursor position, uses the played velocity, previews the sound, then advances by the current Piano Roll snap value. This is meant for careful one-note-at-a-time composition independent of real-time performance.

The cut subdivision selector is the CUT SNAP dropdown in the Piano Roll row. CUT SNAP follows the main grid snap; the explicit CUT 1/2 STEP, CUT 1/3 STEP, and similar options let Ctrl+A chop notes into faster subdivisions.

MPC Marketing Connection

There is a real marketing advantage in borrowing the language of immediacy from MPC-style workflows, but SpaceAge should not imply an Akai partnership, endorsement, replacement, or direct compatibility unless that becomes legally and technically true.

The safer and stronger angle is: SpaceAge gives producers MPC-style pad immediacy inside a software microDAW, then goes further with hybrid pads, deep sample layers, native synth engines, clip lanes, Pad Vault, themes, and project archiving.

Good language:

• MPC-style pad workflow
• classic pad-based beatmaking
• groovebox immediacy
• pad-first creative microDAW

Avoid:

• MPC-compatible unless a specific compatibility feature is real
• Akai-style branding language
• claims that suggest official association
• using Akai product names in marketing headlines

2026-07-29 - What Roadblocks Remain For A Beta Version?

The short answer: the automated MIDI backend is strong, but beta is blocked by proof and trust work rather than glamorous new features. The main blockers are real MIDI hardware evidence, Instrument Bay / lane independence finalization, human audio QA for every synth/lab/sampler, UI clipping/readability cleanup, save/load/recovery confidence, render/export proof, and clean packaging/legal/release hygiene.

I created a dedicated report here: docs/Beta_Roadblocks_Report.md.