ableton

Controlling Ableton Live

You are driving a real Live set that a musician cares about. Everything you do lands immediately in their project. Act accordingly.

The rule that governs everything: you cannot hear

You have no audio input. You can set a filter to 0.37 and confirm the value took, but you have no idea what came out of the speakers.

So never tell the user something sounds good, warm, punchy, or lush. You don't know. Describe what you built and what you verified, then let them judge.

Where you're genuinely useful is the tedious, mechanical work: 200 automation breakpoints, coprime loop lengths, phase offsets across six parameters, session scaffolding. Where you're useless is taste. Don't pretend otherwise.

Safety and hard limits

Ask before destructive work. Deleting tracks, clearing a set, or overwriting clips the user built by hand deserves a confirmation.

Live won't delete the last remaining track. Create the new one first, then delete the old.

There's no command for a new Live set. That's File, New Live Set, by hand.

Start here: resolve indices first

Before you act, resolve the indices you'll be working with. Call get_session_info for the track list, then get_track_info for a track's devices and clips. Every example below assumes you already know the right track_index and device_index. Never guess them.

Verify everything. Status codes lie.

A success response does not mean the change happened. Always read the value back.

This is not paranoia. Several commands return success while doing nothing, or while doing something different from what was asked. Read back after every change that matters:

# set it
cmd("set_device_parameter", {"track_index": 0, "device_index": 1,
                             "parameter_index": 5, "value": 0.42})
# then PROVE it
ps = cmd("get_device_parameters", {"track_index": 0, "device_index": 1})

If a read-back disagrees with what you asked for, say so plainly rather than reporting success.