MixPill 3.2.3

A performance release, and one bug that 3.2.2 introduced.

The mixer kept animating after you closed it. 3.2.2 stopped the level meters when the popover is dismissed, but the mute glyph's animation was driven by the last level reading — which freezes at whatever it was. Close the popover while something is playing and every row that had been playing kept a repeating animation running at a screen nobody was looking at. It now follows whether the app is playing, and stops with the popover.

Opening the mixer costs about a third less. Level readings arrive thirty times a second and used to live on the model that the whole popover is drawn from, so a six-point meter moving rebuilt every row, thirty times a second. Each channel's meter now has its own path to its own reading. Measured on the same machine with music playing: 32.5% of a CPU core down to 21.1%, and the view-rebuilding part of that from 1119 samples out of 4547 to 2.

Dragging a fader is 3 to 9 times cheaper. Three things were happening on every event of a drag, sixty times a second: the whole popover was being rebuilt to keep a preset checkmark honest, a Launch Services lookup ran to build an undo label that was then discarded, and the output menu regrouped its device list for a menu nobody had opened. None of them do now.

Nothing in the audio path changed. Its real-time guarantees were re-checked against the shipped binary rather than the source — no allocation, no locking, no reference counting on the render or capture threads — and they hold.

Full Changelog: v3.2.2...v3.2.3

MixPill 3.2.2

Two fixes, both found by measurement rather than by reading.

Apps that were playing showed up as quiet. macOS accepts a listener on an audio process's IsRunningOutput property and then never posts it, so MixPill only ever re-read play state when an app launched or quit. A browser creates its audio process objects when a page loads — before any sound — so Chrome was read as silent once and filed under Quiet Apps for the rest of the session. MixPill now listens to the property macOS does post, and also counts the tap's own pre-fader level, so an app that starts playing appears immediately and one that stops drops out ten seconds later instead of leaving its row the instant a track ends.

The menu bar app used 18-23% of a CPU core with the popover closed. A MenuBarExtra in window style keeps its content alive after it is dismissed, and the level meters kept animating the whole mixer at the display's refresh rate at a screen nobody was looking at. Meters now stop when they are not visible and run at the rate the audio engine actually sends. Measured on the same machine: 18.4% to 0.0%.

What's Changed

• Resample between the two audio clocks instead of splicing by @kuntayerkus in #3
• Draw a new mark, and drop the gradient it used to sit on by @kuntayerkus in #4

Full Changelog: v3.2.0...v3.2.2

MixPill 3.2.0

What's Changed

• Rebuild the audio path, translate the catalog, and true up the README by @kuntayerkus in #2

New Contributors

• @kuntayerkus made their first contribution in #2

Full Changelog: https://github.com/kuntayerkus/MixPill/commits/v3.2.0