Live Exposes an API, but Not Bonfire's Core Fit

"A real API is necessary, not sufficient. Its supported scope still has to match the product's core work."

Live Exposes an Official Object Model

Ableton Live is interesting because Max for Live provides an official Live Object Model (LOM). The LOM exposes tracks, clips, devices, and parameters; clients can read, write, and observe supported properties. It also exposes audio-clip information such as file paths and warp markers. The official execution context matters: LOM is a Max for Live API. Projects such as ableton-js are third-party bridges built around Live, not the first-party API itself.

The Open Surface and Bonfire's Core Work Are Separate

Ableton Live                 scope / fit                    finding
------------                 -----------                    -------
LOM via Max for Live         session, track, clip, device   official API
Audio clip file_path         input path for MIR             adapter candidate
Chord/key/stem analysis      Bonfire's core analysis        not provided by LOM
Dad's primary music host     real residency                 Logic

It is also inaccurate to say the LOM cannot see audio. It can expose an audio clip's file path and playback or warp information, which could feed a Bonfire analysis adapter. What it does not provide is a built-in service that turns audio into chords, keys, or stems. Bonfire's MIR layer still owns that work. Dad's primary music workflow is in Logic, so Live does not need to become Bonfire's mandatory home either.

Separate Official Scope, Value, and Residency

Live shows why 'has an API' does not settle the host decision. Distinguish the first-party API from third-party bridges. Then ask whether the surface supplies the product's core capability or merely an input. Finally, verify where the user's real work happens. Under those tests, Live is closer to an optional input-adapter candidate than a core dependency.

Code

Live scorecard — separate the official API from product fit·text

Ableton Live                 scope / fit                    finding
------------                 -----------                    -------
LOM via Max for Live         session, track, clip, device   official API
Audio clip file_path         input path for MIR             adapter candidate
Chord/key/stem analysis      Bonfire's core analysis        not provided by LOM
Dad's primary music host     real residency                 Logic

# API exists != adopt it as the core host.
# Live is closer to an optional input adapter.

Exercise

Choose a tool with a documented API. Divide the integration into what the first-party API provides, what third-party bridges add, and what your product must still own. Then record whether the user's primary workflow actually lives in that host. Decide only then whether it is a host, an adapter, or neither.

Hint

A rich API may hand your product an input without performing its core work. That is not a failure; it is a different role. Do not collapse host, adapter, and analysis engine into one box.