djdron
projectM v4.0.0
https://github.com/projectM-visualizer/projectm/releases
Target Audience: Developers
This release is mainly aimed at developers integrating projectM into their applications. The main focus of this major release was to provide a new, stable API based on pure C functions, which will make it easier to create bindings for other languages as well as using it as a shared library. We also fixed many crashes and improved the overall visual quality and compatibility of presets to some degree.
The API will remain stable and forward-compatible until the next major release. Any changes made will only include new functions, so the ABI will always stay forward-compatible. This means an application built and linked against a specific 4.x version will build and run with any libprojectM with a major version of 4 and the same or higher minor version. If an application uses libprojectM as a shared library, no relinking is required at all - simply swap the library file with the new one and it should work.
libprojectM 4.1.1 is out, with massive visual upgrades. Now is a good time to update!
@djdron hello? Will projectM for Foobar2000 ever be updated or can we consider this project dead?
@djdron hello? Will projectM for Foobar2000 ever be updated or can we consider this project dead?
Hello @Kappa971 , it will be released after SDL2 frontend repaired & steam version released.
Hello @Kappa971 , it will be released after SDL2 frontend repaired & steam version released.
Actually, there's no need to wait for the SDL2 frontend to be done. It's a completely separate project now and has no effect on the Foobar2000 plug-in, except for using it as a reference. libprojectM has a stable API since 4.0.
The only reason to wait a little more might be the additonal render-to-texture functionality we'll be releasing in v4.2 of libprojectM if that's easier than directly rendering to a native surface. It's already in master, so you could easily start using it already if you don't want to wait for the release.
There are plenty of resources, not perfect, but given how simple the API is, it should suffice:
Most API functions are getter/setter functions replacing the previous settings struct.
If there's still something unclear, e.g. regarding OpenGL, just DM me on Discord, I'll surely be able to help.
I'm using foobar2000 for Mac.
Foobar version: 2.24.1 Mac OS: 15.2, Apple Silicon M1
Unfortunately https://www.foobar2000.org/components/view/foo_vis_projectM doesn't work. I get the following error when I try to install this component:
Component installation error: This component does not support Mac OS.
According to https://github.com/projectM-visualizer/projectm?tab=readme-ov-file#macos it should also work on Mac OS.
The projectM library definitely works on macOS. I don't think that the foobar2000 projectM plug-in was ever built or released for macOS (I guess djdron is in the same boat as me and doesn't own a Mac to build and test it on), so someone else would possibly have to take this task. It's basically the same situation we have with projectM' frontends, that there's currently no one who can test, package and release it on macOS. Apple is really a bad vendor in that regard - you can't emulate or virtualize their stuff, neither easily nor legally. And you need a paid subscription to their developer program as well.
I'm a Mac with M chip owner, but I have no time to re-build this plugin even for windows with newer projectM version. Because I added some features which was not exist in original projectM like reading visualizations files/textures from zip archive. And now after huge projectM refactoring/upgrade I need to re-implement this. Also all ARM binaries for MacOS with M chips must be signed (notarized). So I see only plugins compiled by foobar2000 author are exist (signed). Unsigned binaries only for x86-64 may be launched in latest MacOS'es.
Because I added some features which was not exist in original projectM like reading visualizations files/textures from zip archive.
How about creating a new feature request or PR in https://github.com/projectm-visualizer to support your use case? After that, rebuilding would be easier and more appealing for you.
That's actually planned, but we didn't create a ticket for it yet.
I've done that now, but no ETA on when this will be released. I'll see if I can also squeeze it into the 4.2 release though.
https://github.com/projectM-visualizer/projectm/issues/870