dbRackModules releases

hi, thanks for your input.


Generally i am not a real fan of putting much effort into anti aliasing as i do not expect that every instrument or oscillator must have a octave range of a piano and i design sounds almost always for much smaller ranges. Second i generally handle aliasing which is in fact a computer thing and we indeed produce sound with a computer and not an analog circuit, if it occurs, by either using it or adjusting it e.g. in this example reduce clip and skew dependent on v/oct input. Well, a small effort would be that i measure the actual clip length which also depends on the skew value and output a sine wave if it is smaller than a threshold value.


Indeed Ratio was designed together with EVA to have a tiny fm operator with minimal CPU usage, here an example of an epiano like sound:


How should polyphony behave? Currently the ratio value is overridden by the input value visible on the knob. Should it be relative with attenuation?


PHSR2 is part of the modular phase distortion and not designed for making sound by its own or as envelope generator (may be this is an idea for a different module), here the small standard example:


The outer points should in general not be touched i.e. should be -5, 5 as otherwise discontinousities can occur on the resulting PhO output (also the reason why they cannot be modulated).

Anti aliasing would make noise on the phase driven oscillator.


This issue should be fixed here (tested on some smaller laptops - old mac pro and linux - also thanks to @Wirenes and @FiroLFO for reporting and testing)


Yes, your choice to have the knob follow the CV input surprised me. I can see how it might be useful/interesting to be able to visually follow the incoming CV values, but it does not make sense with polyphony.

If you do add polyphony, then I think the best option is to simply sum the values, probably clamping the result between -10 and 10 (though it could be interesting to allow CV to access ratios greater than 32). So if you sum the CV with the knob value, then I think it makes more sense for the knob to go from -10 to 10, and ditch the 1/x button. The initialized value would be 0V.

Alternatively you could go the attenuation route and preserve the 0 - 10 knob range and the 1/x switch. If CV input is provided, then the knob becomes an attenuator, and negative CV could invert the state of the 1/x switch.

Either way, I think an animated knob does not make sense with polyphonic inputs

I really like the way recent VCV Fundamental modules determine channel count - the maximum number of channels found across all inputs. There are two different behaviors when an input has fewer channels

  • If the input has exactly one channel, then the CV is applied to all channels
  • If the input is polyphonic, but with fewer channels, then the missing channels are defaulted to constant 0 volts

This arrangement can be very useful. With this module

  • poly V/Oct with mono Ratio - compute the nth partial CV for all input pitches
  • mono V/Oct with poly Ratio - compute a series of partial CV values for a single input pitch

For completeness, you could make the Fine input polyphonic in the same way.

Given that you already invested effort to animate the knobs, I would be surprised if you adopt my ideas. But it never hurts to ask.

Yes, but there is that saying “It’s all voltage”. One of the beauties of modular is how you can experiment and repurpose modules to achieve all manner of wonderous results that might not have been the original designer’s intent. Adding a one shot option would in no way interfere with your original intention for the module, but it would open it up for many more uses.

Alternatively, you certainly could create another module.

No doubt. That is why if you did implement it, it would have to be an option, probably in the context menu.

I was referring to inner points - sometimes I am unable to grab hold of an inner point and move it, other times I can. Additionally, sometimes I can move the right outer point up and down (but not side to side, which makes sense). I would be sorry to see you “fix” the outer right behavior! If you don’t want discontinuities when using it as a phasor, then simply don’t move the last point.

I presume you are referring to the pops that I am getting when “Use thread” is enabled.

But can you modify the module to save the state of the “Use thread” option? Or did that get fixed as well?

The modular phase distortion system you’ve built is really cool! I took a self-contained approach for Warp Core but I absolutely see the appeal of breaking it out into an actually modular system, makes a lot of sense.

I see what you’re saying, and agree in some cases, but aliasing is especially noticeable and easy to get with phase distortion, Have you thought about using the sample rate converter class in the Rack SDK to allow optional oversampling of the oscillator? That’s what I did in Warp Core and it makes a big difference even at lower pitches if you have more extreme levels of distortion/modulation applied. With an external phasor signal which comes in at the Rack sample rate, you could probably buffer it and upsample that signal first before processing the oscillator phase lookup/calculations at the oversampled sample rate.


Ratio: ok i will think about and check the effort.

However what about this tiny solution :wink: ratio_formula_one

PHSR2: i my view a phasor is not an envelope generator and has no gate/trig input. making a gate/trig would turn it into a multi function module, which i personally don’t like because i see not much advantage in a virtual rack rather than to have separate modules per use case. Btw: I recommend Formula One with the lseg or eseg function to make such one shot envelopes e.g.

if(st(0,w)>0) { v1:=0; }
var o:=lseg(v1,0,0.3,5,0.2,3,0.5,2,0.3,

see here

MVerb: Yes the noise and pops should be fixed - the saved state will come in 2.1.4

Great news about MVERB - thanks.

It certainly would then be a multi function module, which I think would be great. But I respect your perfectly reasonable view point, and decision. Thanks

i had a look at Warp Core (nice sounds!) - the heavy CPU usage for oversampling has not yet convinced me to do such things for the phase driven oscillators. When looking at 4x oversampling (=7.1% CPU for 4 voices) i can still get aliased sound and so i am still responsible to adjust the parameters so that it sounds fine – not very different to my anti-anti- aliasing approach.

However, cool would be if Warp Core would have a phase input -5/5V (it seems that the ext PM is not a direct phase input) and the phasor output also would be in range -5/5V and never oversampled (as this makes noise in the phase driven oscillators).

Well, that’s why you have the option to disable it if you want to have lower CPU usage. It’s about tradeoffs (though I’m sure with some effort I could further improve the CPU usage - polyphony takes a toll regardless). The optional oversampling strategy is pretty common across software audio processors (VST plugins, especially) that can benefit from oversampling - you have the option to disable it if you wish to save on CPU usage, or you can enable it to achieve a better sound with higher CPU.

It’s a known thing that phase distortion/modulation can suffer a lot from aliasing - Schlappi Engineering even went as far as to build their new Three Body eurorack FM/PM oscillator on an FPGA to run on a sample rate in the MHz to prevent aliasing (which is obviously not feasible in VCV Rack, but still pretty cool!)

I respect that but I don’t necessarily agree. Personally I don’t see there being an equivalence between “I will change my parameters so that I can avoid aliasing” and “I will change the anti-aliasing settings so I can achieve the timbre I want with less aliasing”

Ext PM is not a direct phase input, correct. It’s an additional external phase modulation input that further modulates the oscillator. I thought about adding a direct phasor input but without a system of modules like yours that provide suitable phasors and voltage standards for direct phasor input, it would be a little more difficult to use with intention, I think. And it would change the UX of the instrument, since presumably if that input were connected then the internal phasor (and pitch control, V/Oct input) would have to be disabled.

I could definitely consider making the phasor output -5V/5V, shouldn’t be too hard… thanks for the suggestions

1 Like

Also IMO 7% is not bad for 4 voices on a complex oscillator with anti-aliasing enabled… hard to make a direct comparison but on my machine Vult Vessek uses about twice as much CPU for four voices as Warp Core does at 4x oversampling (10% vs. 5%)

The point is that as i am using this phase driven approach now for a long time and i never had any problems with aliasing (as i almost in no case need a sound which spans the whole piano octaves). The PhS module provides a lot of phase shapers which do not add discontinousities and reduce therefore the aliasing. The phsr2 module also will not add discontinousities if the outer points are not touched and the inner points are not aligned vertically. So i think people could try it out in practice.

ExtPM: In CSOSC, GeneticTerrain,GeneticSuperTerrain,SPL the V/Oct/FM is simply ignored if the phs input is connected – nothing fancy …

CPU: Yes, a long time i thought that GeneticTerrain which uses now after a lot of performance improvements 2-3% CPU per quad voice is incredibly slow but compared to most other modules not that bad … But as i don’t use any daws i.e all is made in VCV Rack i appreciate low CPU modules to avoid using multiple threads.

dbRackModules v.2.1.4 is now in the library:


  • MVerb : Fix audio glitches/clicks/pops. Added menu for setting thread buffer size in threading mode. Default 256 should work on laptops. Otherwise a bigger size can be chosen.
  • Faders : added insert an delete pattern
  • SPL : fixed occasional clicks if driven by phase
  • EVA : Channels are taken now from Gate and In input. The Env output always gets the channels from the gate input and the CV output from the In input.

Ooh, I just discovered the Preset module. :+1:

It took me a few minutes to figure out how to pair it with a target module (i.e. park it to the immediate right), but once that was sorted out it’s very easy to use. (Just beware of fencepost errors. :smiling_face: )

My first test drive with it was to have it select different “QUANT” presets for key and chord changes, controlled by Count Modula’s “Basic Sequencer”.


@docB What are the syntax limits of the JustScaler? From what I can tell, it only loads my scale.json file if I define a scale with no more or fewer than twelve pairs of numbers representing ratios, and it’s OK if these are duplicates. There seems to be a limit to the number of scales I can define - what is it?

I guess my dream function for a module like this would be to be able to scan through a lot more scales - 42 would be nice - but I’d settle to know just what the rules are. Thanks (again) for making these excellent modules!

yes, the main idea of the jt scaler was to convert an already 12-edo quantized v/oct signal to a 12 tone just scale. there is no limitation on the number of scales – the only trick to know is that if the menu exceeds the window height then you have to use the mouse wheel to scroll to the undisplayed scales.

1 Like

dbRackModules v2.2.2 is now in the library

New modules: Osc1, Osc2, Osc3, Osc4, Osc5, Osc6, PRB, SPF, SKF, L4P, USVF, CHBY, AP, LWF, DRM, SWF, JWS, CLP, CWS, RndH2, AUX, OFS and OFS3


Holy cow doc, you’ve been productive. Thanks!

1 Like

The oscillators are super fun!

1 Like

Seems like the new oscillators mostly have alias reduction, but the waveshapers don’t? Or am I getting that wrong?

No that’s correct.

1 Like

dbRackModules 2.3.0 is now in the library.

New modules in 2.3.0: Osc7, Osc8, Osc9, Drum, PPD


Man, I love your modules! Can’t wait to try these out. Thank you!!!