Skip to content
Documentation

Introduction

Every generative music system exposes its own idiosyncratic controls. GAS (Generative Audio Syntax) is an open language and runtime for directing these systems with a single, standardized interface.

It all starts with writing a .gas file: you describe what the music should do with as little or as much detail as you would like – from high-level descriptions of the mood of each section all the way down to exact note sequences for an instrument. Then the GAS runtime converts the file into a sequence of commands and sends them to supported generative music models.

Here is a complete example GAS document:

gasPlayground
tempo 88
key "C major"
time_signature 4/4
length bars 4
 
track piano "Soft felt piano"
 
section intro:
    length bars 4
 
    bar 1:
        piano.play
 
intro()

That is all you need to get started – four lines of setup, one instrument, one musical section, and a line at the bottom that says when to play it.

Reading the document

The first four lines set up the piece. tempo 88 means 88 beats per minute. key "C major" sets the tonal center. time_signature 4/4 means four beats to a bar. length bars 4 says the whole piece is four bars long.

track piano "Soft felt piano" names an instrument. The quoted text is the description the model works from, written in plain language rather than as a preset or a patch name.

section intro: groups musical intent, and bar 1: places it. So, piano.play means the piano starts at the first bar of that section.

intro() at the bottom is the arrangement: it plays the section. A document can call several sections in order and call the same one more than once.

It can change while it plays

A GAS document is not a file you render once. While audio is playing, you can send a fragment that changes what happens next:

gas live
piano.flavor "busier, left hand walking"
tempo 96

The music does not stop and restart. The change is applied straight away, reaches your ears within moments, and the piece carries on from there. Changes sent this way are overrides: they sit on top of what the document said, and they stay in effect until you clear them or the music stops. The language reference explains how they layer.

This is the part of GAS that matters most for applications. A game, an installation, or a visualizer can push overrides as its own state changes, and the score responds.

How the pieces fit

Four things sit between your document and the audio you hear:

  • The compiler parses your document and compiles it to a timeline in musical time.
  • The session is what your application talks to: it loads the timeline, takes changes, and controls playback.
  • The renderer converts musical time to real time against a clock, and decides what to ask for and when.
  • A connector translates those requests for one specific model.

Architecture describes each part and the packages that provide it. Supported models lists the models you can connect to today.

Where to go next