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!
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.
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.
No problem. You did not confuse me 
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:
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.
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.
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:
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.
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?
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.
I will play with STRIP++ again. It has been a while since I did and I cannot remember why I chose not to use it.
Well, STRIP++ does preserve CV-MAP mappings to ADDR-SEQ step knob params, as long as I remember exactly how to use STRIP++. I had to refer back to your post on how STRIP++ seems to work.
I suppose you are referring to this post.
A suggestion to @stoermelder: Maybe the STRIP++ manual would benefit from a modest expansion, because it is such a valuable module but not straightforward to use without more guidance.
Unfortunately, using CV-MAP setting up ADDR-SEQ to sequence AaronStatic DiatonicCV octave crashed rack and corrupted the patch such that it cannot be reloaded. Reload crashes Rack and the log file shows the fatal error in the Aaron Static plugin. I was able to reload the oatch since I had not saved the modified version, but all of that work is now gone, so, not sure how much farther I will take this. I have not had a Rack crash in a long-long time. I didn’t even get to using STRIP++ to load this selection this time.
