dbRackModules releases

hi, dbRackModules 2.0.4 is now in the Library.

ChangeLog:

HexSeq and HexSeqP

hexseq204

Features:

  • the focused field is highlighted
  • the dirty color is more red
  • lower case input i.e. abcdef is now also supported
  • an asterix (*) input char where the hexchar is randomly chosen every time it is hit
  • copy/paste from menu does now work with inactive fields.
  • added Randomize and Initialize
  • new key commands for active fields:
    • TAB: moves focus a field down without saving
    • UP: saves/activates the field and moves focus a field up
    • DOWN: saves/activates the field and moves focus a field down
    • p: randomizes the current active field, P: additionally activates/save
    • r: rotates the current active field one bit right, R: additionally activates/save
    • l: rotates the current active field one bit left, L: additionally activates/save
  • if the mouse is over the module the field 1-9 can be focused by pressing key 1-9
  • Menu for setting the bit-density for the randomization
  • Menus for setting the length range for the randomization
  • Lights for the current Step - can be turned on/off in the menu

Fixes:

  • ESC unfocuses and restores now the previous saved value
  • live coding works now - the issue that the tracks were out of sync if the length of a track was changed is solved.
  • paste from right click menu is checked now for a valid hex string

HexSeq

Features

  • some factory presets (drum patterns) for learning purposes (Thanks to @FiroLFO)
  • added polyphonic trigger output
  • Added Expander HexSeqExp for
    • gate outputs(reflects the current state of the bits)
    • clock outputs (represents the incomming clock gate if bit is set)
    • inverted output (fires a trigger if bit is zero)

HexSeqP

Features

  • pattern select mode also via voltage configurable via menu (see manual)
  • clock delay setting now in menu
  • added gate, clock and inverted output (see HexSeq)

Fixes

  • after ‘paste pattern’ the fields are updated/visible

Thanks to @FiroLFO for feature requests/testing and @DaveVenom for feature requests.

9 Likes

dbRackModules 2.0.5 is now in the Library.

ChangeLog:

PAD

  • Fixed crash in Bitwig

RndG

  • Clock output represents now the in coming clock
  • Clock input is now polyphonic

Geneticsuperterrain/Geneticterrain

  • Added new terrain (tanh(sin(sqr(y+x))*x+sqr(sin(x)*cos(y))) which can/should be taken instead of sin(sqr(y+x))*x+sqr(sin(x)*cos(y)) as the latter produces too high voltages on the diagonale while increasing x,y and has occasionally upset filters (also the internal dcblocker in geneticsuperterrain).

Thanks to @FiroLFO for feature requests and testing.

7 Likes

dbRackModules 2.1.0 preview release is available here

Test,comments are welcome.

There were two objectives:

  1. Establishing a modular phase distortion system. The sound is produced by oscillators which do not take pitch information but a phase wave to produce sound. This enables to have a chain of phase modulators/shapers (starting e.g. from a clean saw) which produce complex phase waves which are passed to the oscillator. (see examples in the Manual).
  2. Putting heavy computations in background threads. Please try PAD2 or MVerb.

Changelog:

New modules:

Performance enhancements:

  • MVerb can run now with a background thread and should be mainly below 1% CPU.
  • Geneticterrain, Geneticsuperterrain should be mainly 1-2 % better.

Fixes/Enhancements:

  • Frac makes now a reset if the N or D parameter is changed.
  • RSC behaves now correct on startup.
  • RndH has now a menu option which causes the seed value rounded to a less precision float to provide inter compatibility for different seed providers.
  • Geneticterrain, Geneticsuperterrain now have phase inputs.
  • SuperLFO can be phase driven if the frequency is set to the lowest value (i.e. is normalized to zero in this case).
  • Plotter: if placed on the right side of SuperLFO it displays the current curve.
  • Geneticterrain has now a rectangular curve
  • Geneticterrain, Geneticsuperterrain have now a some noise terrains.
  • HexSeqP can now fetch data from left placed modules by pressing ‘f’: HexSeq, CM Euclidean (unsupported), CM GateSequencer16 (unsupported)
13 Likes

I have been having fun creating drones with Pad2! It is working well on both my Windows machine and my M1 MacBook Air.

I am puzzled by the Pad2 Fundamental frequency and the VCV sample rate. The sounds I get seem particularly sensitive to the sample rate. Changing the sample rate can dramatically change overall volume and timbre. It seems I can adjust the fundamental frequency to sort of compensate, but I can’t find any pattern. I don’t know if this is an inherent artifact of the algorithm or not. If not, it would be nice if it gave more consistent results with the different sample rates. Sample rates can become important when using a patch on different computers with different capabilities, and currently the same patch can sound radically different.

I see tremendous potential for Pad2, and I have a bunch of ideas for enhancements. OK to post them here? Or would you prefer I submit issues to github?

Here is the patch I have been playing with.

Pad2 Drone.vcv (21.5 KB)

I recorded the audio on my M1 MacBook Air with VCV using 1 thread at a sample rate of 192 kHz. If not recording with the VCV recorder, then I can run the patch at 384 kHz.

Note - there are no effects applied to the recording what-so-ever! Not even any EQ or compression.

There are two alternating chords sent to the Pad2. The first is D3, F#3, A3, E4, G#4, B4 (E major triad above a D major triad). The second simply inverts the two triads, with D major above E major. More about these chords later. I used the new PLC module to generate the polyphonic chords.

A gate sequencer alternates the chords in a pattern of 6, 3, 3, 6, 3, 3 at 15 BPM. A slew limiter is applied to the transition.

I use Stoermelder’s Transit to map all the Pad2 partials. (I mapped the entire module, then unmapped everything but the partials). I pressed the Generate button repeatedly and saved a set of 12 profiles that I liked into Transit.

A clock divider triggers Transit to pseudo randomly pick a different partial profile every 4 beats, and the fade feature is used to gradually morph between each setting.

The left and right Pad2 outputs feed two Lateralus low pass filters, with the cutoffs controlled by two of the outputs from the docB RndC to provide additional stereo definition.

I wanted some more bass oompf - so I take the low note of the currently playing chord to drive a 0 Hz FM carrier wave. The sine wave modifier uses the bass note 1 octave lower, and a 2nd modulator pitched 2 octaves lower modulates the 1st one. A slight DC bias is applied to the 0 Hz carrier to give a beat effect, and the 3rd output from RndC modulates the carrier FM depth.

I chose the chords based on the video below from Andrew Huang. I’m thinking of doing a performance of some version of this patch with my flutes, and submitting it to Andrew.

3 Likes

hi, great patch!

The far most CPU (>50%) on 48kHz is used on my machine by the two Lateralus.

I have bypassed them (then the patch runs with 14%avg) and also the bass voice to hear the differences on a sample rate change - i would say: room for enhancements. That a change of the sample rate causes changes in timbre is most likely caused by using a fixed buffer size for the algorithm, so i would have to increase it e.g. by factor 8 for 384 kHz and adjusting accordingly if the sample rate changes and check if the performance is still OK. I have also made a quick fix that the sample buffer is computed immediately if the sample rate changes (now you have to wait until a parameter changes).

I think github is better suited for discussing further enhancements but discussing here is also OK for me.

While writing this i still listened to the patch - could do it long times - very contemplative!

1 Like

yep, just reprod that here too, slurping 60% CPU with a 4 channel poly voice into it.

@modlfo what gives on that CPU hungriness?

Lateralus is a complex filter. The CPU consumption varies as needed. By running it in polyphonic mode the consumption just piles up. For a lighter filter, I would recommend swapping it for Nitrous. Nitrous uses a different simulation technique. I have been wanting to port that technique to Lateralus. I hope to do it for the next version.

4 Likes

Yes, I forgot to mention that Lateralus consumes most of the CPU. I tried a half dozen different filters hoping to find something more CPU friendly, but none of them sounded as good as Lateralus. I’ll have to try Nitrous. I just realized I need to try the VCV filter as well.

Good call! I was able to dial in an almost identical sound with just the right amount of glistening shimmer, while using 50% less CPU then the Lateralus (11% vs 22% per filter).

Pad2 Drone Nitrous.vcv (19.8 KB)

The VCV filter used only 4%, and also sounded good, but it had more of a smeared swoosh sound, not what I wanted.

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