lom_set
Set any Live Object Model property by dotted path and receive before, after, clamped, and changed status to verify the write.
Instructions
Write a property value by LOM path and return verification read-back.
The generic write, for the property no dedicated tool covers. Prefer
set_parameter for a device knob, set_mix for a mixer control and set_tempo for
the tempo: each validates against the catalog before writing, which this does
not. Use lom_call for a method, which is not reachable as a property, and
lom_batch to send several writes in one round trip.
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. It refuses out loud and stores nothing, so
``...volume.value = 1.4`` answers
``live_error "Invalid value. Check the parameters range with min/max"`` and leaves
0.85 standing. A tempo of 5000 and a panning of 5 are refused the same way.
What the read-back really catches is quantised snap.
``<Compressor>.parameters[10].value = 0.4`` (Model: Peak / RMS / Expand)
stored 0 and reported ``clamped: 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.
Three more, measured separately. A write can apply asynchronously, so the
first read is stale and comes back ``read_back: "not_observed"``, which is
not ``clamped`` and not a failure. A method call has no read-back at all.
And Live ignores an unknown property name silently, reporting success for a
write that did nothing, so check ``changed`` rather than ``ok``.
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. Where a property really holds
one (``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``) pass
``value={"__path__": "song.tracks[2]"}``, resolved through the same guards as
a lom_call argument (protocol section 5.4). Handed a plain JSON value the
first five answer ``not_settable``.
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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Settable dotted LOM path, e.g. 'song.tempo' or 'song.tracks[0].mixer_device.volume.value'. Note the trailing ``.value``: a mixer control is a DeviceParameter object and the number lives one level inside it. | |
| value | Yes | The value to store. A number, string or boolean for a scalar property; a reference dict {'__path__': 'song.tracks[2]'} for a property whose value is itself a Live object. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||