DEV Community: Anup Jayant Dharangutti

An exploration of media as code: deterministic audio, synchronized visuals, runtime-bound media, transcription, and developer tooling in .NET.

Anup Jayant Dharangutti — Sat, 03 Oct 2026 13:45:50 +0000

Media as Code: Building Deterministic Audio, Visuals, and Adaptive Experiences with SoundScript

What changes when audio, visuals, timing, application state, and even parts of media analysis become things developers can compile, inspect, test, diff, and version?

Most software teams are comfortable treating configuration as code.

Infrastructure became code.

Build pipelines became code.

UI increasingly became declarative.

But media still often enters a project as a collection of opaque artifacts:

success-final.wav
success-final-v2.wav
success-final-v2-fixed.wav
notification-new.wav
animation-final.webm
animation-final-really-final.webm

That workflow is perfectly reasonable when the media itself is the final product.

It becomes less comfortable when media is actually part of software behavior.

A monitoring system needs a warning cue.

A test suite needs a repeatable audio fixture.

An application needs synchronized audio and visual status feedback.

A developer tool needs generated notification sounds.

A data-driven experience needs its media to respond to state.

A transcription experiment needs to turn suitable audio back into something editable.

In those situations, the interesting question is not:

“How do I store this media file?”

It becomes:

“How much of this media can I describe as source?”

That is the direction behind SoundScript: an open-source .NET project for programmable audio and synchronized media.

Rather than treating every sound, score, visual cue, or media state as an opaque binary, SoundScript lets developers work with readable descriptions, compiled representations, deterministic renderers, queryable timelines, and application-facing APIs.

This article explores that idea from the perspective of a developer building something—not from the perspective of release notes.

Start with something deliberately small

Imagine an application needs a short success cue.

You could ship a WAV file.

Or you could describe the musical intent:

tempo 120

track success {
    instrument piano
    mf

    C4 e
    E4 e
    G4 q
}

Then compile it from .NET:

using SoundScript;

var compilation = SoundScriptEngine.Compile("""
    tempo 120

    track success {
        instrument piano
        mf

        C4 e
        E4 e
        G4 q
    }
    """);

File.WriteAllBytes("success.wav", compilation.RenderWave());
File.WriteAllBytes("success.mid", compilation.RenderMidi());

The result is still media.

The difference is that now the reason the media sounds the way it does is visible in source control.

If somebody changes the last note from G4 to C5, that change can appear in a diff.

If the tempo changes from 120 to 108, you can review the exact intention.

If a regression test expects a known deterministic rendering, the source that generated it lives beside the test.

Why this helps

Media stops being only an artifact and becomes partly an explainable software input. That makes review, reuse, debugging, testing, and maintenance much closer to ordinary engineering workflows.

This does not mean every piece of audio should become code.

It means code becomes another useful representation when the media participates in application logic.

From notes to a small musical language

A three-note cue is useful, but real authoring needs structure.

SoundScript's music language includes pitches, rests, ties, standard and numeric durations, dotted notes, tuplets, grace notes, chords, dynamics, articulations, time signatures, tempo changes, tracks, reusable blocks, patterns, phrases, loops, imports, layers, and orchestration helpers.

A more structured score might look like this:

perform expressive

tempo 96
time 4/4

pattern arp {
    up
}

block resolution {
    C4 q
    E4 q
    G4 q
    C5 q
}

track lead {
    instrument flute
    mf

    phrase {
        articulation legato
        crescendo

        C4 q
        D4 q
        E4 h
    }

    play resolution
}

This matters because musical intent is not just a list of MIDI numbers.

There is a difference between:

C4 D4 E4

and:

phrase {
    articulation legato
    crescendo
    C4 q
    D4 q
    E4 h
}

The second version says something about how the phrase should behave.

SoundScript keeps a distinction between the written structure and the renderer interpreting it.

That becomes important when the same source can travel toward different outputs.

                   SoundScript source
                          │
                          ▼
                 Parser / interpretation
                          │
                ┌─────────┴─────────┐
                ▼                   ▼
              MIDI                Wave
          event-oriented      rendered audio

The two outputs share musical intent but are not identical representations.

MIDI carries events.

Wave carries samples.

Some expressive information naturally behaves differently across those worlds.

Why this helps

A developer can keep intent above output format. The score does not have to be designed exclusively around a single file type from the beginning.

The full language reference is available in the SoundScript documentation.

Determinism is more useful than it sounds

“Deterministic media” can sound like an academic concern until you put media inside tests, automation, CI, build systems, or generated application assets.

Suppose a test creates a notification sound.

If every run changes slightly because humanization uses uncontrolled randomness, byte-level regression testing quickly becomes unpleasant.

SoundScript instead uses controlled deterministic behavior for supported rendering paths.

Humanization can still exist:

track piano {
    humanize timing=0.02 velocity=0.08 seed=42

    C4 q
    E4 q
    G4 q
}

The important difference is that variation can be repeatable.

When a seed is not explicitly provided in supported Wave features, SoundScript can derive deterministic variation from content rather than reaching for clock-based randomness.

That makes “humanized” and “reproducible” less contradictory than they first appear.

Why this helps

Deterministic media is especially valuable for test fixtures, CI comparisons, generated assets, reproducible demos, regression investigation, and build pipelines. When output changes, you can ask whether the source or renderer actually changed instead of wondering whether randomness changed it.

There is an important boundary here.

Repeatability depends on the relevant fixed inputs: source, assets, renderer version, configuration, and supported deterministic execution path.

Compressed-media decoding and codec-based video encoding have additional environmental variables.

The goal is not to claim that every multimedia byte will magically be identical everywhere.

The goal is to make determinism a deliberate engineering property where it is defensible.

Direct audio: not everything needs to become MIDI first

A programmable music language does not necessarily have to route every operation through MIDI.

SoundScript also has a direct Wave backend.

That path can render a script directly to WAV and adds capabilities that make more sense after audio samples actually exist.

For example:

effect delay time=0.25 feedback=0.35 mix=0.25
effect filter type=lowpass cutoff=2400

track cue {
    humanize timing=0.015 velocity=0.05 seed=12

    C4 q
    E4 q
    G4 h
}

The Wave path supports areas such as:

Wave rendering
├── direct script → WAV
├── mono / stereo output
├── expressive performance
├── deterministic humanization
├── delay
├── low-pass filtering
├── high-pass filtering
├── samples / recorded WAV stems
├── synthetic speak/prosody cues
├── external vocal stems
└── unpitched percussion events

Why keep this separate from MIDI?

Because MIDI has no final mixed audio buffer on which to apply a post-mix delay or filter.

That separation avoids pretending every media concept belongs in every backend.

Why this helps

Backend-specific features can remain explicit instead of silently degrading. When an operation fundamentally requires audio samples, it belongs on an audio path rather than being awkwardly disguised as a MIDI feature.

See the Wave grammar documentation.

What if timbre were styled?

One of the more unusual pieces of the project is SoundCSS.

The rough analogy is intentional:

HTML describes structure.

CSS describes presentation.

SoundScript describes musical/media structure.

SoundCSS describes aspects of sound character.

A stylesheet can define phoneme-oriented properties such as harmonics, formants, transient behavior, brightness, noise components, resonance, and smoothing.

Conceptually:

aa {
    formant1: 700Hz;
    formant2: 1100Hz;

    harmonic1: 0.9;
    harmonic2: 0.6;
    harmonic3: 0.3;

    smoothness: 0.9;
}

The project also supports word-level rules for things such as delivery style, pitch shift, speed, energy, timbre, persona, emotion, breath, vibrato, and other bounded transforms.

For example:

"initialize" {
    persona: robot;
    pitch: -2;
    vibrato: none;
    timbre: flat;
}

This is not an attempt to replace modern neural speech synthesis.

It is a declarative way to experiment with reproducible transformations in the offline rendering pipeline.

Why this helps

Style-like media configuration separates what should be said or played from how a renderer should color it. That makes it easier to reuse content while experimenting with presentation.

The detailed model is documented in SoundCSS.

Text can become musical structure

There are several very different things people might mean by “text to sound.”

One is speech synthesis.

Another is turning language into musical structure.

SoundScript includes deterministic text-to-melody paths.

For example, the compose workflow uses syllables and phonemes as input to musical gesture generation.

A separate prosody path uses word stress and sentence contour to influence pitch.

Conceptually:

Text
 │
 ├── syllables
 │
 ├── phonemes
 │
 └── prosodic structure
       │
       ▼
 musical gestures
       │
       ▼
 SoundScript score / MIDI

That means text can become editable musical source rather than terminating as an opaque generated asset.

This distinction matters.

Text-to-melody is not text-to-speech.

A phoneme composer generates notes.

A vocal pipeline can associate written lyrics with written pitches.

A Wave speak path can generate synthetic phoneme/prosody audio cues.

A WordBank-based path can work with recorded or generated word stems.

Those are separate tools because they solve separate problems.

Why this helps

Keeping text-to-melody, lyric alignment, synthetic cues, and vocal rendering separate avoids one oversized “AI voice” abstraction. Developers can choose the representation they actually need and inspect the intermediate result.

Lyrics can live next to pitches

Another part of the project treats vocals as symbolic data.

Consider:

voice lead {
    vocal choir
    mf

    sing "Twinkle twinkle little star"
         C4 q C4 q G4 q G4 q A4 q A4 q G4 h
}

The engine aligns syllables with notes and emits lyric metadata in MIDI.

That makes the file useful to tools that understand karaoke-style lyric events.

The lyrics themselves are not audio embedded inside MIDI.

They are structured metadata associated with musical events.

The Playground can provide a browser speech preview, while deterministic MIDI remains separate from browser-dependent speech synthesis.

Why this helps

Symbolic lyric timing is reusable. The same musical/lyrical structure can travel into a DAW, karaoke workflow, another synthesizer, a visual lyric display, or a later rendering stage without forcing one speech engine into the core model.

See the vocal documentation.

Audio is only one rail

At some point the project crossed an important boundary.

Instead of asking only:

“What sound should happen?”

the language can also ask:

“What should exist visually at this moment?”

A simplified media program can combine a musical cue and a visual element:

tempo 120

track cue {
    C4 q
    E4 q
    G4 h
}

sync audio

visual "indicator" for 4s {
    shape circle
    fill "#16a34a"

    animate x 200 -> 1080 over 4s
}

The important idea is not merely that a video can eventually be rendered.

It is that the visual timeline itself is queryable.

From .NET:

using SoundScript;
using SoundScript.Media;

var compilation = SoundScriptEngine.Compile(source);

var media = compilation.CompileMedia();

var scene = media.SceneAt(TimeSpan.FromSeconds(2));

string json = TemporalVisualJson.Serialize(scene);
string svg = TemporalSvgRenderer.Render(scene);
byte[] wav = media.RenderAudio();

That makes the core model:

                    compiled media
                          │
             ┌────────────┴────────────┐
             │                         │
             ▼                         ▼
           Audio                    Timeline
          WAV/PCM                  SceneAt(t)
             │                         │
             └──────── shared t ───────┘
                          │
                          ▼
                    scene model
                ┌─────────┼─────────┐
                ▼         ▼         ▼
              JSON       SVG      custom UI

This is different from treating video as the primary abstraction.

The application can ask:

What exists at t = 2.0 seconds?

without first generating a video and decoding frame 60.

Why this helps

SceneAt(t) turns media timing into application data. That is useful for synchronized dashboards, simulations, accessibility layers, tests, alternate renderers, custom UIs, and systems where the application—not the media file—owns playback.

See the programmable media runtime.

The timeline is not tied to one renderer

Once a scene can be queried as structured state, the host has options.

The same conceptual media state can feed:

SceneAt(t)
├── JSON
├── SVG
├── HTML
├── Canvas
├── application-native UI
└── sampled frames → WebM

That architectural separation is subtle but useful.

A browser does not need to implement a second interpretation of the SoundScript timing model.

A desktop application does not need to parse the source again.

A video exporter does not need to invent its own semantics.

They all consume evaluated state.

Why this helps

One timing model can support multiple presentation technologies. That reduces the chance of the browser, CLI, server, and video renderer slowly developing different interpretations of the same source.

Then comes the interesting part: application state

Static media is useful.

But applications are not static.

A monitoring system might have:

Normal
Warning
Critical

A game entity might have changing intensity.

A simulation may expose continuously changing numeric state.

Rebuilding source strings every time a value changes would technically work, but it is not a particularly clean host API.

SoundScript therefore supports a constrained runtime-parameter model.

Consider:

param intensity = 0.25
param xpos = 200

perform expressive
tempo 120

track cue {
    gain intensity

    C4 q
    E4 q
    G4 h
}

visual "indicator" for 4s {
    shape circle

    set x xpos
    set y 360
    set width 120
    set height 120
    set opacity intensity
}

The source describes a fixed structure.

The application changes approved numeric values.

using SoundScript;

var runtime = SoundScriptEngine.CompileRuntime(source);

runtime.SetMany(new Dictionary<string, decimal>
{
    ["intensity"] = 0.90m,
    ["xpos"] = 900m
});

var snapshot = runtime.Bind();

File.WriteAllBytes("critical.wav", snapshot.RenderAudio());

var scene = snapshot.SceneAt(
    TimeSpan.FromSeconds(2));

The source was not regenerated.

The structure was not reparsed for the update.

The host supplied state.

The runtime validated it.

The snapshot froze a coherent view.

That last part is important.

If the host updates the runtime again, a previously bound snapshot does not silently mutate.

Compiled structure
       │
       ├── Runtime instance A
       │      ├── state
       │      └── Bind() → Snapshot A
       │
       └── Runtime instance B
              ├── state
              └── Bind() → Snapshot B

Why this helps

Snapshots provide a clean boundary between mutable application state and stable media output. A render can finish against the state it was given instead of observing half of one update and half of another.

The runtime is deliberately constrained.

Parameters do not rewrite arbitrary notes, imports, tempo, timing, names, or structural decisions.

Supported use is intentionally more like data binding than self-modifying source code.

That limitation is valuable.

Why this helps

Restricting runtime parameters keeps the compile-time structure understandable. The host gets adaptability without turning every media operation into dynamic code generation.

The complete model is described in the runtime parameters guide.

A monitoring example makes the model concrete

Imagine a build or infrastructure dashboard.

Instead of playing the same alert for everything, application state can become both visual and audible.

Healthy
  ↓
low intensity
green indicator
quiet cue

Warning
  ↓
medium intensity
larger/brighter indicator
stronger cue

Critical
  ↓
high intensity
prominent indicator
louder cue

That same state could drive:

                 Application state
                        │
                        ▼
               validated parameters
                        │
                        ▼
                  bound snapshot
                  ┌─────┴─────┐
                  ▼           ▼
                audio       visual
                  │           │
                  └─────┬─────┘
                        ▼
                 shared experience

The interesting point is not the warning sound itself.

It is that one piece of typed state can influence multiple media channels coherently.

Why this helps

In status-oriented applications, audio and visuals can reinforce each other from the same state instead of being maintained as unrelated assets and UI logic.

Media can become test data

This is one of the less glamorous use cases, but perhaps one of the most practical.

Tests often need inputs.

A media-processing system might require:

a 440 Hz cue
a known sequence of notes
a fixed-duration WAV
a deterministic alert pattern
a synchronized visual timeline
a repeatable transcription input

Traditionally you check binary fixture files into the repository.

Sometimes that is exactly the correct solution.

But generated fixtures have a useful property:

the fixture can explain itself.

A source such as:

tempo 120

track fixture {
    C4 q
    E4 q
    G4 h
}

is much easier to inspect than a binary WAV when the test expectation is “three known notes at known durations.”

A build step can render the media when necessary.

Why this helps

Programmatic fixtures reduce the gap between what a test says it needs and what the binary fixture actually contains. That can make failures easier to investigate and fixtures easier to evolve intentionally.

SoundScript includes examples oriented toward deterministic fixtures and DevOps-style sonification in its documentation and sample projects.

CI can listen too

Once audio is programmable, non-media systems can use it.

One small example is sonification: mapping application or pipeline states to sound.

A CI system could represent:

Build started     → short neutral cue
Tests passed      → ascending confirmation
Tests failed      → contrasting alert
Deployment ready  → completion phrase

This is not intended to replace logs.

It creates another channel.

The interesting part is that the mapping can live in source and be tested like any other behavior.

Why this helps

Sonification can provide ambient feedback when developers are already overloaded visually. It is especially useful as a complement to logs and dashboards rather than a replacement for them.

The reverse direction: audio back into editable source

So far, the flow has mostly been:

source → media

But sometimes developers begin with media.

SoundScript also contains a transcription subsystem.

For suitable monophonic input, the goal is:

audio
  │
  ▼
analysis
  │
  ▼
musical observations
  │
  ▼
editable SoundScript
  │
  ▼
render / compare / modify

A .NET example looks like this:

using SoundScript.Transcription;

var audio = PcmWaveInput.Decode(
    File.ReadAllBytes("melody.wav"));

var result =
    await new TranscriptionEngine().TranscribeAsync(
        audio,
        new TranscriptionOptions(
            Tempo: 120,
            Instrument: 73),
        TranscriptionMode.Monophonic);

Console.WriteLine(result.Suitability.Status);

var source =
    new SoundScriptOutput().Source(result.Score);

File.WriteAllText("melody.ss", source);

The emphasis on suitability matters.

Audio transcription is not deterministic truth recovery.

A waveform does not contain a hidden .ss file waiting to be extracted perfectly.

Pitch estimation, segmentation, tempo inference, mixtures, room effects, noise, instrumentation, and performance variation make the problem ambiguous.

SoundScript therefore separates the supported monophonic baseline from experimental analysis modes.

Transcription
├── Monophonic
│   └── supported baseline for suitable single-line material
│
├── Extract Melody
│   └── experimental dominant-line estimation
│
├── Polyphonic / Piano
│   └── experimental simultaneous-note analysis
│
├── Mixed Roles
│   └── experimental melody / harmony / bass estimates
│
└── Percussion / Rhythm
    └── experimental transient / unpitched events

Compressed desktop media can be decoded through FFmpeg-supported paths, while browser decoding depends on available browser codecs.

Analysis is bounded to short clips rather than pretending to be an unlimited music-understanding service.

Why this helps

Treating transcription as evidence plus editable output is much safer than pretending an estimated score is ground truth. Developers can inspect diagnostics, correct the generated source, and keep the human review step where the signal is ambiguous.

See the transcription documentation.

The Playground makes the model easier to understand

A language is much easier to understand when you can modify something and immediately experience the result.

The SoundScript Playground provides browser workflows around several parts of the system:

Playground
├── Music & Wave
├── text-to-melody
├── prosody
├── Wave rendering
├── audio/visual timelines
├── runtime parameter examples
├── transcription
├── source editing
├── diagnostics
├── timeline scrubbing
├── play / pause / resume / restart
└── export workflows

The editor also contains developer-oriented assistance such as validation, formatting, completion, hover information, outlines, find/replace, transposition helpers, duration editing, and visual authoring conveniences.

The point is not to become a full DAW inside a browser.

The Playground is closer to an interactive executable documentation surface for the language and runtime.

Why this helps

Developers can explore the model before committing to an integration. A concept like SceneAt(t) or a runtime parameter is easier to understand when you can scrub time or modify a value and immediately see the state change.

Try it at soundscript.net/playground.

The .NET API keeps the core inside your process

For .NET applications, the package exposes a programmatic facade.

The current public library is available as:

dotnet add package SoundScript --version 16.0.1

The basic workflow is intentionally straightforward:

var compilation =
    SoundScriptEngine.Compile(source);

byte[] midi = compilation.RenderMidi();
byte[] wav = compilation.RenderWave();

For synchronized media:

var media =
    compilation.CompileMedia();

byte[] audio =
    media.RenderAudio();

var scene =
    media.SceneAt(TimeSpan.FromSeconds(1.5));

For adaptive state:

var runtime =
    SoundScriptEngine.CompileRuntime(source);

runtime.Set("intensity", 0.8m);

var snapshot =
    runtime.Bind();

Compilation does not need to launch a CLI subprocess.

That distinction matters when SoundScript becomes part of a server, worker, desktop application, testing utility, or internal tool.

Why this helps

In-process APIs avoid shell parsing and process orchestration for normal application use. Media generation can participate directly in typed application code, exception handling, testing, and dependency management.

See the .NET API guide and NuGet documentation.

The CLI solves a different problem

A library is useful when your program owns the workflow.

A CLI is useful when your shell, script, or CI pipeline owns it.

The project exposes commands for areas such as:

Music
├── run
├── compose
├── prosody
├── render
└── wave

Media
├── visual
└── video

Analysis
└── transcribe

Automation
├── validate
└── inspect

Vocals
├── vocal generate
├── vocal batch
├── wordbank ensure
└── wordbank normalize

Validation and inspection are particularly useful in automation because they can return structured diagnostics and stable exit behavior.

A workflow can ask:

Does this source compile?
Which outputs are supported?
What is its duration?
Which visuals exist?
Are dependencies available?
Can FFmpeg produce the requested video format?

before committing to a full render.

Why this helps

Separating validation from rendering lets CI fail early. You do not need to generate every media artifact just to discover that the source or environment is invalid.

The current public library is published to NuGet; the CLI is documented as a source-build workflow for the public version rather than a separately published NuGet CLI tool.

See the CLI reference.

The capability map

By this point, the project is easier to understand as a set of connected developer capabilities than as a list of releases.

SoundScript
│
├── Musical authoring
│   ├── notes / rests / ties
│   ├── durations / dotted notes / tuplets / grace notes
│   ├── chords / voicings
│   ├── tempo / meter
│   ├── tracks / melodies / sequences
│   ├── loops / blocks / imports
│   ├── patterns
│   ├── phrases
│   ├── dynamics / velocity
│   ├── articulations
│   ├── deterministic humanization
│   ├── GM instruments
│   ├── layers
│   └── orchestration
│
├── Audio
│   ├── MIDI
│   ├── direct Wave rendering
│   ├── stereo rendering
│   ├── expressive performance
│   ├── samples / stems
│   ├── delay / filtering
│   ├── synthetic speak cues
│   ├── unpitched percussion
│   └── SoundCSS timbre
│
├── Text and vocals
│   ├── text → melody
│   ├── word-level prosody
│   ├── editable .ss output
│   ├── lyric-to-note alignment
│   ├── karaoke MIDI metadata
│   ├── vocal stem workflows
│   ├── WordBank
│   ├── pronunciation transforms
│   └── continuous vocal rendering
│
├── Programmable visuals
│   ├── timed visuals
│   ├── overlaps / waits
│   ├── audio synchronization
│   ├── shapes / text
│   ├── fills / strokes / styles
│   ├── animations
│   ├── exact SceneAt(t)
│   ├── typed scene model
│   ├── JSON
│   ├── SVG
│   └── WebM export
│
├── Adaptive runtime
│   ├── compile once
│   ├── typed decimal parameters
│   ├── validation
│   ├── atomic SetMany
│   ├── reset
│   ├── independent instances
│   ├── immutable bound snapshots
│   ├── audio binding
│   └── visual property binding
│
├── Transcription
│   ├── monophonic baseline
│   ├── melody extraction [experimental]
│   ├── polyphonic/piano [experimental]
│   ├── mixed roles [experimental]
│   ├── percussion [experimental]
│   ├── diagnostics
│   ├── suitability
│   ├── editable source
│   └── reconstruction comparison
│
├── Developer tooling
│   ├── .NET 10 library
│   ├── CLI
│   ├── validation
│   ├── inspection
│   ├── JSON diagnostics
│   ├── Playground
│   ├── examples
│   ├── deterministic fixtures
│   └── CI-oriented workflows
│
└── Labs
    ├── VideoLab
    └── Signal Lab

That map is useful because the individual features make more sense once the connecting idea is visible:

Source → validated structure → deterministic interpretation → inspectable state → chosen output.

Labs: experiments should look like experiments

Not every idea belongs in the stable package immediately.

SoundScript keeps experimental work in Labs, outside the main supported product surface.

That separation is important because experimental code can answer architecture questions without silently becoming a compatibility promise.

VideoLab

VideoLab explores programmable composition of actual video/audio assets using an independent experimental model.

Its work includes areas such as:

JSON composition
       │
       ▼
immutable composition
       │
       ▼
runtime bindings
       │
       ▼
snapshot
       │
       ▼
SceneAt(frame)
       │
       ▼
FFmpeg
       │
       ├── MP4
       └── WebM

The experiment covers clips, transforms, crops, opacity, audio gain, expressions, easing, reusable effects, conditions, parameterized variants, data-driven sequences, batches, and review-annotation scenarios.

It is deliberately bounded.

It is not presented as a full nonlinear video editor.

Why this helps

A separate lab allows the project to explore new composition semantics without contaminating the compatibility surface of the production language.

Explore the public VideoLab area at soundscript.net/labs/videolab.

Signal Lab

Signal Lab explores another direction: signals rather than music.

Its small experimental language can generate deterministic signals such as sine, square, chirp, and sweep waveforms and analyze them with operations including FFT, peak detection, RMS, and frequency estimation.

Outputs include structured JSON plus WAV, PCM16, and Float32 data.

Its scope is deliberately narrow and simulated.

It does not claim hardware capture, calibration, machine control, or measurement certification.

Why this helps

Keeping signal experiments isolated makes it possible to test whether SoundScript-like ideas generalize beyond music without prematurely expanding the production product.

See SoundScript Labs.

Where this architecture becomes especially useful

The value of programmable media varies enormously by project.

For a professionally mastered album, source-based synthesis may not be the interesting part.

For application media, however, several situations stand out.

Test automation

A test can generate the media it expects instead of depending entirely on unexplained fixture binaries.

Benefit: fixtures become easier to review, regenerate, and version.

Monitoring and operational software

One state can influence both audible and visual feedback.

Benefit: status communication can stay synchronized across multiple channels.

Developer tools

Build status, diagnostics, workflows, or simulations can emit meaningful cues.

Benefit: audio can supplement crowded visual interfaces.

Games and interactive applications

A compiled structure can create independent stateful instances and bound snapshots.

Benefit: one media definition can support many entities or sessions without source regeneration.

Procedural content

Inputs can produce repeatable outputs rather than requiring a hand-authored asset for every variant.

Benefit: content scales with data.

Education and experimentation

Music, signal, timing, and rendering concepts are visible in source and inspectable at intermediate stages.

Benefit: the path from intent to artifact becomes easier to study.

Accessibility experiments

Queryable media state creates opportunities for alternate representations rather than assuming one fixed rendered output.

Benefit: applications can interpret the same timing/state model differently for different users or interfaces.

CI and reproducibility

Validation, inspection, deterministic rendering, and structured diagnostics fit naturally into automated workflows.

Benefit: media becomes more compatible with ordinary software delivery practices.

What SoundScript deliberately does not try to hide

A programmable-media system becomes less useful if every boundary is marketed away.

Several distinctions matter.

SoundScript is not a DAW replacement.

It is not a neural music generator.

Its synthetic vocal paths are not a replacement for production speech synthesis.

Experimental transcription is not perfect music understanding.

VideoLab is not a production nonlinear editor.

Signal Lab is not measurement hardware.

Runtime parameters are not unrestricted self-modifying code.

WebM export still depends on FFmpeg.

Browser speech and browser media decoding depend on the browser environment.

These boundaries are features of the engineering story, not weaknesses to conceal.

Why this helps

Explicit limitations tell developers where the abstraction ends. That makes integration decisions more reliable than an API that appears universal until edge cases reveal otherwise.

The deeper idea: version the reason, not just the result

Imagine reviewing these two commits.

Commit A

Replace notification.wav

Commit B

- tempo 120
+ tempo 108

track warning {
-   C4 q E4 q G4 h
+   C4 q Eb4 q G4 h
}

The first commit tells you that the media changed.

The second begins to tell you why.

That difference is the part of programmable media I find most interesting.

Developers already expect software behavior to be explainable through code.

Media embedded in applications is also behavior.

Sometimes the right representation is still a handcrafted WAV, PNG, MP4, or professionally produced asset.

But sometimes the better representation is:

intent
+
source
+
parameters
+
assets
+
renderer

with the final media treated as an output.

Why this helps

Versioning the explanation makes media changes easier to review, reproduce, compare, regenerate, and connect to the application behavior that required them.

A practical way to explore SoundScript

If you want to understand the project, I would not begin by trying every feature.

Start with one tiny outcome.

Create a three-note cue.

Change its instrument.

Add a phrase.

Render it to WAV.

Add one visual.

Query the scene at two seconds.

Replace one constant with a runtime parameter.

Bind a new value from C#.

Only then explore text composition, vocals, transcription, or Labs.

The conceptual progression is:

sound
  ↓
structured sound
  ↓
rendered audio
  ↓
timed visuals
  ↓
queryable media
  ↓
application-bound media

At each step the question is the same:

Can the media remain understandable as software?

Final thought

Software engineering has spent decades converting opaque operational processes into inspectable systems.

We did it with builds.

We did it with infrastructure.

We did it with deployments.

We did it with configuration.

Media will never become entirely code—and it should not.

Human performance, filmmaking, sound design, illustration, and production assets have value precisely because they are richer than a declarative model.

But application media occupies an interesting middle ground.

When a sound represents application state...

when a visual follows an application clock...

when a test requires known audio...

when a generated artifact must be reproducible...

when multiple variants come from the same structure...

when the system needs to inspect what exists at an exact time...

then treating at least part of that media as code becomes surprisingly powerful.

The biggest benefit is not that code can generate a WAV or a WebM.

The benefit is that the system can retain an inspectable explanation of how that media came to exist.

That is the idea I am exploring with SoundScript.

If that problem space interests you, start with the Playground, read the source, or try the .NET package.

Playground: soundscript.net/playground

Documentation: soundscript.net documentation

GitHub: github.com/dharangutti/sound-script

NuGet: SoundScript

Labs: soundscript.net/labs

Procedural Game and Application Audio in .NET

Anup Jayant Dharangutti — Fri, 18 Sep 2026 11:48:59 +0000

What if your application generated sound from state instead of maintaining a WAV file for every possible variation?

Games and interactive applications are full of events.

A player collects an item.

A mission completes.

Health drops.

A warning appears.

A build succeeds.

A device enters an error state.

A message arrives.

The traditional architecture is straightforward:

Event
  ↓
Audio Asset
  ↓
Play

And for many products, that's exactly the right solution.

But sometimes sound isn't static.

Sometimes it depends on runtime state.

In those cases, a growing library of audio files can become increasingly difficult to maintain.

Instead of:

warning-1.wav
warning-2.wav
warning-3.wav
warning-4.wav

what if the application could derive the cue from the state itself?

That's where SoundScript becomes interesting.

Application State
        ↓
   Musical Rules
        ↓
   SoundScript
        ↓
    WAV / MIDI

Rather than selecting every sound from an asset library, your application generates controlled musical behaviour from data.

Let's build one.

Install SoundScript

SoundScript 13 targets .NET 10.

dotnet add package SoundScript --version 13.0.0

We'll start with a small set of application events.

Define Event Cues

Imagine a game or desktop application supports these events:

Collect
Achievement
Warning
Failure

Create a simple model:

record AudioCue(
    int Tempo,
    string Dynamic,
    string Motif);

Now define your musical rules:

var cues =
    new Dictionary<string, AudioCue>
    {
        ["collect"] =
            new(
                132,
                "mf",
                "C4 e E4 e G4 q"),

        ["achievement"] =
            new(
                120,
                "f",
                "C4 e E4 e G4 e C5 q"),

        ["warning"] =
            new(
                104,
                "f",
                "A3 e A3 e E4 q A3 e"),

        ["failure"] =
            new(
                72,
                "ff",
                "C3 e C3 e G2 q C3 e")
    };

Notice what the application owns:

Tempo
Dynamics
Musical motifs

Not:

Audio samples
DSP code
MIDI event streams
Waveform generation

The application describes intent.

Turn an Event into Audio

Choose an event:

var cue =
    cues["achievement"];

Build a SoundScript program:

var source = $"""
    tempo {cue.Tempo}

    track eventCue {{
        instrument piano

        {cue.Dynamic}

        {cue.Motif}
    }}
    """;

Render it:

using SoundScript;

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

File.WriteAllBytes(
    "achievement.wav",
    wav);

The entire pipeline becomes:

Achievement Event
        ↓
 Lookup Musical Rule
        ↓
    SoundScript
        ↓
        WAV

Why Not Just Use WAV Files?

A fair question.

If your product genuinely has four final sounds:

collect.wav
achievement.wav
warning.wav
failure.wav

then static assets are probably simpler.

Procedural generation becomes more compelling when runtime state influences the cue.

For example:

Warning
    +
Severity 1

may not need to sound identical to:

Warning
    +
Severity 4

Instead of storing:

warning-1.wav
warning-2.wav
warning-3.wav
warning-4.wav

you can derive variation from application state.

Let Severity Control Dynamics

Suppose severity ranges from 1 to 4.

Map it into musical dynamics:

var dynamic =
    severity switch
    {
        1 => "mp",
        2 => "mf",
        3 => "f",
        _ => "ff"
    };

Conceptually:

Severity 1 → mp
Severity 2 → mf
Severity 3 → f
Severity 4 → ff

The business meaning remains entirely inside the application.

SoundScript simply renders the resulting musical behaviour.

Let Progression Influence Tempo

Games often evolve over time.

A simple rule:

var tempo =
    80 + level * 4;

Produces:

Level 1  → Tempo 84
Level 5  → Tempo 100
Level 10 → Tempo 120

Your cue can evolve naturally without requiring dozens of manually authored audio assets.

Let State Choose the Musical Motif

You can also map application state directly into motifs.

var motif =
    status switch
    {
        "healthy" =>
            "C4 e E4 e G4 q",

        "degraded" =>
            "A3 e E4 e A3 q",

        "critical" =>
            "C3 e C3 e G2 q",

        _ =>
            "C4 q"
    };

Conceptually:

Healthy
    ↓
Bright Motif

Degraded
    ↓
Warning Motif

Critical
    ↓
Failure Motif

This keeps the relationship between state and sound explicit.

Combine Multiple Pieces of State

Most real applications have more than one variable.

Imagine:

record RuntimeState(
    string Status,
    int Severity,
    int Level);

Now derive each musical property independently.

var tempo =
    80 + state.Level * 4;

var dynamic =
    state.Severity switch
    {
        1 => "mp",
        2 => "mf",
        3 => "f",
        _ => "ff"
    };

var motif =
    state.Status switch
    {
        "healthy" =>
            "C4 e E4 e G4 q",

        "warning" =>
            "A3 e A3 e E4 q",

        "critical" =>
            "C3 e C3 e G2 q",

        _ =>
            "C4 q"
    };

Generate the final source:

var source = $"""
    tempo {tempo}

    track stateCue {{
        instrument piano

        {dynamic}
        {motif}
    }}
    """;

Render:

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

One event can now produce meaningful variation from multiple dimensions of state.

Procedural Audio Without DSP

The term procedural audio often makes developers think about:

Oscillators
Filters
Envelopes
Mixers
Modulation
Sample buffers

That's one kind of procedural audio.

SoundScript operates at a higher level.

Instead of thinking in samples, you're thinking in:

Tempo
Notes
Dynamics
Instruments
Motifs
Musical phrases

The question becomes:

What should this state sound like?

rather than:

How do I generate every sample?

Static vs Procedural Architectures

Static Assets

Event
  ↓
Asset Key
  ↓
WAV
  ↓
Play

Advantages

Simple
Predictable
Easy to preview
Production-friendly

Trade-off

More variations typically require more assets.

Procedural Audio

Event + State
       ↓
      Rules
       ↓
 Musical Source
       ↓
     Render
       ↓
      Play

Advantages

State-driven variation
Versionable rules
Reproducible output
Fewer asset variants

Trade-off

More application logic

Neither approach is universally superior.

The right choice depends on the problem.

The Best Architecture Is Often Hybrid

Most games shouldn't generate everything.

A practical hybrid might use static assets for:

Main themes
Voice acting
Hero moments
Cinematics
Signature character sounds

And procedural generation for:

Status cues
Notifications
Temporary UI sounds
Alerts
Monitoring events
Prototype content

Hand Crafted Audio
         +
 Procedural Utility Audio

The two approaches complement each other well.

Cache Generated Audio

If the same state appears repeatedly, avoid rendering identical output over and over.

Build a cache key:

var key =
    $"{eventName}:{severity}:{level}";

Check the cache:

if (cache.TryGetValue(
        key,
        out var existing))
{
    return existing;
}

Otherwise render:

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

cache[key] = wav;

return wav;

The flow becomes:

Event
  ↓
Build Key
  ↓
Cache?
 ↙     ↘
Hit    Miss
 ↓       ↓
Play   Render
          ↓
        Cache
          ↓
         Play

Deterministic generation makes caching extremely natural.

Procedural Doesn't Have to Mean Runtime

Another pattern is build-time generation.

Imagine your game supports:

3 Statuses
×
4 Severity Levels
×
3 Environments

That's:

36 Variations

A build step could generate:

success-1-dev.wav
success-2-dev.wav
success-3-dev.wav

warning-1-prod.wav
warning-2-prod.wav

failure-4-prod.wav
...

Runtime remains:

State
  ↓
Lookup
  ↓
Play

But the assets were generated from version-controlled rules.

This hybrid approach is often very attractive.

Example: Health Warning System

Imagine a player currently has:

var health = 24;

Map health into severity:

var severity =
    health switch
    {
        > 70 => 1,
        > 40 => 2,
        > 20 => 3,
        _ => 4
    };

Then dynamics:

var dynamic =
    severity switch
    {
        1 => "mp",
        2 => "mf",
        3 => "f",
        _ => "ff"
    };

Result:

Health 90 → Quiet Cue
Health 50 → Medium Cue
Health 24 → Strong Cue
Health 8  → Very Strong Cue

The gameplay state now influences sound directly.

Example: Achievement Rarity

Suppose achievements have rarity levels:

Common
Rare
Epic
Legendary

Map them into different motifs:

var motif =
    rarity switch
    {
        "common" =>
            "C4 e E4 q",

        "rare" =>
            "C4 e E4 e G4 q",

        "epic" =>
            "C4 e E4 e G4 e C5 q",

        "legendary" =>
            "C4 e E4 e G4 e C5 e E5 h",

        _ =>
            "C4 q"
    };

Now the musical phrase itself communicates rarity.

Rarity
   ↓
Known Rule
   ↓
Known Musical Behaviour

No AI required.

No randomness required.

Example: Monitoring Applications

The same concept works outside games.

Suppose a monitoring system tracks:

Healthy
Degraded
Critical

Map them into motifs:

var motif =
    status switch
    {
        "healthy" =>
            "C4 e E4 e G4 q",

        "degraded" =>
            "A3 e A3 e E4 q",

        "critical" =>
            "C3 e C3 e G2 q",

        _ =>
            "C4 q"
    };

Now system health can have an auditory representation.

Not as a replacement for dashboards.

As an additional information channel.

Procedural Rules Are Reviewable

Suppose you modify a warning cue:

- A3 e A3 e E4 q
+ A3 e C4 e E4 e A4 q

That's reviewable in Git.

Compare that to:

warning.wav changed

where the most detailed review may simply be:

binary file modified

Developer-owned audio behaviour benefits from being represented as text.

Generated Audio Can Be Tested

Deterministic generation enables automated testing.

var first =
    RenderEventCue(
        "warning",
        severity: 3,
        level: 8);

var second =
    RenderEventCue(
        "warning",
        severity: 3,
        level: 8);

Console.WriteLine(
    first.AsSpan()
         .SequenceEqual(second));

Or generate a hash:

using System.Security.Cryptography;

var hash =
    Convert.ToHexString(
        SHA256.HashData(first));

Console.WriteLine(hash);

Your audio behaviour becomes part of your testable system.

A Reusable Renderer

You can wrap the entire approach into a helper:

using SoundScript;

static byte[] RenderEventCue(
    string eventName,
    int severity,
    int level)
{
    var dynamic =
        severity switch
        {
            1 => "mp",
            2 => "mf",
            3 => "f",
            _ => "ff"
        };

    var motif =
        eventName switch
        {
            "collect" =>
                "C4 e E4 e G4 q",

            "achievement" =>
                "C4 e E4 e G4 e C5 q",

            "warning" =>
                "A3 e A3 e E4 q A3 e",

            "failure" =>
                "C3 e C3 e G2 q C3 e",

            _ =>
                "C4 q"
        };

    var tempo =
        80 + level * 4;

    var source = $"""
        tempo {tempo}

        track eventCue {{
            instrument piano

            {dynamic}
            {motif}
        }}
        """;

    return SoundScriptEngine
        .Compile(source)
        .RenderWave();
}

Usage:

var wav =
    RenderEventCue(
        "warning",
        severity: 3,
        level: 8);

File.WriteAllBytes(
    "warning.wav",
    wav);

The application interface remains simple and expressive.

What the Application Owns

The application owns:

Event semantics
State
Severity rules
Progression systems
Cache strategy
Playback decisions

SoundScript owns:

Musical representation
Compilation
Rendering
WAV generation
MIDI generation

That's a healthy separation.

Where Procedural Audio Fits Best

🎮 Game Prototypes

Generate useful audio before final sound design exists.

🔔 Application Notifications

Create state-driven event cues.

🚦 Monitoring Systems

Sonify changing system health.

♿ Accessibility

Provide additional non-visual feedback.

🏭 Industrial Applications

Represent process and machine states.

🧪 Automated Testing

Generate deterministic audio fixtures.

🎓 Education

Demonstrate state-to-music mappings.

🛠 Developer Tooling

Generate build and status cues programmatically.

When Static Assets Are Still Better

Static assets remain the right choice when you need:

Professional sound design
Recorded instruments
Voice acting
Branded audio
Cinematic sequences
Ambient environments
Mastered production quality

Procedural audio doesn't replace professionally authored media.

It complements it.

One Simple Rule

Ask a single question:

Does the sound meaningfully depend on application state?

If the answer is:

No

Use a static asset.

If the answer is:

Yes

Consider procedural generation.

That's usually the right architectural test.

The Bigger Idea

Applications already generate many outputs from state.

State
  ↓
UI

State
  ↓
Notification

State
  ↓
API Response

State
  ↓
Report

SoundScript adds another possibility:

State
  ↓
Musical Behaviour
  ↓
Audio

That's the core idea behind procedural application audio.

Try It Yourself

Install SoundScript:

dotnet add package SoundScript --version 13.0.0

Start with:

var source = """
    tempo 120

    track eventCue {
        instrument piano

        mf

        C4 e
        E4 e
        G4 q
    }
    """;

Render it:

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

File.WriteAllBytes(
    "cue.wav",
    wav);

Then make the source depend on:

Event
Severity
Level
Status

Change one variable at a time and observe how the output evolves.

The workflow becomes:

Application State
        ↓
Derive Musical Intent
        ↓
Compile
        ↓
Render
        ↓
Cache or Store
        ↓
Play

That's procedural audio from a developer's perspective.

Try SoundScript

dotnet add package SoundScript --version 13.0.0

Resources

🌐 Website: https://soundscript.net/
📦 NuGet: https://www.nuget.org/packages/SoundScript
💻 GitHub: https://github.com/dharangutti/sound-script
📚 Documentation: https://soundscript.net/doc.html?p=documentation.md
🚀 V13 Release: https://github.com/dharangutti/sound-script/releases/tag/v13.0.0

SoundScript Developer Series

Generate Background Music from JSON in .NET

In This Series

Generate MIDI and WAV in a Few Lines of C#
Deterministic Audio for Automated Testing in .NET
Text-to-Music with SoundScript: Deterministic Composition Instead of Prompting
Generate Background Music from JSON in .NET
Procedural Game and Application Audio in .NET

SoundScript

Write audio and media like code.

📧 info@dharangutti.in

🌐 https://www.dharangutti.in/

Generate Background Music from JSON in .NET

Anup Jayant Dharangutti — Fri, 18 Sep 2026 11:48:05 +0000

What if application data could drive sound without your application owning an entire audio engine?

Modern applications already use JSON to describe behaviour.

Configuration
User preferences
Application state
Notifications
Workflow status
Environment settings
Feature flags

That data typically controls things like:

JSON
  ↓
UI

JSON
  ↓
Feature Behaviour

JSON
  ↓
API Configuration

JSON
  ↓
Workflow Logic

But JSON can also drive audio.

With SoundScript, a .NET application can transform ordinary structured data into musical intent and render deterministic WAV or MIDI output.

The key idea is that JSON is not SoundScript's language.

Your application owns the JSON schema.

Your application decides what the data means.

SoundScript simply performs the rendering.

JSON
  ↓
Application Mapping
  ↓
SoundScript Source
  ↓
Compile
  ↓
WAV / MIDI

That separation turns out to be surprisingly useful.

Business data remains business data.

Audio remains programmable.

Let's build it.

Install SoundScript

SoundScript 13 targets .NET 10.

dotnet add package SoundScript --version 13.0.0

We'll also use the JSON functionality built into .NET.

Start with a Simple Configuration

Imagine an application has a configuration file like this:

{
  "name": "checkout-success",
  "tempo": 120,
  "dynamic": "mf",
  "notes": "C4 e E4 e G4 e C5 q"
}

Create a matching model:

record AudioCue(
    string Name,
    int Tempo,
    string Dynamic,
    string Notes);

Load the JSON:

using System.Text.Json;

var json =
    File.ReadAllText("cue.json");

var cue =
    JsonSerializer.Deserialize<AudioCue>(
        json)
    ?? throw new InvalidOperationException(
        "Invalid audio configuration.");

At this stage there's nothing audio-specific happening.

The application simply has structured state.

Map JSON into SoundScript

Now transform that state into musical intent.

var source = $"""
    tempo {cue.Tempo}

    track cue {{
        instrument piano

        {cue.Dynamic}

        {cue.Notes}
    }}
    """;

Compile and render:

using SoundScript;

var compilation =
    SoundScriptEngine.Compile(source);

var wav =
    compilation.RenderWave();

var midi =
    compilation.RenderMidi();

File.WriteAllBytes(
    $"{cue.Name}.wav",
    wav);

File.WriteAllBytes(
    $"{cue.Name}.mid",
    midi);

That's the entire pipeline.

cue.json
    ↓
Deserialize
    ↓
Application Model
    ↓
Map to SoundScript
    ↓
Compile
    ↓
checkout-success.wav
checkout-success.mid

Why Not Just Store a WAV File?

A reasonable question.

For a single fixed cue:

checkout-success.wav

is often the best solution.

Static assets are:

Easy to preview
Professionally designed
Simple to deploy
Simple to maintain

You shouldn't replace static audio just because dynamic generation is possible.

The value appears when application state influences the sound.

Example: Severity-Driven Audio

Suppose the application receives:

{
  "state": "warning",
  "severity": 3
}

Instead of exposing raw audio controls, define a simple business model:

record StatusCue(
    string State,
    int Severity);

Map severity into known dynamics:

var dynamic =
    cue.Severity switch
    {
        1 => "mp",
        2 => "mf",
        3 => "f",
        _ => "ff"
    };

Map state into known musical motifs:

var motif =
    cue.State switch
    {
        "success" =>
            "C4 e E4 e G4 e C5 q",

        "warning" =>
            "A3 e A3 e E4 q A3 e",

        "failure" =>
            "C3 e C3 e G2 q C3 e",

        _ =>
            "C4 q"
    };

Create SoundScript:

var source = $"""
    tempo 110

    track status {{
        instrument piano

        {dynamic}
        {motif}
    }}
    """;

And render:

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

Notice the separation of responsibilities:

State + Severity
         ↓
Application Rules
         ↓
Musical Intent
         ↓
SoundScript
         ↓
Audio

Keep Business Logic Outside the Audio Engine

This is an important architectural boundary.

You probably don't want SoundScript deciding:

Severity 4 = Emergency

That's an application concern.

Likewise, you probably don't want your business configuration describing:

MIDI Channel 1
Velocity 112
Tick Position 480

That's audio implementation detail.

A cleaner architecture is:

Business State
      ↓
Application Rules
      ↓
Musical Intent
      ↓
SoundScript
      ↓
Audio

Each layer has a single responsibility.

Avoid Passing Arbitrary Source from JSON

A tempting approach is:

{
  "source": "tempo 120 track x { ... }"
}

followed by:

SoundScriptEngine.Compile(
    config.Source);

For trusted developer-authored configuration, that's perfectly valid.

For user data or external input, a better pattern is:

{
  "state": "warning",
  "intensity": 2
}

Then map it explicitly:

Known Input
      ↓
Validation
      ↓
Application Rules
      ↓
Known Musical Structures

Rather than:

Arbitrary String
        ↓
Compiler

The same principle applies to many configurable systems.

A More Realistic Example

Imagine a deployment monitoring system producing:

{
  "event": "deployment",
  "result": "failed",
  "severity": 4,
  "environment": "production"
}

Create a model:

record DeploymentEvent(
    string Event,
    string Result,
    int Severity,
    string Environment);

Now define rules.

Tempo

var tempo =
    data.Environment switch
    {
        "production" => 116,
        "staging" => 104,
        _ => 96
    };

Dynamic

var dynamic =
    data.Severity switch
    {
        <= 1 => "mp",
        2 => "mf",
        3 => "f",
        _ => "ff"
    };

Motif

var motif =
    data.Result switch
    {
        "success" =>
            "C4 e E4 e G4 e C5 q",

        "failed" =>
            "C3 e C3 e G2 q C3 e",

        _ =>
            "C4 q"
    };

Assemble the cue:

var source = $"""
    tempo {tempo}

    track deployment {{
        instrument piano

        {dynamic}
        {motif}
    }}
    """;

The same deployment state always produces the same intended musical behaviour.

That's one of the biggest advantages of deterministic audio.

JSON Is Control Data, Not Music

Notice the difference between these two representations.

Application state:

{
  "result": "failed",
  "severity": 4
}

Musical intent:

tempo 116

track deployment {
    instrument piano
    ff

    C3 e
    C3 e
    G2 q
    C3 e
}

They serve different purposes.

Trying to make them identical often creates unnecessary coupling.

Keeping them separate tends to produce cleaner designs.

Why Not Use an AI Music API?

Let's compare the goals.

Imagine sending:

{
  "state": "warning",
  "severity": 3
}

to a generative music system using a prompt like:

Create a short urgent notification sound for severity level 3.

That can work very well if you want creative variation.

But application audio often requires different guarantees.

You may want:

Severity 3
      ↓
Same Rules
      ↓
Same Output

You may want to:

Test it
Cache it
Hash it
Version it
Reproduce it

Deterministic generation is often a better fit for those requirements.

Comparing Audio Architectures

Static Assets

State
  ↓
Lookup
  ↓
Existing WAV

Advantages

Simple
Fast
Professional audio quality

Trade-off

Every variation usually requires another asset.

Generative Music Service

State
  ↓
Prompt
  ↓
Model
  ↓
Generated Audio

Advantages

Creative
Rich output
Large stylistic range

Trade-off

Probabilistic behaviour
External dependencies
Different reproducibility model

DSP / Custom Synthesis

State
  ↓
DSP Code
  ↓
Oscillators
Envelopes
Mixers
  ↓
PCM Audio

Advantages

Maximum control

Trade-off

Significant audio-engine complexity

SoundScript

State
  ↓
Application Rules
  ↓
Musical Intent
  ↓
SoundScript
  ↓
WAV / MIDI

This occupies a useful middle ground.

More dynamic than static assets
Higher level than DSP
More deterministic than prompt generation

User-Configurable Notification Profiles

Imagine users can select:

{
  "notificationStyle": "gentle",
  "speed": "normal"
}

Your application maps:

gentle
   ↓
piano
mp

and:

normal
   ↓
tempo 100

Another profile might be:

{
  "notificationStyle": "urgent",
  "speed": "fast"
}

Mapping to:

urgent
  ↓
stronger dynamic
different motif

fast
  ↓
tempo 132

Notice that you're exposing meaningful product concepts, not audio-engine internals.

That's generally easier for both developers and users.

Game State as Audio

Imagine:

{
  "health": 24,
  "danger": true,
  "level": 7
}

Application rules derive:

danger = true
      ↓
warning motif

health < 30
      ↓
stronger dynamic

level = 7
      ↓
tempo adjustment

Result:

Game State
     ↓
Application Rules
     ↓
Musical State
     ↓
Audio

This pattern is particularly useful during prototyping when sound design is still evolving.

Cache Repeated States

Not every cue needs to be rendered repeatedly.

Generate a cache key:

var key =
    $"{state}:{severity}:{tempo}";

Then:

if (cache.TryGetValue(
        key,
        out var existing))
{
    return existing;
}

Otherwise:

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

cache[key] = wav;

return wav;

The architecture becomes:

Application State
         ↓
      Key
    ↙     ↘
 Hit     Miss
  ↓        ↓
Reuse   Render
           ↓
        Cache

A simple optimisation with substantial benefits.

Generate Assets at Build Time

Dynamic audio doesn't have to mean runtime rendering.

Suppose you support:

3 States
× 4 Severity Levels

That's only:

12 Outputs

A build pipeline could generate:

success-1.wav
success-2.wav
success-3.wav
success-4.wav

warning-1.wav
warning-2.wav
warning-3.wav
warning-4.wav

failure-1.wav
failure-2.wav
failure-3.wav
failure-4.wav

At runtime, the application simply loads files.

You keep deterministic generation while avoiding runtime rendering entirely.

This hybrid model is often very practical.

Audio Mappings Can Be Tested

Because generation is deterministic, it can participate in automated testing.

var first =
    BuildCue(config);

var second =
    BuildCue(config);

Assert.True(
    first.AsSpan()
         .SequenceEqual(second));

Or use hashes:

using System.Security.Cryptography;

var hash =
    Convert.ToHexString(
        SHA256.HashData(first));

Console.WriteLine(hash);

Your configuration-to-sound rules become testable software.

A Simple Helper

You can encapsulate the entire workflow:

using SoundScript;

static byte[] RenderCue(
    string state,
    int severity)
{
    var dynamic =
        severity switch
        {
            1 => "mp",
            2 => "mf",
            3 => "f",
            _ => "ff"
        };

    var motif =
        state switch
        {
            "success" =>
                "C4 e E4 e G4 e C5 q",

            "warning" =>
                "A3 e A3 e E4 q A3 e",

            "failure" =>
                "C3 e C3 e G2 q C3 e",

            _ =>
                "C4 q"
        };

    var source = $"""
        tempo 110

        track cue {{
            instrument piano

            {dynamic}
            {motif}
        }}
        """;

    return SoundScriptEngine
        .Compile(source)
        .RenderWave();
}

Usage:

var wav =
    RenderCue(
        "warning",
        3);

File.WriteAllBytes(
    "warning.wav",
    wav);

Your application stays focused on:

State
Severity

rather than audio implementation details.

Where This Approach Fits

🔔 Application Notifications

Generate controlled cues from application events.

🎮 Games

Derive audio behaviour from game state.

🚦 Monitoring

Map system status into repeatable cues.

♿ Accessibility Experiments

Create structured non-visual feedback.

🏭 Industrial Applications

Represent machine and process states.

🎓 Education

Demonstrate how structured data can drive music.

🔄 CI/CD

Turn build and deployment status into deterministic audio.

🧪 Automated Testing

Generate reproducible audio fixtures.

When Not to Use It

Don't adopt this architecture simply because your application already uses JSON.

If the requirement is:

Play one professionally designed notification sound.

Then:

notification.wav

may be the ideal solution.

Dynamic generation becomes valuable when audio meaningfully depends on application state.

That's the real decision point.

The Bigger Idea

Modern software already transforms data into many outputs.

JSON
  ↓
UI

JSON
  ↓
HTML

JSON
  ↓
API Behaviour

JSON
  ↓
Workflow Execution

Programmable audio adds another possibility:

JSON
  ↓
Application Rules
  ↓
Musical Intent
  ↓
Audio

The important part isn't the JSON.

The important part is that sound becomes another output of application logic.

Try It Yourself

Create:

{
  "name": "success",
  "tempo": 120,
  "dynamic": "mf",
  "notes": "C4 e E4 e G4 e C5 q"
}

Map it to SoundScript:

var source = $"""
    tempo {cue.Tempo}

    track cue {{
        instrument piano

        {cue.Dynamic}
        {cue.Notes}
    }}
    """;

Render it:

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

File.WriteAllBytes(
    $"{cue.Name}.wav",
    wav);

Then experiment.

Change:

"tempo": 120

to:

"tempo": 80

Or:

"dynamic": "mf"

to:

"dynamic": "ff"

Render again and compare the result.

The workflow is straightforward:

Configure
     ↓
Map
     ↓
Compile
     ↓
Render
     ↓
Listen

Try SoundScript

dotnet add package SoundScript --version 13.0.0

Resources

🌐 Website: https://soundscript.net/
📦 NuGet: https://www.nuget.org/packages/SoundScript
💻 GitHub: https://github.com/dharangutti/sound-script
📚 Documentation: https://soundscript.net/doc.html?p=documentation.md
🚀 V13 Release: https://github.com/dharangutti/sound-script/releases/tag/v13.0.0

SoundScript Developer Series

Text-to-Music with SoundScript: Deterministic Composition Instead of Prompting

Coming Next

Procedural Game and Application Audio in .NET

We'll move from configuration-driven cues to event-driven procedural audio and explore when generated sound makes more sense than maintaining large collections of static assets.

SoundScript

Write audio and media like code.

📧 info@dharangutti.in

🌐 https://www.dharangutti.in/

Text-to-Music with SoundScript: Deterministic Composition Instead of Prompting

Anup Jayant Dharangutti — Fri, 18 Sep 2026 11:47:38 +0000

Generated music does not have to mean unpredictable music.

When developers hear text-to-music today, they often think of generative AI.

The workflow is familiar:

Prompt
   ↓
AI Model
   ↓
Music

It's a powerful approach when your goal is creativity, experimentation, or stylistic exploration.

But what if your requirements are different?

What if:

The same input must produce the same output
Results must be reproducible in CI/CD
Generated music must be testable
Output should be inspectable and versionable
Media generation should behave like software

That's the problem SoundScript's text composition engine is designed to solve.

Instead of interpreting prompts probabilistically, SoundScript applies a deterministic transformation pipeline.

Plain Text
     ↓
Syllables
     ↓
Phonemes
     ↓
Musical Gestures
     ↓
Musical Program
     ↓
MIDI

Same input.

Same rules.

Same output.

Every time.

Generated Music vs Deterministic Music

Most AI music systems optimise for creative interpretation.

You might ask for:

"An emotional piano piece about space exploration."

The model then decides how to interpret that request.

Two runs may produce two different results.

That's often exactly what you want.

SoundScript asks a different question:

Can text be transformed into musical structure using explicit, repeatable rules?

This distinction is important.

AI Generation

Prompt
   ↓
Generative Model
   ↓
Creative Interpretation
   ↓
Music

SoundScript Composition

Text
  ↓
Deterministic Rules
  ↓
Musical Structure
  ↓
MIDI

Both are useful.

They solve different problems.

Install SoundScript

SoundScript 13 targets .NET 10.

dotnet add package SoundScript --version 13.0.0

SoundScript includes a text composition subsystem capable of transforming ordinary text into musical material.

A minimal example looks like this:

using SoundScript.Compose;
using SoundScript.Midi;

var program =
    PhonemeComposer.ComposeProgram(
        "Twinkle twinkle little star");

using var stream =
    new MemoryStream();

MidiGenerator.Write(
    program,
    stream);

File.WriteAllBytes(
    "twinkle.mid",
    stream.ToArray());

The result is a standard MIDI file generated directly from text.

No hosted AI service.

No prompts.

No random seeds.

No unpredictable interpretation.

Just a deterministic transformation pipeline.

What Happens to the Text?

Consider this input:

Twinkle twinkle little star

Before music appears, SoundScript processes the text through several stages.

Stage 1: Syllable Analysis

Conceptually:

Twinkle twinkle little star
         ↓
 Twin
 kle
 twin
 kle
 lit
 tle
 star

The text is broken into manageable linguistic units.

Stage 2: Phoneme Analysis

Those units are further analysed into phoneme-like components.

For example:

star
  ↓

s
t
aa
r

This stage focuses on how words sound rather than how they're spelled.

Stage 3: Musical Gestures

Phoneme categories are mapped to musical behaviours.

Conceptually:

Phoneme
    ↓
Gesture

Possible gesture categories include:

Staccato
Legato
Accent
Swell
Fade

These categories influence musical expression.

Stage 4: Musical Structure

The generated gestures become actual musical events.

Word
  ↓
Syllable
  ↓
Phoneme
  ↓
Gesture
  ↓
Pitch + Rhythm + Articulation
  ↓
Phrase

Those phrases are assembled into a complete musical program ready for MIDI generation.

Why Determinism Matters

Suppose your application generates media.

Many software systems require reproducibility.

Input A
   ↓
Output A

Run again:

Input A
   ↓
Output A

And again:

Input A
   ↓
Output A

The same result every time.

That property is valuable in:

🧪 Automated testing
🔄 CI/CD
🎓 Educational software
📊 Data sonification
🧬 Research
🎮 Procedural content generation
📦 Build-time asset generation
📚 Reproducible demonstrations

For software engineers, repeatability is often more valuable than creativity.

Verify It in Code

Let's turn composition into a reusable function.

using SoundScript.Compose;
using SoundScript.Midi;

static byte[] Compose(
    string text)
{
    var program =
        PhonemeComposer.ComposeProgram(
            text);

    using var stream =
        new MemoryStream();

    MidiGenerator.Write(
        program,
        stream);

    return stream.ToArray();
}

Generate output twice:

var first =
    Compose("Hello world");

var second =
    Compose("Hello world");

Console.WriteLine(
    first.AsSpan()
         .SequenceEqual(second));

For identical inputs, the generated MIDI can be compared directly.

That's a very different engineering goal from probabilistic generation.

Deterministic Doesn't Mean Boring

Repeatability does not mean every input sounds the same.

Change:

Hello world

to:

Hello from SoundScript

and the generated musical structure changes.

Conceptually:

Text A
   ↓
 Rules
   ↓
Melody A

and:

Text B
   ↓
 Rules
   ↓
Melody B

The important guarantee is:

Text A
   ↓
Same Rules
   ↓
Melody A

every single time.

Think of It Like a Compiler

A useful mental model isn't:

Text
  ↓
AI Musician

Instead think:

Text
  ↓
Transformation Pipeline
  ↓
Music

Developers already work with systems like this every day.

Compiler

Source Code
     ↓
    Parse
     ↓
Intermediate Representation
     ↓
Machine Code

Template Engine

Template + Data
         ↓
      Render
         ↓
     Document

Code Generator

Schema
   ↓
Generator
   ↓
Code

SoundScript

Text
  ↓
Linguistic Analysis
  ↓
Musical Gestures
  ↓
Musical Program
  ↓
MIDI

Generated doesn't automatically imply random.

Use the CLI

The same workflow is available from the SoundScript CLI.

soundscript compose \
  "Twinkle twinkle little star" \
  twinkle.mid

Or from a repository checkout:

dotnet run \
  --project src/SoundScript.Cli \
  -- compose \
  "Twinkle twinkle little star" \
  twinkle.mid

Generate the same text twice:

dotnet run --project src/SoundScript.Cli -- compose "Hello world" first.mid

dotnet run --project src/SoundScript.Cli -- compose "Hello world" second.mid

The workflow remains simple:

Text
  ↓
Compose
  ↓
MIDI

This makes text-to-music useful both in application code and automation pipelines.

Generated Music Doesn't Have to Be the Final Result

One interesting possibility is using generated music as a starting point.

Text
  ↓
Composition
  ↓
SoundScript Source
  ↓
Manual Edit
  ↓
Render

Instead of:

Generate
   ↓
Accept Result

you get:

Generate
   ↓
Inspect
   ↓
Edit
   ↓
Render

This feels much closer to code generation than AI prompting.

The generated material becomes editable.

Developers stay in control.

Example: Refining Generated Music

Suppose the generated material contains:

C4 e
E4 e
G4 q

You might decide to change it to:

C4 q
G4 q
C5 h

Or adjust:

tempo 96

to:

tempo 120

Render again.

The workflow becomes:

Generated Structure
        ↓
Developer Edit
        ↓
New Output

That's a blend of automation and deliberate authorship.

Use Case: Stable Musical Identities

Imagine an application containing named entities:

Alpha
Bravo
Charlie
Delta

Each name can deterministically generate its own motif.

Alpha
  ↓
Motif A

Bravo
  ↓
Motif B

Charlie
  ↓
Motif C

Every occurrence of "Alpha" produces the same musical identity.

Potential applications include:

🎮 Games
📊 Sonification
🎓 Education
♿ Accessibility research
🖥 Interactive systems

Use Case: Procedural Games

Imagine a game generates locations dynamically:

Aurora Station
Crimson Valley
Echo Ridge
Silent Harbor

Instead of manually designing audio for every generated location:

Location Name
        ↓
Text Composition
        ↓
Location Motif

The same location name always generates the same identity.

That's extremely useful for procedural worlds.

Use Case: Education

Text-to-melody can help students explore relationships between language and sound.

Try entering:

computer

then:

automation

then:

deterministic audio

Students can compare the resulting structures.

Because the transformation is rule-based, the system can explain why a result occurred.

That's much harder with purely generative systems.

Use Case: Automated Testing

A deterministic composer naturally fits testing workflows.

"Hello world"
      ↓
Known MIDI

Generate twice:

var first =
    Compose("Hello world");

var second =
    Compose("Hello world");

Assert.True(
    first.AsSpan()
         .SequenceEqual(second));

Or verify a hash:

using System.Security.Cryptography;

var midi =
    Compose("Hello world");

var hash =
    Convert.ToHexString(
        SHA256.HashData(midi));

Console.WriteLine(hash);

The text itself becomes a reproducible media fixture.

Use Case: Data Sonification

Labels can become stable auditory signatures.

Imagine:

service-authentication
service-payments
service-orders
service-shipping

Each service generates its own musical identity.

Service Name
       ↓
Musical Motif

Generation remains deterministic, allowing users to learn those identities over time.

Deterministic Doesn't Mean Intelligent

An important distinction:

SoundScript doesn't claim to understand the meaning of a sentence.

For example:

The deployment succeeded

and

The deployment failed

produce different musical structures because they're different inputs.

But the composer is not automatically deciding:

Success = Happy Music
Failure = Sad Music

unless your application explicitly defines those rules.

This keeps behaviour predictable and inspectable.

Let Application Logic Handle Meaning

In many systems, semantics belong in the application.

For example:

Status = Success
Text = Deployment Complete

The application might choose:

tempo 120
dynamic mf

while the text composer generates melodic material.

Conceptually:

Application Meaning
         +
Text-Derived Motif
         ↓
Final Musical Behaviour

This separation keeps business logic where it belongs.

Text-to-Music as Software Architecture

The bigger idea isn't turning sentences into tunes.

It's treating musical generation like any other software transformation.

Instead of:

Developer
    ↓
Creates Asset
    ↓
Stores Binary File

you can have:

Data
  ↓
Rules
  ↓
Musical Structure
  ↓
Media

That's a pattern software engineers already understand.

Where This Approach Fits

🎓 Education

Teach relationships between language and music.

🎮 Games

Generate stable motifs for people, locations, and factions.

🧪 Testing

Create reproducible MIDI fixtures from text.

📊 Sonification

Give labels and identifiers musical identities.

♿ Accessibility

Explore alternative non-visual representations.

🧬 Research

Run repeatable language-to-music experiments.

🛠 Developer Tooling

Generate music from build metadata, logs, or structured text.

When Should You Use AI Instead?

If your goal is:

Create an emotional two-minute orchestral score with piano, strings, and a cinematic climax.

then an AI music system is probably the better fit.

If your goal is:

This exact input should always produce the same inspectable musical result inside my application.

then deterministic composition becomes much more interesting.

The distinction is simple:

AI Music

Creative Interpretation

SoundScript Composition

Predictable Transformation

Both are valuable.

They support different architectures.

Try It Yourself

Install SoundScript:

dotnet add package SoundScript --version 13.0.0

Create a small composer:

using SoundScript.Compose;
using SoundScript.Midi;

static byte[] ComposeText(
    string text)
{
    var program =
        PhonemeComposer.ComposeProgram(
            text);

    using var stream =
        new MemoryStream();

    MidiGenerator.Write(
        program,
        stream);

    return stream.ToArray();
}

Generate a melody:

var midi =
    ComposeText(
        "Hello SoundScript");

File.WriteAllBytes(
    "hello.mid",
    midi);

Generate it again:

var first =
    ComposeText(
        "Hello SoundScript");

var second =
    ComposeText(
        "Hello SoundScript");

Console.WriteLine(
    first.AsSpan()
         .SequenceEqual(second));

Then change the text and compare the result:

Hello deterministic music

The workflow is straightforward:

Write Text
     ↓
Compose
     ↓
Generate MIDI
     ↓
Inspect
     ↓
Modify
     ↓
Repeat

Try SoundScript

dotnet add package SoundScript --version 13.0.0

Resources

🌐 Website: https://soundscript.net/
📦 NuGet: https://www.nuget.org/packages/SoundScript
💻 GitHub: https://github.com/dharangutti/sound-script
📚 Documentation: https://soundscript.net/doc.html?p=documentation.md
🚀 V13 Release: https://github.com/dharangutti/sound-script/releases/tag/v13.0.0

SoundScript Developer Series

Deterministic Audio Fixtures for Automated Testing in .NET

Coming Next

Generate Background Music from JSON in .NET

We'll connect application configuration and runtime data to SoundScript, turning ordinary JSON into predictable, programmable musical behaviour.

SoundScript

Write audio and media like code.

📧 info@dharangutti.in

🌐 https://www.dharangutti.in/

Deterministic Audio Fixtures for Automated Testing in .NET

Anup Jayant Dharangutti — Fri, 18 Sep 2026 11:46:59 +0000

We generate JSON fixtures, images, database records, and API payloads for tests. Why not audio?

Most engineering teams already treat test data as code.

We generate:

JSON fixtures
Database records
API payloads
Configuration files
Images

Yet audio is often handled differently.

A WAV file gets copied into a test directory and remains there as a binary asset that nobody wants to touch.

tests/
└── fixtures/
    └── notification.wav

The test passes.

The build is green.

But a future developer reviewing the repository may have no idea:

What sound does this contain?
Which notes are being played?
Why was it generated?
Can it be reproduced?
Was that binary change intentional?

In many projects, the WAV file becomes the only source of truth.

What if the source of the sound was the artifact you reviewed instead?

That's where SoundScript becomes interesting.

The Problem with Binary Audio Fixtures

Consider a pull request containing:

notification.wav changed

What exactly changed?

Tempo?
Pitch?
Instrument?
Duration?
Volume?
Entire musical phrase?

Without specialised tooling, the answer is usually:

"I don't know. Someone changed the WAV."

Compare that to a textual audio definition:

tempo 120

track notification {
    instrument piano
    mf

    C4 e
    E4 e
    G4 q
}

Now the intent is visible.

A code reviewer can understand the change before listening to anything.

Install SoundScript

SoundScript 13 targets .NET 10.

dotnet add package SoundScript --version 13.0.0

Create a deterministic audio fixture directly from C#:

using SoundScript;

var source = """
    tempo 120

    track fixture {
        instrument piano

        C4 e
        E4 e
        G4 e
        B4 e
        D5 e
        G4 e
    }
    """;

var compilation =
    SoundScriptEngine.Compile(source);

var wav = compilation.RenderWave();
var midi = compilation.RenderMidi();

File.WriteAllBytes("fixture.wav", wav);
File.WriteAllBytes("fixture.mid", midi);

The key idea isn't that we generated a WAV file.

The important part is that the fixture now has a readable, reviewable definition:

tempo 120

track fixture {
    instrument piano

    C4 e
    E4 e
    G4 e
    B4 e
    D5 e
    G4 e
}

Treat Audio Like Generated Test Data

Instead of this:

fixture.wav

your workflow becomes:

Test Intent
      ↓
SoundScript Source
      ↓
Compile
      ↓
WAV / MIDI Fixture
      ↓
System Under Test

This is the same pattern developers already use elsewhere.

Schema
   ↓
Generated Client

Template
   ↓
Document

Source Code
   ↓
Executable

SoundScript
   ↓
Audio Fixture

Audio stops being a mysterious binary asset and becomes another generated artifact.

Verify Deterministic Rendering

One of the most useful properties for testing is reproducibility.

Render the same source twice:

var compilation =
    SoundScriptEngine.Compile(source);

var first =
    compilation.RenderWave();

var second =
    compilation.RenderWave();

var identical =
    first.AsSpan().SequenceEqual(second);

Console.WriteLine(identical);

Or make it a test:

Assert.True(
    first.AsSpan().SequenceEqual(second));

If the source and rendering conditions remain unchanged, SoundScript is designed to produce repeatable output.

That means the generated audio itself can participate in automated regression testing.

Add SHA-256 Regression Checks

In many cases, you don't need to store expected byte arrays.

A hash is enough.

using System.Security.Cryptography;

var wav =
    SoundScriptEngine
        .Compile(source)
        .RenderWave();

var hash =
    Convert.ToHexString(
        SHA256.HashData(wav));

Console.WriteLine(hash);

Conceptually:

SoundScript Source
        ↓
    Render WAV
        ↓
      SHA-256
        ↓
Expected Hash?
    ↙       ↘
 PASS   Investigate

Generated audio can now be validated much like any other build artifact.

Example: Testing Audio Upload Pipelines

Suppose you're testing an audio upload endpoint.

Many teams would commit a WAV fixture:

upload-test.wav

Instead, generate one during test execution.

var wav =
    SoundScriptEngine
        .Compile("""
            tempo 100

            track upload {
                instrument piano

                C4 q
                E4 q
                G4 h
            }
            """)
        .RenderWave();

await File.WriteAllBytesAsync(
    "upload-test.wav",
    wav);

Now the fixture is:

✅ Generated

✅ Readable

✅ Reproducible

✅ Versionable

✅ Easy to modify

The musical intent lives inside the test itself.

Store Fixture Sources in Files

For larger test suites, keep the musical definitions separate.

tests/
└── fixtures/
    ├── notification.ss
    ├── warning.ss
    └── failure.ss

Then load them:

using SoundScript;

var compilation =
    SoundScriptEngine.CompileFile(
        "tests/fixtures/notification.ss");

var wav =
    compilation.RenderWave();

Now audio changes show up naturally in pull requests.

Instead of:

Binary files differ

you review:

-tempo 100
+tempo 120

-track notification {
-    C4 q E4 q
+track notification {
+    C4 e
+    E4 e
+    G4 q
}

That's significantly easier to reason about.

A Simple Deterministic Fixture Test

A complete test might look like this:

using SoundScript;

var source = """
    tempo 120

    track fixture {
        instrument piano

        C4 e
        E4 e
        G4 q
    }
    """;

var compilation =
    SoundScriptEngine.Compile(source);

var first =
    compilation.RenderWave();

var second =
    compilation.RenderWave();

Assert.True(
    first.AsSpan().SequenceEqual(second));

The same idea applies to MIDI:

var firstMidi =
    compilation.RenderMidi();

var secondMidi =
    compilation.RenderMidi();

Assert.True(
    firstMidi.AsSpan()
        .SequenceEqual(secondMidi));

The tests aren't just verifying behaviour.

They're also verifying reproducibility.

Should Every Test Compare Exact Bytes?

No.

And that's an important distinction.

Exact byte comparisons are useful when renderer stability matters.

Many audio tests care about different guarantees:

Is the WAV valid?
Is the duration correct?
Is the sample rate correct?
Is the channel count correct?
Does the MIDI contain expected notes?
Is the file size reasonable?

Choose assertions based on what the test is actually promising.

Think in Testing Layers

A useful strategy is to separate validation into layers.

Level 1: Format Validation

Generated Bytes
       ↓
 Format Parser
       ↓
Valid?

Is the output a valid WAV or MIDI file?

Level 2: Structural Validation

Verify characteristics such as:

Duration
Sample rate
Channels
Tracks
Notes
Tempo

Level 3: Deterministic Regression

Verify exact reproducibility.

Expected Hash
      =
 Actual Hash

SoundScript makes this level possible without forcing every test to use it.

CI/CD Gets Interesting Too

This pattern isn't limited to testing.

Build and deployment results can also be represented as sound.

Imagine:

0 failures
    ↓
Success motif

Few failures
    ↓
Warning motif

Many failures
    ↓
Failure motif

Conceptually:

tempo 120

track passed {
    mf

    G4 e
    G4 e
    G4 e
    G4 e
}

track failed {
    f

    C3 e
    C3 e
}

The same test results produce the same audio.

That's deterministic sonification.

Why Sonify CI?

Not as a replacement for dashboards.

As an additional information channel.

Potential use cases include:

Long-running test environments
Monitoring stations
Accessibility experiments
Engineering demonstrations
Industrial control systems
Background build awareness

The goal isn't to add sound everywhere.

The goal is to use sound when sound communicates useful information.

Where Deterministic Audio Fixtures Fit Best

🧪 Media Upload Testing

Generate valid WAV files during setup.

🔔 Notification Systems

Verify generated notification sounds.

🎮 Games

Create repeatable audio scenarios.

♿ Accessibility Testing

Produce controlled audio feedback.

🚦 Monitoring Applications

Validate state-to-sound mappings.

🏭 Industrial Systems

Test machine-state signalling.

🔄 CI/CD Experiments

Generate repeatable build sonification.

📦 Demo Data Generation

Create reproducible audio assets during builds.

Audio as Source Code

The bigger idea isn't WAV generation.

It's moving intent into something developers can inspect.

Instead of:

mysterious binary asset

you have:

human-readable source
        ↓
deterministic build
        ↓
binary artifact

Developers already embrace this model everywhere else:

Source Code → Executable

Schema → Client

Template → Document

Build Script → Package

SoundScript → Audio

SoundScript applies the same engineering principle to sound.

Try It Yourself

Install SoundScript:

dotnet add package SoundScript --version 13.0.0

Create a simple fixture:

tempo 120

track fixture {
    instrument piano
    mf

    C4 e
    E4 e
    G4 q
}

Render twice:

var compilation =
    SoundScriptEngine.Compile(source);

var a =
    compilation.RenderWave();

var b =
    compilation.RenderWave();

Console.WriteLine(
    a.AsSpan().SequenceEqual(b));

Then compute a hash:

var hash =
    Convert.ToHexString(
        SHA256.HashData(a));

Console.WriteLine(hash);

You now have an audio fixture that can be:

Written
   ↓
Reviewed
   ↓
Generated
   ↓
Hashed
   ↓
Tested
   ↓
Regenerated

That's a very software-engineering way to think about audio.

Try SoundScript

dotnet add package SoundScript --version 13.0.0

Resources

🌐 Website: https://soundscript.net/
📦 NuGet: https://www.nuget.org/packages/SoundScript
💻 GitHub: https://github.com/dharangutti/sound-script
📚 Documentation: https://soundscript.net/doc.html?p=documentation.md
🚀 V13 Release: https://github.com/dharangutti/sound-script/releases/tag/v13.0.0

SoundScript Developer Series

Generate MIDI and WAV from the Same C# Source

Coming Next

Text-to-Music with SoundScript: Deterministic Composition Instead of Prompting

We'll take ordinary text, transform it into musical structures, and explore why deterministic composition differs fundamentally from probabilistic AI-generated music.

SoundScript

Write audio and media like code.

📧 info@dharangutti.in

🌐 https://www.dharangutti.in/

Generate MIDI and WAV from the Same C# Source with SoundScript

Anup Jayant Dharangutti — Fri, 18 Sep 2026 11:46:21 +0000

Less audio plumbing. More programmable sound.

Generating a MIDI file in C# isn't particularly difficult.

Generating MIDI, rendering audio, keeping everything reproducible, and making the musical source easy to review in Git is where complexity starts to accumulate.

SoundScript takes a different approach.

Instead of manually creating MIDI events or building audio pipelines, you describe musical intent and let SoundScript render the outputs.

Let's build something.

Install SoundScript

SoundScript 13 targets .NET 10.

dotnet add package SoundScript --version 13.0.0

Create a small C# program:

using SoundScript;

var cue = SoundScriptEngine.Compile(
    "tempo 120 track cue { instrument piano mf C4 e E4 e G4 q }");

File.WriteAllBytes("success.mid", cue.RenderMidi());
File.WriteAllBytes("success.wav", cue.RenderWave());

That's it.

One musical definition produces two outputs:

🎹 MIDI
🔊 WAV

No DAW project.

No MIDI event plumbing.

No duplicated definitions.

The Musical Source

Here's the SoundScript source in a more readable format:

tempo 120

track cue {
    instrument piano
    mf

    C4 e
    E4 e
    G4 q
}

Where:

Symbol	Meaning
C4, E4, G4	Notes
e	Eighth note
q	Quarter note
mf	Mezzo-forte dynamic

Instead of manually creating:

note-on events
note-off events
timestamps
velocities

you describe the musical idea and let SoundScript generate the implementation details.

Why Use a Language Instead of a MIDI API?

Libraries such as DryWetMIDI are excellent when you need direct control over MIDI data.

They expose concepts like:

Notes
Timed events
Tempo maps
Patterns
MIDI devices
Playback
File manipulation

That's exactly what a MIDI library should do.

SoundScript operates at a higher level.

Traditional MIDI Workflow

Application
    ↓
Create musical objects
    ↓
Manage timing
    ↓
Build MIDI structure
    ↓
Serialize MIDI

SoundScript Workflow

Application
    ↓
Describe music
    ↓
Compile
    ↓
Render MIDI / WAV

SoundScript isn't trying to replace MIDI libraries.

It provides a different abstraction when your application cares about musical intent rather than individual MIDI events.

If you're building a MIDI editor, DAW, or hardware integration tool, a MIDI library is likely the right choice.

If your application simply needs to say:

Play this deterministic musical cue.

then a higher-level representation can dramatically reduce application code.

Change the Music Without Changing the Application

Suppose a designer wants a different sound.

Only the musical definition changes:

var cue = SoundScriptEngine.Compile("""
    tempo 96

    track notification {
        instrument violin
        mp

        C4 q
        E4 q
        G4 q
        C5 h
    }
    """);

The rendering code remains identical:

File.WriteAllBytes(
    "notification.mid",
    cue.RenderMidi());

File.WriteAllBytes(
    "notification.wav",
    cue.RenderWave());

Separating musical behaviour from application logic becomes increasingly useful as audio requirements evolve.

One Source, Multiple Outputs

MIDI and WAV serve different purposes.

MIDI

MIDI contains symbolic musical information.

Useful for:

Sequencing
Editing
DAW workflows
MIDI processing
Compact storage

WAV

WAV contains rendered audio.

Useful for:

Direct playback
HTTP delivery
Asset generation
Application packaging
Audio processing pipelines

Using separate systems for MIDI and audio often means maintaining multiple representations of the same cue.

SoundScript generates both from a single source:

                ┌──→ MIDI
SoundScript ────┤
                └──→ WAV

One definition.

Two outputs.

No duplication.

Move Music Out of C

Embedding short cues in code is convenient.

For larger projects, store music in .ss files.

scores/
└── notification.ss

Load and compile:

using SoundScript;

var compilation =
    SoundScriptEngine.CompileFile(
        "scores/notification.ss");

File.WriteAllBytes(
    "notification.wav",
    compilation.RenderWave());

Now musical content can evolve independently of application code.

Audio Becomes Versionable

One of the most interesting side effects of representing music as text is that audio becomes part of normal software workflows.

You can:

✅ Commit audio definitions to Git
✅ Review them in pull requests
✅ Compare changes with diffs
✅ Regenerate assets during builds
✅ Automate fixture generation
✅ Track exactly what changed

Instead of comparing:

notification-old.wav
notification-new.wav

you review:

-tempo 100
+tempo 120

-track alert {
-    C4 q E4 q
+track alert {
+    C4 e
+    E4 e
+    G4 q
}

For developers, that's a much more useful workflow.

Deterministic Rendering

SoundScript is designed around reproducible generation.

Given the same:

SoundScript source
Renderer version
Render options
Referenced assets

the output is designed to be repeatable.

That enables workflows such as:

Source
   ↓
Build
   ↓
WAV / MIDI
   ↓
Hash
   ↓
Regression Test

This becomes particularly valuable when audio is part of:

Automated testing
CI/CD pipelines
Generated assets
Research workflows
Reproducible demonstrations

We'll explore this in a future article.

Interesting Use Cases

🔔 Application Notifications

Generate cues for:

Success
Warning
Failure
New messages
Deployment completion

🎮 Game Prototypes

Create state-driven audio behaviours without manually managing countless variations.

🧪 Automated Testing

Generate WAV and MIDI fixtures as part of test setup.

🚦 Monitoring Systems

Map operational state into repeatable audio signals.

♿ Accessibility Experiments

Explore alternative non-visual feedback mechanisms.

🎓 Education

Programmatically demonstrate:

Notes
Intervals
Tempo
Dynamics
Musical structure

🏭 Industrial Applications

Represent machine or process state through structured audio.

When Not to Use SoundScript

SoundScript is not a replacement for a DAW.

A traditional DAW remains the right tool for:

Recording
Mixing
Mastering
Complex arrangements
Plugin-heavy workflows
Live performance

SoundScript addresses a different question:

What if audio is part of your application's programmable behaviour?

Try Modifying the Example

Start with:

C4 e
E4 e
G4 q

Then experiment.

Change the tempo:

tempo 80

Change the instrument:

instrument violin

Change the dynamics:

Change the phrase:

C4 q
G4 q
C5 h

Recompile.

Render again.

Listen to the WAV.

Inspect the MIDI.

Commit the source.

That's the entire SoundScript workflow:

Write
  ↓
Compile
  ↓
Render
  ↓
Version

Get Started

Install SoundScript:

dotnet add package SoundScript --version 13.0.0

Resources

🌐 Website: https://soundscript.net/
📦 NuGet: https://www.nuget.org/packages/SoundScript
💻 GitHub: https://github.com/dharangutti/sound-script
📚 Documentation: https://soundscript.net/doc.html?p=documentation.md
🚀 V13 Release: https://github.com/dharangutti/sound-script/releases/tag/v13.0.0

SoundScript Developer Series

This article is part of a series exploring programmable audio with .NET.

Coming next:

Deterministic Audio for Automated Testing in .NET

We'll generate WAV and MIDI fixtures from source, render them repeatedly, and verify the output programmatically.

SoundScript

Write audio and media like code.

📧 info@dharangutti.in

🌐 https://www.dharangutti.in/

DEV Community: Anup Jayant Dharangutti

An exploration of media as code: deterministic audio, synchronized visuals, runtime-bound media, transcription, and developer tooling in .NET.

Media as Code: Building Deterministic Audio, Visuals, and Adaptive Experiences with SoundScript

Start with something deliberately small

From notes to a small musical language

Determinism is more useful than it sounds

Direct audio: not everything needs to become MIDI first

What if timbre were styled?

Text can become musical structure

Lyrics can live next to pitches

Audio is only one rail

The timeline is not tied to one renderer

Then comes the interesting part: application state

A monitoring example makes the model concrete

Media can become test data

CI can listen too

The reverse direction: audio back into editable source

The Playground makes the model easier to understand

The .NET API keeps the core inside your process

The CLI solves a different problem

The capability map

Labs: experiments should look like experiments

VideoLab

Signal Lab

Where this architecture becomes especially useful

Test automation

Monitoring and operational software

Developer tools

Games and interactive applications

Procedural content

Education and experimentation

Accessibility experiments

CI and reproducibility

What SoundScript deliberately does not try to hide

The deeper idea: version the reason, not just the result

Commit A

Commit B

A practical way to explore SoundScript

Final thought

Procedural Game and Application Audio in .NET

Install SoundScript

Define Event Cues

Turn an Event into Audio

Why Not Just Use WAV Files?

Let Severity Control Dynamics

Let Progression Influence Tempo

Let State Choose the Musical Motif

Combine Multiple Pieces of State

Procedural Audio Without DSP

Static vs Procedural Architectures

Static Assets

Procedural Audio

The Best Architecture Is Often Hybrid

Cache Generated Audio

Procedural Doesn't Have to Mean Runtime

Example: Health Warning System

Example: Achievement Rarity

Example: Monitoring Applications

Procedural Rules Are Reviewable

Generated Audio Can Be Tested

A Reusable Renderer

What the Application Owns

Where Procedural Audio Fits Best

🎮 Game Prototypes

🔔 Application Notifications

🚦 Monitoring Systems

♿ Accessibility

🏭 Industrial Applications

🧪 Automated Testing

🎓 Education

🛠 Developer Tooling

When Static Assets Are Still Better

One Simple Rule

The Bigger Idea

Try It Yourself

Try SoundScript

Resources

SoundScript Developer Series

Previous

In This Series