Very happy to announce that we now have a new community website!
The community works as a forum, mailing list and chat space, and is based on the Discourse platform. We have migrated the old OWL forum from hoxtonowl.com so you will see that there is already content dating back from several years.
As well as being a place to ask questions, we look forward to the community website becoming the centre of discussions and debate to guide our future work!
We’re very pleased to announce the official release of the OWL package for Cycling ’74’s Max. You can now program and remotely control an OWL, all from within Max.
“The end result is a seamless workflow from inside of Max directly to the hardware.” – Andrew Pask, Cycling ’74
The OWL package comes with the OWLwatcher to communicate between Max, our server, and an OWL, along with a selection of delay, distortion, synthesis and sampling patches to try out. If you have a copy of Max you can download it for free using the package manager.
Check out this video made by Cycling ’74 and read more about it on their site:
Many thanks to the team at Cycling ’74 for all their hard work with us over the past year to make this possible.
Posted inUncategorized|Comments Off on OWL Package for Max Announced
1.) If you’ve already done the tap tempo delay tutorial, you should already have the template and the PGL patch that we will be using today in the OwlGenPatches-master folder. If you don’t have these, you can get them from our Github.
We begin with the Dev_default patch, our basic template for OWL patches in Gen. Open this, unlock the Gen patch and save it as something else – in our case, this is PGLTut.gendsp. Inside that, there is a a folder called PGL containing a Max patch called PGL.maxproj.This looks complicated, but we’ll break it down into smaller chunks and steps which we can simplify. For now, copy the objects below, which includes [data], [in], [counter], [poke] and [i], and paste them into our patch.
2.) Then copy the following objects from the bottom of the PGL patch, including [sample] and [i], and paste these into our patch.
3.) To these, we add a [phasor] object. Your patch should now look like this.
4.) Before we go any further, let’s look at the core concept of PGL. PGL stands for Pitch Grain Looper. Ultimately, it’s a live looping tool. Any audio signal that comes into input goes into a buffer: space in the OWL’s RAM where you can store things. You fill this space with the incoming audio, and you can play back parts of that recorded audio. When playing it back you can change pitch, direction and length. Today we’ll look at how to allocate space in the RAM, how to write values into that (ie how to record audio in Gen and on the OWL), and how to play it back (so you could use this to make a loop pedal, too!).
The first object we’ll look at is [data] which allocates RAM for sample storage. This is the sister object of the [buffer] object you’ll know from Max. [data] has an outlet that’s useful for what we’re doing: if you hover your mouse over the left outlet you’ll see it says “length in samples”. The first attribute of [data] is a name – in this case ‘pitchloop’ – this allows other objects to refer to that space in the memory too. The next attribute is the size of the buffer in samples (48000 samples is one second with our 48k sample rate) and the third attribute is the number of channels – in this case 2 (for stereo).
As soon as you set the size of the [data] object, it continually sends this out of the left inlet, which goes into the [counter] object and sets the upper limit of [counter]. The [i] object outputs the integer argument we give it, so [i 1] outputs a 1. This sets the increment of the [counter] so for every sample that passes it adds the number 1 to the outlet. This object is therefore creating a constant stream of how many samples have passed, counting from 0 to 48000. This value goes into the [poke] object.
5.) [poke] is a “pokes” the value into a specifed space in the buffer. The first argument of [poke] is the name of the RAM it’s writing into. In the first inlet of [poke], we enter the value (ie, audio) that we want to write, so we can connect [in 1] to the first inlet:
6.) The second inlet is the position we want to write to. Every time we want to write to the buffer, we need to set the position – this is why we are using the values from counter. Every time audio arrives, the [counter] tells [poke] where to write this to. The third inlet sets the channel, which starts at zero, which is set by [i 0].
This collection of objects is writing audio to the buffer, in realtime, in a one second loop, so you’ve always got the last second of audio recorded.
7.) Now, we need an object that reads the value that’s being written (ie, plays back the recorded audio). We will use [sample] which requires a ramp input from 0 to 1 to read through the recorded audio. For this ramp we use [phasor]. We use an argument to set [sample] to read from our buffer called pitchloop. We found the setting the interpolation (@interp) attribute to spline was the nicest, but you can try others. So, we connect [phasor] to both [sample] objects in order to use it to control playback.
8.) Add a [mix] object so we can here the difference between the dry and wet. We use [param D] to control the cross fade.
9.) Changing the frequency of [phasor] will change the rate at which we read through the buffer, ie, the speed (and pitch) of sample playback. We will set this playback speed – the frequency of [phasor] – with [param] for input A.
A [phasor] frequency of 1 will ramp from 0 to 1 once per second. Because our buffer is one second, this means it will play one second of audio back at normal speed. A frequency of 0.5 plays back at half speed (and an octave lower), and a frequency of 2 will play it back at double speed (and an octave higher).
We want to control the frequency of [phasor] by [param] which is set to output 0 to 1, and we will multiply this by 2 using the [*] object so we can play the recorded audio back up to twice as fast, and use [clip] to prevent it from ever going to 0 (which would stop playback!).
10.) Your whole patch should now look like this:
Let’s go to the top level of the patch (the main max patch) and test it out!
Last month we had Jake Williams of Flies + Flies join us as our Resident Artist. A sneak preview video of their rehearsals shows Rebel Tech modules being used in their set. We can’t wait to hear what they’ll come up with!
Posted inUncategorized|Comments Off on Flies and Flies Using Rebel Tech Modules!
We’re back to show you how to build another awesome effect using Cycling 74’s Max Gen software running on the OWL Modular or pedal. This is the PGL (Pitch Grain Looper), your go-to patch for stuttering and glitching. In this video Cherif introduces you to the patch, and next time we’ll get programming!
was great to use the owl last night. worked really really well and
sounded great. no problems at all. really looking forward to using it more.
All in all, I adore this module. It can take the simplest gate/trigger streams and create fun and wild new patterns, but all the while doing it in an intelligent way.
Tyler PorterFort Worth, USA
It’s the modul of the years! Woooooow lot of possibility!
OWL is a great module! Very well done, Sir!
Steve EverittEat Static
Dan Nicholls, Shobaleader One
I have the OWL Pedal and I love it!
Very nice, super clean!
I just ran the owl through a very good large pa in Edinburgh. 2x d&b c7
tops and 4x c7 subs and it sounded really great. really detailed clean
sound. lots of depth and texture. really good.
A fool-proof good groove!
It’s amazing. Very flexible and straightforward. Sending funky clock signals to the clock input can yield some really nice variation in a pattern with minimal amount of work. The design choice of how the envelope restarts plays into this very well. Very ‘sweet-spotty’ and can make a huge difference in a patch with small adjustments. It accomplishes the main thing I love about modular and can do stuff you just can’t do anywhere else.