First the floor: TandaBox for Mac now requires macOS 26 Tahoe, and the iPhone app requires iOS 26. This site said macOS 14 until yesterday, so if you read it last week and worked out that your machine qualified — I’m sorry, it may not any more. The reasoning is written down rather than hidden: building on the current frameworks is what keeps a one-person app maintainable, and a lower floor would cost more than it returns. There’s now a FAQ entry that says plainly which machines run it, including the honest answer for the ones that don’t. I also dropped the chip line entirely. It used to say “Apple silicon & Intel”, which stopped being true, but replacing it with “Apple silicon” would have been wrong in the other direction, because four Intel models still run macOS 26. The version number already tells you what you need to know.

Second, a claim I had to correct. The privacy policy said this website doesn’t use analytics. It does: the hosting platform’s stats module counts page views, and it has been on the whole time. The apps are unchanged and still collect nothing, which is the part I actually care about — but a privacy policy that overstates the case is worse than one that admits the boring truth. The page now says what is counted and why, and the effective date moved to today.

Third, smaller: the Equalizer Pack is ten bands, not five. That was decided back in July and the site never caught up.

Dragging a track from Finder into a tanda works. It used to fail with “the dropped item could not be read”, in both a new tanda and an existing one, and there turned out to be two separate causes rather than one. The first was a check that treated a normal condition as a fatal error. The second was subtler: the file the system handed us only lived for an instant, and by the time the import ran it was gone.

So the fix isn’t just a repaired check. A dropped file is now looked up in your library by identity, and if it’s already there, the existing track is used and nothing is imported at all. That’s the case that actually matters — you drag from your own collection. A file that isn’t in your library yet is refused for now, with a message that says so. Two reasons for holding that back, and both are honest ones: we haven’t measured whether a file from an unwatched folder can be read reliably, and that path leads into a separate performance problem I’d rather fix properly than ship around.

Second thing: an empty result now explains itself. Before, a filter combination that matched nothing gave you a blank table and no reason — which fooled both me and my tools into thinking the filter was broken when it was working correctly. It now names the situation, summarises the filters that are active, and offers one click to clear them. The status strip still just says “0 tracks”; saying why isn’t its job.

Building a tanda finally has somewhere to do it. The New Tanda screen is now three panels: style and orchestra on the left, each orchestra with a count, so you can see how much material you actually have before you commit to one; the matching tracks in the middle, with a year filter you can either type as a range or tap as a chip, including the two-year chips like 1938-39, because that is how the recordings cluster; and the tanda you are assembling on the right.

It is not a separate window. That was the first decision and the one I was most tempted to reverse, because a modal editor window is far easier to build and it is what my own older tool does. But you build a tanda while looking at the rest of the library, and a window sitting on top of the library breaks the thing it is there to help with. Same single-window shell, sidebar included.

Adding a track works three ways: click to select, double-click to add straight away, or drag it over. Three, not one, because in my own use it depends on whether I am scanning or committing, and I would rather not force the choice.

The constraint worth writing down is width. Three panels want room, and the easy fix is to raise the app’s minimum window size. I didn’t. The minimum is still 720×480; below a certain width the middle panel folds behind a Filter button, opens as a popover, and unfolds by itself once you widen the window again, with your selections still in it. Raising a minimum is a cost you quietly hand to everyone on a small screen so that one screen can be simpler to write.

The toolbar had a glass capsule wrapped around the status controls on the right. It looked heavy and the items were crowded against each other. It’s gone — device status, theme and the panel toggle now stand on their own, with the system deciding the spacing. Action buttons keep their own material on purpose: the primary action on a screen should still look like the primary action.

That fix took two rounds, and the second round is the interesting one. The first pass cleaned up the main window and I called it done. It wasn’t: the same capsule was still sitting on three other screens, because I’d fixed the place I was looking at instead of asking how many places there were. A one-line search found them. The lesson isn’t “search more” — it’s that “I fixed it” and “I fixed all of it” are different claims, and only one of them was true.

Second: the playing track now shows itself. It’s selected and scrolled into view, and the selection follows as tracks change. Three rules — following is on by default, browsing away turns it off, playing something or pressing ⌘L turns it back on. My first draft had double-clicking a track to play it turn following off, which is technically consistent and practically absurd: the act that starts playback shouldn’t disable the feature that follows playback. Caught before it shipped, but only just.

And if the playing track isn’t in your current filter, nothing happens at all. Your filter is never cleared behind your back — only ⌘L does that, deliberately, because you asked.

Third, in the tanda editor: track rows now show orchestra and artist as separate fields on both sides. They’re deliberately not falling back one to the other — a track’s “artist” is often the singer, and conflating the two misleads you at exactly the moment you’re building a tanda by orchestra. The guide badge came back too. It had been computing “Guide: tango 4” and then hiding it, because a toolbar quietly collapses a label down to its icon. It had the answer the whole time and wasn’t showing it.

New installs now open in dark mode. The room this app is used in is usually dark; if you’ve already picked a theme, yours is kept.

Clicking a column header to sort the library could lock TandaBox up for minutes. Not a stutter — a full freeze, with force-quit as the only way out. It had been sitting in my notes as “sorting takes about two seconds,” which is the kind of note that hides a problem instead of recording it.

My theory was that columns with few distinct values were the expensive ones. Genre has around 130; sorting by it was catastrophic, so the theory fit. Then I measured every sortable column instead of the one that annoyed me. The cheapest column to sort had 29 distinct values. The most expensive had 31,903. The theory was not just wrong, it was backwards.

What actually costs is how much the new order disturbs the old one. Sorting by composer was cheap because 99.7% of my files have no composer, so almost nothing moved. Sorting by file size was ruinous because everything moved. And that means the freeze was never a property of a column at all — it depends on what you sorted by last. No column was safe.

The sorting itself was never the problem; that already happened off the main thread, in the database. The problem was how the table applied the result — rebuilding thirty-two thousand rows one at a time, on the thread that also draws the window. It now rebuilds the view once. Sorting went from over 108 seconds — where I stopped the clock, not where it ended — to 3 or 4, with peak memory down from about 4 GB to under 1. The cost no longer depends on what you sorted by before.

I’m writing the wrong theory down because the measurement is the only reason the right fix got built. Had I trusted the note in my file, I would have optimised the fast half of the problem and shipped the freeze.

The past few weeks on TandaBox for Mac had one theme, and it wasn’t features. It was trust. A library tool you can’t trust is worse than no tool, because you find out late — usually at a milonga.

Switching library sources used to rebuild the catalog from scratch, which quietly emptied every saved tanda and milonga playlist. It now matches files across sources and keeps them, and the dialog spells out what stays and what goes. Rescans used to read an unplugged drive as a mass deletion; now nothing is removed when a folder is unreachable, or when more than half its files suddenly look missing, and it tells you why. Thousands of tracks were missing their genre and track number — not because the tags were absent, but because two binary m4a fields were never being read. Both are decoded now, and a real gap in the cortina rule closed with them.

The last piece landed today. A scan from scratch used to be a spinner and a guess. Now it counts: how many tracks read out of how many, and it is the same indicator whether you are rescanning a folder, refreshing a source, or switching to a different one. Underneath, every audio file was being opened twice while its tags were read; now once. On a 32,000-track library the first full scan went from 80 seconds to 65. I had assumed the double-open was costing half the time. It wasn’t — about a fifth. The measured number is the one that goes here.

Next comes the part that makes the app pleasant rather than merely correct: the library view itself, cortinas, tandas, and milonga playlists.

This page is what the name suggests: half changelog, half blog. Most changelogs tell you what changed; most blogs tell you what the developer thinks. Building a tango player as one person means those two are never really separate, so here they share a page.

What you’ll find here over time: release notes for every TandaBox version, Mac and iPhone, site updates, and short notes on what’s being worked on and what got cut. No schedule, no filler. An entry appears when something actually changed.

It arrives with two more changes. The site dropped its borrowed warm palette for TandaBox’s own colors, the three genre colors on black and white. And there’s now a Pipeline page: the public to-do list.

The site you’re reading launched today, rebuilt from scratch so every page speaks the app’s design language, genre colors included: tango burgundy, vals green, milonga blue. Alongside the home page there’s a complete feature list, a plain-language privacy policy, and a support page with the questions I expect to be asked most.

One more thing became official today: the app’s full name is MyLonga TandaBox. MyLonga is the personal tango toolkit I’ve been building for my own DJ work; TandaBox is the part of that world being made for everyone. The full name ties the two together — and puts it on the record.

TandaBox for iPhone and the free TandaBox for Mac are both in active development. The order of work is deliberate: playback reliability comes first — AirPods pause/resume, background audio, ReplayGain loudness, CarPlay — because for a DJ those aren’t features, they’re the floor. Nothing ships until they pass on real devices.

TandaBox for Mac is released first, from the Download page, before the iPhone app reaches the App Store. Dates will appear here when they’re real. Not before.