New Polyphonic Utility Module, Looking for Help Testing

I have a new polyphonic utility module that I’m getting ready to submit to the Library: Voly Pector. It allows configuring 16 polyphonic constant signals. Basically 16 copies of Knoly Pobs, but you select which “view” so you aren’t seeing all 256 voltage value knobs at the same time. You can view/edit each voltage for an Output “Band” (the Output cable, labeled A thru P), OR by Output Channel (eg: view/edit Channel 6 for all output Bands. Illustrated in screenshot)

Also includes a scale/offset for each channel/band (allows eg: offset channel 6 of all Outputs by +3 volts, or scale the knobs of Output C by 0.32)

At the bottom, there are inputs and buttons for randomizing, initializing, and “wiggling” (moving a knob by some small amount) with associated scale and probability knobs and CV inputs.

There are 3 trigger inputs for each of randomize, wiggle, and initialize, allowing the operation to be done to everything, per-channel (via a polyphonic trigger signal), or per-output (via polyphonic trigger signal.

Any testing anybody would be willing to do, especially on Windows or Linux would be much appreciated! The v2.3.6 Release Candidate is on Github

A couple more random fixes/updates as part of this release:

Knoly Pobs:

  • Fix saved bipolar main knob values loading as 0 when they were negative

Sloly Pit:

  • Add blank routes and randomization defaults

Debug:

  • Note name / midi note number mode to display, eg: “Db3” or “F#5 - 43”

Development:

  • Add portable vcvmon watcher script
5 Likes

Thank you very much for this really interesting module! Tested in VCV Rack Pro 2.6.6 WIN10.

Maybe I am doing something wrong, but it appears that RAND, WIG and INT via CV-port trigger always affects the first channel (1) or band (A), independent of which channel or band is selected via the buttons. Is this the way it is supposed to be?

Just a small note: I think it’s less intuitive to not place the CV port for RND, WIG and INT ‘all’ next to the respective buttons, but have two other ports in between.

Didn’t find any other issues.

2 Likes

Thanks for testing!

Each of the Init / Random / Wiggle “rows” has 3 trigger inputs:

Left : Randomize All - will randomize all bands/channels (no polyphony)

Middle, under the Channel buttons - Randomize by channel (is strictly polyphonic, I think what you’re seeing is sending a 1ch signal to this is just operating on channel 1)

Right, under the Band buttons - Randomize by Band (strictly polyphonic, a 1ch signal will randomize only Band A)

I think what you were intending to do (randomize everything) could be accomplished by patching to the left-most input.

I thought that the “standard polyphonic behavior” generally found in Rack (a 1ch signal applies to all channels) didn’t seem intuitive for these inputs, but maybe this is also confusing. “Standard polyphonic behavior” would look like: there is no “randomize/wiggle/init all” input jack; a 1ch signal will apply to all; and in order to just randomize ch1, you’d need to wire up a polyphonic signal with your desired trigger on ch1 and a blank 0v on ch2. This seemed weird to me, and I just added the “randomize all” jack.

2 Likes

Thank you for your response!

So, if I understand correctly, ports of the ‘ALL’ inputs (left column) distribute an incoming monophonic trigger onto all output channels, whereas for the middle and right columns, the input is truly polyphonic.

The buttons (1, 2, 3… and A, B, C…) have no impact on which channels/bands are being randomized. If so, everything makes good sense to me now.

It’s a bit ironic for me, because in other modules I often look and long for the polyphonic modulation of input ports, and this time I simply didn’t think of it. :slight_smile:

Also, I now understand better what you mean by “each polyphonic input channel randomizes the matching channel across all bands” in the manual.

So this works perfectly — thank you for clarifying and for another great module!

1 Like

Yes, precisely. Your current “view” (Channel 5, or Band K, for example) has no bearing on what the trigger inputs affect. It does however affect what the built in randomize/initialize functions do (via modKey+R, or modKey+I) - these only affect the current “view”, which I felt made sense, and is why I added the “randomize all” button/trg to provide a way to randomize everything.

Thanks again for the feedback!

1 Like

Working great on Mac/Win.

  1. Here’s a fun, potentially exploitable edge case:

CV-Map will reflect whichever channel/band is selected, and modulate accordingly. The non-selected channels/bnands will hold the values that were present when the channel/band was changed.

  1. It looks like your pretty close to ‘finished’ with the module, but perhaps consider for future update two “voltage addressed” CV inputs - one for “channel #” and one for “band #” so one could sequence/automate the channel and band selection (without manually clicking). eg, “0V = channel (or band) 1” through “10V = channel (or band) 16”.

Love your stuff!!

1 Like

Cool idea, I don’t usually do much MIDI mapping but I see how this would be useful. I think there is (just barely) room to jam one more input jack onto the panel. A couple thoughts:

  1. I think it needs to be just a single CV input: for example what happens if both are patched? Ought it be focused on a Band or a Channel?
  2. For the CV Range I’m thinking to use positive and negative voltage values to focus on Bands and Channels (respectively). So there would be 16 total divisions of 10v both positive and negative, with the 1st division (0v thru +.625v) selecting Band A, and so on up to (9.375v thru 10v) selecting Band P. Values less than 0v similarly scan through focusing on Channels 1-16.

Here is a new build, v2.3.7 with this feature, let me know what you think!

2 Likes