Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Preview of next-gen foobar2000 SDK (Read 8847 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Preview of next-gen foobar2000 SDK

Introducing foobar2000 SDK with libPPUI
Download: https://www.foobar2000.org/SDK
Now available on the main website - old SDK available as the 'backwards compatible version'

What is libPPUI?
libPPUI consists of:
  • All code from "SDK helpers" modules in old foobar2000 SDK versions that was not in any way specific to foobar2000.
  • Never-published-before utility code from Default User Interface, including full source code of CListControl which is used to implement the default playlist view.
Unlike old foobar2000 SDK helpers, libPPUI can be easily used in any C++ program for Windows desktop.
libPPUI is available under a non-restrictive license (zlib license), can be reused in free or commercial programs, open or closed source, without copyright disclaimers - as long as you don’t redistribute source claiming that you wrote it.

Compatibility with existing source code
Because code from old "helpers" got moved to new locations, your existing code will likely require editing. In most cases, fixing #include paths will be enough.

Compatibility with old foobar2000 releases
Nothing changed here, this SDK can produce components compatible with 1.3 series and newer.

Highlights of interesting classes for reuse in other apps:
CListControl - Win32 list control with embedded editboxes, buttons, group headers, etc. This is the class that drives the default playlist view of foobar2000 0.9.5 and newer.
CMiddleDragImpl - Implementation of middle click scroll for any win32 control (treeview, listview, custom controls).
CEditWithButtons - Embed buttons in an editbox.

Note that foo_sample component has been fully updated for libPPUI; a CListControl demo has been added.

Have fun.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #1 –
Hm... I'm a bit confused with new `metadb_handle::get_info_ref` method.
It seems that info that info returned by `metadb_handle::get_info_ref` is:
1. Constant: can't be modified via `set_*` methods.
2. Non-updateable: data will remain the same, even if some tags were modified.

Since `metadb_handle::get_info` was declared as `deprecated`, I'm trying to replace it with the new API, but I'm not sure how to workaround these two new characteristics.
The scenarios I'm trying to (re-)implement:
1. Modify associated file tags in metadb_handle (via `file_info::meta_*` methods).
2. Keep the same behavior as it was previously for the `file_info` constness (I'm might be mistaken though that `file_info` from `get_info` was actually dynamic).

Thanks in advance! =)

Re: Preview of next-gen foobar2000 SDK

Reply #2 –
get_info_ref() is old subject really, 1.3 era change.

It accesses metadb-managed file_info instances in a lockless/noncopying way.
With get_info(), a lock+copy cycle occurred - slow for lots of items.
With get_info_locked(), caller had to ensure metadb lock for the duration of whatever the caller does with the data.
Both were problematic for multi-threaded processing of metadb info.
With the new function, you can efficiently obtain a reference to a snapshot of the current state, which can be then accessed without any locking or copying, from any thread.

Not sure how/why you want to modify metadb contents. None of these functions were ever meant for this.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #3 –
Quote from: Peter on
Not sure how/why you want to modify metadb contents.
It was used to modify metadata tags. Same usage as "Properties" context menu for track in the playlist.
Is there a better/proper API?

Re: Preview of next-gen foobar2000 SDK

Reply #4 –
Sample code please, I'm not sure if I understand correctly what you did before.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #5 –
https://gist.github.com/TheQwertiest/e08460f6da620107ddf4fad38d5b9dc8
^ this is just an example, and not the code that is actually used in my component.
The method in my component works on handle list and can update arbitrary number of meta tags, but the fb2k API usage is mostly the same.

Re: Preview of next-gen foobar2000 SDK

Reply #6 –
file_info_impl fileInfo = handle->get_info_ref()->info();

... and the rest doesn't need changing.

The result is the same as before, only with better performance if used in multiple threads due to less locking.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #8 –
No problem, happens to all of us...
The reasoning of this change is non obvious, until you dig into specific usage cases... Selection Properties and Library Search which need to go over lots of info - preferably in multiple threads - benefit the most.

Frankly the old API still works and will probably never stop working.... as it would make some of existing >10 year old DLLs in circulation stop working.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #9 –
New version posted: SDK 2019-07-08 ( see first post )
Added Tree View multi-selection tool from Album List.
CListControl improvements, added new ready-to-use CListControl flavours that do not need subclassing.
Added two new CListControl use demos to foo_sample.
Microsoft Windows: We can't script here, this is bat country.
 

Re: Preview of next-gen foobar2000 SDK

Reply #11 –
New version posted, with bug fixes in libPPUI classes and dynamic main menu item example in foo_sample.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #13 –
Seems to be an issue with the latest v1.6 inside popup_message.cpp. Some usages of popup_message_v3 aren't guarded with

Code: [Select]
#if FOOBAR2000_TARGET_VERSION >= 80

which causes compilation to fail if you're targetting v1.4

Re: Preview of next-gen foobar2000 SDK

Reply #14 –
Another minor v1.6 issue. Debug builds on VS2019/v142 toolset fail with this addition to SDK/dsp.cpp remove_bad_chunks

Code: [Select]
#if PFC_DEBUG
			uDebugLog() << "Removing bad chunk: " << chunk->formatChunkSpec();
#endif

Code: [Select]
D:\a\foobar2000-sdk\foobar2000-sdk\foobar2000\SDK\dsp.cpp(89,69): error C2678: binary '<<': no operator found which takes a left-hand operand of type 'uDebugLog' (or there is no acceptable conversion) [D:\a\foobar2000-sdk\foobar2000-sdk\foobar2000\SDK\foobar2000_SDK.vcxproj]

edit: probably related to having conformance mode enabled.

Re: Preview of next-gen foobar2000 SDK

Reply #15 –
Re popup_message_v3,
There are cases when new APIs may be used by components targetting old foobar2000, with a fallback mechanism if running under old foobar2000, that's why I'm not #ifdef'ing these out. I'll think of some better solution to check for these at compile time.
Re uDebugLog(),
Change to FB2K_console_formatter() and move on, I just did that for the next update.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #16 –
Hi All,
Noticed problems with the latest SDK:
1. There are no correct paths to the ATLHelpers folder
2. in SDK\foobar2000.h should be:
// # define FOOBAR2000_TARGET_VERSION 79 // 1.4
#define FOOBAR2000_TARGET_VERSION 80 // 1.5, 1.6

Besides, a pretty good job!

I also have one suggestion, maybe set VS 2019 by default (PlatformToolset: v142) and remove the fixed Windows SDK 8.1?
my test projects build correctly with VS 2019 and Windows SDK 10

Re: Preview of next-gen foobar2000 SDK

Reply #17 –
Setting 2019 would require him to use 2019 in the first place.

Re: Preview of next-gen foobar2000 SDK

Reply #18 –
[already reported]

Re: Preview of next-gen foobar2000 SDK

Reply #19 –
Quote from: komires on
Hi All,
Noticed problems with the latest SDK:
1. There are no correct paths to the ATLHelpers folder
2. in SDK\foobar2000.h should be:
// # define FOOBAR2000_TARGET_VERSION 79 // 1.4
#define FOOBAR2000_TARGET_VERSION 80 // 1.5, 1.6

Besides, a pretty good job!

I also have one suggestion, maybe set VS 2019 by default (PlatformToolset: v142) and remove the fixed Windows SDK 8.1?
my test projects build correctly with VS 2019 and Windows SDK 10

1) ATLHelpers is dead. Long live libPPUI.
2) The SDK defaults to making components that work from foobar2000 v1.4 up, as documented. Changing the #define makes built components not load in 1.4 series.
Microsoft Windows: We can't script here, this is bat country.

Re: Preview of next-gen foobar2000 SDK

Reply #20 –
Quote from: Peter on
Quote from: komires on
Hi All,
Noticed problems with the latest SDK:
1. There are no correct paths to the ATLHelpers folder
2. in SDK\foobar2000.h should be:
// # define FOOBAR2000_TARGET_VERSION 79 // 1.4
#define FOOBAR2000_TARGET_VERSION 80 // 1.5, 1.6

Besides, a pretty good job!

I also have one suggestion, maybe set VS 2019 by default (PlatformToolset: v142) and remove the fixed Windows SDK 8.1?
my test projects build correctly with VS 2019 and Windows SDK 10

1) ATLHelpers is dead. Long live libPPUI.
2) The SDK defaults to making components that work from foobar2000 v1.4 up, as documented. Changing the #define makes built components not load in 1.4 series.

1) * libPPUI requires ATL (paths to the foobar2000\ATLHelpers\ folder are not set correctly)
    * foobar2000_sdk_helpers still requires ATL (paths to the ..\ATLHelpers\ folder are not set correctly)
    * foo_sample still requires ATL (paths to the ..\ATLHelpers\ folder are not set correctly)
2) foobar2000\SDK\popup_message.cpp does not compile for
#define FOOBAR2000_TARGET_VERSION 79 // 1.4

hence now to compile we need to change:
//#define FOOBAR2000_TARGET_VERSION 79 // 1.4
#define FOOBAR2000_TARGET_VERSION 80 // 1.5, 1.6


In my case, in order to compile the plugin sample from the SDK, I had to:

1. Download and unpack the SDK 2020-07-28

2. Download latest WTL from https://sourceforge.net/projects/wtl/files/WTL%2010/
   and unpack to the foobar2000\ATLHelpers\

3. Edit the file: foobar2000\helpers\foobar2000_sdk_helpers.vcxproj
    adding the section (important!: after last </PropertyGroup>):
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
    <IncludePath>..\ATLHelpers\Include\;$(IncludePath)</IncludePath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
    <IncludePath>..\ATLHelpers\Include\;$(IncludePath)</IncludePath>
  </PropertyGroup>

4. Edit the file: libPPUI\libPPUI.vcxproj
    adding the section (important!: after last </PropertyGroup>):
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
    <IncludePath>..\foobar2000\ATLHelpers\Include\;$(IncludePath)</IncludePath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
    <IncludePath>..\foobar2000\ATLHelpers\Include\;$(IncludePath)</IncludePath>
  </PropertyGroup>

5. Edit the file: foobar2000\foo_sample\foo_sample.vcxproj
   adding the section (important!: after last </PropertyGroup>):
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
    <IncludePath>..\ATLHelpers\Include\;$(IncludePath)</IncludePath>
   </PropertyGroup>
   <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
    <IncludePath>..\ATLHelpers\Include\;$(IncludePath)</IncludePath>
   </PropertyGroup>

6. Edit the file: foobar2000\SDK\foobar2000.h
   and change the lines:
   #define FOOBAR2000_TARGET_VERSION 79 // 1.4
   // #define FOOBAR2000_TARGET_VERSION 80 // 1.5, 1.6
  
   to:
   // #define FOOBAR2000_TARGET_VERSION 79 // 1.4
   #define FOOBAR2000_TARGET_VERSION 80 // 1.5, 1.6

Re: Preview of next-gen foobar2000 SDK

Reply #21 –
If the foobar2000\ATLHelpers\ folder previously contained additional foobar2000-specific classes,
now you can safely allocate it to WTL-only by setting the correct paths for *.h files in projects

Re: Preview of next-gen foobar2000 SDK

Reply #22 –
It is advisable to manually add the relative or full path to your installation of WTL\include to every project which uses it. Even better if you keep a copy of WTL in your project tree, so you won't have to reset your global settings every time you provision your source onto a new machine or VM.

ATLHelpers no longer exists. You should have deleted it when updating to the new SDK.

Re: Preview of next-gen foobar2000 SDK

Reply #23 –
SDK/titleformat.cpp won't compile with the latest VS2019 Preview. Just mentioning it because it will be "production" ready in a month or 2...

Code: [Select]
1>Z:\Git\foobar2000-sdk\foobar2000\SDK\titleformat.cpp(58): error C2102: '&' requires l-value
1>Z:\Git\foobar2000-sdk\foobar2000\SDK\titleformat.cpp(81): error C2102: '&' requires l-value
1>Z:\Git\foobar2000-sdk\foobar2000\SDK\titleformat.cpp(88): error C2102: '&' requires l-value
1>Z:\Git\foobar2000-sdk\foobar2000\SDK\titleformat.cpp(79): error C2102: '&' requires l-value
1>Z:\Git\foobar2000-sdk\foobar2000\SDK\titleformat.cpp(95): error C2102: '&' requires l-value

@musicmusic already "fixed" it some years ago for clang compatibility...

https://github.com/reupen/foobar2000-sdk-modified/commit/acfe19797c35f26154dcee3eb93b7de1d04bed3f#diff-8b775bfb871048598055ff68b9371c79