MIR as a Parts Library, Not a Framework

"librosa, Essentia, and Demucs are parts in a drawer, not a frame the product must live inside."

Candidate Parts, Not a Framework

Open-source implementations already exist for tempo, beat, feature, pitch, and stem-separation problems. The important decision is not to canonize library names in advance; it is to define the contract Bonfire needs from each capability. Candidate implementations stay behind Bonfire-owned interfaces. The engine depends on StemSeparator, not directly on Demucs. Accuracy, maintenance, licensing, and runtime cost can choose a different implementation without changing the learning flow. Own the interface; borrow the implementation.

Demucs as a Stem-Separation Example

Demucs v4 models can split a mix into drums, bass, vocals, and an 'other' accompaniment stem. However, Meta's original repository is now archived and no longer actively maintained. That makes Demucs a candidate to evaluate alongside its maintenance fork and other separators, not a permanent foundation to hard-code by name. The capability can still buy a learning tool a great deal:

Isolate what you are studying. Solo a bass stem to reduce the rest of the mix.
Lower the part you will replace and play over the rest. The remaining stems can act like a backing track.
Test analysis per stem. Separation may improve some downstream analysis, but separation artifacts may also hurt it. Measure on a representative song corpus rather than assuming accuracy improves.

Place Heavy Work by Measurement

Stem separation can consume substantial compute and memory, so a Python backend is a natural first placement. The browser can request work and play results while a server uses available acceleration. A particular Mac specification or 'never in the browser' is not a product invariant, though. Implementations and hardware change. Benchmark again when they do. The durable decisions are the StemSeparator contract and its evaluation criteria, not today's machine or stage label.

Code

A separator is a swappable adapter·python

class StemSeparator(Protocol):
    def separate(self, audio: AudioBuffer) -> dict[str, AudioBuffer]: ...

class DemucsAdapter:
    def separate(self, audio: AudioBuffer) -> dict[str, AudioBuffer]:
        return demucs_apply(audio)  # -> {drums, bass, vocals, other}

# Compare candidates on one corpus:
#   quality / artifacts / runtime / memory / maintenance / license
#
# The engine knows the StemSeparator contract.
# A particular separator stays inside its adapter.

Exercise

Pick a library you depend on heavily. Write the thin interface your code would call if you wanted to replace it next year without touching upstream callers. Then define comparison criteria for candidate implementations: accuracy, maintenance, license, and runtime cost.

Hint

Could a different implementation sit behind the same interface with no caller changes? If callers reach into library-specific types and idioms everywhere, you are living inside the framework rather than using a part.