It stays on BackgroundWorkerSync::wait_for_bg_to_finish() and does not become the signal: https://github.com/projectM-visualizer/projectm/blob/master/src/libprojectM/BackgroundWorker.h#L43

Initially thought that it had to do with p8-platform removal and its conversion to std::unique_lock<std::mutex>, but even after this was removed from the Kodi addon came also the freeze, only then could the transfer of the audio stream continue to work. But the GL rendering got stuck.

Changed also temporary the Signal way to the C++11 way (http://www.cplusplus.com/reference/condition_variable/condition_variable/notify_all/) on BackgroundWorker.h but still brought the freeze.

I think somewhere becomes the void finished_work() call not done. Only ~1-2% of all test runs has worked without a freeze.

Unfortunately, my experience with the Lib is not good enough to directly recognize what the trigger is. Also error occurred with all existing * .milk files.

Error related to Kodi addon: https://github.com/xbmc/visualization.projectm

Fault on Linux 64bit (Ubuntu 19.04) with GL.

Command Line output direct before freeze:

[PresetFactory] url is /home/alwin/.kodi/addons/visualization.projectm//resources/projectM/presets/Bmelgren & Krash - Rainbow Orb Peacock (Unknowable Mix 5).milk
[PresetFactory] url is /home/alwin/.kodi/addons/visualization.projectm//resources/projectM/presets/Bmelgren & Unchained - Effort (Remix) - the city of glass that i live in, the coldness from my brother's skin nz+.milk
Successfull compilation of Warp
Successfull compilation of Comp

Backtrace:

#0  0x00007ffff7f8b3bb in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x7fffa86e61a0 <worker_sync+128>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x00007ffff7f8b3bb in __pthread_cond_wait_common (abstime=0x0, mutex=0x7fffa86e6120 <worker_sync>, cond=0x7fffa86e6178 <worker_sync+88>) at pthread_cond_wait.c:502
#2  0x00007ffff7f8b3bb in __pthread_cond_wait (cond=cond@entry=0x7fffa86e6178 <worker_sync+88>, mutex=mutex@entry=0x7fffa86e6120 <worker_sync>) at pthread_cond_wait.c:655
#3  0x00007fffa861997b in BackgroundWorkerSync::wait_for_bg_to_finish() (this=0x7fffa86e6120 <worker_sync>) at BackgroundWorker.h:43
#4  0x00007fffa861997b in projectM::renderFrameOnlyPass1(Pipeline*) (this=this@entry=0x5555590de9d0, pPipeline=pPipeline@entry=0x7fffffffd700) at projectM.cpp:396
#5  0x00007fffa861cba7 in projectM::renderFrame() (this=0x5555590de9d0) at projectM.cpp:310
#6  0x00007fffa8603d05 in CVisualizationProjectM::Render() (this=0x5555590e22b0) at /home/alwin/Development/Kodi/_Addons/bbb/visualization/visualization.projectm/src/Main.cpp:127
#7  0x00007fffa86069f0 in kodi::addon::CInstanceVisualization::ADDON_Render(AddonInstance_Visualization const*) (addon=0x5555594b7270)
    at /home/alwin/Development/Kodi/_Addons/bbb/visualization/visualization.projectm/build/build/depends/include/kodi/addon-instance/Visualization.h:694
#8  0x00005555562efca8 in CGUIVisualisationControl::Render() ()
#9  0x00005555562737de in CGUIControl::DoRender() ()
#10 0x00005555562845c6 in CGUIControlGroup::Render() ()
#11 0x00005555562737de in CGUIControl::DoRender() ()
#12 0x00005555562f65f4 in CGUIWindow::DoRender() ()
#13 0x00005555562fc535 in CGUIWindowManager::RenderPass() const ()
#14 0x00005555562fc920 in CGUIWindowManager::Render() ()
#15 0x00005555564a8b2d in CApplication::Render() ()
#16 0x0000555556555863 in CXBApplicationEx::Run(CAppParamParser const&) ()
#17 0x00005555561c524e in XBMC_Run ()
#18 0x0000555555c03075 in main ()

Trying to get rid of super ancient unsupported nVidia Cg framework and use standard GL shaders. The shaders in preset files are written in HLSL for DirectX. projectM used a toolkit from nVidia called Cg to handle them, but Cg is long deprecated and obsolete. I'm attempting to use https://github.com/Thekla/hlslparser to transpile from HLSL to GLSL on the fly, and it's close to working but has some syntax issues.

The main conversion is done in: https://github.com/projectM-visualizer/projectm/pull/26/files#diff-6df95f02d59c83baf42ed81c8668722a https://github.com/projectM-visualizer/projectm/pull/26/files#diff-f4b5c1904e3d8fa6c1248fe1ac843d79

This may be close to working but it has issues right now. Needs work.

I've just successfully 2.1.0 -> 3.1.0 projectM on NixOS: https://github.com/NixOS/nixpkgs/pull/70433

If you interested, minimal direct build dependencies for --emable-qt --enable-sdl are:

, autoconf
, automake
, pkgconfig
, SDL2
, qtdeclarative
, libpulseaudio
, glm

Some of them with dev parts probably, that is automated in tooling.

That libtool can be omitted - it is almost a sin doing on my part.

1. But, if SDL2, the build does not need SDL v1.

2. Personally, I did not found an option for Jack, maybe it is fully autodetects?

3. Default qt5 seems unneeded, 1) it is indirect dep of qtdeclarative, 2) indirect deps are ommited from builds in Nix tooling, so I can assure you that project builds with operational qtdeclarative provided alone.

Thank you for everything.

For more:

https://bugzilla.redhat.com/show_bug.cgi?id=1663047

But, as Vashirov has the bug, and he is the master of all orphans, redhat won't be of much help.

Problem: different systems and drivers have support for different versions of GLSL. ProjectM will not run unless the shader language matches the supported driver version.

As an example, my raspberry pi outputs:

INFO: GL_VERSION: OpenGL ES 2.0 Mesa 13.0.6
INFO: GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.0.16
INFO: GL_VENDOR: Broadcom
Failed to compile shader 'Vertex: v2f_c4f'. Error: 0:2(1): error: syntax error, unexpected NEW_IDENTIFIER
Failed to compile shader 'Fragment: v2f_c4f'. Error: 0:3(1): error: `in' qualifier in declaration of `fragment_color' only valid for function parameters in GLSL ES 1.00
0:4(1): error: `out' qualifier in declaration of `color' only valid for function parameters in GLSL ES 1.00

And @servimo reports the error: error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES
And again in #101

How can we support multiple versions of GLSL, ES and non-ES?

Also important: detect if GLES is needed automatically in configure.ac so that users don't have to do --enable-gles manually. A decent number of issues on here are related to people not specifying that they need GLES.

More info: #115 #101

@deltaoscarmike could really use your help here

Hey so I'm using project M with a pretty beefy system, milkdrop runs just fine, but for whatever reason project m locks up for 1second out of every 3-4. It doesnt matter what visual is playing, or even if its the same one over and over, I can literally watch my GPU dip at every freeze, picture related!

I just heard about projectM and I'm very excited to learn more about this. For a little background I am a podcaster who does mostly audio podcasts and would like to create a video version that is some kind of visualization based on the audio file. and export that as a mp4 for upload to YouTube. My current plan is to use this audio visualizer based in python which gives you animated bars in front of a static image. This is cool but myself and others in podcasting would like more variety in the visualizations, and projectM could give us a lot of unique visuals. I was thinking a first step would be to create a wrapper to the projectM code in python so it could eventually be incorporated in to other audio visualization tools like the aforementioned visualizer, but I was wondering if there were additional documentation or other general advice for created a wrapper to projectM?

This pull request includes the milkdrop text files from the mega preset pack, this PR omits all the textures. also, some/many of these presets have inappropriate names, this should be discussed before merging into the code.

Hello, I'm trying to build ProjectM on a Rpi3, thinking that it would be cool to be able to bolt it onto "volumio" (https://volumio.org/)

The code builds on the rpi (ableit with a bunch of warnings). I've built SDL 2.0.8 (more on that later) and verified that SDL works using some test code. I've verified that there's GLES working using some of the test code in the rpi.

Running projectMSDL results in:

root@volumio:~# projectMSDL 
INFO: GL_VERSION: (null)
INFO: GL_SHADING_LANGUAGE_VERSION: (null)
INFO: GL_VENDOR: (null)
[projectM] config file: /usr/local/share/projectM/config.inp
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted

This clearly isn't optimal. :-)

Here's as much detail as I can think to provide, please let me know if more is needed, if there are other tests / code I can run, etc.

system environment:

root@volumio:~# uname -a
Linux volumio 4.14.69-v7+ #1141 SMP Mon Sep 10 15:26:29 BST 2018 armv7l GNU/Linux

root@volumio:~# more /etc/apt/sources.list
deb http://archive.volumio.org/raspbian/ jessie main contrib non-free rpi
deb-src http://archive.volumio.org/raspbian/ jessie main contrib non-free rpi

compiler version

root@volumio:~# g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Raspbian 4.9.2-10+deb8u1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.2 (Raspbian 4.9.2-10+deb8u1) 

SDL version:

root@volumio:~# sdl2-config --version --cflags --libs
2.0.8
-I/usr/local/include/SDL2 -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads -I/opt/vc/include/interface/vmcs_host/linux -D_REENTRANT
-L/usr/local/lib -Wl,-rpath,/usr/local/lib -Wl,--enable-new-dtags -lSDL2

SDL was built with:

# SDL config
sdl_arm_config_flags="\
--disable-video-opengl --disable-video-x11 \
--disable-pulseaudio --disable-esd \
--disable-video-mir --disable-video-wayland"

projectMSDL in gdb:

root@volumio:~# !480
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/vc/lib/
root@volumio:~# gdb projectMSDL
GNU gdb (Raspbian 7.7.1+dfsg-5+rpi1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from projectMSDL...done.
(gdb) catch throw bad_alloc
Catchpoint 1 (throw)
(gdb) run
Starting program: /usr/local/bin/projectMSDL 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x7685e440 (LWP 13835)]
[New Thread 0x75eff440 (LWP 13836)]
[New Thread 0x756ff440 (LWP 13837)]
[New Thread 0x74eff440 (LWP 13838)]
[New Thread 0x74611440 (LWP 13839)]
INFO: GL_VERSION: (null)
INFO: GL_SHADING_LANGUAGE_VERSION: (null)
INFO: GL_VENDOR: (null)
[projectM] config file: /usr/local/share/projectM/config.inp
Catchpoint 1 (exception thrown), 0x76d5acac in __cxa_throw ()
   from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
(gdb) set pagination off
(gdb) bt
#0  0x76d5acac in __cxa_throw () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#1  0x76d5b388 in operator new(unsigned int) () from /usr/lib/arm-linux-gnueabihf/libstdc++.so.6
#2  0x00038d50 in allocate (this=<optimized out>, __n=1996379485) at /usr/include/c++/4.9/ext/new_allocator.h:104
#3  allocate (__a=..., __n=1996379485) at /usr/include/c++/4.9/bits/alloc_traits.h:357
#4  _M_allocate (this=<optimized out>, __n=1996379485) at /usr/include/c++/4.9/bits/stl_vector.h:170
#5  _M_create_storage (__n=1996379485, this=<synthetic pointer>) at /usr/include/c++/4.9/bits/stl_vector.h:185
#6  _Vector_base (__a=..., __n=1996379485, this=<synthetic pointer>) at /usr/include/c++/4.9/bits/stl_vector.h:136
#7  vector (__a=..., __n=1996379485, this=<synthetic pointer>) at /usr/include/c++/4.9/bits/stl_vector.h:278
#8  ShaderEngine::checkCompileStatus (shader=shader@entry=0, shaderTitle="Vertex: v2f_c4f") at ShaderEngine.cpp:469
#9  0x000399f0 in ShaderEngine::CompileShaderProgram (VertexShaderCode=..., FragmentShaderCode="#version 300 es\nprecision mediump float;\nin vec4 fragment_color;\nout vec4 color;\nvoid main(){\n    color = fragment_color;\n}\n", shaderTypeString="v2f_c4f") at ShaderEngine.cpp:1235
#10 0x00039c00 in ShaderEngine::ShaderEngine (this=0x13ac98) at ShaderEngine.cpp:399
#11 0x000383f4 in Renderer::Renderer (this=0x13abc0, width=512, height=512, gx=<optimized out>, gy=125, _beatDetect=0x137fc0, _presetURL="\\\236\022\000\004\236\022\000\324\234\022\000\000\000\000\000\270\342\r\000\230u\022\000\030\373\377~\320u\022\000\000\000\000\000#\000\000\000\030\000\000\000 \000\000\000\220\260\002\000\000\002\000\000\000\002\000\000\000\002\000\000h\371\377v\324\230\022\000\324\230\022\000\334v\022\000\324\230\022\000\334v\022\000\334v\022\000\f\237\022\000\244\236\022\000\334v\022\000\334v\022\000\374v\022\000\304\342\r\000\334v\022\000\064w\022\000\304\342\r\000\334v\022\000\064w\022\000\304\342\r\000\334v\022\000\244\236\022\000\f\237\022\000\n\000\000\000\000\000\000\000,S\022\000\244v\022\000\274v\022\000\000\000\000\000\000\000\000\000 u\022\000\260\233\022\000\310\232\022\000\016\000\000\000\204\373\377~"..., _titlefontURL="\004\236\022\000\324\234\022\000\000\000\000\000\270\342\r\000\230u\022\000\030\373\377~\320u\022\000\000\000\000\000#\000\000\000\030\000\000\000 \000\000\000\220\260\002\000\000\002\000\000\000\002\000\000\000\002\000\000h\371\377v\324\230\022\000\324\230\022\000\334v\022\000\324\230\022\000\334v\022\000\334v\022\000\f\237\022\000\244\236\022\000\334v\022\000\334v\022\000\374v\022\000\304\342\r\000\334v\022\000\064w\022\000\304\342\r\000\334v\022\000\064w\022\000\304\342\r\000\334v\022\000\244\236\022\000\f\237\022\000\n\000\000\000\000\000\000\000,S\022\000\244v\022\000\274v\022\000\000\000\000\000\000\000\000\000 u\022\000\260\233\022\000\310\232\022\000\016\000\000\000\204\373\377~\230u\022\000"..., _menufontURL="") at Renderer.cpp:25
#12 0x0002a874 in projectM::projectM_init (this=this@entry=0x127598, gx=220, gy=125, fps=35, texsize=512, width=512, height=512) at projectM.cpp:515
#13 0x0002b090 in projectM::readConfig (this=this@entry=0x127598, configFile="/usr/local/share/projectM/config.inp") at projectM.cpp:234
#14 0x0002b94c in projectM::projectM (this=0x127598, config_file="", flags=0) at projectM.cpp:131
#15 0x0001fbd8 in projectMSDL::projectMSDL (this=0x127598, config_file=..., flags=0) at pmSDL.cpp:229
#16 0x0001a590 in main (argc=<optimized out>, argv=<optimized out>) at projectM_SDL_main.cpp:121
(gdb) 

I have tried running the rpi with the three different (as far as i know) possible video driver modes: /boot/config.txt: dtoverlay=vc4-fkms-v3d dtoverlay=vc4-kms-v3d and no dtoverlay in config.txt

The first two modes, SDL does not operate. The setting with no dtoverlay, SDL does operate.

Note that there is no difference in any of the projectMSDL output no matter the setting I use.

SDL is tested with code such as:

root@volumio:~# more hello_sdl2.cpp 
// SDL2 Hello, World!
// This should display a white screen for 2 seconds
// compile with: clang++ main.cpp -o hello_sdl2 -lSDL2
// run with: ./hello_sdl2
#include <SDL2/SDL.h>
#include <stdio.h>

#define SCREEN_WIDTH 640
#define SCREEN_HEIGHT 480

int main(int argc, char* args[]) {
  SDL_Window* window = NULL;
  SDL_Surface* screenSurface = NULL;
  if (SDL_Init(SDL_INIT_VIDEO) < 0) {
    fprintf(stderr, "could not initialize sdl2: %s\n", SDL_GetError());
    return 1;
  }
  window = SDL_CreateWindow(
                            "hello_sdl2",
                            SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
                            SCREEN_WIDTH, SCREEN_HEIGHT,
                            SDL_WINDOW_SHOWN
                            );
  if (window == NULL) {
    fprintf(stderr, "could not create window: %s\n", SDL_GetError());
    return 1;
  }
  screenSurface = SDL_GetWindowSurface(window);
  SDL_FillRect(screenSurface, NULL, SDL_MapRGB(screenSurface->format, 0xFF, 0xFF
, 0xFF));
  SDL_UpdateWindowSurface(window);
  SDL_Delay(2000);
  SDL_DestroyWindow(window);
  SDL_Quit();
  return 0;
}

glxgears reports:

root@volumio:~# glxgears -info
GL_RENDERER   = Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)
GL_VERSION    = 3.0 Mesa 13.0.0
GL_VENDOR     = VMware, Inc.
GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_ATI_texture_compression_3dc GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_ATI_texture_mirror_once GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_texture_array GL_EXT_texture_compression_latc GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_debug_output GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_shader_stencil_export GL_ARB_shader_texture_lod GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_multisample GL_ARB_texture_rgb10_a2ui GL_ARB_uniform_buffer_object GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_ARB_get_program_binary GL_ARB_robustness GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_base_instance GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_texture_storage GL_ARB_transform_feedback_instanced GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_transform_feedback GL_AMD_shader_trinary_minmax GL_ARB_ES3_compatibility GL_ARB_arrays_of_arrays GL_ARB_clear_buffer_object GL_ARB_copy_image GL_ARB_explicit_uniform_location GL_ARB_invalidate_subdata GL_ARB_program_interface_query GL_ARB_stencil_texturing GL_ARB_texture_query_levels GL_ARB_texture_storage_multisample GL_ARB_texture_view GL_ARB_vertex_attrib_binding GL_KHR_debug GL_ARB_buffer_storage GL_ARB_internalformat_query2 GL_ARB_multi_bind GL_ARB_seamless_cubemap_per_texture GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_stencil8 GL_ARB_vertex_type_10f_11f_11f_rev GL_EXT_shader_integer_mix GL_ARB_clip_control GL_ARB_conditional_render_inverted GL_ARB_cull_distance GL_ARB_get_texture_sub_image GL_EXT_polygon_offset_clamp GL_KHR_context_flush_control GL_MESA_shader_integer_functions 
VisualID 420, 0x1a4

Hello hello! I have been using ProjectM for YEARS every day! I have a secondary PC that acts as a "stereo-server", with two smaller 19-21" inch screens on each side of my 40 inch screen, with ProjectM set to open on boot-up, its really beautiful!

There hasn't been an update to ProjectM in a very long time on Arch Linux, I can't even remember when the last time was I saw an update for ProjectM... So I'm just wondering... Is that because you haven't made an official release in a while or perhaps it just hasn't been getting updated in the arch linux repositories? And can the iProjectM HD be ported to Linux or is there perhaps a "ProjectM HD"? It'd be really awesome if we had a similar plugin for Clementine if that is even possible.

The version in the Arch Linux "Community" repo is: 2.1.0-17 For the record I'm using Artix, which is OpenRC arch that shares a few repos with the official Arch.

Thank you for your time & especially for your work.

This would allow running projectM binaries from the build directory without needing to install them.

Mixxx does this by searching for CMakeCache.txt in the build directory and finding the path to the source tree from that. Optionally this can be overriden by the user with a command line argument. If neither the command line option is used nor CMakeCache.txt is found, then the application searches for data in the installed path (PROJECTM_DATADIR_PATH for projectM).

Two small additions to the playlist API for more convenience:

• Added missing getter methd to return shuffle mode.
• Added start/count parameters to projectm_playlist_items() to enable returning only a range of items in the playlist if needed.

Currently, libprojectM only supports rendering using OpenGL 3 and GLES 2. Since OpenGL is generally considered a deprecated API and Vulkan/Metal has a better API to perform multi-threaded rendering and shader compilation, it will be a good step forward to add support for these next-gen rendering APIs.

Any API-specific initialization calls, e.g. providing the required Vulkan structs, should be implemented in a specific header, e.g. libprojectM/renderer_vulkan.h. Adding support for multiple rendering backends will also require a major refactoring of the library, abstracting rendering-related calls. projectM only renders a few primitives (triangle fans/strips, line strips and points) and uses vertex and fragment shader programs, so there's not much to implement.

Line rendering should be improved beforehand, as covered by issue #682.

Vulkan support should be introduced together with the EGL migration covered by issue #681.

Curently, projectM implements the exact same line rendering technique as Milkdrop. It renders either a single, 1px-wide line or four 1px-wide lines in a 2x2 raster for thick/bold lines. There are a few issues with the current implementation, from which Milkdrop also suffers:

• Line anti-aliasing is not a guaranteed feature, e.g. it's basically only available on desktop platforms and if the line is only 1px wide.
• The line with always stays the same, regardless of the rendering resolution, meaning that the higher the resolution gets, there is less and less brightness/color added to the image overall. This causes many presets to become darker or almost black on 4K+ screens, while very small resoutions will be way too bright.
• Vulkan/Metal don't support line rendering with the optional VK_EXT_line_rasterization extension.

Ideally, line width should scale smoothly with the rendering resolution, e.g. 1px width (or 2px for thick lines) at 1000px. such lines would then render 4px/8px wide on 4K resolutions, covering about the same percentage of image pixels overall.

One feasible approach would be implementing a technique suggested by this article, which will also work fine for OpenGL and WebGL. This will also take care of line joints and end caps to look nice, e.g. shapes can use miter joints while waveforms should ideally be rendered with round joints and end caps.

Currently, projectM uses GLX or GLES on Linux. Since both APIs are highly specialized (GLX for the X Window System/X11, GLES for embedded devices like RPi and also WebGL), plus future Linux desktops will at some point switch to Wayland (which doesn't support GLX at all and requires EGL to be used), it makes sense to remove any code that's specific to one of these APIs and fully migrate to the EGL API/headers.

Note: This change will require changes to applications using projectM, as they'd need to create an EGL context specifically. Because of this breaking change, I suggest to implement this feature alongside adding Vulkan/Metal rendering support and then update projectM to the next major version, as covered by issue #683.

From @revmischa on the projectM Discord Server, 10.11.2022 20:18:

If someone can create a GStreamer plug-in that will enable any sort of custom media pipeline application for projectM. E.g. turn an audio file into a video, create a video from a live stream, overlay or mix visualization on existing video, easy automation, etc.

I'll put a bounty of $500 for whoever lands a working GStreamer plug-in. Paid out of our OpenCollective.

https://gstreamer.freedesktop.org/documentation/plugin-development/index.html?gi-language=c

A few additions/clarifications by me (@kblaschke):

• The plug-in should compile/work on all platforms supported by both GStreamer and libprojectM.
• The plug-in should use the new C API that will be released in the libprojectM 4.0 version and link against the shared projectM library (dll/so/dylib). Ideally, wait until after the initial 4.0 release to start the implementation, as the API will still change before the release.
• The plug-in should consume an audio/x-raw audio stream and pass it on to projectM.
• The plug-in should produce an video/x-raw video stream as output.

The */x-raw types would probably be the most appropriate input/output formats as they don't require any de-/encoding overhead in the projectM plug-in and has no compression artifacts. While having the highest bit rate, users can put an audio decoder before and a video compressor plug-in after projectM in the GStreamer filter chain if needed.

In the original Milkdrop, a simple monitoring feature exists that preset authors can use to watch how a single value in a preset evolves over time. This is done by pressing "N", and also adding a monitor = EXPR line in any per-frame equation in the preset. The value is then displayed on screen.

projectM currently lacks this feature. Since the on-screen UI has been removed recently, an API-driven debug feature would be more convenient, which might even go beyond what Milkdrop provided. Here's my porposal:

Per-Frame debugging

This will implement the debug feature similar to what Milkdrop provides with the monitor variable, but a bit more flexibility and without the requirement to add a line in the preset file. This is accomplished by adding three new API functions, e.g. in a separate "debug.h" header:

• projectm_debug_milkdrop_add_watch(): A function that adds a watch on a certain named variable, taking a second parameter to specify the per-frame code block (preset, custom wave 1-4 or custom shape 1-4).
• projectm_debug_milkdrop_get_value(): This function will return the value of a previously enabled watch. If the watch hasn't been enabled, it will return 0.
• projectm_debug_milkdrop_remove_watch(): Deletes a previously enabled watch.

Theoretically, the get_value method would suffice, but since the variables need to be copied into another context after preset evaluation, copying all possible values (e.g. predefined and locally defined variables) without knowing they're being used will incur a slight performance drop and is not necessary for general use.

Embedding applications can then request the variable contents after calling projectm_render_frame() and display or store the values as required, for example display them on screen, using them to plot a graph or store them in a CSV file.

Per-Vertex equation debugging

By watching a single variable per frame, it's not possible to see the values from per-vertex/per-shape equations, as these are evaluated hundreds or thousands of times per frame. With a slightly larger performance impact, it would be possible to store all these values as arrays and pass them to the application. A real-time display of this large number of values could be challenging, but for graphing and storage purposes it should be a great tool. The above add/remove functions could be reused by adding more enum values in the second parameter, e.g. CUSTOM_WAVE_1_PER_FRAME for the above suggestion and CUSTOM_WAVE_1_PER_VERTEX for monitoring all values calculated for each waveform vertex.

The get_value function would only work with single values, for the per_vertex/per_shape equations, two more functions would be required to properly retrieve the data into a buffer:

• projectm_debug_milkdrop_get_value_count(): Takes the variable name and equation enum value as provided in the add_watch function, and returns the number of values generated in the last frame for this specific equation. The number of values can change for custom waveforms, as the samples value is dynamic and determines the number of vertices in the resulting waveform.
• projectm_debug_milkdrop_get_value_array(): Returns the values for the given variable and equation type into a user-provided buffer, which needs to be large enough to take at least the number of values returned by the get_value_count function. Applications may choose to make the buffer a fixed size (1000 floats for shapes, 512 for waves, meshx*meshy for preset per-vertex code) to prevent frequent reallocations, and just use the count to access the values.

Unsupported watches

Since it would add a lot of runtime overhead to projectM's expression parser to support "step-by-step" debugging, for example by registering callbacks that are run each time a variable changes, only the final state of a variable after the equation block has finished running will be visible after the frame has been rendered. There won't be a way to watch variable changes during loops, or record changes from line to line.

The proposed debug features above are already a huge improvement in comparison to what Milkdrop provides, and should already help preset authors enough to fix issues.