Source-linked AI summary
One Timeline, Many Renderings: A Wolfram Language Paclet for heterogeneous musical output
Francesco Vitucci, Michele Lorusso, Francesco Scagliola
TL;DR
Temporal System addresses drift among Csound, notation, live control, and click outputs by compiling one immutable typed store on a rational beat timeline. It renders that store through backend-specific contracts, preserving synchronization across Csound, beta MusicXML, OSC, and click artifacts. The system demonstrates shared timeline edits across heterogeneous outputs, while remaining limited by proprietary authoring, beta release status, and Csound adapter constraints.
Problem
Separately authored musical outputs can diverge because their seconds, divisions, milliseconds, and samples no longer share one authoritative timeline.
Method
Temporal System uses an immutable typed store with rational beat-time, authored meter, session configuration, and backend-specific rendering contracts that defer unit conversion to serializers.
Results
The downbeat of bar 3 aligns at Csound p2= 4.0 s, OSC time ms= 4000, a strong click at 4.0 s, and MusicXML bar 3, beat 1; changing 90 →60 BPM moves later time-domain onsets consistently.
Takeaways & Limitations
One authored timeline can produce unequal but synchronized synthesis, click, notation, and OSC projections, with curves represented according to each backend’s contract.
Takeaways & Limitations
Authoring remains dependent on a proprietary Wolfram environment, and the Csound adapter requires declared p-fields and rewritten instrument copies.
Abstract
from arXiv · showhide
One algorithmic composition may require a Csound score, engraved notation, real-time control, and a rehearsal click. Authored separately, their timelines drift. Temporal System is a Wolfram Language paclet that instead compiles one immutable store of typed entities on a rational beat timeline through backend-specific contracts. It emits Csound synthesis, beta MusicXML 4.0, OSC control, and click artifacts that remain synchronized because they share that store. Conversion to seconds, samples, or hertz occurs only at render time. Csound notes use stable named instruments in external .orc files; curves become k-rate signals declared against score p-fields. The click backend derives rehearsal audio from the same meter and tempo and reuses the Csound serializer. We describe the temporal, semantic, and rendering-contract layers, their practical trade-offs, and the limits of this proprietary authoring environment within an otherwise open-source ecosystem. The archived supplement exposes the reported outputs pending paclet release.
1 Introduction
Temporal System addresses timeline drift in heterogeneous musical outputs by making one timeline authoritative and deriving each rendering from it. Its distinctive combination spans explicit backend contracts while retaining exact beat-time modeling, but authoring remains tied to a proprietary environment.
- Separately authored scores, notation, live control, and clicks can diverge in seconds, divisions, milliseconds, and samples.
- Temporal System combines exact fractional timing with explicit contracts for notation, offline Csound, OSC, and click output.
- The system stores exact Rational onsets in an immutable typed store, authored meter, session tuning, and external .orc instruments.
- Authoring requires a proprietary environment, while emitted .csd/.orc, MusicXML, and JSON remain open plain-text artifacts.
2 Anatomy of the Paclet
The paclet separates backend-agnostic temporal and semantic layers from backend-specific rendering contracts. It preserves rational beat-time until rendering, validates typed entities and fallback behavior, and provides self-inspection and archived outputs for reproducibility.
- The implementation has fourteen modules, 80 public functions, and three conceptual layers: temporal, semantic, and rendering-contract.Utilities support the layers rather than forming a fourth layer, and all functions are pure.
- Tempo uses stepwise BPM points to compile an analytically invertible beat-to-seconds map, without continuous accelerando or ritardando.Onsets and durations remain Rationals until a renderer requests seconds or samples.
- The typed store provides O(1) access by entity type, supports seven implemented entity types, and treats authored meter as a state entity.Session configuration includes freely reassignable tuningA4, defaulting to 440 Hz.
- Rendering contracts validate backend payload keys and declare fallbacks, such as reducing continuous curves to textual directions in MusicXML.
- drawTimeline renders lane-based graphics from authored meter entities, while the Zenodo supplement archives notebooks, outputs, audio, and a tempo-edit demonstration.The paclet release remains pending.
3 The Implemented Renderers
The implemented renderers are data-defined projections dispatched from the shared store, with MusicXML explicitly lossy and backend-specific entity coverage. They target Csound, click, notation, and OSC outputs through distinct serialization contracts.
- A backend association contains an identifier, renderer, serializer, emitted primitive types, and fallback policy.The generic renderTo entry point dispatches the shared stemData to a selected backend.
- MusicXML: MusicXML builds measures from meter state, splits notes at barlines into tied fragments, and validates measure, part, tie, and chord integrity.
- MusicXML and OSC: MusicXML is an explicitly lossy beta projection emitting MusicXML 4.0 partwise, while OSC emits schedule-ready JSON in milliseconds with sampled curves.
4 The Csound Renderer
The Csound renderer compiles typed timeline entities into score and orchestra primitives while preserving external instruments and applying curve controls through generated copies. Late conversion derives seconds, frequencies, and amplitudes from the tempo map, tuning, and dynamics at render time.
- Rendering: Csound renders notes and triggers as i statements, markers as onset-ordered comments, and curves as k-rate control signals.Curve signals use either a GEN-2 table reader or generated transeg, according to session choice.
- Rendering: Both Csound-family renderers share one serializer while source instruments remain in external .orc files.Curve bindings add generated instrument copies without modifying the source files.
- Rendering: Late conversion computes score onset and duration in seconds, pitch in Hz, and amplitude from Rational timing, session tuningA4, and dynamics.Changing tempo or tuning regenerates rendered values without changing entities.
- Instrument identity: Named instruments use stable .orc filenames as identifiers in both instrument definitions and entity payloads, avoiding numeric renumbering as the orchestra grows.A rendered example remains readable and stable as the orchestra expands.
- Curve binding: Curve bindings target p-fields in multiply or replace mode, and affected instrument bodies are copied and rewritten at each render.The rewrite changes only bound p-field use-sites while preserving other instrument logic.
- Trade-offs: The current adapter favors deterministic offline, self-contained score artifacts and legacy score-style instruments, while channel-based control remains future work.Duplicating and rewrite-parsing instrument bodies is identified as a limitation.
5 A Click Track from the Same Timeline
The click backend derives rehearsal audio from authored meter and tempo rather than maintaining a separate timeline. It reuses the Csound serializer, so meter and tempo edits propagate without additional click authoring.
- Click generation: The click backend reads meter entities and the tempo map, builds the measure grid, and emits one short i event per beat with downbeat accents.Its session-configured parameters include beat unit, click duration, frequencies, amplitudes, and pan.
- Click generation: For two 4/4 bars at 120 BPM, it emits strong downbeats at 0 and 2 s with weak intervening beats.The complete .csd and .wav are included in the supplementary folder.
- Reuse and scope: The backend reuses serializeCSnd unchanged and does not modify the temporal or semantic layers.This demonstrates reuse in one case, not a general measure of arbitrary backend-addition cost.
6 Keeping the Projections Synchronous
All projections read the same rational onsets and compiled tempo map, preventing timeline drift across Csound, click, OSC, and beta MusicXML. Tempo edits shift time-domain outputs while preserving beat-space notation durations.
- Shared timing: A timeline of two 4/4 bars followed by 3/4 at 120 then 90 BPM places bar 3’s downbeat at 4.0 s in Csound, OSC, and click, and at bar 3 beat 1 in MusicXML.The four projections therefore represent the same event through different backend contracts.
- Tempo editing: Changing the second tempo segment from 90 to 60 BPM moves the beat 9/4 note from 4.667 to 5.0 s in time-domain backends.In MusicXML, only the second tempo mark changes; the initial tempo and written durations remain unchanged.
7 Conclusions
Temporal System compiles an immutable rational-beat store into synchronized Csound, click, notation, and OSC projections. The conclusion frames this architecture alongside unresolved release, format, backend, and portability boundaries.
- Conclusion: The system turns one immutable rational-beat store into unequal but synchronized Csound, click, notation, and OSC projections.Its central separation is computed time from rendered sound.
- Boundaries: The paclet is unreleased, MusicXML remains beta, MIDI and continuous-tempo support are absent, and named Csound channels are not implemented.MIDI and additional renderers are planned for future work.
- Boundaries: Authoring remains proprietary in the unreleased Wolfram paclet, although emitted artifacts and the supplement are portable.These boundaries delimit the current results and motivate open-source portability work.
- Boundaries: Csound curves require declared p-fields and rewritten instrument copies, while named-channel adaptation remains future work.This constrains the current Csound projection design.