lom_set
Set an Ableton Live property via LOM path and verify the applied value with read-back, catching clamped, quantized, or ignored writes.
Instructions
Write a property value by LOM path and return verification read-back.
Args:
path: Settable dotted LOM path.
value: Value to set, or object reference dict {'__path__': '...'} for object properties.
Returns:
Dictionary reporting requested, before, after, clamped, and changed status. For a
device parameter it also carries ``display`` and ``is_quantized``.
Note:
Live does not accept an out-of-range value silently, however often that is given
as the reason to read back. Measured 2026-08-30 against Live 12.4.5: it refuses
them out loud and stores nothing. ``...mixer_device.volume.value = 1.4`` answers
``live_error "Invalid value. Check the parameters range with min/max"`` and the
value stays at 0.85; ``song.tempo = 5000`` answers "Tempo out of range"; a
panning of 5 is refused the same way.
What the read-back really catches, measured the same day, is quantised snap:
``<Compressor>.parameters[10].value = 0.4`` (Model: Peak / RMS / Expand) stored 0,
reporting ``before 1, after 0, clamped: true, changed: true, read_back:
"clamped", display: "Peak", is_quantized: true``. A caller who asks for a value
between two steps gets a different one and is told nowhere else.
Two more, measured separately: a write can apply asynchronously, so the first
read is stale (``read_back: "not_observed"``, which is not ``clamped``), and a
method call has no read-back at all. Live also ignores an unknown property name
silently and reports success for a write that did nothing.
A collection (``song.tracks``, ``device.parameters``) cannot be assigned. Address
an element and set one of its properties.
A Live object cannot travel as a plain value, and there are two cases behind
that. ``song.tracks[0].mixer_device.volume`` is a DeviceParameter and the wanted
value is one level down, so write ``...volume.value``. But a property whose value
really is an object (``song.view.selected_track``, ``song.view.selected_scene``,
``song.view.detail_clip``, ``browser.hotswap_target``, ``clip.groove``, and on a
device ``input_routing_type`` and ``input_routing_channel``) is written by passing
a reference: ``value={"__path__": "song.tracks[2]"}``, resolved through the same
resolver and guards as a ``lom_call`` argument (protocol §5.4). Handed a plain
JSON value the first five answer ``not_settable`` (measured 2026-08-29 against
Live 12.4.5). The two routing properties, a compressor's sidechain source and its
tap point, take their reference out of
``<device>.available_input_routing_types`` and
``...available_input_routing_channels``, never a name string, because RoutingType
carries ``category`` and ``display_name`` read-only and an ``attached_object``
pointing at the Track (measured 2026-08-30, same Live).
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| value | Yes |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||