Sunday 3 May 2020

Polyphonic note probability and velocity randomisation Max For Live device in Ableton Live

'Prob' is an ongoing background project of personal 'fixers' that I sometimes release utilities from - list below. So here's the latest device from that, and unlike previous devices, this one isn't intended specifically for drum sounds (but...).

There's not very much in the UI, and most of the MIDI processing inside uses the 'message box' method that I've been exploring recently. But what it does is something that I find very useful, and it builds on MIDIswapNV and the rest of the 'prob' series of devices... (The core of MIDIprobNV is based on MIDIswapNV!)


MIDIprobNV is a simple utility that does two things to MIDI notes that pass through it: it allows the probability of a note being passed through to be controlled, and it also allows the velocity of the notes that pass through to be offset and a random value added. In other words: it allows you to control the percentage of missing notes, and to adjust how much extra variation is added to the velocity. This allows you to vary MIDI note streams quickly and in a useful way - and I use it all the time!

The 'Probability' rotary control sets the probability of a note passing through the device. At 100%, all the notes should go through. At 0%, no notes will go through. At 50%, half of the notes will go through, but they are randomly chosen, so you do not have any way of controlling (or knowing) which notes will get through. The note choice is polyphonic, so if you play a chord, then some of the notes will get through, whilst others will not. So broad, jazzy chords will get thinned out, but will be voiced differently each time you repeat them, with different notes being dropped. (If you want the opposite effect, where notes are added to the ones you play, then you could try auditioning devices like Spitfire Audio's 'Stratus' Kontakt device...)

Note that the next two rotary controls and bar displays will only work when notes are actually passing through the device! This helps to reduce the CPU load...(I think...)

The 'RandomV' rotary control sets how much random velocity you add or subtract to the original velocity of the incoming notes. If it is set to 0%, then nothing is added or subtracted. If it is set to 100%, then it is probably going to max out the MIDI velocity at 127. (the device clips MIDI velocity, because the repercussions of MIDI velocities above 127 are not good!) In between these limits, you can add as much extra randomness as you want. Note that your sound-producing instrument needs to have some velocity sensitivity, otherwise no amount of random velocity will affect it!

The 'Offset' rotary control adjusts the middle value of the output velocity. If this is set to 0, then the outgoing velocity will have random velocity values added or subtracted to it, and the average will be much the same as the incoming velocity. If you increase the offset value, then the output velocity will tend to be higher, whilst decreasing it will reduce the output velocity. Remember that the values that are added to or subtracted from the incoming velocity are random, and so there will be a range of range of velocities.

This is where the three 'bar' displays come in. The one on the left simply shows the incoming velocity. The one on the right has two parts: the left side is the actual outgoing velocity, but alongside it on the right is a 'Range' bar that shows the maximum and minimum values that it can have. The size of the range bar changes as you alter the 'RandomV' rotary control - the bigger the RandomV value, the bigger the range bar. Changing the 'Offset' rotary control moves the range bar up and down, so you can immediately see when the output MIDI velocity is too low (1) or too high (127). 

I always try to avoid repeating other devices, so MIDIprobNV combines probability control with random velocity, which means that it hopefully provides a very different way of controlling these two parameters than you get with the stock 'Velocity' plug-in. I'm particularly proud of the range display, which I may use in other devices - modulation controls have always been something that I have wanted to make more intuitive... For the final release I have also added 'scrolling 'history' plots, so you can see what the velocity values have been back in time...

 In use

MIDIprobNV 'thins' out MIDI notes at random that you pass through it, so on chords it will change the voicing, and you may lose the root note. On melody lines or arpeggios, then it will remove notes at random, which can include the first note in a bar, which can sound unusual. One mitigation for this is to include a second track where you include all the notes that you definitely need to hear!

The demo track on SoundCloud uses two tracks, but has an arpeggio on track 1, and chords on track 2. The settings of MIDIprobNV are similar on the two tracks, and the delay and reverb are much the same for both tracks. The same instrument is used on both tracks, but is tweaked slightly. The musical content of the demo is not going to win any awards - but it serves well as a way of showing one way to use MIDIprobNV.

Here are the chords on track 2:

Remember that MIDIprobNV will remove notes from these! (So the density of notes is not as bad as it appears!)

Here are the arpeggios on track 1:

Again, this is just to provide raw material for MIDIprobNV to thin out...

And the tone generation:

I have used a stock MIDI LFO to modulate the 'Probability' rotary control in MIDIprobNV so that it varies from 75-ish to 40-ish, so the number of notes removed keeps varying. I do this on both tracks, with different LFO speeds. 'Muted1 Impure' is a modified stock/factory preset for Analog...

Finally the effects: 

A tiny bit of my fave 'ping pong' delay, and a stock reverb. Nothing special.

Yes, I know the chords are too loud! Hopefully, despite my rapid mixing (no time!), you can see/hear that what should be a mind-bogglingly boring set of chords and a pedestrian arpeggio turns into something much more useful when it is 'thinned'. The chords and arpeggios took a couple of minutes to put into Ableton's piano roll, but there's hours of wannabee elevator music lurking...

I'm sure that you can do much better than this!

You can extend the LFO-control here to use clip envelopes, as seen here:

One other use is to remove notes from drum clips! See below for the earlier devices in the 'Prob' series which allow you to set exactly which notes/sounds are processed, but MIDIprobNV just removes drum sounds without caring, which may be exactly what you want... Once again, a good ay of using this may be to record two tracks, where one contains essential beats, whilst the other one is where MIDIprobNV can remove notes as it feels like it...

The RandomV and Offset rotary controls can also be controlled by other dvices via the Ableton Live 'remote control' 'control voltage' 'Map' buttons that you find on devices like LFOs...

Previous devices in the 'Prob' series...

MIDIiprob+D4    (Includes time delays as well!)

MIDIprobD4       (Simple 4-note probability control)

MIDIoffGRID4   (Lots of time delay variations! Closely related to, and almost one of the 'Prob' series...but named for clarity with what it does!)

Previous devices with similar names, which might be confusing...

MIDIprobablyR  (Actually a very sophisticated probabilistic step sequencer from a different series - the 'Probably' series!)

SoundCloud demo

The SoundCloud demo is here:

Inside the M4L code...

I won't bore you with a random number generator and a '>' object! Instead, I thought it might be more interesting to look at timing considerations. One of the techniques that is used when designing anything where timing is important is to look at the code that is used most often, and the code that the main data flow goes through. In this case, these are both the same: for every MIDI note, there needs to be a probability calculation and a random velocity calculation, and so generating random numbers  is definitely going to be in the 'critical path' because it needs to happen for every MIDI note... Generating random numbers is probably going to take longer than a simple comparison for the probability calculation, so that's what I concentrated on. In the past, I've had problems with modulo functions taking a long time, so here I did some timing tests between the standard 'random' object in Max and one of the 'cheats' that sometimes gets used when time is critical. Here's the tester being used to try the 'random' object:

The 'timer' object measures the time (in milliseconds) between the bang in the left input, and the right input. I started out with the rotary control at 100, so the metro object was ticking quite slowly, and then turned it anti-clockwise to see if I could get the 'random' object to stutter/stop/repeat outputs, etc. As it happens, the initial delay was large, but rapidly settled down to 5 milliseconds, and I didn't see any repeated values (there's a scrolling multislider not shown here).

For an alternative, I used what is sometimes called 'captured entropy', which is just another way of saying that I captured 512 random numbers and put them in a lookup table:

The speed of this probably boils down to how efficiently the zl object can do a lookup...

What was interesting here was that the initial time delay was very large, presumably as buffering took place for those 512 random values, but then it stabilised. However, overall, it seems that zl is not as fast as the 'random' function. I did wonder about going for an implementation in Gen, but ran out of time... (In the lockdown, everyone I know is busier than usual!)

I did consider having a switch in the plug-in, so that you could choose between the built-in 'random' function (which the documentation says is a pseudo-random generator (quite normal - I wasn't expecting a cryptography-quality function!)) and the 'captured randomness' version. Would you start to notice the repetition every 512 notes? But in the end I went for speed, and so there's only the stock/factory random function in the released version. But at least I did some checking! (Although checking timing in the same environment is not the best technique!)

One thing which I did think about was to deliberately exploit repeated patterning instead of pseudo-randomness, and so there may be a plug-in that uses that at some date in the future...

Getting MIDIprobNV_mr01

You can get MIDIprobNV_mr01 here:

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 a blog post is behind the version number of

Modular Equivalents

In terms of basic modular equivalents, then implementing MIDIprobNV_mr01 requires very little beyond a couple of noise generators, plus two sample & hold modules, giving an ME of about 4!


If you find my writing helpful, informative or entertaining, then please consider visiting this link:

No comments:

Post a Comment