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.
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.
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.
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.
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!
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.
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.
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:
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.
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.
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.
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.
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 . Does that make any sense and would something like it perhaps be doable?
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.
. Does that make any sense and would something like it perhaps be doable?