OWL Pedal and OWL Modular Jam

With the rise in popularity of Eurorack modules in the last few years, it is easy to get caught up with building an impressive module collection and neglect the main reason why we build them, which is to help enhance creativity. Here is a short jam which includes two OWL Pedals and an OWL Modular.


Posted in Demos, Educational, Tutorials | Comments Off on OWL Pedal and OWL Modular Jam

OWL Modular ClingWrap Distortion

Here’s a video of Cherif demonstrating a new Max MSP Gen patch called ClingWrap on OWL Modular. It lets you morph between four different digital clipping algorithms  to explore all that nasty digital harshness. Great for destroying synth lines and drum loops! To download this patch click here.

Posted in Demos, Educational, Tutorials | Comments Off on OWL Modular ClingWrap Distortion

Phoreo Trigger Processor Demo

Check out our demo of the Phoreo trigger processor. It is a triple function processor for triggers, gates and clocks. It simultaneously performs pulse width modulation, multiplication and repetition, with individual input, output and CV for each function.


Posted in Demos | Tagged , , , , | Comments Off on Phoreo Trigger Processor Demo

MIX 01 Matrix Mixer Demo

Here is a demo of our matrix mixer Mix 01 which features the Rebel Technology analogue bus. The extensibility of Mix 01 allows users to connect more than one module and expand the number of inputs and outputs, as needed.


Posted in Demos | Comments Off on MIX 01 Matrix Mixer Demo

OWL Max Tutorial 4: XFade Delay

Welcome to the fourth Max Gen! This will be the final tutorial looking at delays in Max’s Gen, from Cycling ’74. Today we’ll show you a cool function on the delay object inside Gen.

You can have multiple taps (delay lines) within one [delay] object: with two delay lines, you can update one of them and crossfade to the other. This gives different sounds from tape style delays. We’ll be using this to make today’s delay patch.

Test the patch here: hoxtonowl.com/patch-library/patch/XFade_Delay/

1.) We’ll build on our patch from Tutorial 3. You can download this and the TXDelay patch we’ll be drawing on from our Github:


Let’s begin by getting rid of and move things around to give us more space. Now let’s add an extra delay line. To do this we add a second argument to [delay]. This argument specifies the number of delay lines, so we update it to 2, giving us [delay 48000 2 @feedback 1].

You’ll notice an extra inlet and an extra outlet appear. The second inlet is the delay time for the first delay line, the third inlet is the delay time for the second delay line (and the first inlet is still the signal that is to be delayed). The first outlet is for the output of the first delay line, the second outlet for the output of the second delay line.


2.) Like we did last time, we’re going to take a few objects from another patch. Open the TXDelay patch. You can get this from github.com/pingdynasty/OwlGenPatches

We’ll copy a bundle of objects consisting of [gen switcher], [+ 1], [history], [gate 2] and .

screen-shot-2017-01-25-at-12-20-283.) We can now paste these objects into our [gen~] patch, and connect the delay time (the output from [/]) into both [gen switcher] and [history], and the two outputs from [gate] into inlets 2 and 3 of [delay].

screen-shot-2017-01-25-at-12-22-464.) The key thing is clearly [gen switcher], so let’s open it up. First of all, you can see a new object called [change]. This is a bit different to the max object [change] which (as you may know) only passes a value when there’s a change. Gen’s [change] returns the sign of the difference. This means every time there is a change in the positive direction (ie if the value goes up) it spits out a 1, and if it goes down it spits out a -1, and if it stays the same it spits out a 0.
Because the values will end up in [accum], we want to keep the output as a boolean, a simple 0 or 1, so when there’s a change there’s a 1, and when there’s no change it spits out 0. We use [abs] which gives the absolute value of what’s coming in, so this changes -1 to 1. [accum] counts what’s coming in and outputs the count which goes into [%], the modulo. For every value, [% 2] will alternate between 1 and 2.


5.) To demonstrate how these objects are working, we can create an [out 2] in [gen switcher] and an [out 3] in our gendsp patch, then in the main maxpat and create a [scope]. We can see, if we connect the output of [change] to [out 1], the new second output of [gen switcher] to [out 3], and the new output of our [gen~] object to a [scope~], that every time we increase the value we get a 1 and every time we decrease the value we get -1. We can connect different objects within [gen switcher] to the [out 2] in [gen switcher] to see their behaviour. Looking at the output from [abs], we can see that we add 1 every time we change delay value. Looking at the output of [accum] in a [number~], we can see it counts every time the delay time is updated.



6.) We only have two delay lines we are switching between, so we only need two values to be outputted from [gen switcher]. This value will tell us which delay line we are working with. Since the output is going into the selector input on [gate] and this only has two outputs, we need the values 1 and 2. This is where [%] (modulo) comes in handy. It alternates the output between 0 and 1. Now, every time we change the value for the dial a, [gen switcher] outputs 0 or 1. The [+ 1] adds one to this, giving the [gate] path selector input the 1 or 2 it needs.

7.) We are alternating the delay time, and the outputs from [gate] are going into the two delay lines. We need a particular order for the logic here, which is why we’ve used the [history] object. Before the new delay value comes to the [gate], we want the correct path to be open for the new value to go to. [history] delays the delay time value by 1 sample. This means that upon changing delay, first the gate opens through to the new path, and then the delay value arrives and is sent down this path. Now, every time you change the delay time, it goes into the new tap and the new tap will update the value immediately.


8.) Now we need another [mix] object. The output of [gen switcher] goes through a object and into the third inlet of this [mix], the interpolation factor between the two inputs.

screen-shot-2017-01-25-at-12-26-559.) The two outputs from [delay] go into the first two inlets for [mix], and this connects to the other [mix] object that was already in our patch. We now automatically crossfade between the delay lines every time we change the delay time.


10.) We can set this up for the second channel. If we test this finished patch in our Max patch we can hear there is no pitch change when changing delay times!

screen-shot-2017-01-25-at-12-30-32So, now you’ve made a great sounding delay! Upload this patch to the OWL using the online compiler at hoxtonowl.com.

Even if you don’t have an OWL, you can test the delay in the browser.

You can find more instructions about compiling Gen patches for the OWL at http://www.rebeltech.org/2016/11/owl-max-tutorial-1-getting-started/

Posted in Tutorials | Comments Off on OWL Max Tutorial 4: XFade Delay

OWL Max Tutorial 3: Tempo Sync Delay

Today we will be adding a tempo sync or tap tempo function to the simple delay we worked on in the last tutorial. We will be building on that patch, and if you haven’t done it already, we’d recommend starting with that tutorial which is available here.

This is a delay that can be quantised either by tapping the push button on the OWL or by using an external clock connected to the push input. Try it out and download the gendsp file here:


1.) We will begin by grabbing a ready made tap tempo analysis subpatch from the TXdelay patch. You can find that on our Github here:


We need to copy the [gen] object inside the gendsp patch, [gen~ @gen TXDelay]. The object called [gen] is a subpatch we’ve made to count the elapsed time between two presses of the trigger on the OWL. If you’re going to reuse a bit of code, you can make it into a subpatch or abstraction.

screen-shot-2017-01-11-at-15-02-03If we look inside the [gen] subpatch by double-clicking on it, it might look a bit strange even to seasoned Max users, but don’t worry, we’ll be unpicking it to see how it works.


2.) Now we need to paste this [gen] subpatch back into [gen~ @gen SimpleDelay]. We then need to connect the [gen] subpatch to the push button / trigger input which comes into [param @name Push @min 0 @max 1].


3.) We can see what’s going on inside the [gen] subject by creating a third output from our gendsp patch with an object called [out 3] and visualising the output with a [scope~] in the main maxpat. Remember, we use [out] objects to get out of the gen and gendsp parts of the patch. The range of the [scope~] needs to be set to -1 1 in the inspector, accessible via View > Inspector Window, and audio needs to be turned on for it to work. We can now visualise what’s coming in to the push in by temporarily connecting [in 1] in the [gen] subpatch to an output, [out 2], and connecting the second output of [gen] subpatch to [out 3] in the main gendsp patch. When we click the bang in the top right corner of our main maxpat to simulate a trigger input, we can see that we are causing a value of one to be constantly transmitted, 48000 times per second in fact!

4.) We just want to know the moment the button is pressed, so we actually only need to see this value once, and this is where the [delta] object will help. This object tells us the difference between inputs it receives. Disconnecting [in 1] from [out 2], and connecting [delta] to [out 2],  we can see two sharper spikes in our scope when we click the bang: one from 0 to 1 and one from 0 to -1. This is because pressing the button creates a value change from 0 to 1 – a difference of 1 – and releasing the button creates a value change from 1 to 0 – a  difference of -1.


5.) This is handy because we only have the value of 1 once, but it creates a problem because we need to filter out the negative side of the ‘blip’, and gen gives us an object that does this, [gtep], which stands for Greater Than or Equal Pass. We know what value we want to filter out and what we want to pass. We can set the value we are wanting to pass with an argument, and so if we give it an argument of 1 we will only get the positive ‘blip’.


6.) Now, every time we hit the button or press the bang in our main maxpat, the value 1 will be transmitted to the next object which is called [accum]. This object accumulates amounts over time, and outputs it’s accumulated value every time it receives a new input. This then goes into the [counter] object. If you input the value 1 to the counter, it starts counting at the samplerate. That means that in 1 second it will have counted to 48000, because the samplerate of the OWL is 48000. If you input a value other than 1, it will multiply the output by this amount. That means that if we input a 2, it will start counting at 96000 per second.

The first output from [accum] outputs a 1, and this is good for us. However, the second time we output from [accum], we get a 2, and this is going to be a problem if it gets sent to [counter], and that’s why we’ve made a feedback loop.


7.) Remember: we want the first bang or ‘tap’ to start counting the length in samples, and the second tap should stop that counting and output the value. [==] is a logic operator and will only output 0 (false) or 1 (true). [== 2] is looking for 2. For any value that comes in that is not 2 it will always output 0, and as soon as it receives a 2 it will output 1. So, every time we hit the push button for a second time, [accum] outputs 2, this goes into the logic operator [==] which will output the value 1, which does two things:

i.) Every time [accum] receives a non-zero input in the second inlet it resets. The [history] object just creates a one sample delay which prevents a feedback loop that max won’t like! This goes into [counter] which we also want to reset.

ii.) Our final object, [latch], ‘latches’ the last value. It always stores the very last input,  whenever it receives a non-zero value to the second inlet, it releases (or purges) the final count stored to the output. We want the [latch] to purge the final count before the [counter] and [accum] are reset. The [history] object creates a delay which means this happens in the correct order.

8.) So, [accum] triggers [counter] on the first push of the button, then on the second push, it first tells [latch] to purge the last number it received (ie, how high the counter got), then it resets [latch] and [counter]. We can test this by connecting [latch] to [out 2] and replacing the [scope~] with a [number~] box in the main maxpat. If the bang is pressed twice, [number~] will display the elapsed time (in samples) between presses. This now means that our trigger or push input gives us a delay time or tempo!


9.) We are going to divide the delay tempo by a varying amount, so as you turn the knob higher you get a faster delay time. We will replace our previous method for turning dial a into delay time. We can delete [* 48000] that is connected to [param @name A @min 0 @max 1].

Remember, in in the world of DSP, you must NEVER divide something by zero, because this will give us an answer of infinite which we won’t be able to compute. What we need to do is create a failsafe system. First of all, we want to offset what’s coming in from [param @name A @min 0 @max 1] using a [+] object with an argument of [0.001]. That means that instead of going from 0 to 1, the value from our input becomes 0.001 to 1.001. Then we can multiply it by 7 using [* 7] and finally pass it through the [ceil] object. The [ceil] object rounds its input to the nearest maximum integer, meaning the value will be truncated to 1, 2, 3, 4, 5, 6, 7 or 8. These are good ‘musical’ numbers to divide our delay time by.


10.) We now divide the time in samples from our tap tempo subpatch by the value coming in from dial a, then connect this into and the time input – the second inlet – for both [delay] objects. We delete [out 3], because the OWL only has two audio outputs.

screen-shot-2017-01-11-at-17-33-5911.) Now let’s test this! Upload this patch to the OWL using the online compiler at hoxtonowl.com. We can get a tightly synced delay by using feeding the clock into our trigger input!

Even if you don’t have an OWL, you can test the delay in the browser. You can find more instructions about compiling Gen patches for the OWL at http://www.rebeltech.org/2016/11/owl-max-tutorial-1-getting-started/

Posted in Tutorials | Comments Off on OWL Max Tutorial 3: Tempo Sync Delay

OWL Pedal demo with Robert Bowers

Watch and hear Robert Bowers talk about his favourite patches for playing guitar with the OWL pedal.

Posted in Demos | Comments Off on OWL Pedal demo with Robert Bowers

ACID Groovebox

Posted in Demos | Comments Off on ACID Groovebox

Testing OWL patches in your web browser

You can now test (and even edit) OWL patches in your web browser through hoxtonowl.com.

Here’s a short video of Adam playing an FM synth in the browser:

Posted in Demos | Comments Off on Testing OWL patches in your web browser

OWL Pure Data Tutorial 4: FM Synthesis

Today Adam will talk you through building a simple FM synth in Pure Data that you can run on the OWL. Test and download the patch at https://hoxtonowl.com/patch-library/patch/SimpleFM/

FM (Frequency Modulation) Synthesis was developed by John Chowning at Stanford University, and it’s the technology found in synthesisers such as the infamous Yamaha DX 7, Ableton’s Operator or Native Instruments FM8. FM synthesis is perfect for digital synths as it relies on a stability that you don’t often get in analogue oscillators. It enabled the manufacture of affordable but versatile digital synths.

1. I’m using Steve Cooley’s Pure Data template which you can get from hoxtonowl.com.

Remember, to ‘modulate’ something basically means to change it. Frequency modulation uses one oscillator to change (modulate) the frequency of another. First we set up the carrier frequency. The carrier frequency is added to the modulator. As the modulator varies between positive and negative values, we get a signal that oscillates around (that is, on either side of) the carrier frequency.

We will use dial / CV A to set the carrier frequency. We take [r Channel-A], scale it for midi by multiplying it by 128 using [* 128], then we scale it to frequency values using the [mtof] object, which converts midi to frequency. We then convert it to audio rate using the [sig~] object.

fm_tut13. The carrier frequency is added to the modulating frequency (which we’ve not set up yet) using a [+~] object. After that, it is connected to an oscillator – an [osc~] object – so that we can control the frequency of it.

fm_tut24. Now we’ll create another oscillator to do the modulating. We need a second [osc~] object. The frequency input that this receives should be a multiple of the carrier frequency. To achieve this, we’ll multiply the output of the carrier – the [sig~] object – by something (we don’t know what yet) and then connect it to our modulating oscillator.

fm_tut35. We also want to control the amount the modulating frequency, called the modulation index, so we will connect it to [*]. Finally, we add this back to the carrier.

fm_tut46. Now, we’ll create an overall volume control with another [*~] controlled by dial / CV D and connect it to the [dac~], so we’re ready to input some numbers and make some noise!

7. We can create some number boxes and put some values into the synth to get some sounds out. Whole numbers in the ratio give harmonic sidebands, whereas non-integers give inharmonic sidebands. A greater modulation index (the amplitude) increases the volume of the sidebands and the brightness of the sounds. This amplitude can be far greater than 1, and changes the range around the carrier that we are modulating.

fm_tut5a8. Pick some ranges that work well, and scale the inputs for channel B and C accordingly. We’ll use a range of 16 for the harmonicity ratio and 2000 for the modulation index.

Now, get to hoxtonowl.com, log in to your account, and go to patches to create a new patch and upload your patch. You can test it in the browser and load it onto your OWL!

See our instructions for uploading patches for more details.



Posted in Tutorials | Comments Off on OWL Pure Data Tutorial 4: FM Synthesis