Express Cue

Overview #

Express Cue turns a description of a sound into a short audio clip. You give it a few words — a bright chime, distant thunder, a soft click — and it gives back a clip of up to a few seconds, along with the settings that produced it so you can adjust and render again. Use it for interface sounds, alerts and placeholder ambience.

Express Cue is a sound-cue generator: it reads a short text description of a sound — “short bright chime, two notes rising”, “low rumble of distant thunder” — and returns a rendered cue of between 0.1 and 6 seconds as 24 kHz mono WAV. It does not generate audio samples directly. The model predicts a kind from a catalogue of eighteen sound kinds and a set of continuous synthesis parameters, and a deterministic synthesis engine turns those parameters into sound.

It is the only member of the Sound family and the one Express model that does not speak. Its one sibling in the series, Express Voice, reads text to be spoken; Express Cue reads text that describes a sound. The two share one style of API surface, one runtime convention and one licensing stance, and differ in what they return.

Because the audio is rendered by a fixed engine from a small set of parameters, every render is reproducible, inspectable and short: the same description and seed give the same bytes, the parameters come back with the audio so a host can adjust and re-render them, and nothing the model returns is a recording.

Intended use #

• Interface cues a host application plays on events: a confirmation chime, an alert, a tick while something loads, a swoosh on a transition.
• Placeholder ambience and textures — rain, wind, static, an engine hum — for a prototype that needs sound before a sound designer does.
• Reproducible sound assets: a description and a seed pinned in configuration render the same cue on every deployment.
• A parameter starting point: a host reads params from one render, edits them and calls the service's direct render route.

Out of scope #

• Speech of any kind — Express Voice speaks; Express Cue never does.
• Music: melodies, chords, rhythm patterns or anything longer than one short cue.
• Sampled or recorded audio: the engine synthesises every sample; there is no sample library.
• Sound design or foley that needs more than one cue of at most six seconds.

Choose Express Cue when #

• The host needs a short, non-verbal sound from a description and wants the result to be reproducible and adjustable.
• The description fits one of the eighteen kinds — tones, chimes, alerts, clicks, transitions, noise textures and a few environmental sounds.
• Otherwise choose Express Voice, the Voice family default for spoken text. Neither series has a music or sound-effects library model.

Architecture #

Express Cue has no tokeniser and no vocabulary file. The description is lower-cased, whitespace-collapsed and turned into one list of hashed features: every character 3-gram and 4-gram, followed by every word unigram and bigram, each hashed into one of 16,384 buckets. This is the same feature scheme the Falcon intention classifiers use, and it is why a model this small can read free-text descriptions: “bright” and “brite” share most of their character n-grams, and “two notes rising” contributes the bigrams that separate a chime from a single tone.

The backbone is a mean-pooling embedding bag of shape 16,384 × 384 followed by a small multi-layer perceptron over the pooled vector. Two groups of heads read the result. A categorical head predicts the kind, one of eighteen classes listed under Inputs & outputs and on Output vocabularies. A set of regression heads predicts the continuous synthesis parameters: duration, base frequency (as log₂ hertz), the number of partials, inharmonicity, the four ADSR envelope values, the noise colour mix, the low-pass cutoff (as a logarithm) and its sweep, the amplitude-modulation rate and depth, a pitch glide in semitones, a repeat count and interval, a reverb amount and a gain. The layer widths of the perceptron are fixed by the first training run and are recorded here, with the parameter count, once that run has written its checkpoint.

The engine is not learned. It is a deterministic signal-processing chain in ordinary numeric code: additive oscillators build the tonal part from the base frequency, the partial count and the inharmonicity; white, pink and brown noise sources are mixed by the noise colour parameter; a low-pass filter sweeps from its cutoff by the sweep amount over the cue; an ADSR envelope shapes the level; the repeat parameters copy the cue at the given interval; a Schroeder reverb adds space; a soft clip bounds the output. The kind selects which stages are active and what shape they take — a click is an envelope over noise with no oscillators, a pad is many partials under a slow envelope, rain is filtered noise with fine repeats — and the parameters set their values.

What is deliberately absent: no sample library, no neural vocoder, no autoregressive audio model and no speech. The model never sees or produces waveforms; it produces a kind and a parameter vector, and the engine produces every sample from those alone.

Inputs & outputs #

Input #

The description is a short, plain phrase or sentence. The service collapses runs of whitespace to one space and trims the ends before the length is checked; a description that is empty after trimming is rejected, and one longer than 400 characters is rejected rather than cut. A request:

{
  "text": "short bright chime, two notes rising",
  "seed": 7
}

Limits:

• text is at most 400 characters after whitespace is collapsed. The limit is the reference client's guard; the service applies the same one.
• seed is optional. Given as an integer, it fixes the engine's noise sources, so the same text and seed produce the same bytes; a fractional value is truncated.
• Descriptions are read as English. The model has no notion of grammar; it reads hashed n-grams, so word order matters only through bigrams and character 4-grams.
• Nothing in the request selects a kind directly: the model chooses it from the description. A host that wants a specific kind and parameters calls the service's direct render route described under Runtime & deployment.

Output #

The response carries the rendered audio and the parameters that produced it. params holds the predicted kind and every continuous synthesis parameter as the engine used it, after clamping to the engine's ranges, plus the seed, so the object can be edited and rendered again. An illustrative response — the values show the shape; no trained model has rendered them:

{
  "ok": true,
  "engine": "express-cue",
  "duration_seconds": 0.9,
  "params": {
    "kind": "chime",
    "duration": 0.9,
    "base_freq_log2": 10.2,
    "partials": 4,
    "inharmonicity": 0.02,
    "attack": 0.005,
    "decay": 0.25,
    "sustain": 0.2,
    "release": 0.4,
    "noise_colour": 0.0,
    "lowpass_log": 13.5,
    "filter_sweep": -0.5,
    "am_rate": 0.0,
    "am_depth": 0.0,
    "pitch_glide": 5.0,
    "repeat_count": 2,
    "repeat_interval": 0.18,
    "reverb": 0.15,
    "gain": 0.8,
    "seed": 7
  },
  "wav_base64": "UklGR…"
}

The continuous parameters, what each drives in the engine, and its unit. The key names are the planned names and are fixed when the model is trained:

duration_seconds is the length of the decoded file, which the engine holds within 0.1–6 s whatever the model predicts. wav_base64 decodes to a RIFF/WAVE file at 24 kHz with one channel; the reference client reads the sample rate and length back from the RIFF header rather than trusting the envelope.

Training #

Express Cue trains on synthetic data only: a library of (description, parameters) pairs generated from templates, with no external audio, no recordings and no user data. Each template names a kind and a way of describing it — adjectives for brightness, length, pitch and texture, counts of notes or repeats, words for space and distance — and draws parameter values that match the words, so that “short”, “bright”, “rising” and “distant” each move the parameters they should. The first trained version used a library of 2,000,000 descriptions for 16 epochs, generated on the training machine in under a minute; no real user data was used.

The recipe is a cross-entropy loss on the kind head and a regression loss on the parameter heads, each parameter scaled to a comparable range, trained from scratch. No warm start, no external corpus and no audio enters training: the model learns the mapping from words to parameters, and the engine's rendering is fixed by construction rather than learned. The first version was trained on 2026-09-13 on Vertex AI, on one A100, in Vertex AI job express-cue-20260913-092405: size xl, 16 epochs over the 2,000,000 descriptions, 7.4 minutes of training.

What it is not trained on: recorded sound-effect libraries, music, speech, non-English descriptions, or descriptions longer than the template phrasings.

Evaluation #

Two evaluations stand behind the table. The rows marked trainer validation are the trainer’s own pass over the held-out 5 % of the synthetic library (100,000 descriptions the model never saw), recorded in the run metadata of job express-cue-20260913-092405. Every other row comes from the evaluation programme of 2026-09-13, run offline against the final weights and recorded in eval/express-cue/2026-09-13/results.json, with the roll-up in REPORT-2026-09-13.md; the key path after the file name names the exact figure. It has four parts: a fresh held-out set, an audio judge, two controlled tests scored from the rendered audio, and latency.

Held-out #

The fresh held-out set is 20,000 synthetic descriptions from generator seed 9001. Kind accuracy is exact-match over the 18 kinds and is 1.000 on every kind (heldout.kind_acc_by_kind). The parameter error is the mean absolute error over every continuous field after min-max normalisation to [0, 1]; restricted to the fields a description explicitly mentions (68,866 mentions) it falls from 0.0598 to 0.0549, and a mentioned attribute lands within a tenth of its range 0.818 of the time. The fields a description never mentions — partials, filter sweep, pitch glide — are predicted as population averages, which is what keeps the overall error above the mentioned-attribute error; per field (heldout.metrics.text_attr_acc_by_field), decay, pink noise and repeat count are read right 0.99–1.00 of the time when mentioned, partials (0.63), release (0.66) and amplitude-modulation depth (0.67) least often. The spectral distance renders 200 held-out cues twice, from the predicted and from the reference parameters, and averages the log-mel distance in decibels: 15.9 dB, against the trainer’s 17.2 dB on its own split.

Audio judge #

120 held-out descriptions, spread over the 18 kinds (six or seven each), were rendered and each clip was scored by an LLM audio judge (a third-party model that listens to the 24 kHz mono clip and reads the description; temperature 0, low thinking budget) on a 1–5 rubric for three questions: does the audio match the named kind, does it honour any count or duration the description states, and is it a plausible rendering of the description as a whole. The kind head was right on all 120 clips (judged.kind_acc_on_set).

Per kind (judged.per_kind), swoosh, static and thunder score 5.00 on plausibility and beep_sequence, alert and pad above 4.7; engine (4.17), chime (4.29), click (4.29) and drop (4.29) sit lowest of the ordinary kinds. **buzz is the weak kind**: kind match 2.43, count/duration 2.57 and plausibility 2.14 over its seven clips, and four of the ten worst-scored clips in the whole set are buzzes (judged.worst_10). Because the kind head chose buzz correctly every time, the fault is on the rendering side — the judge describes the clips as dull thumps or a musical bass tone rather than an abrasive buzz — so a host that needs a buzz should expect the least convincing cue in the catalogue until the engine’s buzz stage is revised.

Counts and durations in the audio #

Two controlled sets of 100 descriptions each test whether what the text states is honoured in the rendered file, not merely in the predicted parameters. The count test asks for N beeps, clicks or ticks with N from 2 to 8 and counts onsets in the audio with an RMS onset detector whose own accuracy on 120 reference renders with known counts is 0.950 (controlled.detector_self_check.exact), so the audio-based figures are bounded by it. Exact count in the audio: 0.650; exact count in the predicted repeat_count: 0.800; within ±1 in the audio: 0.800; count MAE 0.69 (controlled.count). Counts of 2 are exact every time and counts of 3 and 4 exact 0.87 and 0.86 of the time; the misses concentrate at 6 to 8 repeats, where exact-in-audio falls to 0.36–0.43 (controlled.count.by_expected_count). The duration test asks for a cue “for N seconds” with N from 1 to 6: the WAV length is within 0.191 s of the request on average, within ±0.25 s 0.870 of the time and within ±0.5 s 0.900 of the time; the effective length to a −40 dB tail is within 0.329 s (controlled.duration). Durations of 1 to 4 s are within a quarter of a second at least 0.88 of the time; 5 and 6 s, the sparsest region of the generator’s range, only 0.56 and 0.75.

Latency #

Batch-1 on an arm64 workstation CPU with eight threads: the description-to-parameters pass takes 0.59 ms median and 0.74 ms p95 over 200 texts (latency.describe_to_params_batch1); the render takes 11.5 ms median and 68.0 ms p95 over 60 cues of 2.18 s mean length, about 9.7 ms per second of audio (latency.render). A six-second cue therefore renders in about 60 ms. These are the model’s and the engine’s own costs; the hosted route adds network time and the base64 encoding of the WAV.

Known gaps #

Every ground truth is synthetic or a machine judgement. The held-out descriptions come from the same template generator as the training library, so the perfect kind accuracy measures fit to the generator’s phrasings, not to how people describe sounds; an unfamiliar phrasing lands on the nearest hashed features and may pick the wrong kind. The judge is an LLM listening to 24 kHz clips: its scores are a proxy for plausibility, they were produced by one model at one temperature, and no human listening study has been run. The spectral distance is likewise a proxy, not a judgement of quality. The audio-based counts depend on a simple onset detector whose own accuracy is reported beside them, and the controlled tests cover only the three kinds with repeats and only stated durations. buzz renders badly and the cause is in the engine, so a retrain alone will not fix it. Latency was measured in PyTorch and plain numeric code on a workstation, not inside the hosted container.

API #

Route /v1/sound · quota bucket audio.

Express Cue is exposed through the Falcon API at /v1/sound, which has served this version from a CPU service since 2026-09-13. Requests count against the audio preview quota bucket. The base URL, envelope, authentication, rate limits and retry guidance are documented in API conventions.

POST /v1/sound HTTP/1.1
Authorization: Bearer fln_…
Content-Type: application/json

{
  "text": "short bright chime, two notes rising",
  "seed": 7
}

{
  "ok": true,
  "engine": "express-cue",
  "duration_seconds": 0.9,
  "params": {
    "kind": "chime",
    "duration": 0.9,
    "seed": 7
  },
  "wav_base64": "UklGR…"
}

params is abbreviated above; the full object is shown under Output. The reference client sends "format": "json" in the body as well as Accept: application/json, decodes wav_base64 to bytes, and takes the duration from the RIFF header when duration_seconds is absent.

Errors:

The 502 and 503 codes follow the series pattern (spatial_failed, waymark_unavailable) and are fixed with the route.

Runtime & deployment #

Express Cue runs as a CPU service: one container holding the model and the engine behind routes of its own, fronted by the Falcon API at /v1/sound. The hosted endpoint has served this version since 2026-09-13.

• Service contract. GET /health; POST /v1/sound taking {text, seed?} and returning the WAV — as audio/wav by default, or as the JSON envelope above when the request carries Accept: application/json or "format": "json"; POST /v1/render taking a params object directly and returning the same, so a host can re-render edited parameters without the model.
• Loading. The service answers 503 while it loads its weights. The reference client waits 2.5 s and retries once, and gives up on a request after 45 s.
• Cost. The model is a bag lookup and a small perceptron; the engine renders at most six seconds of 24 kHz audio in plain numeric code. Measured on a workstation CPU (Evaluation): 0.59 ms median from description to parameters, 11.5 ms median to render a cue of about 2 s, about 9.7 ms per second of audio, so the longest cue renders in about 60 ms before network time and base64 encoding.
• Selection. There is one Sound model; nothing selects between siblings.
• What the host provides. The description, optionally a seed, and a player or file sink for the WAV. The host decides the level at which a cue plays and whether an alert repeats.

Limits & safety #

Express Cue does not hear anything: it reads a text description, and the engine it drives never sees the description. It does not see who asked, where the cue will play, or anything about the host's audio pipeline.

• It does not produce speech, words or anything with a linguistic meaning; a description that asks for a voice renders as a tone or a noise of some kind.
• It does not produce music: no melody beyond a pitch glide or a short note sequence, no harmony, no rhythm pattern beyond repeats.
• It does not play recordings: every sample is synthesised, so a description of a specific real sound — a named bird, a particular engine — renders as the nearest kind, not the real thing.
• It does not render longer than six seconds or shorter than a tenth of a second; a request for a minute of rain gets six seconds of rain.
• It does not read descriptions outside its template vocabulary reliably; an unfamiliar phrasing lands on the nearest hashed features, and the kind may be wrong.
• It does not control loudness in the host: gain bounds the file's level, but the host decides how loud the cue plays.

Out of scope. Express Cue is not a sound-effects library, not a music generator and not a text-to-speech model. It is not suitable for alarms whose absence or misfire has safety consequences: a rendered alert is an interface cue, not a certified alarm signal.

Fixed weights per version; the model does not learn from requests.

Versions #

Version numbers follow the series convention: a major bump changes the input or output contract — the request fields, the kind catalogue, the parameter keys or the response shape; a minor bump is a retrain with the same contract, so a description may land on different parameters but the same fields come back; a patch bump changes metadata or runtime only and never changes a render. The engine is part of the contract: a change to how a parameter is interpreted is a major bump even when the model's weights do not change.

Current weights: version 1.0.0, express-cue.bin of 97,791,612 bytes with its meta.json of 25,385 bytes, both written 2026-09-13 by Vertex AI job express-cue-20260913-092405 (size xl: a 16,384 × 768 embedding bag and a four-layer, 1,536-wide perceptron). The kind catalogue and the parameter ranges in meta.json are the ones listed on this page.