Trying increasing the OCT, or plug something into V/OCT?
Sure, I tried several obvious ârevival effortsâ (Randomize, V/Oct In etc) 
Same storyâŚ
Now we are talking 
P.S. BTW, do you see ânanVâ message from the 2nd one?
The setting are pretty different. Probably doesnât matterâŚ
Seems random, one instance will work and then another wonât. Also, not sure if this was how it used to work, but when opening VCV with a patch that was playing Basal into Slap, thereâs some funky noises happening before the notes kick in. I feel like I would have been used to that if it was the old behaviour.
Thatâs because I was I kept prodding it trying to make a noise 
Put another Basal in and see if it still works. Itâs a random thing, I got Basal to work too in the end.
I have four running now and everything seems fine. 
Ahh but then when I closed and reopened Rack, there was a short chirp of audio and then everything went silent. No sound from any of the Basals now.
Thanks for the report. I think I know whatâs the issue. I started building the modules with GitHub - VCVRack/rack-plugin-toolchain
It seems like the windows compiler there has a bug that Iâm hitting. I have code like this:
void initializeBuffer(Context &ctx) {
for (int i = 0; i < 1000; i++) {
ctx.buffer[i] = 0.0f;
}
}
Using the mingw gcc compiler turns this code into an instant crash. The code works fine on Mac and Linux.
Iâm trying to find a workaround this issue. Because it affects all the modules that have a large buffer.
I have had problems a LOT where my local build runs fine in windows, but the one from the rack toolchain crashes. I have never found out the source of the problem, but I used to work around it by building in a Linux VM with the ârealâ rack toolchain, then keep changing the code until it didnât crash any more. In my case it was always c++ library functions like std::stringstream, or the boilerplate that lets you catch an exception. Never could prove it wasnât just something in my code, although I did run it in linux under address sanitezer and found no issues.
Iâm having the issue on Mac.
Ubuntu 18.04 VCV Rack Free v2.beta.1
[0.199 warn src/plugin.cpp:170 loadPlugin] Could not load plugin /home/dlphilp/src/Rack2/plugins/VultModulesFree: Failed to load library /home/dlphilp/src/Rack2/plugins/VultModulesFree/plugin.so: /home/dlphilp/src/Rack2/plugins/VultModulesFree/plugin.so: undefined symbol: _ZSt28__throw_bad_array_new_lengthv
me too.
Notice ânot built yetâ and âalpha statusâ.
We have updated the rack-plugin-toolchain v2 to the latest cross-compilers available for all platforms.
One artifact of this are changes in gcc 11 where there are issues at runtime when loading plugins into a Rack version that is not compiled with (at least) gcc 11. This results in the error that @dlphillips posted above (undefined symbol: _ZSt28__throw_bad_array_new_lengthv).
If you load the the Vult modules @modlfo provided in the official Rack beta, they will load fine, because it was compiled with gcc 11.
Other issues @Squinky mentioned are purely anecdotal at this point since we donât have enough data with the new compilers to know if there are still differences between the native (mingw-based) Windows compilers and the (mingw-based) cross-compilers used for the rack-plugin-toolchain.
I have been compiling all available open source plugins for v2 with the rack-plugin-toolchain and tested runtime with the official Rack releases on all platforms. So far I have not encountered any issues that could be traced back to the rack-plugin-toolchain.
The above mentioned gcc 11-related issue is somewhat unfortunate for people compiling from source and we keep monitoring availability of gcc 11 releases that might resolve this. Until then, you can compile your local Rack version with a more recent compiler to resolve this issue.