dizzisound
commented
4 years ago So sad this project is abandoned due to the cross-platform inherent compilation intricancies!
Anyway, @davephillips I can't understand if the crash you experiment was the same to me, but I could rid off a crash when adding the modules, by wrapping the body of the step() member in BaseProjectMWidget, with a if (module) ... {
So, just as maybe-one-day-wanna-be-useful archive notes @korfuri Still I can build the v1 branch on Windows with MingW, passing a slight modified
makefile, and using my custom arrangement of projectM. The libprojectM library is built in the process and successfully linked. So sorry I have no idea how to commit/share my configuration of the project, it seems to be so peculiar and not reproducible/automatable without manually tricking the original repo files. I suspect it's quite a "dirty" arrangement, yet it works on my system. May be I could upload a "freezed", archive project? The only anomaly I experiment is the following: when opening the module browser, a new rendering window of the "windowed" module is initiated and pops up every time. Basically, I have to forget of this and let these child windows live as-is, without taking actions with it. Doing so, I'm still able to add both the "windowed" and the "embedded" versions of the module, switch the presets, connect audio/CV, etc. As already said, I only have to forget the floating windows, both the "extra" (initiated by the module browser) and the "legitimate" ones (initiated by dragging a windowed-module onto the Rack stage). By closing or minimizing these, the
assert() macro in projectM::projectM_resetGL triggers the ungraceful exit from Rack.
Posting a screenshot of the thing. 
Greetings !
Here's the info you requested:
And the output from glxinfo:
glxinfo.txt
I can also run a debug session if you need a gdb report. Btw, this kind of crash (open browser, crash Rack) is often the result of a NULL module in a custom widget. Anything like that in your code ?
Best regards,
Dave Phillips