Native macOS frontend for projectM 4 — would you want it, and where should it live?

[seitzbg]

Hi all — I've built a native Mac app on top of projectM and I'd like to sort out with you whether it belongs in the project before I put it anywhere public.

What it is:

• A SwiftUI/AppKit app that drives libprojectM 4.1.7 through the public C API. The engine is linked dynamically and I haven't touched any engine source.
• Audio comes from whatever else is playing on the Mac via ScreenCaptureKit, resampled to feed the presets, with an input meter so you can see what's actually reaching the visualizer.
• A preset browser with import, search, favorites, auto-cycling and fullscreen.
• A little GPU "beat scope" for checking that what you see lines up with what you hear, plus an adjustable delay to compensate for Bluetooth/output lag.

Honest limitations: macOS 14+, and I've only validated on Apple Silicon so far. It uses the OpenGL path, which I know Apple has deprecated — that's a known constraint, not the end state. Intel and notarized distribution aren't done yet.

Your README keeps the library repo library-only and points frontends to their own repos, so I didn't want to just open a PR. What would you prefer?

• a new frontend repo under the projectM org that I contribute to,
• I keep it in my own repo and you link it from the library README, or
• whatever else makes sense to you.

It needs no changes to libprojectM. Happy to share the source, build scripts and tests whenever it's useful. Thanks for the engine — it's been great to build on.

[seitzbg]

Small update: I went ahead and put it in its own repo so it's easy to look at — https://github.com/seitzbg/projectm-macos. It's standalone, doesn't touch libprojectM, and it's MIT licensed. The classic MilkDrop presets and textures aren't bundled, since those repos don't carry a clear redistribution license; there's a small script that pulls them from upstream at pinned commits instead. If you'd rather it live under the org, I'm glad to move it, or you can fork it from there.

[kblaschke]

Good to see another native integration! Looks really nice.

You're right with your observation, with the 4.0 release, we've split up the core projectM library and the various frontends and side-projects into their own repositories to keep the main repo small (as it's a reusable library) and many people probably don't want to build additional executables and requiring more dependencies than absolutely necessary. It also makes it easier to package for Linux distros, Homebrew and vcpkg.

Regarding the location where the project lives: we don't have a clear stance on this, but generally I'd say if its a personal project/integration, the author should keep the repository under their own user or organization. We're mostly working on the core library and a few apps and plug-ins (e.g. for GStreamer) which mainly serve as examples or reference implementations.

The only thing I would suggest is giving the application some name that doesn't make it look like it's made by the projectM team itself, and especially doesn't clash with any existing app name (e.g. our own macOS app written in C++ uses the bundle name projectM.app). This has the simple reason that users are often not aware that the app isn't being developed by us, and come here or on our Discord and ask us questions or want us to fix a certain bug - which we can't.
This is currently a concern with the Android app, which is being developed and sold in the Play Store by a former projectM developer, Peter Sperl, but wasn't open-sourced yet (might happen some time in the future though) and is still being privately developed by him. We sometimes have users come here or on Discord, being angry and demanding their money back if the app doesn't work for them - and are even angrier if we send them away as we can't help.

While the name "projectM" itself isn't trademarked (and other, unrelated projects, software and others, also use it) it would be nice to keep it for the core library and any app directly developed by the projectM team, and give other apps a distinctive name. We can't enforce it though, and thus only ask this politely.

Regarding OpenGL - it's been deprecated for almost ten years now, since Metal was released. I'm not seeing Apple removing GL support anytime soon since too many old (and even new) apps use OpenGL, which is less capable but easier to use than Metal. If OpenGL is or becomes a concern though, libprojectM (needs current master or the upcoming 4.2 release) can be used with ANGLE to translate OpenGL ES calls to Metal. Only have to compile projectM with GLES, and then create a context with ANGLE and use the external GL resolver callback to pass the proper function pointers to projectM.

The next major release of projectM - no ETA yet, not even started any work on that - will focus on porting the library to support more modern APIs like Metal and Vulkan. There are a number of problems to be solved, especially the shader transpiler which requires lots of quirks and tricks to make some presets run as they depend on undocumented/undefined DX9 behaviour like returning proper values for taking a square root of negative numbers and other oddities. Thus, we might have to implement some kind of shader preprocessor to add those quirks in the HLSL code before transpiling the final shader to GLSL, SPIR-V, Slang or WGSL without having to keep the slow "hlslparser" HLSL-to-GLSL transpiler from Unknown Worlds Entertainment.

Once we start the implementation/refactoring required for this, we'll certainly need some more experienced macOS dev with some Metal knowledge to implement the renderer - Vulkan should suffice for other platforms, and GL can probably still be supported.