projectM Visualizer
Replies: 6 comments 4 replies
-
|
I last tried this a few years ago. At that point the PI seemed hopeless. However, I had good luck running it on NVIDIA Jetson. It had the video power needed to run OpenGL. I managed to build a "headless" visualization box. If that's your aim, I can try to dig up what I learned to get that to work with no interaction (mouse/keyboard). |
Beta Was this translation helpful? Give feedback.
-
|
Clementine, as of now, uses a very old copy of projectM, with their own patches. I hope we can get a patch up in their repo so it uses the new API and shared library. projectM itself will run, but many presets have performance issues. Two reasons:
We're getting many requests about the Pi in the last weeks, so I may create a build for the latest RaspiOS for you to play with. Will finish the UI of the SDL frontend though, as it'll make it easier to change settings. |
Beta Was this translation helpful? Give feedback.
-
|
I am surely interested in a Pi specific built and would volunteer as tester .... |
Beta Was this translation helpful? Give feedback.
-
|
I've been using projectM on a rpi4 or two years now, currently on RaspiOS/Bullseye:
all in all - while it does work now, I'd say the bookworm raspiOS will be a better starting point because of the updated SDL. combined with the recent improvements maybe it's time to make a curated list of resource friendly presets for small sbcs later this year? will definitely look into this again |
Beta Was this translation helpful? Give feedback.
-
|
Yes, RPi 3 only has a GLES 2 GPU. Not much we can do here, as we're limited to the hlslparser generator output formats, which only support version 100 and 300 ES shader syntax. The version 100 shader language doesn't even support the required texture samplers and some other mandatory rendering details, so we can't make it work (only Milkdrop 1.04 presets, but that would require maintaining a separate renderer as the OpenGL commands are different). Rendering performance will always be an issue, as many modern presets were written with desktop CPUs and GPUs in mind, especially the shaders can be very demanding. The CPU side can be mitigated somewhat by reducing the per-pixel mesh size resolution. The SDL frontend has a very high default value of 200x125, while Milkdrop uses 48x32 by default, which will probably be the default setting in future projectMSDL versions as well. Plus, we can't really perform anything on the CPU in parallel due to fact that the expression code needs to be executed strictly serially to prevent memory issues and make presets work as intended. I can post an update here if there's a new version worth testing. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, thanks for all your work. Im also very interessted in the RPi4 version, thx |
Beta Was this translation helpful? Give feedback.
-
|
Hi folks, |
Beta Was this translation helpful? Give feedback.
-
|
Running on a Pi is a bit tricky, as well as on WebGL. We're working on the GLES implementation, which is behaving quite differently than the OpenGL Core profile. In the future (which will become the 5.x release series), we're going to add Vulkan/Metal support, so things should become a bit easier (and more performant) on embedded platforms as well as desktop. For VLC, I've opened an issue which I'll be working on after the 4.1 release, so future VLC releases should include an out-of-the box experience with the newest projectM version, including the rewritten renderer and preset parser. Clementine is basically dead and no longer being maintained. There's a fork though, Strawberry, which sees improvements and releases, though they've seemingly removed projectM from it. It might be worth a short reintegrating the 4.x release into it, but at least my time is limited so I can't currently do that. Thing is, we're basically dependent on other developers to write third-party integrations. In the past, projectM's C++ "API" wasn't really convenient or stable, so adoption was slow or limited to a specific version (e.g. Clementine copied the libprojectM code to their codebase and patched it for their purposes, but never actually updated it). Plus, versions before 4.0 did not support building a shared library on all platforms, which also makes it harder to use (and update). This issue was also fixed in the 4.0 release, so libprojectM now has a stable, backwards-compatible API only using C functions and builds as a shared or static library on all major desktop operating systems. We'll be looking forward to see it being adopted in more players due to this change, even in closed-source players, which can now also properly use projectM on Windows without violating the LGPL. |
Beta Was this translation helpful? Give feedback.
-
|
Recently got my hands on a Pi 5 and tested the latest development sources on it. Despite a few general fixes required to make it build, it works very well. The overall hardware limitations still apply of course, as the GPU is faster but stil very limited in regards to shader units, so higher resolutions (>1080p) will tend to run slowly. Reducing the per-point mesh resolution also takes some strain from the CPU. During transitions, there are occasional slowdowns as two presets render at the same time, plus an additional blend shader on top, so one should either select presets which generally run fast or disable smooth transitions to mitigate it. With a resolution of 720p projectM runs very smoothly, even on the Pi 4. Will set up a Pi-based build server soon, so we can build binaries on it and later also release DEB packages for use with the official Raspberry Pi OS. Ideally, getting the packages into their repository would be best for user experience, we'll see how this would be possible. |
Beta Was this translation helpful? Give feedback.
-
|
Hello Kai,
Greetings from german, Thanks for the information. I really would love a
release for PI 4/% for raspian OS. I would really Donate for some beer or
coffee. :)
Kai Blaschke ***@***.***> schrieb am Mi., 24. Jan. 2024,
10:15:
… Recently got my hands on a Pi 5 and tested the latest development sources
on it. Despite a few general fixes required to make it build, it works very
well. The overall hardware limitations still apply of course, as the GPU is
faster but stil very limited in regards to shader units, so higher
resolutions (>1080p) will tend to run slowly. Reducing the per-point mesh
resolution also takes some strain from the CPU. During transitions, there
are occasional slowdowns as two presets render at the same time, plus an
additional blend shader on top, so one should either select presets which
generally run fast or disable smooth transitions to mitigate it.
With a resolution of 720p projectM runs very smoothly, even on the Pi 4.
Will set up a Pi-based build server soon, so we can build binaries on it
and later also release DEB packages for use with the official Raspberry
Pi OS <https://www.raspberrypi.com/software/>. Ideally, getting the
packages into their repository would be best for user experience, we'll see
how this would be possible.
—
Reply to this email directly, view it on GitHub
<#697 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AKAZJIMOGJ4NLF2AVO4XA4DYQDGLFAVCNFSM6AAAAAAUNP7OD2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DEMZQGIYTA>
.
You are receiving this because you commented.Message ID:
***@***.***
.com>
|
Beta Was this translation helpful? Give feedback.
-
Hi there, everybody
I am wondering if anybody got ProjectM working on a Raspberry Pi.
I am using a Pi 3B+ Bullseye and read that Clementine / QmmP would be supporting ProjectM ??
Which they apparently don't do ?? Please confirm.
Is there any other way to get this running on a Pi (possibly a how to hint available) ??
any feedback much appreciated
Gunter
Beta Was this translation helpful? Give feedback.
All reactions