load_device
Destructive
Search Ableton Live's browser for devices, then load a chosen device onto the currently selected track. Use confirm=False first to review candidates and track selection, then confirm=True with the item path to execute.
Instructions
Search Live's browser and load a device onto the currently selected track.
Two steps, and the first one is not optional in practice: call with confirm=False
to search and to see which track is selected, then call again with confirm=True
and the uri or item_path of the item you chose.
Returns:
Dictionary of search candidates and the selected track on the search step, or
the load result and the resulting device chain on the load step.
Note:
Loading an instrument is destructive. ``Browser.load_item`` takes no track
argument: it loads onto whatever ``song.view.selected_track`` points at.
It cannot be aimed inside a rack from here. Measured 2026-09-07 against
Live 12.4.5: writing ``rack.view.selected_chain`` reads back as the chain
that was asked for, and a device loaded afterwards still lands on the
track. The chain kept its six devices and the track went from one device
to two. Live's browser follows the selection in its own interface, which
no write over this channel drives. An effect is appended to the end of the
chain, but an instrument replaces the instrument already on the track and
discards it silently, together with every parameter configured on it and
every clip envelope pointing at it. Check the selection and the existing
chain with get_devices before confirming.
Loading plug-ins in rapid succession can crash Live (measured: a batch load
during a background plug-in rescan, with a licence dialog open, took the
whole application down). Load one at a time, check the connection between
loads, and save the set first.
A successful return proves the call ran, not that the track makes a sound: a
measured Drum Rack load reported success on a silent track. Read the chain
back with get_devices, and for a rack check that ``chains`` is not empty.
An instrument load renames the track while the track still carries Live's default
name, so a track name cached from an earlier get_session is stale afterwards. An
effect never renames. To reorder what is already loaded, call ``song.move_device``
through lom_call rather than loading again.
Three things about the search step are worth knowing before trusting it.
An empty ``candidates`` with ``truncated: true`` is not proof that the item is
absent. The walk ran out of budget before it reached the item, and a search
narrowed with ``root`` can find on the first try what an unrooted search missed
entirely. Narrow before concluding something is not installed.
A ``uri`` from the search step can fail to resolve on the load step for the same
reason, with ``stopped by node_budget``: resolving one walks the browser again,
and a uri carries no hint about where to look. The ``item_path`` in that same
candidate addresses the item directly and cannot run out of budget, so prefer
it. Where the uri is what you have, pass ``root`` with it and the second walk
is narrowed to that one category the same way the search was.
Loading onto the main track works and is reached the same way as any other
target, by pointing the selection at it first: write ``song.view.selected_track``
with ``{"__path__": "song.master_track"}`` through lom_set, then load. There is no
track index for the main track, which is why the usual index does not apply.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| uri | No | The uri of one candidate from a previous search step, copied back verbatim to say which item to load. Resolving it walks the browser a second time, so pass root as well when the item sits deep; item_path avoids the walk altogether and is preferred. | |
| root | No | Browser category to search inside. Empty searches every category, which is slower and returns more near misses. | |
| limit | No | How many search candidates to return. | |
| query | No | What to look for in the browser, matched against item names, e.g. 'Operator' or 'reverb'. Required for the search step; on the load step it can be dropped once uri or item_path is known. | |
| confirm | No | False searches and loads nothing, reporting the candidates and which track is selected. True loads the item named by uri or item_path. | |
| item_path | No | The browser item as a LOM path rooted at app, e.g. 'app.browser.instruments.children[3]'. The reliable handle, and the one to prefer: unlike a uri it is not walked for again, so it cannot fail on the walk budget. Every search candidate carries one. |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||