Pitch, slew and demand

For our MCU targeting examples, one goal is to turn our Clef display and input work into a playable instrument: a Minimoog-inspired synthesizer with a range-sensing theremin mode. Moving a hand toward the sensor would raise the pitch, and the screen could show how that motion becomes a musical control. The pitch-smoothing example from our design discussion illustrates how that control could work.

Back in the 90s Houston helped Bob Moog build synthesizers for years, starting with the Lintronics Advanced Memorymoog modification, which was a different kind of instrument for its era: digital control of analog VCOs and VCFs, with digital patch memory and a microprocessor managing parameters that had previously been hardware switches. We also built analog designs such as theremins and other specialty projects where precision played a key role in every decision. The theremin mode on our STM43H7 “Discovery” board project traces directly back to those projects.

That history of the technology matters here. Analog signal paths carry voltage that moves continuously. The control voltage from a theremin sensing circuit follows the player’s hand in real time, with the only distortion being the noise and bandwidth limits of the circuit itself. The person’s body is actually part of the circuit itself. Digital systems sample that motion at discrete intervals and reconstruct it through a digital-to-analog converter. The gap between sampling and reconstruction is where smoothing lives, and it is where we choose how much lag to introduce versus how much ripple to accept.

This browser based case study lets us hear the response while varying the sampling and smoothing independently. It is inspired by a possible Cortex-M4 control role. We would select the sensor and processor allocation through the board work, where we can measure the timing.

Move the input and compare the sampled target with the smoothed response. Sampling captures the desired hand position at intervals and holds the latest target between captures. Even a smoothly moving hand can produce a staircase of target values. A real sensor would add noise and calibration requirements, with its own response to a lost or out-of-range reading.

The smoother approaches each held target gradually:

Here, $x_n$ is the current target and $y_n$ is the smoothed control. The update interval is $\Delta t$, and $\tau$ is the time constant. For a fixed target, one time constant closes about 63% of the initial distance. A larger time constant gives a gentler, slower approach. A smaller one follows the target more closely, including more of its steps.

“Slew” is musical shorthand here. The implementation is one-pole smoothing, whose rate depends on the distance to the target. A strict slew-rate limiter would instead impose a maximum change per second. With either approach, the instrument has to trade a smoother control for some response delay.

The lag introduced by smoothing is the critical design parameter, and its musical effect depends entirely on the time scale relative to what the player is doing. A time constant under roughly 5 milliseconds is essentially invisible for hand-position control. The ear does not detect the delay as lag at all. The smoothed output tracks the sampled target closely enough that the pitch feels like a direct extension of the hand.

Between 5 and 50 milliseconds, the lag becomes perceptible but can still serve a musical purpose. This is the portamento region. Early analog synthesizers often had portamento circuits built in, and they worked exactly this way: a capacitor charging through a resistor created a smooth pitch glide between notes. The player chose the glide time by selecting a capacitor value, and the resulting delay was part of the instrument’s character. A well-chosen portamento time makes a synthesizer feel alive, connecting discrete pitches with continuous motion that the ear interprets as musical intention rather than system delay.

Above 50 milliseconds, the lag becomes distracting for most musical contexts. The player moves the hand and the pitch follows a half-second later, breaking the causal connection. A theremin player expects nearly instant response from the antenna fields. A keyboard player expects the pitch to move with the key press. Smoothing that pushes response beyond 50ms turns the instrument into something you watch rather than something you play.

Audio is optional. Enable it to listen, then stop it independently of the graph. The browser schedules the target events with a 40 ms buffer, adding delay to the output. We would measure the instrument’s latency on the board and choose the volume response separately. (The ear is less sensitive to volume changes than pitch, so there’s a slide rule that applies) Final amplitude shaping could remain with the audio generator.

The sensor’s sampling interval and the smoother’s time constant are separate from the oscillator’s note frequency. For a positive time constant, the continuous-time first-order model has a cutoff of $1/(2\pi\tau)$. That cutoff describes how changes in the control are filtered.

Our model maps distance linearly into three octaves, smooths that logarithmic pitch coordinate, and converts the result to a frequency between 110 and 880 Hz. Smoothing normalized distance gives the same result with this mapping. A nonlinear distance calibration would change that relationship, and smoothing frequency directly would produce a different pitch trajectory.

This is the same kind of signal-tracking problem that appears across the Fidelity Framework. The MCU path with Fidelity on MCU handles direct register access, typed MMIO, and vector reset bring-up. The RA6M5 work established that the compiler can enforce boundary contracts at the silicon level: memory-mapped peripheral registers carry their own type and dimensional information from source through to the binary. A sensor reading arrives through an ADC register, passes through the application’s validation, and feeds into a reactive signal. The MMIO contract at the hardware boundary and the reactive contract at the software boundary use the same disciplined approach to keeping information intact across transformations.

MCU work is a microcosm of the full framework. It exercises tight resource constraints, direct hardware access, and deterministic behavior. But the same principles scale to server infrastructure. The actor-owned reactive graph handles event delivery and incremental computation the same way whether it runs on a Cortex-M33 collecting entropy or on a Cloudflare edge server processing thousands of concurrent streams. BAREWire describes how typed messages and owned buffers feed those demand-driven reactive views across all targets. The microcontroller case is worth examining in detail because it forces the design choices into the open: every byte is accounted for, every timing boundary is measurable, and the compiler’s type and dimensional information survives all the way to the register file.

Hiding the graph while the tone continues makes the UI question concrete. The control data still has an audio consumer, even after the chart stops drawing. Our Fidelity demand model would allow the instrument or a background service to keep those calculations active under its own ownership. An optional derivation could become idle after its last consumer releases demand, retaining a result that may later be stale.

This is the intended behavior of our reactive-area UI model. A visual inspector could be opened, moved or closed while the instrument continued responding. The Incremental demand contract specifies the foundation, and the cold half of concurrency describes why we favor that starting point.

On our audio projects for MCU we would compare captured input timing with the resulting audio and display activity under load. Closing the inspector would provide a useful test: visual work should stop while the instrument continues serving its active consumers.

The smoothing parameters and the demand model both describe how an application maintains coherence when information flows through discrete stages. The engineer chooses a time constant for the smoothing to balance ripple against lag, and chooses a demand policy for the reactive graph to balance computation against responsiveness. The mathematics of one-pole smoothing and the ownership rules of incremental computation are different tools for the same underlying problem: keeping derived values current without introducing the artifacts that come from careless updating.

Tight Bounds, Loose Scales

Distributed systems and realtime systems are often treated as separate domains in engineering. The realtime world is measured in milliseconds of latency, timing jitter, and interrupt response. A theremin player’s hand doesn’t care about TCP congestion windows or distributed consensus, and it doesn’t care that the pitch has to pass through a sampled-and-smoothed path. A distributed system cares about ordering, delivery guarantees, and eventual consistency. It does not care whether the pitch tracking on its input channel introduces a 20 ms portamento glide.

But they meet at the boundaries. Every distributed system that handles real-time input: a video game server processing player positions, a telepresence robot following a controller, an industrial control network reading sensor arrays, has to carry tight timing constraints across the same event delivery and computation machinery it uses for the rest of its workload. The actor that receives a hand-position reading from a theremin sensor has to decide whether to forward it immediately to the audio synthesis actor, buffer it for ordering with other messages, or cache it for a slow analytics consumer. The choice of smoothing time constant and the choice of demand policy are both answers to the same question: how much of the system’s state needs to be current, and how quickly does each consumer need it? We had to deal with that as the MIDI control design took shape for those theremin instruments. Crossing the analog and digital “divides” meant seeing them both for the continuous domains the represented and reconciling those competing demands.

Those lessons are not lost here. The MCU path in the Fidelity Framework establishes that the compiler can enforce boundary contracts at the silicon level: typed MMIO registers carry their own type and dimensional information from source through to the binary. The actor-owned reactive graph handles event delivery and incremental computation the same way whether it runs on a Cortex-M33 or on a Cloudflare edge server. The BAREWire contracts describe how typed messages and owned buffers feed demand-driven reactive views across all targets. The microcontroller case forces those design choices into the open — every byte is accounted for, every timing boundary is measurable. The same principles scale to server infrastructure without requiring different tools or different reasoning.

In the example above, a time constant of 3 ms keeps the smoothed pitch invisible to the player. A demand policy that gives audio actors first-priority access to reactive derivations keeps the audio pipeline clear of the latency that would come from competing with visual rendering or bulk data movement. Those are different engineering decisions that The Fidelity Framework’s ownership and demand model lets you express together, with the compiler tracking their consequences. The smoothing coefficient belongs to the signal path. The demand registration belongs to the actor contract. All of these considerations, as complicated as they can become, deserve the support of an intelligent compiler and toolchain to aid the engineering decisions that let’s the technical details recent, and the artistic expression (or flow of information) continue without interruption.