The Three-Condition Test

"A sidecar is only as viable as its host. Three things have to be true at once, or it isn't a sidecar — it's a wish."

Why Even Ask the Question

Cinder is a sidecar to Photoshop, and it works beautifully. So the natural brainstorm was: could Bonfire be a sidecar to a DAW the same way — Bonfire is to Logic what Cinder is to Photoshop? It's a good question precisely because pushing it until it breaks is what reveals why Bonfire has to be independent. The test that Cinder passes is the test a DAW has to pass too.

The Three Conditions

Cinder : Photoshop held because three things were all true at once:

(1) the host does the core work overwhelmingly well   (Photoshop = drawing)
(2) it exposes a first-class extension API            (UXP: pixel R/W, batchPlay)
(3) Dad already lives in the host                      (daily Photoshop user)

All three are load-bearing. Condition (1) means the host is worth attaching to. Condition (2) means you can attach — there's a real, documented way in. Condition (3) means attaching is worth it for this specific user, because the workflow already happens there. Miss any one and the sidecar either can't be built, or can be built but nobody would use it.

The Test Is the Tool

Hold these three as a checklist for any 'should X be a plugin/sidecar to Y?' decision. It's the same shape whether Y is Photoshop, Logic, a browser, or an IDE. The next two lessons run Logic and Ableton Live through exactly this test — and watching each fail a different condition is what makes the independent-engine conclusion feel earned instead of asserted.

Code

The three-condition sidecar test·text

Cinder : Photoshop held because ALL THREE were true:
  (1) host does the core work overwhelmingly well   (Photoshop = drawing)
  (2) first-class extension API                      (UXP: pixel R/W, batchPlay)
  (3) Dad already lives in the host                  (daily Photoshop user)

# A sidecar is viable only if ALL THREE hold.
# Miss (2) -> can't build it.   Miss (1) or (3) -> nobody uses it.

Exercise

Take any 'should this be a plugin for X?' idea you've had. Run it through the three conditions: does X do the core job overwhelmingly well, does X expose a real extension API, and do you (or your users) already live in X? Score each condition true/false. If any is false, you've found why the plugin shouldn't exist — or what would have to change first.

Hint

Condition (2) is the binary killer: no real API means not buildable, full stop. Conditions (1) and (3) are about whether anyone would care even if you built it.