Davinci Resolve Dynamic Bin Creator

The Empty Media Pool

There is a moment at the start of every job that nobody thinks about, and it might be the most consequential thirty seconds in post.

You create the project. Resolve opens. The media pool sits there with a single Master bin and nothing in it. Then you start dragging.

What happens next is almost never a decision. It's a reflex, performed while your attention is somewhere else entirely — on the card copy that's still running, on the client who needs an answer about the delivery date, on the fact that the sound recordist's files are named something no human designed. You make a bin called Footage. You make one called Audio. Three hours later there is a bin called New Bin 4 containing something important, and by the following week nobody remembers what.

The cost of this isn't the ten minutes. Ten minutes is nothing. The cost is that your project's structure ends up shaped by the order in which the footage happened to arrive, rather than by how the job is actually going to be cut.

The structure is an argument

Here's the thing I didn't appreciate until I sat down to write a template and found I couldn't write just one.

A documentary bin structure has selects, string-outs, an assembly, a rough cut, a fine cut. That sequence isn't housekeeping. It's a theory of the work: that you don't know what the film is yet, that you will find it by looking at everything, cutting it long, and then removing. The bins are a staircase, and each step is a stage of not-yet-knowing.

A commercial bin structure looks nothing like that. You know the deliverable on day one — it's in the brief, it's in the contract. So the bins are keyed to durations: 60, 30, 15, 06. There is no discovery phase to build scaffolding for. There is a hero cut and there are cutdowns, and the structure exists to make sure none of them go missing at delivery.

An editorial job splits by aspect ratio, because the same material is going to three places with three shapes.

Same software. Same media pool. Three completely different arguments about what the work is. If you build your bins by reflex, you don't make that argument — you inherit whichever one you happened to make last time, on a different kind of job, for different reasons you've since forgotten.

Which is why a template is not admin

I want to be careful here, because "make a template" is the kind of advice that sounds like productivity content and usually is.

The point of templating project setup isn't speed. It's when you make the decision. A template lets you think about structure on a Tuesday afternoon with a coffee, in the abstract, across every job of that type you've ever done — rather than at 11pm on ingest night with a producer texting you. The thinking is the same thinking. It just happens under conditions where you're capable of doing it well.

That reframing changed what I built. My first instinct was a script that dumps a fixed folder tree into a new project. That would have been the wrong tool, because a fixed tree is a decision you can't revisit, and a decision you can't revisit stops being a decision and becomes a habit with better PR.

So instead: an outline you can edit in plain text, a preview with tick boxes, and the ability to turn off any branch on any given job. Presets for the job types we actually shoot, all of them editable, none of them binding.

The honest failure mode

Templates ossify. This is the real risk and it's worth saying out loud rather than pretending the tool solves everything.

A structure designed to fit every job fits none of them. You end up with fourteen bins, eleven of them empty, and an editor who has stopped reading the labels because most of them don't apply. Worse, you get the 99_UNSORTED problem: a catch-all bin that starts as a pragmatic escape valve and gradually becomes where the entire project lives, at which point you have all the overhead of a system and none of the benefit.

The countermeasure isn't a better template. It's the willingness to prune — to open the outline before a job and delete the four bins this particular job doesn't need. Which is only possible if the template is editable in the first place, and only likely if editing it takes ten seconds rather than a meeting.

A workflow tool that nobody adjusts has failed, even if everybody uses it.

On building it

A note on how this got made, because I think it matters and I don't want to overstate it.

Resolve has had a scripting API for years. It's documented, it's capable, and I never touched it, because the distance between "this would be useful" and "I have a working first draft" was too large to cross on a Sunday. That distance is what collapsed. The first version existed in an afternoon.

But the tool doesn't know what a string-out bin is for. It doesn't know that a commercial needs its cutdowns separated by duration or that a doc needs somewhere to put archive material that hasn't cleared yet. None of that came from the code. It came from having made the mistake of not having those bins, on a real job, with a real deadline.

That's the part worth being clear about. The build got cheap. The judgement didn't. If anything, the judgement is now the whole job — the ability to write the tool has stopped being the bottleneck, which means the only thing left that distinguishes a good workflow tool from a bad one is whether the person specifying it actually understands the work.

The empty media pool isn't neutral. It's a question about how you intend to cut the thing. You can answer it by accident, at midnight, in the middle of an ingest — or you can answer it once, on purpose, and spend the midnight on the film instead.

We chose the second one. It took an afternoon and it should have happened years ago.