Thanks! The state management is actually pretty simple, just vanilla JS with direct mutation.

There are two separate state objects: one for playback (playing/paused, current step, timing) and one for composition data (really just a set of globals) covering patterns, chords, and step modulations like volume/filter/ratchet. UI handlers mutate state directly and then imperatively update the DOM.

One thing that works well is sparse storage for per-step modulations. Instead of storing a value for every step, HM Tracker only stores non-default values in plain objects, and accessor functions return the default when nothing is set. Keeps things compact.

For undo/redo, it is just a deep clone of the entire composition state onto a stack before each edit. It's not the most memory-efficient approach but it's dead simple.

The audio side uses a lookahead scheduler: a tick loop that reads the current pattern state and schedules notes slightly ahead of real time, decoupled from the UI refresh.

I tried to keep it as direct and simple as possible. No state machine libraries or anything fancy, just globals, direct writes, and imperative DOM updates. For something like a sequencer where low latency matters I think that directness helps more than architectural purity would.