Thursday, 13 June 2019

Documentation for the 'Probably' series of M4L devices - Illustrated!

The recent release of ProbablyR 0v14 reminded me that the documentation needs writing at some stage... So here's a promoted part of the blog post for that, but as a separate blog post to make it easier to find, and with added graphics to give it extra 'eye-candy'-ness. Not quite a square coffee-table book full of nice glossy photos, but you never know...

Documentation for Probably

The MIDIprobablyR(S,Z...) series is getting to the point where it needs a proper manual, but this may take some time, so, in the meantime, here are links to all of the blog posts covering the various versions of the Probably step sequencer. (and related devices) 

The Probably... step sequencer

Probably was the first (and simplest) of the 'Probably' series of step sequencers. This blog post is a good place to start.

Probably blog post                  The first in the series (four grids, limited panel colouring)

ProbablyZ blog post               The second iteration (added the time-warping 'Order grid/panel)

ProbablyS blog post               The third iteration (added the sub-sequencer 'Memory' grid/panel)

ProbablyR 0v11 blog post      The fourth iteration (added 16 step sub-seq, warp fills, and Step length)

ProbablyR 0v14 blog post      The fifth iteration (added 'Swing' panel and 'Nudge' buttons)

Latest ProbablyR on

Somewhere along the line, the breathlessly-annotated 'white and light purple' advert style got stuck in my mind, and I have used it ever since. Love it or hate it, it is immediately recognisable...

Other 'Probably...' devices

After Probably, there were some other devices that added extra letters to the end. The 'step sequencer' series adds a single letter: S, Z, R - the other devices add more than one letter. The release sequence for 'Probably the step sequencer'  is: Probably, then ProbablyZ, then ProbablyS, then ProbablyR (current).


ProbablyLFO blog post           Outputs probabilistic (variable) waveforms  

ProbablyLFO blog post2         Extra sync additions and time warping               On

Most people glance at the pixelated sine wave in the 0v03 screen-shot and say something like: 'Yuk - a pixellated sine-wave!' and ignore it. What they miss is an LFO that allows you to make arbitrary waveforms that change shape probabilistically and over time (the noise-warping is really cool, even if I say so myself!). Also, the pixelation can be smoothed out, and actually, having a little bit of it sounds good! - if you were raised in the 'S&H filter modulation era' then it is like a more sophisticated version of that. First impressions are not always reliable, and I've not even mentioned really unusual features like the 'Note' mode, where the LFO waveform is 'triggered' by notes in a clip, which one user described as 'genious'!


ProbablyGEN blog post          A poly-rhythmic drum sequencer, plus...  

ProbablyGEN blog post2        Extra asynchronous additions...                           On

ProbablyGEN is pure timing madness. Each of the three horizontal rows is independently timed (synced or free of Live's transport) and so you can do truly free-form poly-rhythms. This is the sort of thing that really ought to be a module for a modular synth...


ProbablyCHORD blog post     Probabilistic chord generator ('Sergeant...')        On

ProbablyCHORD is interesting because it brings together several idea into one place. The TR2gen to-step chord generator puts two chords in sequence and provides inversions, and then lets you automate and add probability to it. So it adds polyphony to the monophonic step sequencing from ProbablyR (and in fact, the variable 'step length' pop-up menu was tested here first, then added to ProbablyR 0v11). But it is also shown to its best advantage when paired with an 'articulated' sound using velocity, and you can learn more about this in two ModeAudio interviews/tutorials.

There is more on Ableton instrument racks here:

- Macro controls in Instrument Racks In Ableton Live

And an example of a more sophisticated multi-layered articulated sound (implemented in an Instrument Rack in Ableton Live) is here:

In the pipeline is a blog post on additional articulations that you can do inside Instrument Racks, which may also have other spin-offs...

ProbablyCHORD blog post2 - coming soon!

There are updates and more devices in the pipeline, of course. Watch this blog!

All free!

Everything here is free, of course, but donations are always welcome!

Tuesday, 11 June 2019

Generative non-linear step sequencer - new 'Swing' panel, and more!

This was going to be a quick post to describe a new panel for my 'ProbablyR' generative, probabilistic sequencer, but it seems to have grown into a longer tome because version 14 has made rapid progress... So this post will cover:

1. The new 'Swing' panel
2. The new 'time manipulation' facilities in the 'Order' panel
3. The new 'Nudge' buttons in most of the panels

As always with a new release of ProbablyR, don't forget to send it a MIDI note (from the keyboard emulation on a laptop, or from MIDI In), click on the 'D' default button to get a clean setup, and then save the settings using the little 'floppy disk' icon in the top right hand corner so that you get a saved .adv file in your library. Then explore the new stuff!

Oh, and I suppose that I should use my new naming scheme, so this updated device is really called: 'MIDIprobablyR 0v014'.

The Swing panel

The 'Swing' panel adds the ability to set the length of each step in the sequence in 64th note intervals. Note that ProbablyR already lets you set the length of the generated note at each step in the sequence,  so the 'Swing' allows you to control the time between steps, which is somewhat unusual in step sequencers.

I'm using the term 'swing' here because that seems to be the most commonly used term in the DAW industry, and I'm very aware that 'Swing', 'Shuffle', 'Groove', and 'Nudge' are all terms that can be used for similar parameters. Now, having been using the amazingly excellent Novation Circuit for the last couple of months, I have to say that 'nudge' was my first choice, but that was already taken for a completely different new feature. (Of course, these days, maybe what I should be doing, is putting a picture up on Facebook in a DAW group that asks: ''Swing', 'Shuffle', 'Groove', or 'Nudge': Which is the right word?' and waiting for comments...)

The 'Swing' panel is the slightly purply, dark blue one (not the re-coloured teal one for 'Note Length' that used to be 'the dark blue one') on the far right of ProbablyR, and uses the same probabilistic grid that I have been using for all of the major control functionality in the Probably series. (Time usually goes horizontally, each white cell vertically is selected at random.) So, yes, the horizontal axis is time: 18 steps maximum in this version (the UI is holding me up for more steps...), whilst the vertical axis sets the number of 64th notes between each step, with fastest (1/64th) at the top of the panel, and the slowest (64/64ths) at the bottom of the panel.

Now, following my usual trend of not doing things in the conventional way, the 'swing' control presented here is rather different to the more usual percentage value from 50% (Straight or 'even' timing, where, for example, every 16th note is the same time after the preceding note - so they are evenly spaced in time) to 70%, or even 85% (Not straight timing at all, but 'swing'-timing, where (typically = there are variations!) each second note is moved in time so that it is not the same time after the preceding note as that preceding note was for the one before that.) Instead, the probability grid allows you to set the thing of any of the 16th notes backwards or forwards in increments of 1/64th notes. In the Ableton Live manual, they describe 'groove' in terms of having a piece of elastic for the timing, instead of a fixed metronomic grid. So in ProbablyR, the probability grid provides exactly that sort of timing flexibility, but it also allows probabilistic control, so the swing is not necessarily the same for each note, or each bar, or each repetition... Now this is quite an unusual ability, even these days, unless you have ever programmed something like a Roland MC500. (where each note's timing can be controlled individually!)

Since ProbablyR's timing runs on 16th notes, then the default horizontal row is the 4/64ths line, which is a 16th note. This row is highlighted in dark grey, with the rows above and below in lighter grey. If you let ProbablyR run with the default '4' setting of white cells for each step, then there is no effect: each step is 16th of a note, as usual. The very top row is coloured red to indicate that it is very fast, so fast that on some slower computers the timing might not be exactly as you would expect. This is a result of the way that ProbablyR gets timing information from Live, and I suspect that a better programmer than me (Gregory Taylor from Cycling'74, for example) would be able to improve upon it. Having been raised in a world where the limits of analogue devices were very evident (anyone who has tuned a Yamaha CS-80 will know what I mean), then I'm very gratified that digital devices  also have limitations and wrinkles, albeit sometimes very different ones. And, as they say, 'limitations are the spurs to creativity'!

First half fast (so middle note is early), and second half slow - on average!

But adding an extra white cell at the start and middle of the sequence (the left hand side and the middle of the grid in the panel) can change the timing - quite radically if you want, or reasonably subtly if you prefer. The timing is altered 'per step', so you can have different timing for each step in the sequence if you wish, although this can be quite challenging to minds and ears that are mostly acquainted with regular 4/4 at 120 bpm. The 'Swing' panel uses the same probabilistic control as the rest of ProbablyR, so if you have more than one white cell in a vertical column, then the probability of that value being used is the reciprocal of the number of cells. In other words, if you have 1 white cell, then it happens with a probability of 1/1, which is 100% of the time. If you have 2 white cells, then each cell has a probability of happening of 1/2, which is 50%. Three cells is 33% each, four cells 25% each, and so on. The mathematical term for assigning probability weights to events is 'Bayesian', so if I was a marketing person, I would be calling this a 'Bayesian step sequencer with weights of 50%, 33%, 25%, 20%...'. But you get the idea - the more white cells there are in a vertical column, the more 'spread out' the chance of each one happening becomes. So an alternative way of thinking about the white cells is that they 'spread' the chance of that value happening: one cell doesn't spread it at all, whereas 10 white cells means that each one is only going to happen 10% of the time, on average.

So what happens when we add a white cell to the default row of '4'? Well, in step 1, the length of the step will be either 3/64ths of a note, or 4/64ths of a note. Each of these will happen half of the time, but randomly - so it won't be 3 followed by 4 followed by 3 followed by 4 each time, it could be more like: 3, 4, 4, 3, 3, 3, 4, 3, 3, 4, 4, 4... but where the 3s and 4s are randomly distributed over time. If you listen for 3 minutes and count them, then each of the counts would be pretty close to being half of the total number. It's a bit like tossing a coin: long-term, it will land on 'heads' 50% of the time, but this doesn't mean that if you get 10 heads in a row the next toss will have to be tails ('to even things out' is what people tend to say). Nope, each and every time that you toss the coin it will give heads or tails independently of the previous tosses, which is why the long-term results are going to be very close to 50% heads, 50% tails. (I am aware that it is possible, with practice, for people to deliver heads or tails on demand, but I'm assuming here that the people tossing the coins are not trained specialists at coin tossing! Or dice throwers, or whatever other 'random choice' mechanism you care to use...)

The step in the middle is going to be either 4/64ths or 5/64ths of a note, so this is slightly longer in time. So the two white cells alter the 'elastic' timing of the step sequence so that the first half of the bar is up to 1/64th note faster, while the second half is slower by up to 1/64th of a note. I write 'up to' because the grid is probabilistic, and so the two white cells in a vertical column mean that the average speed-up or slow-down will be half of 1/64th note (1/128th note). In the UI, white cells above the '4' row make things go faster, whilst white cells below the '4' row make things run slower.

I'm going to stop talking about probability right here, because this is sounding increasingly like a TED talk!

Anyway, back to music and the 'elastic' time concept. The 'Swing' grid allows you to assign any time interval for each of the steps - from 1/64th to 16/64ths (which is a 1/4 (quarter) note). Now if you set all of the notes to 1/64th notes then the whole grid is going to take 16/64ths of a note for all 16 steps (assuming we are using the 16 steps per grid default setting), which is 1/4 of a note - so the whole grid runs at 4x speed and what should be a whole note plays in a quarter note's time. At the opposite extreme, setting all of the steps to 16/64ths gives 1/4 notes per step, and 16x 1/4 notes is 4 whole notes, so the grid runs at 1/4 speed. Okay, so the grid runs faster or slower, but the bars are still in time. Unfortunately, these are ideal cases...

Suppose we leave all of the white cells in the Swing grid in the default '4' position (4/64ths = 1/16th notes, one for each of the 16 steps in a 16 step sequence), except for one. Let's make that 3/64ths, which is 1/64th shorter in time. The whole grid will now take 63/64ths of a whole note to play, which means that it jumps forward in time by one step for each repetition (and so it is not in sync), and after 64 bars we will be back in sync again. Whilst this can be useful for polyrhythms, it would be nice if there was a way of knowing when the Swing grid is going to take the sequence out of sync with
Live's transport, and that is what the large number on the right hand side of the grid is used to indicate (for a 16-step sequence, it will be showing '64' when we are in sync) - the number just above the black box with a 'G' or '4' in it. When the '64' is green, then ProbablyR is going to be playing at the same speed as Live's transport - and don't forget you can always click the Grey "Resync' circle button in the 'Memory' panel if you need to get ProbablyR back in sync with Live. But when the number shows anything other than '64' in red (in the example described just now, it would be showing '63'), then you can immediately see that ProbablyR is going to be slipping or dragging in time. So the number going green is something to look out for if you want to have ProbablyR running in sync.

First quarter of the bar is fast, the second quarter is slow, the third quarter is fast again, and the fourth quarter is slow again - on average.

When you edit the Swing grid live, you will find that the number goes red or green depending on where the white cells are, and it is easy to get out of sync. To enable you to edit the grid and not lose sync, there's a special button that enables you to make changes in the background, check that they add up to '64' (for a 16 step sequence) when the number goes green, and then apply the new swing all at once. It is the 'G'/'4' black box - when you click on it so that it shows '4', then the default 4/64ths '4' setting of swing will be applied to the whole grid, regardless of what the grid actually shows. So you can click and put/remove white cells and check that you get a green number, and then click on the '4' in the black box so that it changes to 'G', and now the Grid will be active and you will get the swing settings that you have chosen applied to the grid step timing. You may need to practice this so that the process of

[ '4', then edit the grid, then check for green, then 'G' to Go with the Grid ]

is fixed in your mind (and fingers), and you will be able to change the swing during live performance without losing sync. If you have seen the fist ProbablyR video then you may not have noticed that it is a live recording and that I never stopped ProbablyR running - it just plays the whole time, live. Well, the 'G/4' button is designed to enable you to make changes to the swing whilst ProbablyR is running and in sync with Live.

Putting a speed-up just after the first note in the bar, then a slow-down just before the middle beat, then a speed-up for the third beat, and a slow-down at the end of the bar

Of course, if you do not want to stay in sync, then go for red numbers and don't bother with the 'G/4' button! I'm hoping that some people will do this live, so please let me know if you are using ProbablyR 0v14 in this way! There is another feature for people who want to do 'off sync', and this is the smaller number just lower down from the black 'G/4' box - this number shows the running average number of steps that ProbablyR has played over the last few repetitions. So if you set the 63/64ths swing grid from earlier, then this will go from 64.0 to 63.0, going through 63.9, 63.8... etc. on the way. And if you go back to 64/64ths (or click on the 'G' black box - just reminding you!), then this 'running average' will gradually go back to 64.0. This is intended to give the performer who wants to go 'off sync' a way to see when they are back in time with Live's transport, or maybe when they need to click the grey 'Resync' circle in the Memory panel to get properly back in sync. With a little practice, you can be in complete control of where ProbablyR is in relation to Live's transport.

Editing the Swing grid whilst the '4' button is active - so the timing is even across the whole bar.

Once the 'G' button is shown, the timing variation is alive. Here the middle beat is late by 1/64th of a note, and the rest of the bar is slightly faster to compensate. Note that there are no vertical columns with two white cells, so this timing is always constant and the sequencer should stay in sync...

The 'Time Manipulation' facilities in the 'Order' panel 

The 'Order' grid sets the order in which all of the other panels happen, and the default is just the lower left-to-upper-right diagonal, which gives the 'linear' time that you expect. The first step is followed  by the second step, then the third, and so on (the cursor lines move from left to right across the panels). If you click on the '-1' button, then you get the opposite diagonal (upper left to lower right) and now time runs backwards in the panels - the cursor lines go from right to left!

Now, whilst you can do a lot with the Order panel, it often requires lots of clicking to clear and set white cells, and so the first new feature is the 'Inc' control number. This sets the number of steps that the sequencer advances across the grid for each step - known as the 'Increment'. Previously this was fixed at 1, and so the default diagonal meant that the cursor moved from left to right one cell at a time. Editing the grid to change the diagonal is possible, but the 'Inc' increment button makes it very quick and easy to change the number of steps. The default is 1, as expected, but if you set it to 2 then the Order grid cursor will jump across the grid two cells at a time, and so the grid takes half the time to complete, assuming that you are using the default 16 steps per bar for the Order grid. But the interesting setting is 3, because now the cursor jumps from cell 0 to 3, then to 6, 9, 12, 15, and then to cell 2, then 5, and ending up at 14, followed by cell 1, then across again, and finally back to cell 0. So the cursor scans across the grid three times, and ends up where it started (assuming 16 steps is set!). Setting Inc to 4 goes across very fast, but 5 is another 'multiple scans for a complete bar', and all of the odd numbers do the same re-ordering of the notes in the Pitch panel, when you have 16 steps set. So why did I include the odd numbers?

Okay, the even numbers are there for when you use an odd number of steps: 15 is a good starting point. You need to change the 'Max' control number to '15' - it will no longer be green (assuming you have the Steps selector in the 'Length' panel is set to 16). The Order grid is now only 15 steps across, and so if you use an Increment (inc) setting of 2, then you now get two scans across the grid for one bar. Now, whilst the Order grid is 15 steps long, assuming that you have left the Steps pop-up menu at 16 (the default), then all the other grids will still be 16 steps long - but only the first 15 of them will now be available to the Order grid. So the Order grid will scan back and forth (depending on the Inc value) and the cursors in the other grids will follow along, but step 16 will never be reached. If you want to use step 16 then you set the 'Min' control number to 2, and Max to 16, and now the Order grid will scan from step 2 to step 16.

In other words, the Max and Min control numbers set the width of the Order grid, and this can be anywhere from 2 cels to 16 cells (as set by the 'Steps' pop-up menu in the 'Length' panel. This allows you to set up several different orders in the Order grid, and choose them by setting the Max and Min control numbers, or control the scanning across the Order grid by using the Inc control number. And I haven't mentioned that the Order grid is probabilistic yet, so that makes things even more interesting. Basically, my recommendation is that you should proceed in this way in order to get familiar with what the new features can do:

1. Play with the Order grid with the default settings of Inc=1, Min=1 and Max =16 using one white cell per vertical column.
2. Then try two or more white cells per vertical column.
3. Then try the 'Inc' increment control number.
4. Then use the 'Max' and 'Min' control numbers to choose a part of the Order grid to control the same part of the other grids. Yes, with Inc=1 and Min and Max set not to overlap, then a basic setup might have two 8 step sequencers on two different Memory slots, or four 4 step sequences, or even two 5 step sequences and an 8 step sequence (with the 'Steps' pop-up menu in the Length panel set to 18 steps). And when you have all of these sub-sequences set-up, then don't forget that the 'Inc' control number will allow you to quickly change the order that the grid plays, or changing Min or Max will change the boundaries of the sub-sequences, and you can overlap them if you want. There's a lot to explore here!

 The 'Nudge' buttons

The Order, Probability, Velocity and Length panels all gain four new buttons plus some associated control numbers, whilst the Pitch and Octave panels both gain two extra buttons. The buttons are Nudge buttons for the grids, and they allow you to move the contents of the grid up, down, left or right. For the Pitch grid this means that you can either use notes in a Clip to control the transposition, or you can do it live using the Up/Down Nudge buttons, or store the nudged grid in a Memory slot. For the Octave grid it speeds up choosing the range of the instrument sound.

But the real fun is the Nudge control numbers. These automatically click the associated Nudge buttons according to the number in them. The default '1' setting doesn't do anything, but if you set the left nudge control number to 16 (and the steps are set to 16...) then the grid will scroll to the left by one cell each 16 steps (each bar). So if you have a probability grid or velocity grid or length grid that is controlling which notes are playing and how they are being articulated, then you can move these independently in time.

I like to have a velocity grid with an up and down wiggle and set to be nudged 1 step less than the number of steps in the bar, so that the grid moves horizontally, but each note gets a different value for 16 bars, and then it repeats. (You can hear this happening on the demo on SoundCloud). If you want, you can set more than one Nudge control number, and then the grids will slide about all over the place. There's huge amounts of control to explore here! (And you can always add more automation using Live's internal facilities as well, of course!)

SoundCloud demo

I'm working on a video, but that takes a long time, so, in the meantime, there's a demo up now on SoundCloud. This is a live recording of a single instance of ProbablyR, plus a drum pattern, and has too much reverb on it. (But it IS a demo, and they always have too much reverb, so that's how you know it is a demo!) The demo has velocity nudging, swing time manipulation, and uses the modulo scanning of the Order grid to give interesting variations of the note pool in the Pitch grid. Hopefully, if I've done it well enough, it should sound like someone improvising on the Marimba, and they are slightly imperfect in their timing... But it isn't anything like that, of course. It is produced by one of those 'boring, static step sequencers that monotonously repeats exactly the same notes...,' except that ProbablyR isn't that kind of sequencer. Not at all.

The MIDIprobablyR(S,Z...) series is getting to the point where it needs a proper manual, but this may take some time, so, in the meantime, here are links to all of the blog posts covering the various versions of the Probably step sequencer. (and related devices) 

The Probably... step sequencer

Probably was the first (and simplest) of the 'Probably' series of step sequencers. This blog post is a good place to start. 

Probably blog post                  The first in the series (four grids, limited panel colouring) 
ProbablyZ blog post               The second iteration (added the time-warping 'Order grid/panel)
ProbablyS blog post               The third iteration (added the sub-sequencer 'Memory' grid/panel)
ProbablyR 0v11 blog post      The fourth iteration (added 16 step sub-sea, warp fills, and Step length)   
ProbablyR 0v14 blog post      This post! The fifth iteration (added 'Swing' panel and 'Nudge' buttons)

Latest ProbablyR on

Other 'Probably...' devices

After Probably, there were some other devices that added extra letters to the end. The 'step sequencer' series adds a single letter: S, Z, R - the other devices add more than one letter. The release sequence for 'Probably the step sequencer'  is: Probably, then ProbablyZ, then ProbablyS, then ProbablyR (current).

ProbablyLFO blog post           Outputs probabilistic (variable) waveforms    
ProbablyLFO blog post2         Extra asynchronous additions... ('swing-like?')   On

ProbablyGEN blog post          A poly-rhythmic drum sequencer, plus...         
ProbablyGEN blog post2        Extra asynchronous additions...                           On

ProbablyCHORD blog post     Probabilistic chord generator ('Sergeant...')        On
ProbablyCHORD blog post2 - coming soon!

There's now a 'coffee-book' illustrated version of this section in a separate new blog post:

    Probably documentation

Hardware Sequencing

If you make hardware sequencers and are busy taking notes from this blog as potential ideas for your next release, then perhaps we should talk. I would love to help someone make a proper advanced hardware sequencer that goes 'beyond' the current 'state of the art', and hopefully ProbablyR (and the other M4L devices in the Probably series) vividly illustrate that I may be useful to you.

Getting MIDIprobablyR 0v014

You can get MIDIprobablyR on

Here are the instructions for what to do with the .amxd file that you download from

(In Live 10, you can also just double-click on the .amxd file, but this puts the device in the same folder as all of the factory devices...)

Oh, yes, and sometimes last-minute fixes do get added, which is why sometimes the blog post is behind the version number of

RAM and CPU in Live

This MaxForLive device uses quite a lot of CPU and RAM, because it is doing quite a lot of work behind the scenes. This is also a very 'wide' device, but I'm cautious about doing a pop-up window (and not very good at programming them!).

Modular Equivalents

In terms of basic modular equivalents, then ProbablyR V14 would require several sequencers in series/parallel to give the same functionality, plus quite a lot of utility logic to do the linking, the probability functions and the nudging, as well as a dedicated 'clock' sequencer just to do the swing function, giving a total of about 16 ME.

Saturday, 8 June 2019

Spectral Hex Ping Pong Delay in MaxForLive for Ableton Live

After playing around with various Ping Pong Delay-like devices for a while, I realised that my 'Hex' template was a good place for experimenting with multiple delays, so I took the internals of the AUDpiPOde device and put it inside the 'hex' device template (six times). The result is AUDhexPPD, where I'm abbreviating ping pong delay to PPD to save characters.


Because AUDhexPPD is another 'wide' device, then here's just the left hand side:

Going across the left to right, the input indicator shows the incoming audio signal (and yes, this does duplicate the tiny meters in-between devices), then the Ping Pong Delay block, with the 'Note value time delay' button grid, followed by the 'Unsync' time tweaker, the 'LR swap' output channel allocator, the 'f' delay freeze button, and the Feedback rotary control (which is individual to each PPD block).

The next block across to the right is the middle block: the three-band 'spectral' filtering, which just gives three outputs via low-pass, high-pass and band-pass filters. Unlike the usual 'crossover' filters that you get in some 'spectral' devices (or loudspeakers, now that I think about it), these filters have a Resonance rotary control, which gives the device the ability to colour the sound, so maybe it is more than just six delays.

Finally, on the right hand side, there is the 'Auto-pan' block, which has an individual meter per audio processing block, the 'X' Active/Muted switch (as per all of the 'hex' devices, and a few others of mine), the new 'Pan Position and LFO Modulation' UI widget that I introduced recently (move the white 'thumb' down and horizontal for pan position, and up for LFO modulation), and finally the LFO Rate rotary control, which goes from very slow to not very quick, but then it is a modulation control and audio rate modulation of pan position is not something I'm a great fan of...

On the far right-hand side, there are the usual memory buttons (Click to recall, Shift-click to save (red when empty, grey when filled)) and the Dry/Wet rotary control, followed by three 'common' controls which affect all of the six audio processing blocks: Feedback, Resonance, and Freeze. These just make it easier to alter all of the six audio processing blocks at once!

As usual in the 'hex' devices, the right hand half of the front panel is mirrored, which looks interesting, and makes it very clear that this is a stereo device. Just repeating things twice can make it look like they are arranged in series... There isn't a perfect solution for this, but this way works for me, and it isn't too hard to flip one half if you need an unmirrored custom device...


So, what's interesting in the M4L code for this device? As I have mentioned previously, I prefer stereo in and out for my devices, and this is normally done with pairs of mono in and mono out devices where the output can be panned across the stereo image... However, each of the 6 audio processing blocks in AUDhexPPD is a tapped delay with a mono input and stereo outputs, and so instead of having one output that needed to be panned, then I had two - and for a ping pong delay then these two outputs should be in the Left and Right channels (or vice-versa - which is what the 'LR Swap' button does). But with two outputs then I needed two auto-pans, and so the obvious answer was to have two auto-pans in anti-phase, so that when one output was on the Left, then the other would be on the Right. 'Dual anti-phase auto-panning' isn't a very catchy description, so I'm going to call it 'Helicopter' mode, because the two pans circle around each other rather like the blades on a helicopter...

Yes, I could have changed the balance between control values and audio signals in this - so the 'snapshot~' and 'sig~'could have been removed from the panning part, but then I would have had to add them back in to the LFO Depth and LFO Out to get control values. This way works for me...

Alternatively, I could have had two SEPARATE auto-pans for each of the two outputs: one LFO for Left, and another LFO for Right. This would have required a doubling of all of the controls in the centre 'panning' block, and would have made the device even wider! (and more complex to use) I decided to go for the simpler solution and leave the 12 pan LFO version for another time (Maybe in an 'mc' version as a way to explore this new feature of Max 8!)

The Max code just inverts the (0 to 1) control value for the multipliers so that the two inputs are affected in opposite ways. Remember that the audio inputs are called 'L' and 'R' because this is the convention for ping pong delays - the first echo comes from the Left channel, then the next from the Right channel. These are not the main incoming audio channels to the whole device - each audio processing block has a mono input and two 'stereo' outputs. So, for each audio processing block, the two inputs are coming from a tapped delay, and so these input signal will be 'bouncing' back and forth between those inputs, and this auto-panning then adds additional pan control on top of that. If you stop the LFO and fix the pan position to Left or Right, then the result is ordinary ping pong echo - where the repeats 'bounce' between Left and Right.

Note that this is the auto-pan arrangement for just one of the six parts in the Pan block. So if you have just one 'X' highlighted and the rest muted, then that ping pong delay will bounce between the Left and Right output channels, panned according to the pan position and LFO modulation as set in that block. If you have two 'X's highlighted (one in the Left half, and one in the Right half), then you have two ping pong delay in parallel - and so the outputs can bounce between the Left and Right outputs independently. If you have all six blocks active, and use the 'triangle' tweak controls to 'unsync' the time delays, then you start to move away from 'echo' and towards 'reverb'-type sounds. The more asynchronous echoes you have, then the more 'reverb'-like the result will be - which, of course, is exactly how real reverb is produced: lots of echoes with different delay times. You 'could' put several 'AUDhexPPD' devices in series, but it is probably going to take a lot of adjusting to get something even approximately like a conventional reverb sound...

Getting AUDhexPPD

You can get AUDhexPPD on

Here are the instructions for what to do with the .amxd file that you download from

(In Live 10, you can also just double-click on the .amxd file, but this puts the device in the same folder as all of the factory devices...)

Oh, yes, and sometimes last-minute fixes do get added, which is why sometimes the blog post is behind the version number of

RAM and CPU in Live

This MaxForLive device has six tapped delays, so it will use lots of RAM storage and CPU power - but it is worth it, IMHO!

Effects Rack Equivalent in Live

I haven't tried it, but it ought to be possible to get quite a lot of the functionality of AUDhexPPD with an Effects Rack in Ableton Live, although the UI is not going to be as compact, and it might even be possible to implement the spectral crossovers using the band-pass filters inside Delay (or Ping Pong Delay if you aren't using Live 10.1).

What is interesting is that the limitations of building AUDhexPPD inside Live result in something which is a nice, usable effect, but it isn't the same as the MaxForLive version. Anyway, it was a good exercise in translation, and I'm making it available for free. You can download it from here...

Modular Equivalents

In terms of basic modular equivalents, then AUDhexPPD would require two high-pass filters, two low-pass filters, two band-pass filters, six tapped time delays, six LFOs, six panner, some utility switches, and two mixers, giving a total of about 24 ME. It is interesting that this is also a 'wide' device in MaxForLive!

Friday, 31 May 2019

Spectral chorus - another 'Hex' MaxForLive device

For a long time, I have been trying to find a good way to provide an intuitive user interface for 'Modulated Pan Position'. You can see me experiment with various ways to implement it in many of my MaxForLive devices - what I have always needed is a simple/obvious way of allowing control over pan position, but also allowing that pan position to be modulated by an LFO.

The 'traditional' way of doing this (and I have used it a lot: albeit unwillingly...) is to have a pan position (a slider is nice and intuitive) plus an LFO 'modulation depth' rotary control. That's two controls, and there is an implicit interaction between them where the LFO over-drives the panning so that the position goes to left or right and stays there, then suddenly pans across - it's because the LFO waveform (typically a sine wave) is over-driving the pan position, and the clipping of the waveform gives 'flat' spots in the auto-panning (Yuk!).

This is why, in AUDhexCHORUS, I'm introducing something that I have been working on for quite a while: a single UI widget that does pan position AND modulation depth combined together.

Here's the UI widget" The components are:

1. a 'thumb' (the bright white vertical bar) that you click with the mouse to control the setting of pan position and LFO modulation.
2. an LFO indicator (the big purple block) that shows the current pan position. (When the LFO modulation is active (as it is here) then this slides horizontally from left to right to show where the audio is in the stereo image.
3. two numbers that show the horizontal and vertical position of the 'thumb'. (These cn be used as mapping targets for other M4L devices)

The UI metaphor is very straight-forward: horizontal is pan position (Left is left, Right is right!), whilst up and down controls the depth of LFO modulation - and there's a triangle graphic that shows you where you need to position the 'thumb' to avoid over-modulation of the pan position. The 'thumb' that you click on is a vertical bright white bar, so when you move it horizontally it looks like a pan position slider, but when you move it upwards, then the LFO modulation is gradually increased, and if you move it all the way to the top of the triangle, then you get perfect side-to-side pan LFO modulation, with no 'hold' at either side. It makes using pan position/modulation SO much easier!

Here's a GIF that shows the UI widget in three modes.

The top example shows the 'thumb' in the 'sweet spot' position at the top of the triangle where the LOF modulation is maximised without clipping. Here the LFO modulation (the purple block) will move the pan position from hard Left to hard Right, without any major pausing at the Left or Right positions. If you move the 'thumb' to the left or the right away from the top of the triangle, then the LFO will spend time at that side (The waveform will be clipped), and may not go all the way across to the opposite direction. (The animated GIF has jerks in the way that the purple block moves - this is because of the looping in the GIF - in the actual device the purple block moves smoothly from sid to side, indicating the LFO-controlled pan position.)

The middle example shows the 'thumb' right in the centre, and so the pan position is only slightly modulated by the LFO.

The lower example shows the 'thumb' in the 'down' position, and this completely removes any LFO modulation, so horizontal movements of the 'thumb' just control the (fixed) pan position. The two numbers underneath the UI widget are the horizontal and vertical positions, and can be used as a target for mapping by LFOs and other M4L devices that use controller mapping. in this case, the 'thumb' is all the way to the left, and so the audio will be panned hard to the Left of the stereo image.


To accompany a neat pan UI widget, there's a neat device: AUDhexCHORUS (AhC for short, to save my fingers as I type!) There are lots of chorus devices out there, but this one has a few 'specials' that make it more interesting...

1. The 'Pan Position/Modulation Widget! (Of course!)

2. Spectral controls, as per some of the previous 'Hex' devices. You have three spectral 'bands' to play with, so you can have different chorus amounts/styles wherever you want across the frequency spectrum, and you can have different bands for the Left and Right stereo channels if you want.

3. Envelope tracking makes the chorus depth tracks the amplitude of the incoming signal... This is particularly good for dynamic sounds...

The actual chorus effect is achieved by using frequency shifting (Via ring modulation (which just multiplies two audio signals together) and can also be called a four-quadrant multiplier or a balanced modulator.) instead of using a modulated delay line. A future version might allow switching between the two methods - let me know if you would like this.

AUDhexCHORUS is a 'wide' device (It uses lots of screen 'real estate' in Ableton Live, so be prepared for some horizontal scrolling) - I'm not known for making 'one-rotary-control' devices!

In detail

AUDhexCHORUS is symmetrical, so both halves of the user interface are mirrored. Let's look at the left hand side - which covers the Left channel. Vertically, there are three similar rows of controls (one for each spectral band), and horizontally there are three similar processing blocks. Going across the blocks from left to right there are:

- The Frequency Shift block, which contains:
-- the frequency shift rotary controls,
-the envelope amount rotary controls (which increase the amount of frequency shift depending on the envelope of the incoming audio),
-- the vertical envelope depth indicator,
-- the smoothing rotary control (which smoothes the envelope control),
-- the 'sideband select' buttons (which select positive frequency shifts, negative or both),

- The Spectral Filter block, which contains:
-- the frequency rotary controls (high-pass in the upper row, band-pass in the centre row, and low-pass in the lower row),
-- the resonance rotary control (higher values get more 'peaky')
-- the 'Broad/Narrow' switches, which controls the number of filter sections that are used,

The Auto-Panning block, which contains:
-- the row output/mute switches (output when the 'X' is light, muted when the 'X' is dark),
-- the UI Widget for the pan position and LFO modulation, as described above,
-- the LFO rate rotary control (which is almost stopped at the slowest speed!).

On the far right hand side, common to both channels, then there is a Dry/Wet mix rotary control, as well as memory buttons which can be used to ave your favourite settings. Just shift-click on a red square to save (or a grey square to over-write), and click on a grey square to recall that memory setting.

Getting AUDhexCHORUS

You can get AUDhexCHORUS on

Here are the instructions for what to do with the .amxd file that you download from

(In Live 10, you can also just double-click on the .amxd file, but this puts the device in the same folder as all of the factory devices...)

Oh, yes, and sometimes last-minute fixes do get added, which is why sometimes the blog post is behind the version number of

Modular Equivalents

In terms of basic modular equivalents, then AUDhexCHORUS would require two high-pass filters, two low-pass filters, two band-pass filters, six frequency shifters, six LFOs, six panners, some utility switches, and two mixers, giving a total of about 28 ME. It is interesting that this is also a 'wide' device in MaxForLive!

Tuesday, 21 May 2019

Ping Pong Delay - Re-imagined differently! (Plus M4L Audio switches)

My first AUDpiPOde (Ping Pong Delay) M4L device had some protracted problems, and hopefully the additional tweaks for version 0.04 should fix them. But in the course of learning more about how the original (and soon to be deprecated) Ableton Live Ping Pong Delay actually worked, I realised that I had re-imagined it along the wrong vector, and that my 'all stereo' approach had too many differences to the original. The band-pass filter also proved to be a significant challenge, and dropping it again restricted the flexibility. (...Now, I'm not the greatest fan of 'muddy' echoes, but they are a defining characteristic of some vintage tape echo units...)

So, here's almost the opposite of AUDpiPOde - it uses a tapped delay line, mixes the channels into a mono signal for the echoes, and puts back the 'far-from-perfect' band-pass filter emulation made up from a high-pass and low-pass filter (and I need to learn more about filters in Max!). It uses a different 'freeze' method (as well as the ones I added), and it provides a 'Thru' button to bypass the filters. I also tweaked the delay routing so that you can have 'Echo in the Left channel first, then the Right channel' or 'Right channel first, then the Left channel' - which is quite striking if you are used to the 'feel' of the original!

And the name? AUDpiPOde-A, of course!

Making audio switches

One of the traps for people who are trying to learn Max are the large variety of switches. There are simple switches, complex matrix switches, routers and the names are sometimes different if audio is being switched. I'm still gathering information for a guide, but in the meantime, here's what I've been doing to build custom audio switches...

LR 'Left first' 'crossover' toggle switch

The 'Echo in the Left channel first, then the Right channel' or 'Right channel first, then the Left channel' switch functionality is a good example. All that needs to happen is that the two outputs from the delay (the middle tap and the end) need to be routed to the Left and Right channels, in the two possible combinations.

This is the output stages of the AUDdiPOde 'Ping Pong Delay' device, with, from top downwards, the feedback rotary control, the 'LR' echo order control, and the Dry/Wet rotary control. For the Feedback control, you can see how the line~ object is fed with pairs of '<new value> 50ms' values for each new line segment, so that the multiplier that does the feedback only gets values that change reliably slowly (each new value takes 50ms to happen) and so the amplitude of the feedback signal doesn't jump suddenly.

Just below the feedback code, the 'LR' box is where the interesting switching takes place. The 'p cross_mr' object has two stereo inputs (from the tap and the final output of the tapped delay line) and two stereo outputs (which go to the Dry/Wet' balance control library object. The 'LR' toggle switch controls the 'p cross_mr' object, and all it does is change between the default 'Left In to Left Out, Right In to Right Out' switch setting to the alternate 'Left In to Right Out, Right In to Left Out' which reverses the channel ordering. So in the default 'Left first' position, the 'LR' switch controls the 'p cross_mr' object so that the tap output of the delay line goes to the Left In of the 'cross' switch and comes out of the Left Out, which means that the tap output is heard in the Left channel first, whilst the final output of the delay is routed to the Right channel and so is heard later. When the 'LR' toggle is in the 'Right first' position, then the 'cross' switch routes the tap output of the delay to the Right channel where it is heard first, and the final delay output is routed to the Left channel, where it is heard later. So the 'cross' switch connections are either straight-through, or crossed-over - hence the name.

I don't think there is a standard MaxForLive switch that does this 'out of the box', so I made the 'cross' switch:

There are only two objects used inside the 'cross' switch - gate~ objects, which are just on/off switches for audio signals, and one of those arcane 'not quite obvious' special-purpose modifier objects: '!- 1', which inverts a 0 or 1 control value. So 0 becomes 1, and 1 becomes 0 - it is an 'inverter' for  control values. If you replace the two left-hand gates with through connections (closed switches) then you can see that A goes to X, and B goes to Y. Whereas if you replace the two right-hand gates with throughs then A goes to Y and B goes to X, and so achieves the straight-through or
crossover switching.

In physical hardware, then crossover switches like this are very easy to spot when you look at the rear  wiring of a front panel - the inputs go to the centre common part of the switch, whilst the outputs come from one of the outer pairs, and two wires cross over the outer pairs - so you can see at a glance that it is a crossover switch!

Fade switches

If you just switch from one audio signal to another, then you get sudden changes in the value of the signal, and these can cause clicks in the audio. To avoid this happening, one technique is to 'dip' the audio volume as you do the switching, and then restore it afterwards. This approach is used in AUDpiPOdePLUS, the 'performance-oriented' freeze echo device.

For this technique to work, then a sequence of operations need to happen in the right order, and at the right times. Here's the sequence:

1. The volume is at maximum.
2. trigger for the switching occurs. In the AUDpiPOdePLUS device, this happens when one of the 'Freeze' mode buttons is clicked.
3. The volume starts the fade downwards to zero.
4. The volume stays at zero for a few milliseconds, whilst the switching takes place.
5. The volume starts to fade back up.
6. The volume reaches maximum level again.

Once again, there wasn't a standard pre-prepped switch for the 'Freeze' mode button signal routing, so I made my own. It uses the 'constant volume' technique from a previous blog post, plus the 'gate~' switching describes earlier, with added 'fading' to dip the audio signals in and out at the right moments.

The three 'Freeze' modes are A, A+B, and B, which correspond to 'Tap', 'Final output', and 'Tap and Final output' being fed back to the input of the delay. the volume compensation is done using a 1/n multiplier, so that the final multipliers multiply by 1 for single inputs, or by half for two inputs. The fading is done by the 'p dip_mr' objects, whilst the gate~ objects do the switching, and the 'pipe' objects just delay th switching so that it happens when the volume is zero. But the really interesting stuff is in the 'dip' object:

Unfortunately, once you have seen it, then it isn't quite a magical as you might have expected. The line falls to zero in 50 milliseconds (ms), then stays there for 10 ms, then rises back to 1 in 50 ms again. The 0to 1 values of this 'fat' or 'dip' envelope are the multiplier value used in the multipliers, so there's no complicated conversions required. Here's the same thing expressed as a timing diagram:

So the trigger happens when one of the 'Freeze' buttons is clicked. The fade envelope starts to fall, and when it reaches zero, then the multiplier is zero, which means that no audio gets through the multiplier. The switch control has been delayed from when the trigger happened, and the audio signal is switched whilst the envelope is at zero and there is no audio signal getting through. Once the switching has happened, then the fade envelope returns back to 1, and the audio has been switched without any click happening.

This 'dip' fade envelope technique can be used whenever you want to switch from one audio signal to another without having a click. There are other ways to do it, including some that don't have any 'dip' in the audio, but this is a simple starting point for further explorations.


I have struggled with the filtering all the way through the two 'AUDpiPOde' devices. In this 'A' version, I have revised the filtering again, so there is now only a single low-pass filter instead of two in cascade, and the high-pass filter is now a State Variable design because the 'subtracted low-pass' technique didn't seem to work very well (but then inside a feedback loop is always a bad place for any filter!). This is far from a perfect design, and full credit to the Ableton coders who have a far superior filter in the original Ping Pong Delay, and in the new 10.1 Delay devices. If only such a filter was available in MaxForLive...

Getting  AUDpiPOde-A 0v05

You can download AUDpiPOde-A 0v0for free from

Here are the instructions for what to do with the .amxd file that you download from

(In Live 10, you can also just double-click on the .amxd file, but this puts the device in the same folder as all of the factory devices...)

Oh, yes, and sometimes last-minute fixes do get added, which is why sometimes the blog post is behind the version number of

Version 0.05 gives some idea of the development problems that I have had with these 'ping pong delay' devices! It seems that having ping pong delay plus several freeze modes is a good way to get confused about single routing, and I have made more mistakes than I want to think about. So my normal 'Work In Progress' label definitely applies to this device!

Modular Equivalents

In terms of basic modular equivalents, then AUDpiPOde-A would require two band-pass filters, two delays, some utility switches, and two mixers, giving a total of about 5 ME.