Attempt to fix #32

This is just a small update that aims to target issue #32.

To test

1. Explicitly select the device that you want to playback (not the auto "default device" selection).
2. Check if device will continue to stick to your selected device, even in circumstances such as EQ / virtual device.
3. (extra) Check if device will revert to previously selected device after plugging and unplugging said device.

Known issues

App device selection menu may glitch out showing 2 checkmarks on app restart, but that should just be a cosmetic issue right now, and should not impact usability. (will fix in future)

About AppleScript Support

• Only build 9 contains the AppleScript changes introduced in beta 5.
• Builds 10 and 11 will not work for local file sample rate switching as a result.
• This is due to issue #30.

Local file sample rate detection

In this beta release,

#15 should be fixed via AppleScript method provided by @fjolnir (thank you!). This should allow for sample rate detection for local files.

As always, thanks for all your support in this project!

Selectable audio device

There is now an option to select the audio device, overriding the default audio device currently selected.
The addition of this release, hence, should solve issue #13.

Release includes everything else introduced in v1.1 build 6/beta 3.

A big thank you especially for @hatemosphere for the recent sponsor!
Also thanks to sponsors @ckortekaas, @luisrjr and an anonymous sponsor for sponsoring this project earlier!

Thanks for all your support!

Hybrid strategies

This release (v1.1, build6, beta3) brings back interval checking from v1.0, and is combined with the audio track change check introduced in earlier betas.

This hybrid approach should hopefully clear some issues with the audio track change detection method. Interval checking stops after about 10s after track change.

In addition, a temporary cache should keep the sample rates of recently played tracks, in hopes that when previous tracks are played, if messages did not emit, at least the app can get the data from the cache.

Sample rate should not change if system detects a new sample rate that is lower than the current one, if track is same.

May help resolve issues in #17, #10, #8, #3

A big thank you especially for @hatemosphere for the recent sponsor!
Also thanks to sponsors @ckortekaas, @luisrjr and an anonymous sponsor for sponsoring this project earlier!

Thanks for all your support!

Additional message detection

• An additional detection route via Core Media messages have been implemented.
  • aimed at 192kHz/96kHz switching to 48kHz issue
  • there was an earlier iteration with Core Audio messages instead (build 4), but omitted due to message only showing up for 192kHz but not any lower sample rates.
• abandoned pause/play issue due to #9 side effect
• App now shows version and build to hopefully make releases less ambiguous?
  • build 3 = v1.1 beta 1
  • build 5 = v1.1 beta 2
  • build 4 = not released in binary form, but can be compiled if wished to (86edbda)

Failure to trigger may still occur.

What to test: see if high sample rate audio like 192kHz ones are either switching correctly or not switching (i.e. no 48kHz sightings)

Some improvements

• now uses private API 😨 (MediaRemote)
• instead of timer based periodic checking, it should now only check console every time theres a play/pause event (still buggy. some times it doesn't trigger)
• bug fix (#6, #5, #3, #1)

Please do expect that sometimes the sample rate may not switch. The new checking method is still rather flaky.

What to test: if audio above 48 kHz (such as 96/192kHz) correctly switches + that it shouldn't drop back to 48 kHz.

The first release.

Please read the README carefully, before use.
Tested on macOS 12.2 & 12.3.1, on Intel Macs, with a USB-input Amplifier as the audio device.

App is signed and notarised.