Well that was fast – not long after releasing the update two bugs have been found, which this update addresses:

• in some cases output settings wouldn’t properly load when not using the Default output
• while stopped, Hog Mode could become selectable in Settings while the Default output is selected

The update is now available through the Mac AppStore!

Hi there! The long wait is over, Colibri 2.0 is now available through the AppStore!

Hello there! Thanks for checking in, I’ve just handed over the update to Apple for an extensive review, which could take anywhere from a few hours to a few days – although personally, I’m hoping for a few hours of turnaround time.

Once the review is done, it should take a few minutes for the update servers to notice the new version of Colibri – followed by your Mac installing the update (if auto-update is enabled) or just getting notified by macOS once the update is ready for download. I’ll put up a post when the update gets verified – hang tight!

Hi there and thanks for checking in!

As we are nearing the end of the update, Colibri had one area that desperately needed attention since the initial conception – loading multiple files at once would cause hiccups, even more so with large amount of nested directories: loading anything above a few gigabytes would cause Colibri to beachball for even up to many minutes, depending on the folder architecture and the files therein.

As of a few hours ago, Colibri just got a brand new, optimised folder crawler that improves upon the previous one in terms of error handling – such as guessing missing cue sheet contents based on initial content discovery -, but also does so at breakneck speeds (compared to the old version, to say the least). To put it into numbers, a mixed folder of cue sheets, tracker music and m3u playlists weighing just a bit above 69 GB is fully processed and loaded within approximately 30 seconds.

Now, as many of you may already know Colibri isn’t yet suited to be a Library-based player and loading that many songs is not ideal – but it can certainly be done. The under-the-hood optimisations also greatly speed things up in the RAM Disk department as now flushing the whole playlist to the RAM can be done as fast as the storage can be read.

Despite the feature freeze I did manage to sneak one small, heavily requested feature in, which is to keep Colibri’s main window floating above other apps! This is a switchable option available from Preferences > Playlist:

More to come real soon, stay safe and please look forward to the update!

In the past few days I’ve searched high and low for a solution that would allow me to release the update with an Apple Silicon native binary – however, as noted in the previous post it was being held back by BASSZXTUNE not being available for M1 Macs. But I couldn’t let it go, especially after making you wait for so long.

Since a few hours ago, the proof-of-concept has been implemented into the update and am happy to report that Colibri 2.0 will have native Apple Silicon support – which means that you’ll be able to run Colibri natively on your shiny new M1 Macs! Here’s a screenshot of Activity Monitor while the development version of Colibri is running:

There is a tradeoff in making all this happen though:
when running Colibri on Apple Silicon hardware, ZXTune will be unavailable. This means that the more exotic tracker formats (for which ZXTune via BASSZXTUNE provides decoding support) will not open and show an unsupported error message.

This change does not affect Intel-based Macs, ZXTune will continue to operate under the x86_64 architecture as expected.

Until a compatible version of ZXTune and BASSZXTUNE is available, Colibri won’t be able to use this library on Apple Silicon machines. I am actively working on remedying this situation and will let you know if I have a viable solution.

In other news I’m still spending all my free time on the update and am getting there. More to follow shortly!

Hi there! Thanks for checking in and for your continued support!

Colibri has now entered a ‘feature freeze’ state of sorts, meaning that from today onwards I’m making sure to the best of my capabilities that the update delivers on all promises made in the previous posts.

Since the last post, I’ve been doing a considerable amount of work on the way Colibri works alongside and in coordination with CoreAudio to handle devices and am happy to report that the Default output with per-device profiles seem to be working rather nicely, here is a sneak peek of the new Output section in Preferences in action: the Default output is set in Colibri and when I change the default output in macOS, Colibri instantly loads the saved options for said device and updates the interface – it does this by ‘subscribing’ to relevant CoreAudio change events (and playback is resumed from the same spot during playback). As you can see, even though the output is reported as being “1: Default”, Colibri knows which is the actual audio output that is being used:

I did plan on releasing Colibri 2.0 with native Apple Silicon support for the M1 Macs – but sadly, three libraries that Colibri uses are not compatible with Apple’s ARM chip. I did manage to acquire the source code and build a compatible version of two of said libraries – but sadly, the third module (BASSZXTUNE) is not currently compatible and according to the author, it is currently at lowest priority to get it working. As I do not wish to stall the update any further I’ve decided to ship the update using the current x86_64 architecture and decide what to do with it in the near future.

In other news a long-standing bug has been fixed that caused the currently played track to not become highlighted in some cases along with some smaller fixes.

I do aim to release it as soon as I can, please bear with me!

Hi again and thanks for checking in!

February has been a busy month that saw a lot of progress on Colibri 2.0 – this was the time when most of the things mentioned in the previous report have been implemented and polished.

Along with those, there were some notable changes that I feel like pointing out:

• Preload trigger logic has been redone to fire under all known conditions (for gapless playback)
• Title bar should properly re-align itself to be in center at all times, without any jitter
• Drastically reduced draw calls to the Title Bar update methods which should save anywhere between 1-1,5% CPU on slower Macs
• UI elements such as buttons are now properly vector-based and draw themselves accordingly
• Fixed two crashes that belonged to FLAC embedded album art reading and playlist row drawing
• There is now a giant “emphasised” clickable play/pause button that reflects the playback state and is essentially showing the reverse as to what the usual play/pause button shows: the idea is that pro and theatre environments need clear and distinctive state feedback even from further away. This has been asked of me multiple times and it is now coming with the update. It is switchable with the default option being ‘off’. Check it out at the Playlist settings!
• Network streams will now properly show the bitrate of the stream being played
• The playlist grid color bug that was reported a few weeks back has now also been resolved
• …and just a few minutes ago I’ve finished adding Default System Output support! You can now have Colibri use and follow the audio output device set in System Preferences > Sound > Output or using the Speaker icon in the Menu Bar of macOS at the top of the screen. This has been long time coming and was quite a challenge: as you know, Colibri does automatic sample rate switching and while the ‘Default’ audio output has been available for some time, the moment you select it as the desired output most of Colibri’s internal logic simply goes off the rails. Why? It is really simple: the ‘Default’ audio output device does not report supported sample rates (frequencies), which means Colibri is not able to switch the rate as the currently (and upcoming) song requires it to do so. It also has no ‘driver’ descriptor so essentially CoreAudio reports nothing about it. Ultimately, had to think a bit outside the box for this one but I’m happy to report that based on the tests I’ve been doing up until now, the ‘Default’ output works as expected with automatic sample rate switching! And yes, switching to your AirPods or other wireless headphones during playback does work without issues.
• As an added benefit, the work that went into the ‘Default’ audio output demanded that I re-engineer the sample rate switching logic and thus for ‘regular’ users the sample rate switching should be near-instantaneous – as there are some ‘slower’ DACs that take almost a second to switch sampling rate with the older implementation. So whether you consider using the ‘Default’ output device or not, this is a win-win for everybody!

As for the dreaded question: when will I release the update? There is still a bit more work to be done on the Output section of Colibri’s Preferences that involves mainly the per-device profile implementation. I’ll be sure to post when I wrap that one up – please bear with me!

I did hope to release the update at the end of January, but I still have a bit of work to do in order to not disappoint the lot of you who have been waiting for this for more than a year now. Highlights since the last report:

• RAM Disk support with automatic playlist management
• Loop Menu has been added to the main window, next to the EQ button
  it is also gone from the Preferences > Playlist section
• New loop/repeat options have been added
• Per device options that can be saved permanently:
  • DoP sending mode
  • DSD DoP treshold: if your DAC only supports DSD64 then you can tell Colibri to use PCM for anything above that
  • PCM Bypass
  • Separate volume controls for Device and Colibri’s mixer output
  • DSD silence multiplexing: eliminate most of the annoying pops during DSD track change when using DoP/DoPA mode
• Seek bar now has FPS controls: yes, it’s ridiculous but it is a thing – you can now control how many times the playhead position is updated and animated. Why? To save system resources.
• Redraw cycles have been reconstructed: Colibri uses even less CPU since the last post (same machine that saw 5-7% usage is now down to 2-3%)
• Bit Rate column is now available in the Playlist: it is called ‘kbps’
• Volume and Seek Bar knobs can be turned off for a sleeker look

I need a bit more time to polish all the rough edges of the per-profile device feature – after that, a final test run and hopefully I can finally release the update. It will be marked as the 2.0 version – please bear with me!