Not just you - but like you, nothing that I can reproduce on demand. I also am using dbRackModules 2.1.0 with Rack 2.0.6 (standalone) on Win 10
However, I don’t think I have tried RSC.
I am not even confident that the common factor has been dbRackModules.
It has happened often enough under some condition(s) (that I can’t put my finger on) to be more than a fluke, but not enough to detect the pattern. And I don’t trust my memory enough to know what minimal set of plugins were in use. I have been using two pre-release plugins - dbRackModules and Stoermelder PackOne. I remember I was trying some modules that were new to the plugin pre-release version when the crashes occurred, but I can’t remember which one(s) And of course they were not the only modules in the (small) patch.
Not much help, I know. I will try to be more diligent if/when a crash happens again.
Actually I am still using Rack 2.0.6 because it appears to be more stable, based on all the reports of instability with the unreleased newer version(s). I haven’t been following the Rack pre-release too closely since I made the decision to wait for the official release. But I was tempted to jump on board until I saw the flurry of problem reports.
I’ve had crashes like this lately too where Rack just suddenly stops responding (but keeps playing audio) and I have to kill the process, and I’ve definitely had it happen without dbRackModules in the patch.
the only change in RSC in 2.1.0 was that on startup it is ensured that the pitch modulation parameter is evaluated and the reverb is initialized correctly. in the previous version RSC made occasionally some noise after startup which disappeared when adjusting the PM parameter. therefore it seems unlikely that the new version is causing crashes - but if you can say for sure that the 2.0.5 version does not reproduce this behavior, i could have a deeper look at it.
Note, for me, this problem is worse in Rack 2.1.1 than in 2.1.0 , but, since I have been able to totally avoid this crash by not doing any module resets automatically with a small delay after patch load, I have quit worrying about it, even though I know there is still an apparent bug in Rack 2.1.0 and 2.1.1 .
With this bug, it seemed sensitive to connecting cables to modules when editing the patch, but was impossible for me to track down what was happening.
By the way, I did have a crash bug in an early version of Meander for V2 that was related to connecting cables to my module and how I was handling internal detection of those connections. Basically, I was accessing the CableWidget in my ModuleWidget:: step() override. I had to add the isComplete() check on the CableWidget object before doing anything with it.
Don’t know if this is relevant, but I have never discussed this here.
for (CableWidget* cwOut : APP->scene->rack->getCablesOnPort(outPortWidgets[Meander::OUT_CLOCK_BEATX8_OUTPUT]))
if (!cwOut->isComplete()) // new for testing, from vcvrack-packone strip.cpp
if (cwOut->cable->id == cwIn->cable->id)
PLEASE, Ignore any specific plugin or modules discussed in my thread. At various times several modules seemed implicated in the crash but that seemed to just be due to the crash being more likely to occur the more modules there were in the patch.
That seems similar to what is happening here in this thread, perhaps.
Note, I edited my first post in my linked thread to clarify that this bug seems to be in Rack rather than in any specific plugin or module. But, this all still unresolved, so there is no solution closing out that topic, yet.