Overview · v1 · A3 Landscape

Dropdowns: when and how they change

A high-level look at the five lifecycle moments at which a dropdown can pick up its options — and what that means for the people building, configuring, and using SpaceMusic.
date  2026-04-27
audience  collaborators · stakeholders
companion  dropdown-types-comparison
The dropdown
lifecycle
Build time
when the app is compiled
App start
when the app boots
Session
at any moment, globally
Scene change
on add / remove of sections
Per row
independently, any time
When the app is built

Built into
the app

01
On FROZEN · Off · On
The list is part of the app itself.
Typical entries
On / Off · Yes / No · Light direction · Quality preset
Who can change it
Only the developer, by rebuilding.
What this means
  • New options never appear at runtime.
  • Saved selections stay valid as long as the option exists in the build.
  • Maximum stability — zero flexibility.
When the app starts

Filled
at startup

02
SCAN ONCE Speakers · Speakers · Headphones · Studio Monitor
The list is filled once, when the app discovers what's there.
Typical entries
Audio devices · MIDI inputs · Connected cameras · Detected GPUs
Who can change it
The platform — at startup, or when something is reconnected and the app re-scans.
What this means
  • The list is a snapshot of what existed when we started up.
  • Plugging in new hardware mid-session may need a restart to show.
  • Saved selections can go stale if the device is gone next time.
During the session

Updated live,
shared

03
SOURCE live updates Theme A Theme A Theme A ALL SHARE ONE LIST
The list can grow or shrink at any time, and everyone sees the same list.
Typical entries
Loaded themes · Registered presets · Imported assets · Available scenes
Who can change it
Patch logic during the session — every UI showing this dropdown updates instantly.
What this means
  • New entries appear everywhere at once.
  • Removing an entry someone had selected leaves a stale selection behind.
  • One central list — no per-place customization.
When the scene grows

Mirrors
the scene

04
L 1 L 2 L 3 + SCENE STRUCTURE Light 2 · Light 1 · Light 2 · Light 3 grows on add
The list mirrors what exists in the scene right now.
Typical entries
Light 1 · Light 2 · Light 3 · Stage A · Layer B (names follow a pattern)
Who can change it
Adding or removing sections in the scene — the list grows and shrinks with the structure.
What this means
  • The list is always in sync with the user's current setup.
  • Removing a section can invalidate selections that point to it.
  • Naming follows the scene — entries are predictable.
Row by row · independent

Per row,
private list

05
SLOT A Liquish Liquish · Glass · Foam SLOT B Sine Sine · Saw · Square SLOT C Hue Hue · Saturation · Lift EVERY ROW DIFFERENT
Every row owns its own list — they are not connected to each other.
Typical entries
Plugin choice in a slot · Effect in a channel · Texture in a layer
Who can change it
The plugin or patch driving that specific row, at any time, independently of the others.
What this means
  • Two rows of the same UI can show completely different options.
  • Each row's list and selection are saved with the scene.
  • Maximum flexibility — also more setup per row.
Decision

How to pick the right type — four questions

Q1 Are the options known when the app is built? if yes → Built into the app
Q2 Are they discovered once at startup and stay fixed for the session? if yes → Filled at startup
Q3 Should every row have its own private list? if yes → Per row, private list
Q4 Is the list tied to the scene structure (one entry per section)? if yes → Mirrors the scene
↳ Otherwise — a shared list that may change during the session. → Updated live, shared
Read this together with

What changes between types

Stability of the list
From "frozen at build" (1) to "fully live, per row" (5). Each step gives more flexibility, less predictability.
Reach of a change
A change can affect everyone (global), only what matches the scene (structural), or just one row (per-instance).
Risk to saved selections
A selection can become stale whenever the list it points into is changed by something outside that selection's control.
Where the list lives
In the build, in app memory after startup, in a shared registry, or directly inside the row's own state.
Maintenance cost
Increases roughly with flexibility — the more dynamic, the more careful the wiring around saved values needs to be.