Real-Time Engine & Analysis

Physics must meet the audio deadline

A convincing model that misses the callback deadline is not a playable instrument. ArcoAura prepares modules for a sample rate and block size, keeps reactive and voice state between blocks, avoids allocation in hot processing paths where possible, and bounds polyphony and iterative work.

The current MIDI string path supports twelve voices, retriggers matching notes, steals the oldest voice when necessary, and releases notes over a short bounded interval. Signal-chain blocks process in a known order.

Analysis is part of design

Frequency response for linear pickup, equalizer, and cabinet stages
Resonant frequency and Q derived from pickup RLC loading
Construction warnings when physical and electrical goals disagree
Deterministic cabinet response and IR generation
Finite-output and audible-output smoke tests
Module manifest and port validation
Future phase, impedance, envelope, nonlinear sweep, and energy-decay plots

Bound the work explicitly

A real-time engine should make overload policy explicit. This example communicates deterministic voice allocation: reuse a matching note, claim an inactive voice, or replace the oldest voice rather than allocating without limit.

ArcoBASICArcoBASIC communication example: bounded real-time voice selection

' Select a voice without growing memory inside the audio callback.
FUNCTION SelectVoice(voices, midiNote)
    oldestIndex = 0
    oldestAge = -1
    index = 0

    FOR voice IN voices
        IF voice.Active AND voice.MidiNote == midiNote THEN RETURN index
        IF voice.Active == FALSE THEN RETURN index

        IF voice.AgeSamples > oldestAge THEN
            oldestAge = voice.AgeSamples
            oldestIndex = index
        END IF
        index = index + 1
    NEXT

    RETURN oldestIndex
END FUNCTION

voices = [
    {"Active": TRUE, "MidiNote": 40, "AgeSamples": 8000},
    {"Active": FALSE, "MidiNote": 0, "AgeSamples": 0}
]

PRINT SelectVoice(voices, 45)

Honest fidelity

ArcoAura separates what is physically derived, empirically calibrated, algorithmically approximated, and planned. The pickup load and circuit solver are active. The coil calculator is empirical and reports disagreement. The current string source is harmonic rather than a completed nonlinear waveguide. The speaker response is deterministic and parameter-derived rather than finite-element simulation.

That honesty makes the roadmap stronger. Each future fidelity increase can be measured against recordings and laboratory data instead of disappearing into a vague claim of realism.

Bounding the work is part of the design

Twelve-voice polyphony and a bounded-callback deadline are specific to real-time audio. A different project’s deadline might be a network round trip or a frame budget instead of a sample-rate callback. What generalizes is deciding the overload policy on purpose instead of discovering it under load.

The same discipline governs any system with a hard resource ceiling: a web server that decides its request-shedding policy before traffic spikes rather than during the outage, a game engine that budgets its frame time deliberately instead of letting whichever system runs first win, a distributed system that names its degraded modes explicitly rather than failing in whatever way happens to be easiest to code.

Decide the overload policy before it is needed, not during an incident. SelectVoice always resolves to a note in three explicit steps, reuse a match, claim an inactive voice, steal the oldest, rather than letting the system behave unpredictably once it runs out of capacity.
Treat "no allocation in the hot path" as a real constraint that shapes the code, not an optimization to revisit later. A convincing model that misses its deadline is not a working feature, it is a bug that happens to run.
Build verification into the same system as the design, not around it. Finite-output and audible-output smoke tests exist alongside frequency-response and construction-warning checks, so a regression in the physics gets caught the same way a regression in behavior would.
Publish an honest map of what is derived, calibrated, approximated, and planned. Sorting the pickup solver, coil calculator, string source, and speaker response into those categories keeps "realistic" from becoming one vague claim nobody can check.

LEARNING LAYER

Key terms, in plain language

You do not need a systems background to follow the work. These are the specialized terms used on this page.

Audio block: A small fixed group of samples processed together during real-time audio. Each block must finish before the audio device needs the next one.
Polyphony: The number of independent notes or voices that can sound at the same time. A bounded voice count keeps real-time work predictable.
Impulse response: A recording or generated description of how a system responds to a very short impulse. Convolution can apply that response to other audio.
Physical modeling: Producing sound by simulating the behavior that causes it, such as a vibrating string or electrical circuit, instead of replaying a recording of the finished result.