fuzzix patch thread

[fuzzix]

This one might seem a little obvious, but my template patch has expanded to include a MIDI Controller mapping facilitated by MindMeld PatchMaster and some stoermelder modules. I had the idea that if I made a PatchMaster layout that looked like my controller and had big labels, it might make the mappings for performance a bit clearer, and a bit more flexible. The template patch is now pretty much the top two rows seen here:

My MIDI controller is a very cheap model (a clone of a Korg NanoKontrol 2, which is already cheap…) with four switchable “banks”. I laid out four copies of its knobs in PatchMaster. MIDI-CAT has “pick up” mode and ranges set up to work with PatchMaster when banks change and CCs are moved from their previous value. It also has a little slew by default for each CC to try smooth out the MIDI stepping … I tried to balance responsiveness and smoothness (Does VCV MIDI-MAP do a better job of smoothing? It felt a bit more “dynamic”, but that could all have been in my head).

I mapped slider CCs to the mixer, with a limit of 79.4% in MIDI-CAT so they hit ~0db at MIDI value 127. They also got reversed because they were in the way while using knobs … so to reduce volume of a channel I have to move the slider up .

The final piece is GLUE to add labels relevant to the current patch. PatchMaster has labels on its controls, but I think GLUE labels are easier to pick out at-a-glance.

This means my default template patch has a sensible MIDI set up straight off, and creating mappings is much more obvious about what on the controller maps to what in the patch… I think…

There are some commercial modules in this patch, but the free ones should give you an idea of what’s going on:

Roland B0B.vcv (7.5 KB)

Hope someone finds this idea useful

[fuzzix]

Within the pattern of using a S&H to pull a bass note from a sequence, there may be a concern that the range of notes sampled will fall outside the range for a nice bass. A common approach to limiting the range of notes is to use a VCA and re-quantize to the same scale as the sampled sequence.

There’s something I don’t quite like about this, but I can’t put my finger on what it is. Forgive me if the below is so common that it’s barely worth mentioning, but I thought a little about using octave shifters and comparators to constrain the octave range of the bass voice:

The S&H / bass parts are lined up beneath Orca’s Heart. From left, we have the S&H, the output of which is instantly lowered 4 octaves.This goes to the A of a comparator, with B’s offset at -2V. It also goes to a second octave shift, which lowers the signal by a further octave. Each octave shift is sent to the logic switch (LGSW). The comparator’s A > B output is sent to one of the logic gates of the LGSW, which is in OR mode.

The end result is, we get the -4 octave sampled V/Oct signal to the bass voice unless that goes too high, in which case the comparator instructs the LGSW to switch it out for a -5 octave signal.

Sample and hold V-Oct with range limit.vcv (2.3 KB)

[auretvh (Auret Van Heerden)]

A very nice setup to control a voltage range.

I think I was trying to something similar here:

Expeditions in Space and Time

Fun with Quantizers So I was inspired by this post: to try to create a patch that restricts chords to a certain range. This is as minimal as I can get it: [Chord1] So this keeps your chords within a one octave range, so if a note goes above the range, it drops it per octave until it is in range. And if it goes below the range, it raises it. You can set the range low cut using the bogaudio REFTONE module. The range high cut is an octave above this. Playing with this can give some interestin…

But in the end I found a module that does this already. Orange Line Fence. It keeps your note CV within a certain range. This might or might not work for you? But I like your approach.

[fuzzix]

It took me quite a while to figure out what was going on there (still not quite sure I have it completely) - great patching!

Fence will do the same sort of thing, though where’s the fun in that?

[fuzzix]

Tiny bit of fun hackery today, more to wrap my head around the vagaries of 14-bit MIDI CC (not NRPN) than actually achieve anything useful. If you need 14-bit MIDI, the MIDI CC > CV module already supports it so just use that.

14-bit MIDI CC relies on sending a pair of CC messages, where the first CC is a control from 0-31, and the second is that control + 32, e.g. if adjusting CC 6, a message would also be sent for CC 38. CC 6 would contain the most-significant byte (MSB - you can think of this as coarse adjust), CC38 would contain the least-significant byte (LSB - the fine adjust).

Step 1 was to write a script which swept through a handful of MSB values to sweep across a few (nominal, possibly not actual) semitones:

#!/usr/bin/env perl

use v5.38;
use MIDI::RtMidi::FFI::Device;
use Time::HiRes qw/ usleep /;

my $midi = RtMidiOut->new;
$midi->open_port_by_name( qr/14bithaxx/ );

my @semitones = 0..3; # These are not "note on" / "note off" MIDI messages - i.e. not note values!

while ( 1 ) {
    for my $semitone ( @semitones ) {
        for my $microtone ( 0..127 ) {
            $midi->send_message_encoded( control_change => 0x00, 0x20, $microtone );
            $midi->send_message_encoded( control_change => 0x00, 0x00, $semitone );
            usleep( 10_000 );
        }
    }
}

This script sends a “microtone” (or fine adjust) value from 0-127 on CC 32 for each of the “semitone” (coarse adjust) values 0-3 sent on CC 0, taking a little over a second to sweep through the fine control values.

Step 2 was to constuct a patch which mixed the MSB + LSB pair into a single value. This is done here with CVMIX, with input 1 set to 100% and input 2 set to 0.78% (roughly 100 / 127). MIDI CC > CV is also handy for this as it allows you to enter CC values with the computer keyboard - it doesn’t require MIDI learn.

This resulted in an audibly smooth sweep, to my ear, but we can see from the yellow trace on the scope that it’s not as smooth as it could be - see the sharp downward spike as the note changes (note change is observable on the blue trace). The fine control is reset to zero before the coarse control is set to the next semitone. The discretisation of messages isn’t really 14-bit - we don’t have a complete pair of values before setting the CV.

The final step was to place MIDI CC > CV in 14-bit mode to see if CC0 would be treated as a smooth sweep across our semitones. The answer is … no! We can see significant jitter when switching between MSB values.

A fix was found in switching the order of LSB/MSB CC messages - I updated the script to send the semitone / coarse / MSB value first (this did not fix the “spike” issue in the hacked together CVMIX 14-bit - the spike just went up instead of down. We have the same discretisation problem either way - we don’t react to complete messages, just partial ones). Some previous discussion of 14-bit MIDI CC, potential MIDI specification ambiguities, and its implementation in Rack can be found on this forum.

In short, if you’re thinking about going 14-bit, try slew first

14bit.vcv (1.5 KB)