Blamsoft is back .. just great !


In fact I first try the command line on the free version, then rune it again by changing “Free” for “Pro”. I tried again with your proposal and same issue. Selecting Blamsoft in the Browser crash VCV. I tried also a search by entering “x” in the search bar. It crashed VCV. May be I will redownload Blamsoft plugins and run the command line on the pro version only.

Interesting, no crash with VCV free version, I can search and select Blamsoft plugin. I should have run the command line on the Pro version first. :frowning:

just in case, the log when it crash.

[12.059 info src/app/Browser.cpp:202 createPreview] Creating module widget Blamsoft XFX Grunge
[12.060 fatal adapters/standalone.cpp:48 fatalSignalHandler] Fatal signal 6. Stack trace:
23: Rack(fatalSignalHandler(int)+27)
22: libsystem_platform.dylib(_sigtramp+29)
21: libsystem_malloc.dylib(malloc_zone_malloc+104)
20: libsystem_c.dylib(abort+120)
19: libsystem_c.dylib(err+0)
18: libRack.dylib(rack::contextGet() (.cold.1)+33)
17: libRack.dylib(rack::contextGet()+28)
16: plugin.dylib(DC1ModuleWidget::DC1ModuleWidget(DC1Module*)+54)
15: plugin.dylib(rack::plugin::Model* rack::createModel<DC1Module, DC1ModuleWidget>(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::TModel::createModuleWidget(rack::engine::Module*)+84)
14: libRack.dylib(rack::app::browser::ModelBox::createPreview()+481)
13: libRack.dylib(rack::app::browser::ModelBox::draw(rack::widget::Widget::DrawArgs const&)+27)
12: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
11: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
10: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
9: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
8: libRack.dylib(rack::ui::ScrollWidget::draw(rack::widget::Widget::DrawArgs const&)+52)
7: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
6: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
5: libRack.dylib(rack::widget::Widget::draw(rack::widget::Widget::DrawArgs const&)+461)
4: libRack.dylib(rack::window::Window::step()+1997)
3: libRack.dylib(rack::window::Window::run()+40)
2: Rack(main+3454)
1: libdyld.dylib(start+1)
0: ???(0x0+1)

I think there are two issues, right? One is the linkage issue which can be worked around with these command line fixes. The other is a crash any time it’s used in inside a VST.

Is this correct? Just trying to sort of this confusing thread. Is it correct that the command line hax will fix the linkage, but not fix the VST crash?



In my case, Pro version crashed when used as standalone. I didn’t try as a VST.

best regards


1 Like

thanks a lot this did the trick for me! :+1:

Fun I had with the modules today…

…FYI - this was via the latest official release of the pro plugin in Reaper 6.67 on Win 11 Pro X64.


I had added the XFX WAVE into a patch to play with it. I just discovered that when I launch Rack and the patch, the output level from the XFX goes extremely high and red-lines the Mindmeld mixer output. This looks like a NaN or array index bounds issue to me.

This in Rack 2.1.2 standalone under Windows 11.

Luckily I did not have my headphones on nor have the output going to my powered studio monitors. I don’t think I have ever experienced this with any other module.

You can just run it now…

This morning when I started Rack with the XFX in it, the sound output did not red-line loud. Several exits and relaunches failed to reproduce the problem. But then I saved the patch and exit Rack and relaunched and the problem is back. But, sometimes it happens, sometimes not.

So, this is just a nuisance problem. Right? Nothing could really be damaged by crazy module voltages. Right?

MixMaster’s master channel clips the output (can be either soft or hard) and I believe the Audio module hard clips the output too - so you are unlikely to send crazy voltage out to your monitors.


Thanks for the clarification. I don’t worry so much about my Behringer 16W studio monitors attached to the PC and my normal Rack output, but I do worry if I happen to have my sound studio 200W subwoofer and monitors on, which is seldom these days.

Couldn’t resist that GOOD hype as well but tested in some brutal manner. Anyway - welcome back!


Same here
MAC 11.6.8

Hey there. I actually have this with all plugins in the VST version, sometimes it will load, then next time it can’t find the plugins from VCV even.

Will this command work for all plugins when I end at the command at …Documents/Rack2/plugins/

Or do I need to do this for every plugin separately? Because this seems to be a solution to my problem. I tried all the permissions solutions I could find in this forum, but nothing worked.

Also VCV bug reports couldn’t help me. Mac Mini M1.

Hmm it sounds like there might be another issue here with the Pro version and/or the VST ?

You could try uninstalling and reinstalling and then running the commands for the pro version only

I don’t know, you may have to wait for an update…

That is what I am doing as the commands didn’t work for me either (Pro Standalone MacOS 10.15). But what’s a couple more days or weeks even after all this time without these excellent modules :slight_smile:

Do we know if these bug reports are making their way to the developer? Does the developer have a VCV account? Sorry for my confusion regarding how closed source works.

Is it @Blamsoft ?

1 Like

The developer and VCV Support are both aware of this issue and are looking into it.


Does “this issue” refer to the red-line issue or the VST crashing issue? Thanks!

The red-dot update issue.

Hi Jeroen,

Have you tried enabling either Full Disk Access or Files and Folders access for VCV Rack and your DAW in the Security & Privacy preferences pane?

1 Like