Skip to content
Halftone illustration of an astronaut adrift, holding a bouquet

Introducing GAS

Every generative music system has its own controls and its own interface. GAS (Generative Audio Syntax) is an open, model-independent language and runtime for interacting with generative audio models. Write your musical ideas and your application against one interface, not many.

What is GAS?

GAS is a language for writing music as plain text and a runtime that plays it through a generative audio model. In .gas code, you can express your musical ideas in as much or as little detail as you would like. Your application can then load that code, play it, and make adjustments on the fly, for example by giving the piano a busier part or picking up the tempo.

first-piece.gas
# two instruments, two sections, and an arrangement
tempo 88
key "C major"
length bars 8
flavor "late night, close and unhurried"
track piano "Soft felt piano, close mic"
track bass "Round upright bass, short notes"
section intro:
length bars 4
piano.flavor "sparse, just the room"
piano.play
section main:
length bars 4
flavor "warmer, more movement"
bass.play
intro()
main()

A complete piece: eight bars, two tracks, two sections. See writing a score.

host.ts
import { createSession, sourceText } from '@luna-estelar/gas';
import { createRenderer } from '@luna-estelar/gas/renderer';
import { createLyriaConnector } from '@luna-estelar/gas/lyria';
const session = await createSession({
// Model-specific wiring belongs here, including credentials and settings.
createRenderer: async () =>
createRenderer({ clock, connector: createLyriaConnector(), settings })
});
// Start from a written GAS piece.
await session.loadSource(sourceText(piece));
await session.play();
// Then steer the same session as your application changes.
await session.setTrackFlavor('track.piano', 'busier, left hand walking');
await session.setTempo(104);

Your app starts a piece, then changes it as the app's state changes. See API reference.

The technical details

A .gas document is parsed and compiled into a model-independent event timeline. The runtime combines that timeline with live changes from your application, schedules each event, and sends requests through a connector to the audio model. Connecting another model requires a connector for that model's API, credentials, and capabilities.

The diagram has three parts: what you bring, what GAS does with it, and which model plays it. There are two ways in, and they can be combined. The first is music generation: writing GAS yourself, either as a .gas document for composing a piece, or as live fragments sent while the music is already playing, for jamming with AI or live performance. The second is your own application — a game, a web application, or an art installation — driving the music from its own state. GAS parses and compiles anything written in GAS into what to play and when, which names no model, and hands it to its programming interface: one session that keeps running while it changes. Your application can skip the language and make API calls to that interface directly. A player then handles playback, placing each moment against a clock. A connector is the last step on the GAS side and the only part that knows which model is behind it: it sends that model requests and passes its audio back. The Lyria connector drives Google Lyria and is the only connector that ships today. The dashed entries show possible integrations through another or custom connector. Those require model-specific integration code and host wiring. Documents and timelines remain model-independent, but the musical intent each model can honor differs.

  • Language
  • Your Application
  • Runtime and Connectors
  • Model Provider
  • Live Input
  • Optional

Hover, focus or tap any part for details

Artists

A GAS document reads much as you would describe the music out loud: the tempo, the key, which instrument comes in on which bar and how each section should feel.

You write and revise the piece in the document. The code that plays it is separate, so you never have to touch application code to change the music.

GAS suits installations, games, and performances where the sound should follow what is happening rather than just loop in the background. Way Back Home is one example.

We would like to make more pieces like this with you. Tell us what you are working on.

Developers

One install gives a web application everything it needs: the compiler, the session, the renderer, browser playback and the connector for Google Lyria.

npm install @luna-estelar/gas

You import only the parts you need, so you can compile and test documents before adding the renderer and connector for audio. The package also includes the gas command for compiling at the terminal. Choosing packages explains what each part does.

Roadmap

Our next priority is support for more audio models. C++ and Python SDKs and plugins for creative tools are further out: we’d build them together with partners who need them, so treat them as possibilities rather than committed releases.

ModelsSupport for more models
GAS uses Google Lyria RealTime today. Other real-time models come first, then models that render a whole piece in one pass.
SDKsC++ and Python
The GAS session API in C++, for game engines and audio plugins, and in Python, for notebooks, tools and installations.
IntegrationsPlugins for existing tools
GAS inside FMOD, Wwise, Max/MSP, TouchDesigner and DAWs, so you can direct generative audio from the tools you already use.

Building something?

Get in touch