A DJ loads a track onto deck B. The title on stream changes. The audience is still hearing deck A.
That tiny mismatch is the whole reason PonAir is interesting.1
The open-source utility, published on August 11, sends rekordbox track information into an OBS browser overlay. Plenty of tools can display a track title. PonAir instead asks a more annoying question: which track is actually coming out of the mix right now?2
Loading is not playing.
A technically correct event can describe the wrong thing
The easy way to build a now-playing overlay is to react when a new track is loaded. The software knows the title, so the overlay updates.
Nothing is broken technically.
The information can still be wrong for the entire transition.
A DJ may prepare the next track minutes early, cue it privately, start it behind a closed fader, bring it in slowly, cut back to the first deck, or keep both decks audible for a while.
PonAir therefore watches the crossfader and channel faders. Its README describes an equal-power decision curve and 0.55/0.45 hysteresis so the displayed title does not chatter when a mix sits around the center.1 An optional confirmation delay can ignore very short cuts and switchbacks.
The broader lesson is useful well beyond DJ software: the easiest state to extract is not necessarily the state that carries human meaning.
An editor can know which clip is selected without knowing which clip contributes to the final frame. A music application can know which track is loaded without knowing what reaches the master output. A design tool can know which document is open without knowing what the person is currently comparing.
Good integrations often begin by finding the event closest to the actual work rather than the event closest to the API.
The strange part is where the data comes from
PonAir does not capture audio. It does not run music recognition. It does not OCR screenshots.
It reads rekordbox's accessibility tree.
On Windows, the bridge uses UI Automation. On macOS, it uses Apple's Accessibility APIs. Those systems exist primarily so assistive technologies can understand an application's interface as structured elements with roles, values, text and hierarchy.4 5
In other words, the application already maintains a machine-readable representation of what its UI is showing people. PonAir treats that representation as a small unofficial local API.
This pattern is becoming increasingly relevant outside accessibility itself. When software has no public API, automation tends to fall back to pixels, invasive hooks, or the structured interface the application already exposes to accessibility clients and test tools.
The third option can be dramatically cleaner than screenshot automation.
It is still a ghost API
There is an obvious cost.
PonAir's README warns that a rekordbox update can change the UI and break the bridge.1 AlphaTheta has not promised that its accessibility hierarchy is a stable third-party protocol.
The project currently documents rekordbox 7.x, Windows and macOS, Japanese and English UI, and a two-deck horizontal layout. Four-deck layouts are not supported yet.1
The repository also refuses to pretend it can extract data that is not available. On Windows, the required audio-level values are not exposed through the accessibility path, so PonAir simply does not provide meters.1
That restraint matters. A small hack quickly becomes a maintenance nightmare when every missing field gets a second capture system bolted onto it.
OBS is almost the boring part
Once PonAir has decided which deck is active, the rest is deliberately simple.
A local helper receives state updates and serves a transparent web page. Server-Sent Events push changes into that page, and OBS loads it through Browser Source, the built-in web surface used for overlays, alerts and other browser-rendered elements.3
That separates three jobs: inspect rekordbox, interpret the mix, render the overlay.
PonAir also supports a two-computer setup. The endpoint that needs to receive track state can be opened on the LAN while the overlay and other services stay local.1
A track title does not need to become a tiny enterprise architecture diagram. This is progress.
The gesture becomes the source of truth
The deeper design decision is not Python or OBS. It is the definition of truth.
rekordbox contains several plausible states: loaded track, playing track, crossfader position, channel-fader position. PonAir chooses the state that best corresponds to the DJ's gesture and the audience's experience.
That is a useful question for creative software in general: does the interface describe what the program thinks is happening, or what the person is actually producing?
Most of the time those states overlap. Interesting little tools tend to appear where they do not.
Accessibility as a creative surface
There is also a satisfying inversion here.
PonAir can read these values because the interface needs to be understandable as something other than pixels. A structure created for accessibility becomes an interoperability surface for a creative workflow.
That is not an argument for treating accessibility APIs as free scraping infrastructure and forgetting why they exist. It points in the other direction: software with a well-structured accessible interface becomes legible to more kinds of tools.
Screen readers, automated tests, personal utilities, agents and workflow bridges can all benefit when an application can identify its own controls and values coherently.
PonAir is far too new to call a proven tool. When we checked it, the repository had been created the same day and had no stars or forks.1
As an experiment, though, it already makes a durable point: sometimes the most useful interface to closed software is the structure it had to expose so people could understand it without looking at the pixels.