Share your patch selections (.vcvs)

To me, it seems that I use some patch elements quite frequently, so I really appreciate that in VCV Rack groups of modules (‘selections’; .vcvs) including their cables can be saved natively. I often load selections as a point to get started, and then customize them further.

Therefore, I would like to collect and share selections with some basic techniques. These selections are for sure no rocket science, rather they are meant to ease and streamline the workflow. Perhaps you’ll find some of them useful.

If you would like to share some of the selections you are using frequently, please add them here at any time and grow the collection.

Table of Contents (updated periodically)

  1. Sequence chords from DiatonicCV (using ADDR-SEQ)
  2. Sequence chords from DiatonicCV (using eigenvalues)
  3. IONS randomized by CV-MAP
  4. IONS Incremental Randomizer w CV-MAP
  5. Flowing random chords
  6. Shimmer Reverb
  7. Click-Free Audio Looper
  8. CV LookUp Table using docB Formula One
  9. Pitch variation for sequences
  10. Polyphonic LFO
  11. Three irregular LFOs using Glee and Frolic
  12. Polyphonic stepped random

I am starting out with a patch selection that connects five 16-step sequencers (ADDR-SEQ, Bogaudio) to each of the knobs (octave, chord, type, inversion and voicing) of DiatonicCV (Aaron Static) in order to create and control chord progressions.

Sequence chords from DiatonicCV_20240320.vcvs (34.7 KB)

As each parameter has a different input range, values are adjusted accordingly inside the sequencers as well as through Offset (Bogaudio) modules.

The selection uses PatchMaster, so import it using STRIP++ (stoermelder) to preserve mappings.


Yours is an interesting idea and I have downloaded your selection file to play with, since I do a lot of Aaron Static module parameter CV sequencing.

I’m not sure what the best way to approach this issue. As mentioned before, for all of my favorite modules, I manually map out the “eiginvalues” for each parameter, i.e., for each parameter, which discrete CV value will result in what discrete parameter state change. If the module has CV parameter control in-ports, I use those. If it does not, I use Stoermelder uMap to accomplish the same thing. I keep 1 sheet of paper with all of one module’s eigenvalues for each of my mapped modules. I can enter these parameter eigenvalue CVs into either a sequencer directly, or into NYSTHI “Fixed Voltage Source” module feeding the steps of a sequencer or sequential switch, typically Count Modula SWITCH 8-1 or 16-1. which then send sequenced CV to the mapped module parameter CV in-port or to uMap.

I have had very good luck with this method, but, it is cumbersome to map and difficult to share generically, although many of my posted patches use this technique in the patch.

Also, for some modules, I have to use BASICally scripts to provide a CV translation for modules that use different schemes for controlling a common parameter such as diatonic “mode”.

I have a few selection files that encapsulate my eigenvalue and BASICally translation approaches. I really use those as new patch templates though.

Anyway, interesting proposal. .

1 Like

Thank you for responding and for giving insight into your process, which sounds great!

It’s clear that there are many ways to accomplish things in VCV Rack, and the technique always depends on the specific circumstances. So, generic exemplification rarely shows all there is to it, but it may lay the framework from which there can be a plethora of modifications.

Would it be possible for you to provide a link to one of your patches, ideally a straightforward example, further detailing your eigenvalue technique?

In any case, conveying basic principles of patching may encourage discussion and learning, and sharing the ‘selections’ as proposed could (and hopefully will) be a fruitful approach to explore.

Going beyond the first posted example, I really would like to collect, share and possibly discuss basic techniques that can be transported in a basic ‘selection’ file. I could envision anything like ‘how to fade voices in and out at desired points in time’, ‘how to make an arp with a shift register’ or ‘how to create a lush pad’.

Many of these approaches are already out there somewhere, but I think it could be an advantage to just have each of them packaged into a single .vcvs file that can be loaded quickly into a project while patching.

Sure. I am modifying your selection file to use my eigenstate/eigenvalue CV control sequeincing, since I already have the values mapped out. I am documenting the values in Notes modules.

1 Like

Here it is:

Sequence chords from DiatonicCV_20240320 via eigenvalues.vcvs (35.6 KB)

I don’t guarantee that there are no errors in this selection file. The main difference between my approach and yours is that in mine no scaling is necessary and the eigenvalue CV’s will always produce a parameter discrete state eigenvalue. I had some difficulty telling from your selection file what the result was going to be, so I may have selected a wrong eigenvalue.

Thank you! This is a nice alternative way. I can see it being really useful when precise/discrete input values are needed. On the downside, as you said, it may be a bit more laborious to map the eigenvalues beforehand, but I suppose you have to do this only once for each target. Thank you for sharing!

1 Like

In an ideal world, the developer would publish the discrete state eigenvalue CVs. I do this for Meander for some discrete state parameters.

I have a paper folder with eigenvalue sheets for about 30 modules for my own usage. I just used a variable voltage source such as “AS Triggers MK1” to adjust the voltage and record the voltages which are guaranteed to change the module parameter to each discrete state. It takes a while, but as you mentioned, I only have to do it once.

1 Like

That’s great!

I just noticed that I placed the ‘Thank you for sharing’ in a totally wrong spot. I was referring to your patch, not your eigenvalue tables, and at no point I meant to persuade you into sharing those. So, please accept my sincere apology if I caused any misunderstanding.

I have generated some eigenvalue tables on the fly for individual patches using a method similar to what you describe, but never as systematic as you did. It would be great indeed if all developers published their tables without being prompted.

1 Like

No problem. You did not confuse me :wink:

1 Like

I was wishing that Geodesics’ IONS had an input to randomize the step values. Better yet, individual step values. But it doesn’t, so I made this.

The SG16 expansion triggers which of the S&H 8 outputs gets a new random value, as generated internally by S&H 8.

OFFSET scales them to 10%, and CV-MAP passes them to the 15 steps in IONS.

Two problems that still inconvenience me:

  1. I cannot figure out how to zero out the S&H 8 modules other than by right-clicking on them to initialize them, or else by using a burst generator and several other modules (including Sapphire’s MOOT) to quickly step through and set them to zeros.

  2. CV-MAP does not remember the mappings when saved as a selection and later reloaded, so you have to click through and remap it to the 15 steps in IONS. They do survive when you save the patch though.

IONS randomized by CV-MAP.vcvs (14.2 KB)

I have a few other variations, including one that will also gradually de-randomized IONS, but it takes up a lot of real estate and looks messy. It needs work.

[edit] It just occurred to me that better use of polyphonic triggers and random value generators might give me a much more elegant and flexible patch, and an easier way to gradually (or immediately) de-randomize all the steps in IONS.

Now I gotta work on that. Real soon.

[second edit] I just noticed @Alphagem-O’s reference to STRIP++, and went •forehead_smack• - that’s how I fix the mapping preservation issue.


Great approach! For zeroing out, I wonder whether you can invert each value (negative becomes positive and vice versa) and add the result to itself. Haven’t tried it though. It would still require some kind of switching and routing, so it’s probably not more straightforward than what you already have.

I noticed that the .vcvs you’ve posted is different from your pic. Is this the most basic version?

use stoermelder strip++ to load your selection, it loads them with mappings intact

1. CV-MAP does not remember the mappings when saved as a selection and later reloaded, so you have to click through and remap it to the 15 steps in IONS. They do survive when you save the patch though.
1 Like

I wish there was a Count Modula (Sequential) Switch 8-1 expander, but there is not. So often I put a lot of time into developing a complex use case for a module and then find that there is no path forward to expanding past 8 or 16 steps. So, your use of the BGA ADDR-SEQ and ASX modules makes sense as a sequencer but not as a sequential switch.

I may play around again with doing some type of CV mapping to the ADDR-SEQ parameter knobs, but that might be pretty messy.

Well. I could not get uMap working correctly with ADDR-SEQ and ASX. I did get CV-MAP working correctly with your implementation of ADDR-SEQ and ASX, but CV-MAP does not preserve mappings in selection files, so once again I have hit the end of the road and cannot get to my destination from here. I could probably use STRIP++, but I’ve lost my enthusiasm for how get everything working.

I’m not sure what is the best way to flexibly manage selections in a way that the user could easily understand the CV to parameter value mapping for parameter sequencing.

guess a feature request to implement preserving mappings to the Rack folks would be the way to go

Yeah, I don’t know enough about this to know how to phrase the feature request.

Uh . . . Maaaay-bee.

This is the real one (like in my original post), that can randomize it incrementally, but minus the NOTES module:

IONS Incremental Randomizer w CV-MAP.vcvs (22.8 KB)

1 Like

Very nice! Useful.

Actually, I think your eigenvalue method is pretty good for what you are doing.

I’ve had relatively good experiences with STRIP++ and am glad it exists. A native implementation in VCV Rack would indeed be very sweet though.

Another idea: Wouldn't it be good to have a generic knob to the likes of a PatchMaster knob, but with steppy behavior to dial discrete steps?

Ideally, the knob would be flexible, so the user could select the number of steps and assign an output value to each step. I envision a ‘Fixed Voltage Module’ but in the form of a compact knob, values being assigned in the context menu.

Stack 8 knobs similar to 8Vert, only with steppy response.

A little number display would show the currently selected step# and another one would display the highest possible step (so e.g. showing that step 7 of 12 is selected)

Or, if the number of steps cannot be handled flexibly, have a series of knob modules with a fixed number of 3,4,5,6 etc. steps.#

Just brainstorming :face_with_spiral_eyes:. Does that make any sense and would something like it perhaps be doable?


Another selection: Soft random chords

Flowing random chords_20240322.vcvs (43.2 KB)

Creates random in-key notes that flow into each other to form ever-changing chords. Each note has its own volume AD-envelope with individual cycle and length. An envelope will re-trigger only if it has completed its previous cycle.

Start by pressing the Start/Stop button of the Fade module.

Rate and Probability sliders of the Random module determine frequency of envelope triggers. Lower values will produce more pauses and longer periods of silence.

Adjust AD parameters in the 8 Attack Decay module to shape envelopes.

Adjust settings in Slew module for additional stereo effect.

Button in the Re-Burst module synchronizes envelopes to some extent, although they may drift apart again very soon.