Skip to content

Components, Layers & Modes

If Architecture is the map, this is the engine room. Components, Layers and Modes are the three ideas that let a fixed piece of hardware behave like ten different controllers. Understand these and almost every Remote Script stops being mysterious.

ELEMENTS 8×8 grid buttons · knobs ModesComponent Shift swaps the active layer Layer · CLIP (active) grid → launch clips Layer · SCENE grid → launch scenes SessionComponent clip + scene logic talks to the LOM

The problem they solve

A controller has a fixed set of physical controls -- say an 8x8 pad grid, eight knobs, a row of buttons. But you want those same pads to launch clips now, select scenes when you hold Shift, play drums in another mode, and step-sequence in yet another. Hard-wiring "pad 5 = launch clip 5" everywhere would be rigid and unmaintainable.

The framework splits the problem into three independent pieces:

  • Component -- what a behaviour does (launch clips, control the mixer, sequence steps).
  • Layer -- which physical control drives which part of a component (the wiring).
  • Mode -- which layers/components are active right now (the context switch).

Keeping these separate is the whole trick: you write a behaviour once, wire it differently per controller, and swap wirings at runtime without touching the behaviour.

Component -- a unit of behaviour

A Component owns a slice of logic and the LOM objects it acts on. It exposes named controls -- abstract slots like play_button, stop_button, clip_launch_buttons -- without knowing which physical control fills them. Examples shipped with Live:

  • SessionComponent -- the clip-launch grid, scene launch, the coloured "ring" that shows which part of the Session view the hardware is focused on.
  • MixerComponent -- volume, pan, sends, mute/solo/arm across a bank of tracks.
  • TransportComponent -- play, stop, record, loop, tempo, metronome.
  • DeviceComponent -- maps eight knobs to the parameters of the selected device.

Two properties matter for every component:

  • enable/disable -- a disabled component ignores input and stops sending feedback. Enabling/disabling components is how a mode change takes effect.
  • nesting -- components can contain sub-components (a CompoundComponent), so a "mode" can be a component that owns several others.

In v3, the ready-made components live under ableton.v3.control_surface.components; in the older lineage they are under _Framework. Same idea, different package.

Layer -- the wiring

A Layer connects physical Elements to a component's named controls:

session_layer = Layer(
    clip_launch_buttons = button_matrix,   # element  -> control name
    scene_launch_buttons = side_buttons,
    stop_all_clips_button = bottom_right,
)
session.layer = session_layer

Read it as a patch bay: the left side is what the component expects, the right side is the hardware you happen to have. Because the wiring is data, not code, the same SessionComponent runs unchanged whether the grid is 8x8 (a big pad controller) or 4x4 (a small one) -- you just hand it a different Layer.

Crucially, a Layer can be applied and removed at runtime. Removing a layer unbinds those elements so they can be re-bound to something else. That is exactly what a mode does.

Mode -- swapping wirings at runtime

A Mode is a named configuration of layers/components, managed by a ModesComponent. Selecting a mode applies its layers and enables its components; leaving it tears them down.

modes = ModesComponent()
modes.add_mode('session', AddLayerMode(session, session_layer))
modes.add_mode('drums',   AddLayerMode(drum_rack, drum_layer))
modes.selected_mode = 'session'

"Hold Shift and the grid becomes scene launch" is a mode change: the same pad Elements are unbound from the clip-launch control and rebound, via a different Layer, to scene launch. The pads didn't change -- the wiring did.

Common building blocks you'll meet:

  • AddLayerMode -- while the mode is active, apply this extra Layer on top.
  • LayerMode -- bind a component to a Layer for the duration of the mode.
  • momentary vs latching -- a mode can last only while a button is held (Shift) or stay until toggled. The ModesComponent handles both, including the button that selects it.

How it fits together

        Mode ("drums")
          |
          | activates
          v
     Component (DrumGroupComponent)        <- the behaviour (talks to the LOM)
          ^
          | bound by
          |
        Layer (drum_layer)                 <- the wiring (data)
          ^
          | maps to
          |
     Elements (the 64 pads)                <- the hardware (pure MIDI I/O)

Bottom to top: physical pads are wrapped as Elements; a Layer maps them onto a Component's named controls; a Mode decides which Layer/Component pairing is live. Change the mode and the same pads do something else entirely.

Why this matters for reading the reference

When you open a device's Specification in the reference, what you're really reading is which components it enables and how its modes are wired. The behaviours themselves -- what SessionComponent actually does -- live in the v2/v3 base classes. So the pattern for understanding any controller is: read its modes and layers to see the wiring, then follow each component into the framework to see the behaviour.

See also: ControlSurface lifecycle for when components are built and enabled, and MIDI message flow for how an element's value reaches the bound control.