CV in Reason: Getting them basics right – Part 2

Part2introC

In the first half of this tutorial, we were able to see that Reason’s virtual Control Voltage has a lot more precision than one might initially consider and that there’s an optimal range to deal with and refer to when thinking about voltage values in Reason.

Now is the perfect time to look at the different types of CV that communicate between devices, and see if there’s any limitations we should be aware of when planning and designing more complex CV-based solutions.

Control Voltage Signal Types

CV can be used to control various types of device parameter targets.

Some parameters expect smooth variations between -1.0 and +1.0, like Pitchbend, Balance or Pan.

Others expect smooth variations between 0 and 1.0, parameters like LFO Rate, Volume level, Filter Cutoff, etc.

Voltage Signal Types - Back

Some CV inputs may expect quantized (i.e. stepped, non-smooth) voltage values still between 0 and 1.0, like Note CV and Gate CV which basically would only need the 0.0 and 1.0 for Gate Closed/Open or Note Off/On… but there’s more to it than that and you soon will know why.

So, it’s useful to know what Unipolar, Bipolar, Note and Gate are all about.

Voltage Polarity

Part2introA

Unipolar CV sources generate voltage values with only one polarity (example in picture above), expected to be in the positive range, usually from 0.0 to 1.0

Bipolar CV sources generate both polarities, negative and positive values (example below), usually from -1.0 to +1.0

Voltage

Some CV target devices expect Unipolar CV. What happens when a Bipolar signal is given instead, it always depends on the device and how it was prepared to deal with the negative values, as described earlier in “Subjecting a device to CV values above those limits“.

Other devices expect Bipolar CV values and those shouldn’t have any issues dealing with Unipolar CV, which should do whatever the positive part of Bipolar was supposed to do, anyway, unless behavior switching exists (see below).

CVin Polarity Option

Some devices provide the option to choose, usually through a switch, what type of CV is being sent to them or it should be interpreted, adjusting their behavior accordingly.

CVout Polarity Option

Same with some CV generators, where some devices provide the option to choose between Bipolar or Unipolar output.

Note, Gate and Trigger

Note CV sources are supposed to generate a Unipolar quantized version of the usual 0.0 to 1.0 CV range.

A device with Note CV input (sometimes simply labeled as “CV” in the Sequencer Control section), expects a voltage value of 0 (zero) when asked to play “C -2”, the lowest MIDI Note an Instrument should be able to handle. The highest should be “G 8” when receiving a voltage value of 1.

NoteGateInputs

So there’s an implicit quantization process applied to CV that translates it’s natural continuous nature into 128 discrete steps of voltage levels. As another example, MIDI Note 60 corresponding to “C 3” is approximately 0.472 in CV.

Below, we see how a Matrix CV output looks like when playing all the C notes from octaves 1 to 6 at 1/16 resolution, 120 bpm tempo. The green line is the Note CV level and the blue is Gate.

Note Gate Graph

Gate CV sources are supposed to generate a Unipolar voltage signal that can translate into the On/Off state of a Note, so that an Instrument device receiving a CV value above 0 (zero) will know that a note is expected to be heard i.e. played (Note ON event).

Getting a CV value of 0 (zero) will kill the Note being played (Note OFF event).

GateVelocity

In Reason, Gate CV was extended to transmit something else besides a Note state. Gate CV is also used to send Velocity i.e. how hard a note key was struck which can be used to influence another instrument parameter besides the state of a Note. So usually Velocity ends up controlling the volume of the note played but obviously its a control value that can be used to modulate other device parameters.

So because of Velocity being usually transmitted through the Gate CV, I referred to the Gate CV values as 0 (zero) to Off and non-zero or above zero as On, because any Velocity above 0 (zero) will be interpreted as a Note ON state.

TrigIN

A short Gate pulse can also be known as a Trigger CV signal, usually used to start some event, like a Sequence or change a multi-state parameter whereas Gate is expected to keep the On/Off or True/False state of a Button or any other dual-state type parameter.

Is CV “Poly… phonic“?!

AutoTheory

As you can easily figure out, 1 CV wire can only transmit 1 Gate state at a time, unlike MIDI, that can deal with several Note ON/OFF events, achieving the expected polyphony on polyphonic Instruments.

When discussing Control Voltage played instruments, CV is considered to be a “mono-event” type of control transmission because you can only send one state or value, at one specific slice of time.

This is why CV may be referred by some, as being “monophonic” because only 1 Note will be played by that 1 Gate state being sent.

Even when controlling a Polyphonic instrument, in most cases, it’ll basically just play 1 Note at a time, sounding like a “monophonic” instrument, all depending on the sound patch being used (Sustain and Release of the Amp Envelope plays an important part here, but that’s something for a future tutorial).

So, it’s this relation between “monophonic” sounding instruments played by CV and also the fact that real CV is basically used to play monophonic hardware instruments, that explains why usually CV may be called as “monophonic”.

Dirty ‘ol CV Tricks!

ChordCVtrick

In Reason, though, there’s a neat old trick that can fool us (and Reason Polyphonic Instruments) into playing chords through a single pair of Gate and Note CV wires.

It’s still a “mono-event”, somewhat related with a paraphonic scenario, because of Gate CV’s nature, where all notes of a chord will either be playing (All Notes ON) or not (All Notes OFF) but at least the “monophonic” spell is somewhat “broken”.

ChordCVtrickA

This little trick allows building Chords just like you’re able to slowly build them when playing a music keyboard, by holding the old notes as you play the new ones, the difference is that you’re able to lift any finger but with this trick, it’s as if you’re forced to lift your entire hand.

ChordCVtrick2

So, as long as you keep the Gate state Open or On (i.e. Gate CV value above 0, represented by the blue line above), you’re able to hold any Notes sent thus adding them to the Chord. How do you send Notes? You send them through Note CV, a value (i.e. a Note) at a time, as the green line in the graphic above tries to show, the CV values of C3, E3, G3 and C4.

The faster the various Note CV values are sent, the less noticeable the “chord build” process is, sounding like being triggered “instantly”.

This works as long as the Instrument device goes along with it, not killing the previous note as soon as a new Note CV value is received.

All notes in that chord may end up having the same Velocity, depending on how the Instrument deals with Gate CV variations, but as soon as the Gate CV voltage level goes to 0 (zero) then all those progressively triggered notes will be killed, turning off the built chord.

ChordPlay

This is the trick that currently allows Rack Extensions, like Pitchblende AutoTheory (by Mozaic) and Black and Orange AutoArp, send Chords to polyphonic Instruments through 1 pair of CV wires.

Voltage vs Audio rate

AudioVsCV25Hz

Lastly, the rate at which CV values can be sent, is something that can’t be left out from CV basics which complements the initial value precision notions presented here.

In Reason, the virtual representation of Control Voltage values can be as precise as the voltage used in Audio, because… you know, audio also deals with voltage levels. Rapidly changing voltage levels sent to your speakers.

Thus, the most important difference between the “virtual voltage” going through a CV wire versus an audio cable in Reason’s rack is the rate at which that “voltage” level is allowed to change. If you want to know how many times a CV value can change per second in Reason, you simply check the Audio sample rate you have set and divide it by 64.

This limitation is only (but barely) noticeable when using higher rates at which CV values are changed through time but for most purposes, it ends up being a good trade-off to keep as much CPU resources dedicated to audio as possible.

AudioVsCV25HzZoomX10

The two graphics above show the same voltage cycles from an audio source (blue line) and a CV source (green line) both at 25Hz.

You can see that the CV values start to “break up” their “smoothness” when zooming in into the 1/10th of a second time range.

We already know that Reason’s virtual CV is able to work with the same voltage values as Audio does, but not as fast and that’s why we’re seeing those “steps” in the graphic. That’s one limitation in Reason’s virtual CV when compared with Audio as a voltage source.

The rate at which CV values can change, is lower in Reason than the audio rate (as mentioned previously, it’s 64 times lower), so value “jumps” will happen more as values need to change faster.

This is why, at higher rates, we start to lose that value resolution we initially talked about but, again, the speed at which this is happening makes it barely noticeable, from a control or modulation perspective.

If you ever see someone complain or request the ability to do Audio-rate CV modulation in Reason, this is what’s all about, which is something that already happens in devices, internally or… through audio cables.

NEXT!

If CV is all about values, then we surely are able to do some useful operations with and to them and that’s what a future tutorial will be about.  Stay tuned and thanks for reading!

The following two tabs change content below.
Profile photo of Koshdukai
Musically inclined I.T. professional, technically minded Reason user since 2009, with infrequent acts of Sound Designing released in the wild, some captured in Propellerhead Record 1.5, Reason Essentials and Reason 6 Factory Sound Banks as well as in a few Rack Extension factory patch banks. Propellerhead Remote technology coder and enthusiast, having contributed to extending the existing factory Reason maps to new rack devices since 2010.