M5live: native MUSIC V reconstruction and performative archaeology

M5live is a browser-based environment for working with MUSIC V scores, developed by Luciano Azzigotti and Nemanja Radivojević. It brings historical synthesis programs, score manuscripts, and contemporary editing tools into a shared working interface. Its research concerns include the reconstruction of executable musical processes, the interpretation of historical code, and the use of these processes as material for composition and performance.

The project was presented in M5live: a historical online environment for electronic music (Azzigotti and Radivojević, 2022). That account establishes the project’s relationship to live coding and performative archaeology. The implementation described here records a subsequent development: the restoration and integration of a native Fortran execution path, alongside an explicitly experimental TypeScript renderer.

Native Fortran Reconstruction — 21 October 2026

Technical account revised 25 October 2026. The upgrade name refers to the implementation and deployment work undertaken on 18–21 October 2026; it does not designate a new edition of the historical MUSIC V language.

This upgrade reorganized M5live around the native three-pass MUSIC V compiler. It introduced isolated compilation of score-specific Fortran subroutines, restored two function generators, made Pass I composing routines callable, and connected the resulting audio to a browser workspace with historical-source navigation, revision-aware corrections, contextual visualization, and executable tutorials.

The term translation covers several distinct operations in this work: adapting historical fixed-form source to a contemporary compiler; reconciling shared-memory declarations; converting score parameters into the representations required by synthesis routines; and packaging native audio for browser playback. These operations have different implications for historical interpretation. Layout normalization can preserve arithmetic, whereas reconstructing a missing generator requires a documented interpretation of external evidence.

Source lineage and implementation boundaries

The native baseline is the MUSIC V port transcribed for modern Fortran by Bill Schottstaedt, with subsequent additions and repairs by Victor Lazzarini. The reconstruction pins its source reference to revision d5e2f9c60a8eb1a188b749aa6bccc64c7ab7f886. The source headers identify earlier listings and later changes, including the recovery of an interpolating oscillator from the Risset archive and repairs to stereo output. These contributions belong to the upstream lineage; the present upgrade integrates them and adds the interventions described below.

Three implementation paths must be distinguished:

The recent work therefore does not constitute a complete Fortran-to-JavaScript or Fortran-to-WebAssembly translation. Standard jobs use the installed Linux Pass I and Pass II executables and a rebuilt Pass III containing the documented repairs. Jobs with composing routines compile a custom Pass I; jobs with a supplied converter compile a custom Pass II. The browser invokes this execution service and plays its returned recording.

This distinction also revises the earlier description of M5live as a continuously operating, real-time synthesis system. The native workflow is an edit–compile–render–listen cycle. It can support iterative and performative use, but it does not provide sample-accurate, continuous mutation of a running Fortran orchestra. The maintained frontend uses Nuxt, Vue, Ace, canvas/SVG visualization, and browser audio playback. Earlier p5.js experiments remain part of the project’s history rather than a requirement of the current renderer.

The three-pass execution model

MUSIC V separates symbolic score preparation from sample generation. M5live retains this separation:

Browser editor: score cards + optional Fortran subroutines
    ↓ extraction, layout normalization, and card validation
Pass I: score reading, instrument encoding, optional PLF execution
    ↓ pass1.data
Pass II: section-based sorting, control-memory updates, CONVT
    ↓ pass2.data
Pass III: instrument execution and sample generation
    ↓ snd.raw + snd_params.txt
PCM16 WAV packaging → browser transport and visualization

Pass I reads semicolon-terminated instructions and encodes instrument definitions. An INS card opens an instrument; unit-generator cards connect its parameter fields and buffers; END closes the definition. Composing routines can consume records and emit additional records during this stage.

Pass II processes sections, orders records by action time, applies relevant control records, and calls CONVT before forwarding records to Pass III. Keeping this native stage preserves section and conversion behavior that a parser based only on independent lines cannot reproduce. Ordering and conversion are musically consequential: a control update and a note at the same action time may depend on their relative position.

Pass III executes the encoded unit-generator network with per-note state, function tables, and signal buffers. The selected native source includes oscillators, envelope and random generators, adders, multiplication, filtering, mono/stereo output, table selection, and the recovered IOS interpolating oscillator. Enabling their native execution is distinct from claiming that every historical score using them has been validated.

Each render receives its own working directory. Intermediate files from simultaneous requests are separated, and a failed native render reports its failure rather than returning audio from another renderer.

Score semantics and parameter conversion

A native note has the form:

NOT time instrument duration P5 P6 ...;

The opcode occupies P1, action time P2, instrument number P3, and duration P4. Subsequent parameters acquire meaning from the instrument and its converter. P5 cannot be assumed universally to mean amplitude, nor P6 universally to mean frequency. A historical orchestra may use these fields for decibels, pitch encodings, envelope controls, modulation indices, or other quantities.

The distinction matters when translating an apparent musical value into an internal synthesis increment. For an oscillator traversing a table of length N, the reviewed conversion uses Δ = f × (N − 1) / Fs, where f is frequency in hertz and Fs is the sampling rate. For the default 512-sample table, a converter may express this as F = 511. / G(4) followed by a multiplication of the relevant parameter. Another converter may expand a note by adding an envelope increment or retain state between successive notes. Conversion is therefore part of the executable musical specification.

A basic score using the compiled general converter is:

SIA 0 4 44100;
SV2 0 10 1 6;
INS 0 1;
OSC P5 P6 B2 F1 P30;
OUT B2 B1;
END;
GEN 0 2 1 1 1;
NOT 0 1 .5 1000 440;
NOT .75 1 .5 1000 660;
TER 1.5;

Here SIA sets the sampling rate. SV2 0 10 1 6 configures the general converter for instrument 1’s P6 frequency parameter. GEN 0 2 1 1 1 constructs F1 with one sine harmonic. P30 provides oscillator phase state; B2 is the signal buffer and B1 the mono output. These assignments describe this instrument, not a universal parameter schema.

Statements terminate at semicolons and can span physical lines. The adapter preserves comma-separated fields and historical parameter order while fitting cards to the native reader. Comment handling recognizes complete C, c, COM, and COMMENT headers, including documented punctuation forms, without treating unrelated opcode prefixes as comments. The editor detects likely physical-line damage and can join numeric or comment continuations. Such a repair remains an editable intervention: the original archive is retained, Undo remains available, and ambiguous lines require review.

Memory layout and compiler adaptation

The historical programs use shared arrays and control blocks rather than the object-based representations typical of current browser applications. Compatibility consequently depends on memory layout as well as on numerical expressions.

Pass I composing routines share P(100), IP(10), and D(2000). Pass II exposes its own parameter and conversion storage, including G(1000). Pass III uses a shared integer workspace I(15000), parameter records P(100), and the control block IP(21); generator routines also use EQUIVALENCE to overlay real-valued working storage on integer memory. Function tables, instrument definitions, and note state occupy regions determined by control parameters. An incorrect index can therefore overwrite a different category of synthesis state.

The manual’s PLF examples declare the shared arrays in IP/P/D order, whereas the selected modern Pass I expects P/IP/D. M5live rewrites that declaration to match the runtime’s application binary interface and verifies the required array dimensions. It preserves the routine’s variable names and expressions. An unchanged-looking equation is insufficient evidence of compatibility if its operands are read from the wrong shared-memory offsets.

Historical fixed-form source also requires careful handling of statement labels, comment columns, continuation markers, and manuscript indentation. The normalizer adjusts these source-layout conventions and removes recognized deck directives. It does not automatically repair arithmetic, replace branches, or infer intended variable names. Compiled units must define supported, no-argument entry points and have a recognizable closing END.

Custom compilation uses GNU Fortran with -std=legacy, -ffixed-line-length-none, -fno-align-commons, -fcheck=bounds, and -O0. These settings accommodate the selected source form and shared-storage conventions while making certain bounds violations observable. They are part of the reconstruction’s execution conditions, not a guarantee that all legacy source is portable or correct.

Per-score CONVT compilation

A supplied SUBROUTINE CONVT is separated from the score and linked with the pinned Pass II source after removal of its built-in converter. The resulting executable performs that score’s conversion in the native pipeline. Both FORTRAN NDECK forms and standalone supported subroutine declarations are recognized. Archival tape directives and prose following the supported compilation units are excluded and reported; they are not silently interpreted as score instructions.

A minimal frequency-conversion fragment illustrates the mechanism:

      SUBROUTINE CONVT
      COMMON IP(10),P(100),G(1000)
      IF (P(1).NE.1.) GOTO 100
      IF (P(3).NE.1.) GOTO 100
      F=511./G(4)
      P(6)=F*P(6)
  100 RETURN
      END

This fragment applies to an instrument whose P6 contains frequency in hertz; it is not interchangeable with converters belonging to other orchestras. It illustrates an alternative to the configured general converter in the preceding score.

The integration tests exercise the mechanism rather than merely checking whether a compiler returns success. A test converter is compiled twice with different frequency multipliers. Its output is measured near 440 Hz and 880 Hz respectively, and the normalized-source hashes differ. Syntax failures, bounds failures, and an attempted write to a read-only input mount are also tested. A failed supplied converter is not replaced automatically by the general converter or by TypeScript synthesis.

Callable PLF composing routines

The upgrade enables score-supplied PLF1 through PLF5 routines in Pass I. A card such as PLF 0 1 ...; dispatches to the supplied SUBROUTINE PLF1; the number selects a program slot, not a universally defined compositional algorithm. A matching routine must be present.

The native scanner was extracted into callable READ0/READ1 routines. Explicit SAVE storage preserves scanner position, partially consumed cards, instrument-definition state, and stereo-control state when a PLF reads additional input before returning. This is necessary for a routine to consume a following note, alter its parameters, emit it, and resume the score reader at the correct position.

WRITE1(10), used by historical examples, is mapped to the job’s isolated Pass I output; logical units 2 and 20 are also accepted. Record length and finite values are checked before writing. The driver applies SV1 and SIA vector writes to the appropriate D-memory addresses, correcting a constant-index assignment in the selected source. A generated dispatcher links only the supplied slots, and several PLFs may be combined with a score-specific CONVT in the same render.

The supplied executable examples demonstrate note generation and a READ1-based delayed, transposed repetition. They are newly written validation examples, not claimed transcriptions of Risset’s composing routines. Native PLS execution in Pass II remains unavailable. The earlier BEFAP experiment is likewise not the implementation of these mechanisms: BEFAP belongs to the MUSIC IV orchestra-assembly lineage, whereas MUSIC V provides score-defined instruments and its own composing/conversion hooks.

Restoration of GEN 4 and GEN 5

The selected upstream Pass III contained a GEN 4 table-clearing operation using an uninitialized index and an empty GEN 5 routine. These cases required interventions beyond source formatting.

GEN 4. The repair creates initialized scratch storage, accumulates bounded sine segments, and normalizes their combined peak before writing the function table. Each group specifies amplitude, cycles, phase, start index, and end index. Both 1…512 and 0…511 conventions are supported; a zero endpoint selects the latter convention. Segment phase begins at the segment’s own first sample. Table identifiers, group arity, and segment bounds are checked before writes to shared storage. The scratch array also removes dependence on the smaller real-array declaration found in the earlier routine.

GEN 5. The reconstruction follows the identification of Little Boy’s GEN 5 with the exponential generator numbered GEN 7 in Risset’s catalogue, discussed by Lazzarini, Keller, and Radivojević (2023, §4.1.3). For normalized table position x = k / (N − 1), a negative parameter p gives decay proportional to 2^(p × x); a positive parameter gives rise proportional to 2^(p × (x − 1)). The zero case produces the documented symmetric bell envelope. The implementation preserves the reference amplitude factors and applies the function-table scale factor to the positive branch, addressing an omission in the published listing’s final integer assignment.

These generator repairs are compiled into native Pass III. The build runs a Fortran table harness covering sine mixtures, segment phase and indexing, exponential rise and decay, and the bell envelope. Invalid tables, invalid segments, and missing parameters must fail. End-to-end fixtures include Grosse Caisse and Fanfare material alongside simpler generated scores. Obsolete GEN cards used for tape-file skipping are rejected rather than treated as table definitions.

A related diagnostic checks positive SET overrides before an oscillator or envelope dereferences a replacement table. A request whose complete table would overlap note storage reports the parameter, table, and instrument. The correction does not guess a replacement for an apparent manuscript error. In one annotated Contreapotheose example, P9 requests F40 beyond the workspace; the score’s own annotation identifies the problematic value.

Audio representation, isolation, and reproducibility

Native Pass III writes little-endian float32 audio to snd.raw and provides channel count and sampling rate in snd_params.txt. The service reads this metadata rather than assigning a fixed browser rate or assuming mono output. It packages the result as PCM16 WAV. Native block padding may remain at the end of a render.

Output protection estimates reconstructed peaks with a four-phase, 48-tap windowed-sinc interpolator. A recording exceeding the 0.85 reconstructed-peak ceiling receives one attenuation factor across both channels. This addresses peaks between stored samples and potential clipping during playback resampling. It preserves relative dynamics within the recording, but changes absolute gain when protection is triggered. Consequently, the browser WAV is a documented delivery representation rather than a claim of sample-for-sample identity with the unscaled native float stream.

Jobs with supplied Fortran compile and execute inside a disposable, non-root Docker container with no network, read-only source and engine mounts, bounded writable memory filesystems, and process, CPU, memory, file-size, and elapsed-time limits. Ordinary native jobs also run in separate directories under process resource limits. The service admits two simultaneous native renders and cleans up job data after completion or failure.

The status endpoint, /api/native/status, identifies executable hashes and available embedded-Fortran support. Custom renders also identify the compiler image and hashes of normalized subroutines. Releases retain their own repaired Pass III binary, enabling a rollback to restore the corresponding implementation. These records support tracing an execution environment; they do not by themselves prove equivalence to a historical machine, tape, or recording.

Historical library and editorial operations

The historical library builds on earlier archival and reconstruction work by Victor Lazzarini, Nemanja Radivojević, Damián Keller, and other researchers who have studied and made Risset’s materials accessible. Radivojević, Keller, and Lazzarini’s “Issues of Ubimus Archaeology: Creative Processes in Risset’s Little Boy” (2022) documents investigations in the Fonds Jean-Claude Risset at Laboratoire PRISM, the recovery of early MUSIC V source, and the reconstruction of musical processes from scores and sketches. This prior work provides an essential basis for the materials and compiler lineage used here.

The present M5live import organizes 342 score files across 13 themes from the existing research collection. Its contribution is the integration of these materials into a searchable, executable, and revision-aware browser workspace. Original paths, variants, descriptions, and SHA-256 checksums are recorded in a collection manifest; fragments remain identified as fragments. The library can be searched and browsed by theme and source folder. Keyboard navigation follows the filtered folder order, crosses folder boundaries, and wraps at the collection ends.

Editorial changes are separated from archival originals. Shared historical corrections require an editing key and a matching revision; stale writes are rejected, and prior versions are retained. Local drafts recover work independently in the main and library editors. Personal scores remain browser-local, with import/export and the option to save a historical score as a separate editable copy. Featured patches can be selected locally for random loading at startup when no edited draft needs recovery.

This arrangement treats a correction as an accountable reading of a source. A playable version and an archival transcription can coexist without silently substituting one for the other. A file’s inclusion in the collection indicates provenance and availability, not that every instruction, converter, or resulting sound has been verified.

Interface and pedagogical capabilities

The browser workspace now combines several forms of inspection and experimentation:

• Native rendering and explicit experimental playback. The F control or Ctrl+Enter invokes native MUSIC V; Alt+Enter selects TS. A failed native job leaves an earlier successful recording available and reports a diagnostic with compiler/pass context and expandable details.
• Rendered-audio inspection. A collapsible console sidebar opens when audio becomes available. It provides play/pause, seeking, elapsed and total time, and a polar trace derived from the decoded recording. Stereo channels are drawn separately. Closing the sidebar does not stop playback. Downloads retain the title captured at render time.
• Contextual GEN visualization. Moving the editor cursor to a GEN card displays one corresponding table, with amplitude and sample-index scales. It updates during editing, supports wrapped cards and repeated table identifiers, and disappears on other instructions. Local previews cover GEN 1–5 and 8; GEN 6/7 are identified as unavailable. These mathematical previews precede native integer quantization and do not replace the native generator tests.
• Executable command tutorial. Cmd/Ctrl+Shift+/ opens a right-hand tutorial with syntax explanations and complete example scores. Examples can replace the editor contents with Undo available, or be rendered directly without changing the working score. Command mentions, including those inside snippets, link to the corresponding explanation. Help also links to tutorial sections and gives the project’s principal research references.
• Editing support. Ace search, wrapped-line annotations, explicit line repair, score naming, keyboard transport controls, and draft recovery support close comparison between manuscripts, corrections, and audible results.

The restrained terminal presentation provides a common visual context for code, diagnostics, and signal inspection. Its role is functional and interpretative: visualization makes intermediate representations available for scrutiny, while the code and resulting recording remain distinct objects of inquiry.

Verification and remaining limits

Validation combines source-level checks, mathematical fixtures, native execution, and selected audio measurements. Tests cover parameter order, comments and continuations, manuscript checksums, shared-library revision conflicts, table shapes, note generation, scanner resumption, D-memory writes, combined PLF/CONVT execution, mono/stereo metadata, concurrent-job separation, and selected historical scores. Deliberately malformed programs must produce explicit errors.

This evidence supports the tested behaviors and source variants. It does not establish universal compatibility with MUSIC V manuscripts, full equivalence of the browser renderer, or perceptual identity with historical recordings. The archived C/WASM work remains unvalidated as a complete translation; native PLS is unavailable; arbitrary extra Fortran program units are not accepted; and live multi-user editing is not provided by the maintained application. Differences in transcription, compiler behavior, integer scaling, and output-level protection remain relevant to interpretation.

Further research can extend the corpus of reviewed converters and composing routines, assess additional generators and historical variants, and compare rendered results with documented recordings under explicit conditions. Such work requires retaining evidence of both successful reconstructions and cases that remain ambiguous.

Artistic research: reconstruction as an experimental practice

The technical work makes compositional procedures available for renewed use. A historical instrument can be approached as an executable proposition: changing an envelope, a conversion rule, or the ordering of generated notes exposes relationships between symbolic notation, computational state, and audible form. Listening becomes part of the inquiry, alongside source criticism and numerical inspection.

The artistic-research contribution proposed here lies in how these operations can be staged and compared. Reconstructing a converter may clarify an earlier composer’s parameterization; using that converter in a new score can test what its constraints afford in another compositional situation. The resulting work need not reproduce an earlier piece to provide knowledge about the system. Its research value depends on making the source, intervention, execution conditions, and listening procedure sufficiently explicit to be discussed and revisited.

The edit–render interval also remains a material condition of performance. It introduces a temporal relationship between a written change and its audible consequence, making the preparation of a sound, its execution, and its subsequent evaluation available as distinct actions. In this setting, historical computation is both an object of study and a resource for present artistic decisions.

References and implementation records

• Azzigotti, Luciano, and Nemanja Radivojević (2022). M5live: a historical online environment for electronic music. Principal project reference. The existing project record is also identified by DOI: 10.5281/zenodo.6819563.
• Mathews, Max V., with Joan E. Miller, F. R. Moore, John R. Pierce, and J. C. Risset (1969). The Technology of Computer Music. MIT Press. The implementation assessment uses the tutorial’s printed pp. 62–66 for CONVT and pp. 78–98 for composing routines; the program description’s pp. 144 and 151–152 distinguish PLF, PLS, and CONVT.
• Risset, Jean-Claude (1969). An Introductory Catalogue of Computer Synthesized Sounds. Bell Telephone Laboratories. Historical context for the catalogue scores and generator conventions; the GEN 5 reconstruction follows the study below and the surviving sources.
• Radivojević, Nemanja, Damián Keller, and Victor Lazzarini (2022). “Issues of Ubimus Archaeology: Creative Processes in Risset’s Little Boy.” Rethinking the History of Technology-based Music, University of Huddersfield, 9–11 June 2022, collected abstracts. DOI: 10.5920/UbimusArchaeology.
• Lazzarini, Victor, Damián Keller, and Nemanja Radivojević (2023). “Issues of ubiquitous music archaeology: Shared knowledge, simulation, terseness, and ambiguity in early computer music.” Frontiers in Signal Processing 3, 1132672. DOI: 10.3389/frsip.2023.1132672, especially §4.1.3.
• Pinned MUSIC V source lineage. Source transcription and port by Schottstaedt, with Lazzarini’s additions and repairs.
• Current implementation evidence: native/UPSTREAM.md, native/pass3-generators.f, native/pass1-driver.f, native/pass1-plf.f, scripts/native-program.mjs, scripts/native-render.mjs, the native and frontend test fixtures, and public/data/historical-scores.json. These paths identify the maintained working repository’s records; they are not claims that every local development artifact is present in the original public repository.

M5live environment · Project repository