dbRackModules releases

Anybody experiencing crashes with dbRackModules 2.1.0?

I think there’s something going on with RSC. I was crashing VCV Rack multiple times a day recently. The only common module was RSC in those patches.

I can’t really report it to Christian as I have no evidence and I can hardly even recreate the crash. But it’s mostly happening when RSC is already in the patch and I’m trying to plug a cable in. Rack starts freezing and then crashing. After re-opening the patch everything looks and sounds okay.

It can easily be that I’m still using VCV Rack 2.0.6 (Win10) but I don’t know. I don’t even see anything suspicious in the log.txt

[1330.224 info src/app/Browser.cpp:86 chooseModel] Creating module docB RSC
[1330.224 info src/app/Browser.cpp:90 chooseModel] Creating module widget docB RSC
[1330.224 info src/app/ModuleWidget.cpp:545 load] Loading preset C:/Users/aszabo/Documents/Rack2/presets/dbRackModules/RSC/template.vcvm
[1330.225 info src/engine/Module.cpp:167 fromJson] Patch created with dbRackModules v2.0.5, currently using v2.1.0.
[1337.675 info src/patch.cpp:194 saveAutosave] Saving autosave C:/Users/aszabo/Documents/Rack2/autosave/patch.json
[1337.681 info src/settings.cpp:437 save] Saving settings C:/Users/aszabo/Documents/Rack2/settings.json

Is it only me?

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) :frowning: 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.

Reading @DaveVenom 's and @TroubledMind 's responses I think it should be a general issue and not related to your modules.

Just some coincidence. I admit I happen to use RSC too often in my newer patches. :slight_smile:

This sure sounds like the issues that lead to me creating this thread:

And to the one pointed out by @marc_boule here:

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                                              
                   		continue;
					if (cwOut->cable->id == cwIn->cable->id)
					{
						module->theMeanderState.theHarmonyParms.STEP_inport_connected_to_Meander_trigger_port=Meander::OUT_CLOCK_BEATX8_OUTPUT;  
					}
				}

Rotary works peachy here in every patch I make as it is part of my default effects in my template. That is never crashing here, nor have I had any crash in 2.1.1 on MacOS 12.4. M1 Mini.

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.

For anyone interested - I posted the following PAD2 enhancement requests on github, in case you want to express interest (or lack thereof) in the ideas:

1 Like

Mainly there are now some features for morphing between PAD sounds. See also:

Changes over pre1:

  • PAD2:
    • Uses bigger wave tables for higher sample rates
    • Has inputs for controlling the partials
    • The partial sliders start now with one - the fundamental (breaking change) which was set to 1.0 before
  • new module µPad2: small version of PAD2 which is fully controlled by inputs (see manual)
  • PAD:
    • has now an amp knob for the first partial, was 1.0 before.
    • has now a menu for setting a fade time for morphing between changes
    • presets are now applied directly
    • has now a trigger input for regenerating the wavetable if parameters are externally changed (e.g.) via µMap
    • has a new method for generating saw and pulse wavetables (see also manual)
  • Faders
    • has now 100 voltage addressable slots
    • has now a knob for setting a glide time to morph between slots
    • has 3 additional knob values
    • has a special function for fetching values from PAD2 to feed them into µPad2 (see also manual)
7 Likes

and people can grab these and make a patch still in time for the current vcp challenge!

1 Like

yes, its still a pre release but i think there will no breaking changes anymore so it will stay compatible in the patches.

Those Pad2 demos sound so gorgeous… :face_with_monocle:

1 Like

Amazing collection of modules doc, really need to dive into these. Well done and thanks!

1 Like

Thanks all for testing/commenting. dbRackModules 2.1.0 is now in the library.

6 Likes

It still excludes the latest ACC modification, doesn’t it?

sure, because ACC is dbRackSequencer. There i have to write manuals first, as there are some new modules.

Ah, right… :face_with_spiral_eyes: I’m already dizzy because of the amount of modules you released.

1 Like

Yesssssss new docB modules! So hyped!