v1 builds but crashes Rack about milkrack HOT 1 OPEN

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) ... {} clause.

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.

from milkrack.