17-Key Virtual Layout and Unified Input Controls
This system operates as a lightweight synthesizer powered by the browser-native Web Audio API, presenting a compact keyboard range of 17 keys from C4 (middle C) to E5.
The 17-key layout visually models the physical positions of white and black keys in the Document Object Model, providing intuitive control for users.
Input is supported across three unified modalities: direct mouse clicks, multitouch interaction on mobile displays, and physical typing via QWERTY computer keyboards.
For keyboard typing, an ergonomic mapping aligns home-row keys, assigning "A" to C4 and ";" (semicolon) to E5. Global keydown and keyup event listeners capture these keystrokes.
In both English and Japanese implementations, the global keydown handler guards against accidental triggers by discarding events where e.repeat is true, where an IME composition is active (e.isComposing), or where modifier keys like Ctrl, Meta (Command), or Alt are engaged.
Furthermore, keydown events originating from editable elements or form controls—specifically input, textarea, select, button, and contenteditable descendants—are ignored to prevent interference while typing.
Shift alone is permitted so uppercase mapped keys still register. In contrast, the keyup listener intentionally bypasses these filtering guards to ensure that any currently sounding note is reliably released even if modifier keys are pressed or if focus shifts into an editable field during playback.
When a valid keypress is accepted, OscillatorNode and GainNode instances are created within the AudioContext, routing audio from the oscillator through the gain node to the AudioDestinationNode.
Mouse and touch events trigger an identical instantiation lifecycle through onMouseDown and onTouchStart, with preventDefault applied on touch surfaces to suppress default scrolling and preserve instrument responsiveness.
Note that broader lifecycle edge cases, such as window blur, visibility state changes, and polyphonic voice limits, are not comprehensively managed, and no claims of zero-latency performance or acoustic safety guarantees are made.
Four Fundamental Waveforms and Acoustic Characteristics
At the core of its sound generation, this system uses mathematical oscillators to synthesize sound waves in real time rather than playing pre-recorded instrument samples (such as PCM audio).
By adjusting the type property of the OscillatorNode in the Web Audio API, users can select among four fundamental waveforms: sine, square, triangle, and sawtooth.
Sine waves consist purely of the fundamental frequency with no harmonic overtones, yielding a rounded, pure tone reminiscent of a tuning fork.
Square waves contain prominent odd harmonics whose amplitudes decrease inversely with harmonic number, producing a hollow acoustic character reminiscent of closed-pipe woodwinds like the clarinet.
Triangle waves also feature odd harmonics, but their higher overtones diminish rapidly, resulting in a warmer, softer timbre closer to a sine wave.
Sawtooth waves contain all integer harmonics (both even and odd), delivering a bright, buzzy tone suitable for brass or string sounds.
This sound generation executes purely through local client-side computation on your device without loading external audio files or recording microphone inputs, prioritizing lightweight performance over complex acoustic resonance modeling.
Frequency Calculation and Dynamic Note Name Synchronization
The system defines base frequencies based on standard concert pitch (A4 = 440 Hz, with C4 at 261.63 Hz). To enable playing across broader pitch ranges and different keys within its visually limited 17-key layout, it provides octave shifting and transposition controls.
Octave shifting moves the entire pitch register up or down between -2 and +2 octaves in integer steps. Transposition shifts pitches in chromatic semitone intervals from -12 to +12, facilitating playing in different keys without altering fingering patterns.
When these parameters change, the system calculates final frequencies using twelve-tone equal temperament: base frequencies are multiplied by 2 raised to the octave shift power, then multiplied by 2 raised to the transposition value divided by 12.
These pitch adjustments synchronize dynamically with the user interface. Display labels on the keys update in real time rather than remaining static strings, parsing pitch classes and octave numbers to render the active transposed pitch.
This ensures displayed note names correspond to actual audible output, maintaining theoretical consistency and intuitive performance.
ADSR Envelope Scheduling for Dynamic Volume Curves
Another crucial element shaping synthesized timbre is the envelope generator, which controls volume evolution over time. This system implements an ADSR envelope (Attack, Decay, Sustain, Release) using GainNodes to schedule the acoustic lifecycle from key press to silence with millisecond precision.
Attack specifies the duration required for volume to climb to peak level after a note is triggered. Decay defines the time taken to drop from peak volume down to the steady sustain level.
Sustain represents the steady-state volume ratio maintained while a key remains pressed. Release governs the fade-out duration once the key is released.
These volume dynamics are scheduled using Web Audio API AudioParam methods: on note-on, gain initializes to zero via setValueAtTime, ramps linearly to maximum during the attack phase via linearRampToValueAtTime, and ramps exponentially toward the sustain level via exponentialRampToValueAtTime.
On note-off, the current gain value is captured with setValueAtTime, subsequent pending events are cleared with cancelScheduledValues, volume fades out toward near-zero across the release phase, and the oscillator is stopped, creating smooth temporal variations from streamlined controls.
Polyphony Management and Audio Node Lifecycles
Polyphonic playback allows multiple keys to sound simultaneously for playing chords, requiring independent audio routing paths for each pressed note unlike monophonic synths.
The system manages currently sounding notes by tracking OscillatorNode and GainNode pairs in a memory dictionary keyed by note identifier.
When a new key is struck, corresponding nodes are instantiated, registered, and started. If an already sounding key is pressed again, the system references the dictionary to trigger release and stop routines on the existing node before voicing the new note.
Concurrently, active notes are tracked in React state, enabling keyboard components to toggle CSS classes dynamically for visual key-press animations.
Because the Web Audio API requires stopped OscillatorNode instances to be discarded rather than reused, every keystroke instantiates and disposes of nodes to support polyphonic play across physical keyboard chords and multitouch inputs.
Local Processing Constraints and Design Scope
Because this tool functions as a lightweight browser-based synthesizer, it operates under inherent client-side constraints unlike dedicated hardware or native audio workstations.
Latency remains the most noticeable limitation: delays inevitably occur between key input and speaker output due to JavaScript engine execution, AudioContext processing overhead, and operating system audio buffer sizing.
Consequently, zero latency cannot be guaranteed, and perceived delay varies with device performance and system settings. Additionally, while no hard polyphony cap is enforced, striking many keys simultaneously on resource-constrained devices can strain processing capacity and produce dropouts.
The synthesis engine does not fetch external audio sample files, though separate site-level network requests may occur. The feature set omits advanced production capabilities such as Web MIDI API support, full 88-key layouts, audio recording, WAV/MP3 export, microphone input, biquad filtering, velocity sensitivity, and automated chord recognition.