Overview

This is the latest foobar2000 v2.0 SDK.

Unlike the SDK released in August 2022, it's based on latest foobar2000 v2.0 source code and publishes ALL new features available for components.

Most notably, if you're upgrading from the August SDK, you might want to look at fb2k::coreDarkMode, see below for details.

This SDK, while retaining the ability to build components for v1.5 & v1.6 series, allows you to utilize all features of foobar2000 v2.0 series.

This most notably includes:

Support for x64 and ARM64 architectures.
Dark mode support.
metadb v2
library_index for optimized library searches
New filesystem API with new file stats struct, access to file creation time, etc.

Backwards compatibility

Since many developers will wish to support both new and old foobar2000 for a while, this SDK defaults to FOOBAR2000_TARGET_VERSION of 80 (foobar2000 v1.5/v1.6). With this target version, you can still detect and utilize foobar2000 v2.0 APIs without actually requiring foobar2000 v2.0.

32-bit version of foobar2000 v2.0 remains capable of running all available components, though performance of playlists and media library viewers may be inferior until the component is updated with foobar2000 v2.0 in mind. 64-bit (x64, ARM64) versions obviously require new builds of components.

Non-x86 architectures

You can now build components for x64 and ARM64 architectures, which is necessary to get them loaded into relevant builds of foobar2000 v2.0.

It's encouraged to keep FOOBAR2000_TARGET_VERSION at 80, so x86 32-bit build of your component works with both old and new foobar2000, while x64 & ARM64 ones, otherwise built from the same source, work in new foobar2000.

audio_sample

64-bit builds of foobar2000 have audio_sample defined to double (64-bit float), contrary to 32-bit in legacy 32-bit builds.

PFC audio_math methods have been modified to take either, as well as re-optimized for all target CPU architectures.

Note that 64-bit processing DOES NOT improve audio quality. It only allows bitexact passthru of exotic formats and valid results of Binary Comparator with such formats.

Dark mode

All foobar2000 dark mode support code, ugly as it is, is now available for anyone to reuse freely, as a part of libPPUI.

I hope that other software authors find it useful, not having to repeat my mistakes to reach usable state.

Helpers exist (see helpers/DarkMode.h) to detect and conditionally enable dark mode depending on foobar2000 settings, if running under foobar2000 v2.0 or newer (idle otherwise).

fb2k::coreDarkMode

Annoying side effect of using dark mode hooks is massive size growth of otherwise small component DLLs. Additionally, dark mode support code gets updated with bug fixes, which adds extra work for you.

This SDK introduces fb2k::coreDarkMode API, which offloads all dark mode support code to foo_ui_std's instance of libPPUI.

To utilize it, just replace your fb2k::CDarkModeHooks use with fb2k::CCoreDarkModeHooks.

Potential drawbacks:

You cannot debug dark mode issues or work around them on your end if foobar2000 dark mode code doesn't work properly with your UI
You're stuck with possibly outdated libPPUI if your users run old foobar2000 versions.

Dark mode in preferences

foobar2000 needs to know if your preferences page is dark mode compliant or not, applying dark/light mode to the whole dialog if necessary, to make the entire dialog appear consistent with the page content.

To accomplish this, alter your get_state() to combine its return value with preferences_state::dark_mode_supported.

metadb v2

Until foobar2000 v2.0, metadb preloaded all indexable track information on app startup.

This is no longer done, info is handled by SQLite; also partial info hacks (LargeFieldsConfig.txt) have been dropped as they're no longer necessary.

While old foobar2000 versions allowed zero-cost querying of track info objects (you'd get a reference to foobar2000's internal data object, without actual copying or malloc!), this is no longer possible, so code abusing the old system will slow down.

To work around this:

Absolutely avoid repeated info queries on the same track, make sure that whatever you're doing does only one query per track and reuses the result.
The new metadb_v2_rec_t structure contains all info about this track; methods that take it, such as formatTitle_v2_(), will not read from the database, so query once and pass the already fetched data to multiple title formatting function calls.
If you must make multiple title formatting calls yet don't want to use new methods, concatenate title formatting patterns and split output. You don't even need the new SDK for this.
When info from multiple tracks is required, check for metadb_v2 availability and utilize its methods to retrieve metadb_v2_rec_t info in batches.