System architecture

Mora is built as a set of deliberately layered systems. The temporal core, runtime, and language sit beneath optional clients and adapters for sound, visuals, analysis, and editing, so the language can be used from a plain SBCL listener as well as inside Mora Studio.

The main systems are layered as follows:

mora/core          temporal values, events, retained pattern protocol
  mora/runtime     transport, channels, scheduling, backend protocol
    mora/mini       terse livecoding language
    mora            user facade

optional clients and adapters
  mora/superdirt    timestamped sound output
  mora/audio       prepared audio/control descriptions
  mora/samples*    discovery, cache, control, import, audition, Studio glue
  mora/visual      visual operators and native GL renderers
  mora/analysis    cl-mltk integration
  mora/link        Link integration
  mora/studio-core editor, evaluation, assistance, inspection; no GL
  mora/studio      native window, GL rendering, application lifecycle

This listing shows the layering rather than every system.

mora/core holds temporal values, events, and the retained pattern protocol. That protocol is described in Patterns and time and Common Lisp and CLOS.

mora/runtime provides the transport, channels, scheduling, and the backend protocol. The transport maps cycles to physical time using tempo and beats per cycle. See Channels, tempo, and transport.

mora/mini is the terse livecoding language that the Language section documents, beginning with Pattern literals. mora is the user facade.

The remaining systems are optional clients and adapters:

• mora/superdirt provides timestamped sound output. For the normal sample and synthesis path, Mora sends timestamped OSC to SuperDirt in SuperCollider; see From pattern to audio.
• mora/audio holds prepared audio and control descriptions.
• The mora/samples* systems cover sample discovery, the cache, control, import, audition, and Studio glue; see Samples and slicing and Stems and sample libraries.
• mora/visual holds visual operators and the native GL renderers; see Shader composition.
• mora/analysis is the cl-mltk integration, through which measured PCM, spectrum, and machine-listening features are available; see Machine listening.
• mora/link provides Link integration.
• mora/studio-core holds the editor, evaluation, assistance, and inspection, with no GL.
• mora/studio provides the native window, GL rendering, and application lifecycle.

Mora’s scheduler and backends are separate from the notation layer. The scheduler and tools obtain behavior through open protocols.

A pattern produces events in answer to a query; a configured output backend interprets those events. Asking a pattern for its events therefore does not send output by itself. See Queries are not playback.

Mora Studio is the native editor and performance environment. It combines a Common Lisp listener, structural source editing, source-linked pattern feedback, interactive controls, and an OpenGL canvas. The editor and the running language share the same Lisp image: a pattern, transform, visual operator, or application object can be inspected and redefined while the session continues.

Studio’s editor and evaluation model (mora/studio-core) is separate from its native GL renderer (mora/studio). This separation allows substantial work from a plain Lisp REPL. See Studio overview.

Studio is an interface to Mora, not a requirement for the language. The pattern system and runtime can be used without loading OpenGL, and the non-graphics layers can be used from a Common Lisp listener, tests, or another host. The native Studio renderer requires OpenGL 4.1 core / GLSL 410; the language itself does not require a GL window.

The normal Studio launcher brings the language, audio backend, native canvas, sample tools, and remote-development interfaces together. See Installation and setup.

Visual operators are pattern objects that also have a GLSL interpretation. Because a visual operator is a pattern, temporal transformations can act on its behavior; the shader interpretation, emit-glsl, applies to visual operators rather than to every pattern class. See Sound, image, and shared time.

Artists can use these mechanisms to create their own retained instruments.

For repository entry points by subject, see the Source map.