Digital Logic in Reason: 8-bit Full Adder

On the Propellerhead's Users Forum, user fieldframe likened my 16-bit counter to a calculator that some clever person had implemented in the successful PS3 game "LittleBIGPlanet":

It was a very generous comparison - I'm sure that person spent a lot longer than I did on their amazing creation. I'm not going to go to such extraordinary lengths to do anything like this in Reason. Well, not for a little while anyway, but it did give me the idea to implement a simple 8-bit adder.

This article contains some introductory explanations of digital logic - you may already know some or all of this, but if you don't then I hope you find this informative.

An 8-bit adder takes two 8-bit binary numbers, and adds them together to give a result. For example, 85 (01010101b in binary) summed with 60 (00111100b) gives 145 (10010001b). I'm only concerned with unsigned numbers in this article.

The heart of the classical digital adder is the 1-bit full adder - a relatively simple device that takes three digital inputs and produces two digital outputs:

• A and B are single bit inputs representing the two 1-bit numbers to be summed ("addends")
  
• input Cin is a single bit input that is usually tied to zero but can accept a carry overflow from a previous adder unit when multiple adders are chained together.
  
• output S is a single bit output that is the binary sum of A and B.
• output Cout is a single bit output that is high if the sum resulted in a carry.

This image is used under the Creative Commons Attribution ShareAlive 3.0 license.

This device is combinational rather than sequential or synchronous because it makes no use of internal state - there are no flipflops or clock signals. Everything happens as soon as the inputs change. A counter is (usually) a sequential circuit - it has internal state (the current count) and that only changes when the clock rises. Generally, sequential circuits are much more interesting than combinational circuits, but you need working combinational circuits to create interesting sequential circuits, so for this project I'm concentrating on creating a robust combinational device.

Quick aside: A OR B (inclusive OR) means (A or B) or (A and B), whereas A XOR B (eXclusive OR) means (A or B) but not (A and B). i.e. one or the other but not both.

A 1-bit Full Adder outputs:

• S as high if A and B are different and Cin is low, or A and B are the same and Cin is high. i.e. (A XOR B) XOR Cin.
• Cout as high if either A & B are both high, or (A XOR B) and Cin are both high.

The schematic for this circuit can be drawn as:

By placing multiple Full Adders together side-by-side with their Carry inputs and outputs connected it is possible to create a wider Full Adder, such as this 8-bit one:

This image is derived from this source and distributed under the same Creative Commons Attribution ShareAlike 3.0 license.

Each bit of addend A (A7..A0) goes into a separate 1-bit Full Adder along with its counterpart from the other addend B (B7...B0). The result is simply the collection of outputs S (S7...So). However, in the event that this eight bit result overflows, the last carry Cout will be set, so the result is essentially a nine-bit number Cout + S (CoutS7...So).

This is essentially the way I've constructed my 8-bit adder, which you can play with here.

For the purposes of my demonstration, to set the 8-bit inputs A and B the following section in the rack is used:

Each input has two combinators associated, with buttons labeled 0 to 7. These represent the bits within the 8-bit input number. Each bit in an unsigned binary number has a weight dependent on its position. Button 0 is the least significant bit with a weight of 1, and 7 is the most significant bit, with a weight of 128. The value of a binary number is the sum of the weights for positions where a 1 appears and these eight buttons can be used to set this. Therefore the buttons represent the ones and zeros in an 8-bit unsigned binary number.

For example, the following represents a digital 0 input:

00000000b = 0*128 + 0*64 + 0*32 + 0*16 + 0*8 + 0*4 + 0*2 + 0*1 = 0

Whereas this represents 71:

01000111b = 0*128 + 1*64 + 0*32 + 0*16 + 0*8 + 1*4 + 1*2 + 1*1 = 71

And of course this represents 255:

11111111b = 1*128 + 1*64 + 1*32 + 1*16 + 1*8 + 1*4 + 1*2 + 1*1 = 255

By setting up A and B, you'll see the sum on the "A + B" Vocoder near the bottom. This example shows 85 + 60 = 145:

01010101b + 00111100b = 10010001b

This example (255 + 1 = 256) shows what happens when the eight bit sum overflows into the final carry output, and becomes nine bits:

11111111b + 00000001b = 100000000b

So how did I construct a 1-bit Full Adder? Look at the schematic diagram again:

You'll notice that the device is made up from two XOR gates, two AND gates and an OR gate. I already have these from my 16-bit counter project, so I can simply wire them up here (after fixing a minor bug in the AND gate):

Because I was able to implement two XOR gates and two AND gates in a single Thor instance, I only need three Thor devices (XOR2, AND2, OR2) to implement this adder. Cool. But what's that fourth Thor for?

It turns out that in Reason, CV signals are not limited to the operational range 0-127. It appears that, with Thor at least, it is possible to go beyond these limits to some degree. As the value gets bigger it eventually reaches a point where the Thor "mod scaling" fails if it uses this value. Normally an input signal of zero scaled by a CV value of 127 gives zero, but if the scaling factor is high enough it seems that Thor's multiplication goes a bit nuts and zero times a large CV value is some other large CV value. This causes the AND gate to fail - you get: (low AND high) gives "high", which is wrong.

In this application, there are four upstream logic gates (Thor instances) that contribute to the Cout signal and this seems to push the CV value too high when all the inputs are high. So the final Thor is used to hard-limit the final Cout output to the range 0-127, using the hard-clip mode of Thor's shaper with minimum drive. Therefore the nasty large CV value is squashed back into the expected 0-127 range and everything downstream works properly again.

The shaper buffer.

For a bit of fun, this is what part of the back of the rack looks like once everything is wired up:

:)

After all that, what use is this adder? Well, for one it helps validate my logic gates - the more things like this that work, the more confidence I have that my designs are working properly. Secondly, with a few changes, this will be the basis for a subtractor, which will then allow me to differentiate a CV signal, which is a measurement of the signal's slope at a point in time. This opens the door to CV integration, where CV signals can be integrated over time by simply keeping a running sum. This is essentially the same as measuring the area under the curve. Integrators and differentiators are an important part of many circuits, including feedback systems, so perhaps I can find some musical use for this yet.

Of course, if you have any good ideas, please let me know or feel free to try building something yourself with the files and ideas I've shared.

For reference, I include my combinational logic gate test-bench (version 0.0.4) - bipolar NOT, XOR, AND and OR gates for your use. Enjoy.

Files in this post:

• 1-bit Full Adder-0.0.2.cmb
• 8-bit Full Adder testbench-0.0.2.rns
• Shaper Buffer 0.0.1.thor
• bipolar-logic-gates-0.0.4.rns

The examples in this article require Reason 4 or newer.

Digital Logic in Reason: Updated Flipflop & Counter

Thanks to everyone here and in various other places for the great feedback on my 16 bit counter. I completely appreciate that this 'invention' is somewhat esoteric at this point - it's not even obvious to me what one might actually use it for. However I do have some ideas brewing and that's led me to slightly refine my flipflop slightly.

The new version (0.0.3) has more consistent assignment of the input and output ports, with a "pass-thru" output port for each of the three (clock, reset, data) input signals. The signal on the input port simply appears on the output port, immediately and unchanged. This allows you to easily chain together multiple flipflops without having to create large banks of CV splitters.

The main state or "Q" output has been moved to CV Out4. The mandatory wire between Audio Out1 and Audio In1 remains - remember that you have to add this manually since it is not saved as part of the .thor patch.

The "beep" button can be used to help debug the operation of the flipflop - to use this, connect a wire from Audio Out4 to a mixer channel, then click the "beep" button and you should hear a beep on each rising clock edge. The tone changes depending on whether the Q output is high or low.

To demonstrate that this flipflop still works, I have included a test-bench and an updated version of the 16-bit counter. Both use version 0.0.3 of the flipflop throughout. I've also included the 4-bit counter combi patch.

I have yet to analyse the setup- and hold-times for this device. The internal 7.9ms delay will definitely limit the maximum speed that this device can run at. If I used an external DDL-1 I could reduce the delay to 1ms but that would mean either putting the entire device inside a combinator (which I want to avoid for as long as possible), or ensuring an external DDL-1 is hooked up to every flipflop.

There was also a slight bug in the AND2 device - this has been fixed in the files above (bipolar and2-0.0.2).

Stay tuned for more digital logic posts.

The examples in this article require Reason 4 or newer.

Synchronous Digital Logic implemented in Reason 4

Updated - Digital Logic in Reason: Updated Flipflop & Counter Correction - FF pass-through outputs are CV Out3 and CV Out4 (not 2 & 3) for clock and reset respectively. The diagram is incorrect for version 0.0.1.

This is the sort of post where you either understand what I'm talking about, immediately realise the huge implications and your brain explodes, or you don't know what I'm talking about, in which case none of this will make much sense. Late last year, I spent a considerable amount of time working on an idea. I wanted to see how far I could get implementing some sort of "digital logic" with Reason4 devices. You know, the sorts of things that make computers and electronics work. I wanted to use CV as a kind of "voltage" and create both combinational logic gates (e.g. AND, XOR) as well as sequential logic (flipflops) so that I can combine them to create various complex devices such as finite state machines or digital adders. This is the sort of thing that electronics engineers like myself think about... I had grand plans for this stuff, but time ran out for now. Therefore I'd like to post what I have to date so that people can pick this up and run with it if they think it's interesting. I did manage to get things working quite nicely - I believe basic finite state machines are definitely possible and to prove this I created one of the most simple of all - a counter. Behold, my 16-bit digital synchronous counter implemented entirely with Reason devices!

RNS file: 16-bit Digital Counter

This design is based on the standard synchronous counter implemented with D-type flipflops, as described here.

Schematic.

In order to achieve this, I had to design a suite of simpler devices such as AND and XOR gates, as well as synchronous elements such as a clock generator and a flipflop. I set myself some goals:

1. each device must compose of no more than a single Thor instance. No combinators allowed because I wanted to put groups of these devices inside combinators without messing around with combi programming.
2. ensure the devices are designed to run at the fastest Reason CV oscillator rate - 250 Hz. Not very fast really, but fast enough for what I want to do.
3. ensure that the flipflops act as registers, not latches. The output should only change on the 'clock edge'.

An important question I had to resolve is whether to use unipolar (0-127) or bipolar (-64 to 63) CV signals as representations of digital logic levels. After a lot of messing around with unipolar CV, I eventually gave up and tried bipolar CV instead. It was much easier and this is what I'm now using. If anyone is interested, here are some unipolar combinational logic gates, but I failed to construct a reasonable flipflop. Bipolar input signals need to be specially constructed, so I designed a bipolar signal source and bipolar clock generator to produce the right CV signals. I'm not going to go into the intricacies of the combinational logic devices, but here is an interactive testbench (RNS). Click the Thor buttons labeled A, B, C and D to generate logical input signals...

then select your function from the Function Select combi (only choose one at a time!).

You should see the result in the Outputs combi. Some devices incorporate multiple gates, and are named as such - e.g. AND2. In this case, inputs A & B correspond to output W, and C &D correspond to output Y. For the NOT4 device, A corresponds to W, B to X, C to Y and D to Z.

You should be able to verify these basic logic operations pretty easily with this testbench. The flipflop (FF) is a much more interesting device, and is the fundamental building block for synchronous logic. I won't go into the details of an ideal D-type flipflop, but one characteristic that is crucial is that the output only changes on the rising clock edge (i.e. when the clock transitions from low to high, in this case).

This testbench shows a single flipflop in operation. The clock is running at about 1 Hz and you can hear and see this in the Monitor combi. You can change the clock rate with knob 1 on the Inputs combi. You'll also see four buttons:

1. reset - used to set the FF into a known state - set the button for at least one clock cycle, then unset it. It is a synchronous reset.
2. data - the input signal that the FF will sample on the rising clock edge and hold.
3. enable - used to turn the clock on or off. This version of the clock generator does not implement this correctly.
4. beep - simply for audio feedback, turn it off if you prefer.

Below, the MONITOR combi shows four button-lights. The "FF Output" is the critical signal, and it should change to whatever "data" is set to, but only when the clock goes from low to high (i.e. just as the CLOCK button lights up).

The FF has 3 inputs on the back panel:

1. ROTARY 1: incoming data that will be sampled and held on the rising clock edge.
2. CV In1: the clock signal - a bipolar CV signal in the shape of a square wave.
3. CV In2: the reset signal - active high, synchronous, sets the FF output to low.

The FF has several outputs:

1. CV Out1: the sampled and held output.
2. CV Out3: simply a pass-through for the clock for chaining FFs together.
3. CV Out4: simply a pass-through for the reset for chaining FFs together.
4. Audio Out4: this is for an optional 'beep' sound that helps debug the FF operation. You can leave this disconnected.

Correction - pass-through outputs are CV Out3 and CV Out4 (not 2 & 3) for clock and reset respectively. The diagram above is incorrect. NOTE: when you save a Thor patch, it does not save any rear-panel cables. For the FF to operate correctly, you must connect AUDIO OUTPUT 1 to AUDIO INPUT 1 with a single cable.

This FF works by using a little trick to store state information. The incoming data value is used to set the transpose level of the Step Sequencer. However Thor will only remember this value when the Step Sequencer is triggered by the clock incoming on CV In1 going high. If we stopped here, there would be a problem. The FF output must only change when the clock edge rises, so it must not be transparent to changes on the data input when the clock is high. I forget exactly how I solved this, but I end up converted the stored value (transposed note value) into an audio signal, passing it out of the Thor via a very small delay, taking it straight back in again and converting it to an output CV value. This also creates a very short propagation delay that prevents the FF output from changing simultaneously with the clock edge - if it did, then downstream FFs would see their input value change too soon and that would be bad as it would make all FFs transparent on the clock edge. Then I simply took the FF and combinational devices and connected them to create 4-bit counter combinators.

By chaining four of these in series, via the carry bit, I created a 16-bit counter. I had to add a FF in-between 4-bit counter to buffer the signal and ensure the first FF in the next 4-bit counter would sample accurately - probably an issue with the way Reason handles CV internally in large networks. This does add extra clock cycles unfortunately, but there may be a cleaner way to buffer between these counters. The BV512 vocoder display is used to display the 16-bit value - you can see the least-significant-bit on the far right, and the most-significant-bit on the far left. It takes some time to reach its maximum value before rolling back over to zero.

This was a very interesting little project and I was immensely satisfied to create a functioning 16-bit counter. Unfortunately other things came up and I lacked the time or energy to take this further, but I envisioned the following projects using these components:

1. a simple finite state machine that can change CV values in response to events - essentially a way for things to change over time in a programmatic way. One example might be a CV signal that changes after a number of events have occurred.
2. a multiplexer design that allows the selection of multiple incoming CV signals so that only one (or a set of several for multi-input muxes) passes through at a time. This would allow programmatic selection of various control signals in real-time.
3. hundreds of other little ideas spinning around inside my head.

I also learned a valuable lesson - in future, when creating many, many different devices with different functions, keep a log! That way you know what these things all are when you look at them again six months later. Sigh. One final note. It is known by some that if you have a NAND gate (negated-and), you can implement any combinational logic function with just NAND gates. I've provided a NOT and an AND gate; the NAND should be trivial. Good luck! RNS files in this post:

• 16-bit digital counter
• Logic gates testbench
• Flipflop testbench
• Unipolar logic gates testbench

You can pull the device patches directly from those files - I do not plan to publish individual patches separately. One last comment - although my demonstrations use Thor buttons in a combi for visual feedback, this is for illustrative purposes only. It's important that the "digital" CV signals sit on the rails - i.e. -64 and +63, or whatever the equivalent scaling is. The Thor buttons in a combi are only on when the signal is at the top rail, but off for all other values. To properly debug any use of these devices, I recommend using the CV Monitor instead of "Thor buttons", and ensuring that the relevant Delay display is either "1" or "2000" and nothing in-between, otherwise these errors will propagate and eventually cause problems.

The examples in this article require Reason 4 or newer.

My Take on the Glitch Device

There have been a lot of fantastic beat-repeating, loop-mangling glitchy effects devices around lately. I thought I'd design my own device, with a few special features of course :)

I don't have a clever name, so I just called mine the Glitcher. Like most of the other devices, mine uses dynamic delays to create the sonic effects, and a bunch of CV routing to tie it all together.


Link: Glitcher 0.0.5.ogg

I'm not going to give an explanation of how it works, but I will outline the main interface and features.

Interface:

• you connect this device like a standard effects combinator - sound goes in, sound comes out.
• hit a MIDI note to trigger the effect. The actual note or velocity has no effect at this time.
  
• use the Mod Wheel to dynamically change the effect when triggered by altering the delay.
  
• use the Pitch Wheel to split the effect between left and right channels, for stereo fun!
  
• obviously you can use a piano-roll track to control the effect in the sequencer by recording these inputs.
  

• knob 1 - "Dry/Wet" should generally be left alone. This is driven by the combi itself to sample the input signal and begin the looping.
• knob 2 - reserved, currently does nothing.
  
• knob 3 and 4: L & R "Delay Offset" - these are used to control the internal delays and should generally be left alone.
• button 1 - "ModW / Internal" - switches between control of the delay by Mod Wheel (off), or internal control by the "Delay Matrix" (on).
• button 2 - "steps/ms" - switches between delay increments in steps (off) and milliseconds (on).
• button 3 - "Fine / Coarse" - switches between fine delay control (off) or coarse delay control (on).
• button 4 - "DelayMatrix / LFO" - switches the internal source of the delay signal between the internal "Delay Matrix" or the Malstrom's LFO A.
  

So what can you do with this device? Well, this RNS demo provides an example of the Glitcher messing around with four different Rex loops. The automation switches between different modes of operation and the effect is pretty clear.

A few things to note about this device:

• generally, you can simply hit keys on the keyboard and twiddle the Mod Wheel to get some cool effects.
• the pitch wheel is set up to split the delay unevenly between the left and right channels, creating some interesting stereo effects - try it with the Mod Wheel!
  
• the "Fine / Coarse" switch can be used to choose between a quite regular and controllable effect (fine) and a more chaotic and unpredictable one (coarse). I find the fine mode to be easier to control in real-time.
  
• if you engage "Internal" mode (button 1), the effect gating is now controlled by the "Gate Matrix" - use curve values of non-zero to trigger the effect. You can change the number of steps and resolution to make things more interesting.
• when "Internal" mode is engaged, the delay modulation is governed by the "DelayMatrix/LFO" mode - either the "Delay Matrix" controls the delay modulation, or the Malstrom's LFO can be used instead. The LFO has been biased to operate over the same range as the Mod Wheel. Try different LFO patterns for some cool sounds.
  
• The arpeggiator labeled "Gate Control" is used to control rhythmic gating effects when using keyboard control - simply modify the pattern (i.e. click pattern steps on/off, or automate the Pattern Value) and hold down a key.
• The Thor instance is purely for CV calculations, and uses a global envelope to smooth out the gate edges a bit, avoiding some of the nasty brick-wall clicks you get with other glitchers.

Thanks to Peff for the Equal Power Crossfader that I made good use of in the demonstration file.

Current version is 0.0.5:

• Combinator Patch
• RNS demo

Have fun!

OffSiteNoise - inudge

Just a neat little musical toy to play with :)

OffSiteNoise - Resonant Filter

L.72 just posted an interesting device on the Propellerhead User forums -

"a CV Delay combi geared towards drums and is a new take on dub with a bit of glitch thrown in for good measure."

This led me to his new blog at:

http://resonantfilter.blogspot.com

This blog has only been in existence for a month but already has over 20 posts - all well written and thoughtful. There's a good variety of technical and artistic articles covering subjects like Reason, Record, real hardware, musical opinion and a few other bits and pieces. There's a good assortment of interesting pictures and linked videos too. If the current posting rate continues, the site will be a very interesting place to regularly visit if you're interested in a broad range of musical technology and techniques.

Shultz's Triple-X Fader

Last month on the Propellerhead Users Forum, Shultz (aka E-Note) posted an innovative device that allows a crossfade between four different audio sources. Essentially, as the mod-wheel is moved through its range, the output audio fades between each adjacent input. I would like to try to explain how this device works for the benefit of everyone else.

Figure 1 - Shultz's Triple-X Fader

The key behind this amazing device is Shultz's clever use of the Thor Shaper. According to the Reason manual, the shaper distorts incoming audio in various ways, and also suggests a certain random element for some algorithms. One of the shaping algorithms is the Rectify function. This is a very simple function that resembles a diode or 'absolute value' function - the output signal follows the input, except when the input is below zero. In this situation, the output signal is inverted. This means it never falls below zero. Figure 2 shows this relationship.

Figure 2 - rectification function

The fading is performed by the Level CV inputs on the back of the Mixer. Each of four channels are driven by a CV signal that consists of a single peak. Each peak is distributed evenly across the mod-wheel domain, so that each channel will be at minimum attenuation (i.e. maximum volume) at a distinct point of the mod-wheel. When one channel is at maximum volume, the other three will be somewhere below.

Figure 3 - Thor programming

The Triple-X Fader consists of two Thor devices, each handling one half of the mod-wheel range. Each Thor performs almost the same function except that different DC signals are combined with the shaper input signal to offset the domain to either the upper or lower half.

Figure 4 - first peak

Figure 4 shows how the first peak is created. On Thor1, CV Out1 is a direct inversion of the mod-wheel added to a constant DC level. This results in a signal that starts at 41 with the mod-wheel input at zero, and falls linearly as the input increases. It crosses zero at an input value of 41. This results in mixer channel 1 at maximum amplitude when the mod-wheel is at zero, and falls away to silence as the mod-wheel increases.

Figure 5 - second peak

Figure 5 shows how the second peak is created. In this case, the mod-wheel input is inverted and fed into the shaper via Filter1. Note that the Thor sequencer is set to run constantly, which keeps a voice "open" and therefore holds the filter & shaper open. A positive DC offset is also added so that the signal into the shaper starts at 41 when the input is zero. This signal also falls to zero as the input increases to 41 and proceeds to go negative for greater values (black line). The shaper rectifies this signal (makes it positive, if negative), so that for input above 41, the signal now increases away from zero (blue line). The return signal is then inverted (turned upside-down) and a positive DC offset is added to raise the peak (red line) up to the same level (41) as the first peak. Clever huh?

The other two peaks are created in the same manner by the second Thor device. However the DC offsets used are different, which positions the peaks in the top half of the input domain. Also, the last peak is an increasing function of the input signal - it increases as the mod-wheel increases.

Each peak signal drives a separate mixer channel, but figure 6 might help you understand how they fit together.

Figure 6 - combined mixer control signals

One major shortfall of Reason is the lack of CV computation. It is very difficult to create even basic CV functions. Thor provides a way to implement addition and subtraction, and now it also provides an absolute value function. Shultz has demonstrated a very clever use of this in his 4-channel fader.

He has kindly granted me permission to provide a link to his Triple-X Fader here.

Update - Noise Gate

A quick and minor update to my Noise Gate.

I've added a Side Channel Monitor button, that allows you to switch off the main audio input and listen directly to the Side Channel input. This may be useful for setting the level of your gate triggering signal.

Version 11:
The updated Combi patch is here.
The updated Calibration RNS file is here.

Update - CV Monitor Tool

A quick update to the CV Monitor Tool.

presiato posted an improvement that allows the four Rotary inputs to be used for bipolar CV signals, rather than the unpleasant truncation that occurred in version 0.0.3.

His original post is here (if you have access to the forum). Many thanks for the improvement!

I have posted the improved CV Monitor Combi patch here:

CV Monitor Tool 0.0.4

Note that the display range is set from 1 to 2000 - this is because a direct mapping between a bipolar CV value and the DDL numeric display does not seem possible. You can get pretty close, but it's often out by 1 or 2. To ensure that this inaccuracy does not confuse anyone, I deliberately extended the range to approximately 1000 in either direction. Feel free to consider this +/- 100.0% if you like. Note that the mid-point is now 992 (for a CV value of zero). I realise this isn't ideal, but it's due to inaccuracies generated by rounding within Reason.

If you can improve it, please let me know!

OffSiteNoise - Peff's Scream4 Waveforms

One of the things I want to do with this blog is direct readers towards interesting articles written by other people. I will call these OffSiteNoise posts. They will probably be Reason-related, although some may cover more general topics like music theory or audio synthesis theory.

So here's the first OffSiteNoise post!

Following my previous post about the Scream4 tape phase inversion, I wish to highlight the observations reported by Peff for the other Scream4 distortion algorithms. You can read all about it with pretty pictures of mangled saw-teeth right here.

Scream4 Tape Algorithm - Phase Inversion

Peff points out here that the Scream4 'tape' algorithm has an effect of inverting the output waveform at lower frequencies. This can have the effect of canceling with the original signal if mixed back (e.g. as a Send Effect). He posts a couple of solutions and a good example that illustrates this "feature".

I have seen many examples where the tape algorithm is used on drums - this is definitely something to keep in mind if you're not using it purely as an insert.

I did my own test with an Oscilloscope application, listening on my sound-card's "stereo mix" or "What U Hear" channel, and as you can see in Figure 1, mixing the 'taped' signal with the original (blue) cancels out a huge part of the original signal (red). Only the higher frequencies remain.

Figure 1

My test RNS file is here.

Blog Review: boddicker.org

Today I came across boddicker.org, via a new Side-Chain Compression tutorial posted on ReasonTutorials.

boddicker.org is dj.boddicker's site. I don't know any more about this person than what is there, but what really struck me is the small but notable collection of Reason-related posts.

These devices are great. There's the side-chain compression tutorial I mentioned earlier as well as:

• a nifty resonator device
• an awesome glitch/loop device
• some great sounding bass patches
• and more

The RNS files are provided, as well as demo music files, so have a listen!

What impresses me is how simple in concept these devices are, yet so elegantly constructed. Even better, the examples provided are top-notch and illustrate the devices perfectly.

There is also a small collection of high-quality tutorials, not all related to Reason, that are very interesting and well written. In particular, "how to make drums sound bigger" answers many questions that confound the search for good rhythms.

Great site dj.boddicker - looking forward to trying out your future creations!

Dual Edge CV Gate

Allow me to introduce a rather unusual device. I'm not sure if a proper name exists for this, but I have decided to call it a "Dual Edge CV Gate".

Figure1

RNS File

Combinator Patch

Actually it's not really a gate - it's more like a switch. The device is designed to switch on or off depending on the input CV signal. When the switch is on, it will output a high CV signal (127); when off it will output a low CV signal (0) . There are two thresholds - lower and upper, such that if the input signal is between these thresholds, then the switch is on. If it is below the lower threshold, or above the upper threshold, then the switch is off. Figure 2 illustrates this relationship.

Figure 2

It would be fairly straightforward to extend this switch to control a gate which passes or inhibits the original input CV signal. This way you would get a 'piece' of the input CV signal for a particular domain, instead of a straight on/off value.

So how does it work?

Figure 3

Well, once again the Thor synthesiser is more than just an audio synth. Inside a Combinator and with some careful routing rules, Thor is able to implement two step functions. One of these step functions is flipped over. When combined with a logical "AND" operation, the result is a pulse, as illustrated by figure 3.

Figure 4

Figure 5

Figure 4 shows a simplified view of the cabling connections on the rear of the device and figure 5 shows the Thor configuration. The input CV signal is connected to the "CV Input" Spider CV Merger, which drives the Combi's Modulation Wheel input and in turn the Thor modulator wheel. Routing rules 1 to 4 combine this value (sum) with DC signals (via CV In1). However these DC values are scaled by the two Thor Rotaries, labelled "Lower Trigger" and "Upper Trigger". Combi knobs 1 & 2 adjust these rotaries, thereby allowing the user to adjust the DC level added to the Mod Wheel value. The output from these rules (CV Out1 & Out2) are connected to the Combi knobs 3 & 4. These are programmed to modulate the Thor Main Buttons. In a similar manner to my Noise Gate, these buttons only activate when the controlling knob reaches it's maximum value (127). Knob 3 activates Button 1 when the sum reaches 127, and knob 4 activates Button 2 when it reaches 0.

This provides two configurable thresholds - upper and lower. The difference between them is that one will activate when the input signal is above the lower threshold, the other activates when the signal is below the upper threshold. You can see the Thor Button1 & Button2 lights activate when the respective thresholds are crossed. You can adjust the thresholds by setting Combi knobs 1 & 2. Typically, you would set knob 1 to be less than knob 2, otherwise the gate will never open.

The long routing rule (CV In1 > CV Out3 / Button1 / Button2) implements an "AND" operation. CV In1 is a DC signal (value 127). This value is passed to CV Out3 when both buttons are on. If either or both are off, CV Out3 is driven to zero.

There's a bit of logic to implement the "invert" function when Button1 on the Combi is selected.

The CV outputs are taken from the "Gate Output" Spider Splitter. The SplitA output is the normal or inverted output, while the SplitB output is always the inverted output.

Figure 6

Figure 6 shows the gate activating when the Modulator Wheel on the Combi is set within the two thresholds. Both Thor Buttons are lit. Note the two DDL Delays in the CV Monitor Combi - as the Modulator Wheel is moved, the gate will open or close and the DDL displays will indicate this. A value of 127 on the left DDL shows that the gate is open (i.e. the switch is on). The right DDL shows the inverted output (switch off).

Figure 7

Figure 7 shows the input CV value set by the Modulator Wheel below the Lower Threshold. Only one Thor button is lit, because the input signal is below the Upper Threshold, and the gate is closed (switch is off). The left DDL shows zero. The right DDL shows the inverted output (switch on).

So what can this device be used for?

That is actually a really good question!

One idea is to use a CV input value from a Malström LFO. With several Dual Edge CV Gates, you could divide the LFO range into sections, where each section enables a particular instrument. In this example file, the LFO changes through several waveforms, having a distinct effect on the sound. Note that there is some overlap between each section, so that sometimes more than one SubTractor is audible at a time. It's a bit cheesy, but it works.

Example 1 RNS
Example 1 OggVorbis

Another use may be to select different instruments or effects depending on the velocity of a MIDI note, or to select different effects or signal paths in response to the amplitude envelope of another audio source such a drum loop.

Example 2 RNS
Example 2 OggVorbis

This device is really a solution looking for a problem - a building block towards larger, more complex configurations. So if you have any good ideas for creative uses of this device, I'd really love to hear about them.

CV Monitor Tool

In the course of developing my Noise Gate, I found it very useful to visualise CV signals in real time. In fact, it surprises me that there isn't a built-in way to do this. So I thought I'd share my very simple "CV Monitor" combinator.

Figure 1 - The CV Monitor

Figure 2 - Connect CV signals to indicated ports

It's a very straightforward device to use - simply connect any CV signal you're interested in to one of the ports on the back of the Combi, as figure 3 demonstrates with the SubTractor's LFO output.

Figure 3 - SubTractor LFO connected to Pitch Bend CV input

Turn the rack around and you'll see one or more of the DDL digital displays changing in real time according to the incoming CV signal. Because the DDL delay starts at one, not zero, I have centred the displays at 1000. So just ignore the leading 1 and read the CV value directly.

Note that the rotary and modulator monitors are restricted to unipolar CV signals from 0 to 127. If you want to view a bipolar signal (such as the sinewave from the Malström LFOs) then you'll want to connect this to the Pitch Bend input. This will display the CV signal from 1 to 2000 for full-range deflection of the Pitch Bend wheel.

This hints at something to be aware of. Reason seems to do CV scaling where necessary, so thinking in terms of absolute CV values can be dangerous at times. For example, if you connect the SubTractor triangle-wave LFO to the Pitch Bend input, you'll see full deflection of the Pitch Bend and therefore the DDL will display a signal oscillating between 1 to 2000. But if you connect the same signal to, say, Rotary 1, then two things happen:

1. the signal is truncated for negative values, so the DDL will show 1000 for those parts of the LFO waveform.
2. the signal is scaled so that the maximum CV value maps to the full range of the control being modulated, in this case 127.

So what is the actual CV value? Does it actually matter? It looks like the effect of the CV signal depends on what you connect it to. This is actually quite useful because it means if the CV generator is oscillating full-range, then whatever you connect it to will also oscillate full range, regardless of the resolution of this destination. Therefore I suppose it might make more sense to think of CV signals as percentages, where unipolar full-range is 0 to 100%, and bipolar full-range is -100% to 100%.

I'll think about this some more - if this is true then it might make far more sense for the rotaries to map from 1000 to 1100 instead.

Also note that the Pitch Bend wheel generates CV values from -8192 to 8191, a range that exceeds the display capability of the DDL delay. The Combi programming scales this range down to 1-2000 for display.

The Combi also accepts and displays Aftertouch and Expression MIDI signals, in case that's useful.

Here is the Combinator Patch.

RNS Example 1 has a bunch of CV automations driving the Combi controls directly. Hit 'play' to view.

RNS Example 2 has several LFOs being monitored simulataneously by the device. Note that the SubTractor LFOs are all bipolar, so you'll see the display stick at 1000 for those parts of the waveform that are below half-way.

I hope you find this useful at some stage.

Blog Review: "Reason: Patch A Day"

Robbneu from Reason: Patch A Day very kindly mentioned this site recently, so I thought it would be good to review his site here, since I have been following it myself for several months.

Robbneu updates his site regularly. His goal is to create a new Reason patch, every day in fact, as a means of learning new methods of synthesis and sharing these with his readers. While I suspect real life occasionally gets in the way of such an admirable goal, he's certainly prolific. There are currently over 100 great patches posted since the site began only six months or so ago.

Robbneu obviously spends a fair bit of time creating each patch, and this shows. These aren't your typical trance leads that anyone can create in just a few minutes. Although experimentation and luck can play a large part in designing new sounds, it's clear that he usually has something in mind. Each patch comes with a short description of the inspiration or intended result, and some include suggestions for taking things further. A small RNS file is usually provided to demo the patch, and if it's an effect then the demo may turn the patch on and off to highlightthe change in sound.

The patches are typically of very good quality and sometimes follow a theme. For example, recently the theme was "Saturn's Rings" - a collection of subtle atmospheric sounds that have a definite 'space' feel to them. Other times the patches may focus on a particular synth or effect within Reason, or even a particular type of sound, like drums.

Just to note - you'll need a copy of Reason (full or demo) to hear the patches, as recorded samples are not provided. Patches are developed with Reason 4 although perhaps some would work in earlier versions.

Robbneu was kind enough to allow me to post a patch myself. I thought it would be interesting to imagine a sound and then find a way to create it. I didn't quite end up with exactly the sound I set out to find, but I was pretty happy with what I ended up with.

Summary: a great blog to follow if you like to hear new and interesting sounds in Reason. Regular updates mean there's often something new to download and try out yourself.

Thor's Destination Amount

Just an interesting observation I made while developing the noise gate. The "Destination Amount" in each of Thor's routing rows goes from -100 to 100 and modifies the Source signal as it goes to the Destination. However this is not a linear modification. It turns out that it's cubic! 100 is still 100% and -100 is 100% inverted, but smaller values follow a cubic relationship. Therefore, a setting of 80 is actually (80/100)*(80/100)*(80/100) = 0.512, or about 50%.

Figure 1 - Thor Destination Amount

Figure 1 makes this clear. Note that this means values of Dest Amount between about -25 to 25 are very close to zero. The regions between -100 & -80 and 80 & 100 are reasonably close to linear.

Figure 2 - Thor Scale Amount

However the scaling caused by the Scale parameter is linear, as figure 2 shows.