Tuesday, 19 March 2019

A little bit of echo here and there - with MaxForLive in Ableton Live...

The last thing that the world needs is 'Yet Another Echo Effect'. This may sound like a good plan, but if you pronounce YAEE then you get something very like 'Yay!' and the fate of the world is sealed! And so, now, I'm going to announce another echo effect...

It was after I finished the hex frequency shifter that I looked at the central hex auto-pan section and thought: 'That would be interesting in an echo effect...' A month later, and here is the result, but, as usual, I'm not one for just doing a 'me too', and so this isn't your ordinary echo effect.

Hex Echo


The core of the hex echo is two sets of three delays, arranged in series, but with access to the delay inputs and outputs in parallel. The output section is exactly the same as the hex frequency shifter, and allows each delay to be selected and panned separately, either fixed (with a rate of zero Hertz for the LFO) or automatically. For the inputs, then you can send the stereo inputs directly to the two delay lines, so this kind of treats them as if they were in parallel as well. The inbuilt links between the three delays are still present though, because that made the routing just a tad too complex.

All of the feedback loops are also switched, which means that you can quickly turn feedback on and off without having to change a rotary control. It means that you get fast control over the feedback, which can be very useful when there's too much overall gain and it starts to run away with itself. There are memories to store your favourite settings as well, and a good idea might be to set one of these to a 'all-feedback-off' setting so that if things do start to get loud, you can stop it quickly. A post-limiter might also be a good thing to add too...


Constant Volume

Apart from having to keep track of lots of signal routing, one of the trickiest aspects of the Max programming for the Hex Echo was the output pan selection. For each channel, you can select any of the delay outputs, which means that you can have 8 combinations of the three selector switches. One of the combinations isn't very useful for most of the time - the 'all off' one where no delay line gets to the output. But actually, it can be useful, because you might want to have just one channel's delays in your output, and for that then you would want to turn all of the selectors in one channel off, and leave the other channel's selectors on. The output panning means that the outputs are positioned in stereo, so this doesn't mean that the output will be mono.

But having three selectors means that the other seven combinations will change the output volume, because when there are two outputs present then they will be louder than a single output, and three outputs will be louder still. What is needed is a 'constant volume' selector, and that is what I programmed inside. Here's the level of abstraction just above the bit where you find out how it works:



So there are three [X] selectors, which route the delay outputs to the banners (pan_mr), and the volume compensation happens in the 'selpan_mr' object, which does all the hard work.


Let's work towards a general case for volume compensation by starting with the simplest case. With two [X]  selectors, then there are only three possible combinations: both on, both off, and one off whilst the other is on. In the 'both off' case, then we don't care about the volume! But the 'both on' and 'only one on' cases will give different volumes: the 'both on' will be the result of two signals being mixed together, whereas the 'only one on' is just one signal. So if we use the 'only one on' case as the reference, then the 'both on' case needs to be reduced by half, so that the result of mixing the two signals together is the same as the single input. In other words: 1/2 plus 1/2 = 1.


For three [X] selectors, then there are more combinations, but really there are only four distinct ones:
- all off
- one on
- two on
- three on

And when there are three signals being mixed together, each one needs to be reduced to one third - which is the clue to the general case. For two signals then the volumes need to be reduced by one half (1/2), for three signals the volumes need to be reduced by one third (1/3)... So, for 'n' signals, the volumes will need to be reduced by 1/n.

For completeness, here are the intermediate stages that I went through developing the final 'selpan_mr' object. First, I tried using the 'select' object to trigger messages to provide the multiplication values (0.33, 0.5, 0.99...)


But whilst this works nicely for two values, there isn't an easy way to scale 'select' for more outputs...

Then I tried using a simple linear equation to generate the 0.3 and 0.9 values, but this had a problem with one of the multiplication values...


There are three repeated sections, where an audio input (port in 1 for instance) is routed through a 'gate~' and then a '*~' multiplier (acting as a VCA) to the audio output (port out 1 for instance). Port in 2 controls that gate, turning it on and off, and so routing it to the panner object. But that control is also used to do the volume compensation. All of the Port Ins that controls the gates (port ins 2 4 and 6) are summed together at the '+ 0' object on the right hand side, just above the '!- 4' object. That '+ 0' object adds the three gates together, so if one gate is on, then the result of the addition is 1, whilst if all three are on, then the result is 3. (You can guess what the output is when two gates are on!) Unfortunately, the gate signals are the wrong way round in terms of adjusting the volume, and the '1- 4' object reverses the result by subtracting the sum from 4, so when all three gates are on, the output is 3, and when two gates are on, the output is 2, and all three gates on gives 1. The '* 0.3' does the volume magic - for three gates, then the 1 is multiplied by 0.3 and this is sent to the multipliers, so each port output will get about a third of the volume, and since all three ports are active, the resulting volume in the channel will be 0.9. If only one gate is on, then the subtraction gives 3, and 0.9 is sent to the multiplier for that gate, which gives 0.9 again. For two gates, then the output is 0.6 twice, which gives 1.2 volume, so this isn't right.

Testing Max patches with complicated sets of inputs and outputs requires a bit of planning. In order to use the three [X] selectors and see what is happening inside the 'selpan_mr' object that they feed into, you need to open two windows: one so that the [X] selectors can be set, and another so that the effects on the internal values inside the 'selpan_mr' object can be observed.


Here are some screenshots of the 'almost right' 'selpan_mr' object in action. (The case shown above was what happens with no gates active, so there's no output at all!)

First one gate on:



Which gives the 0.9 multiplier for that single output.

Then two gates on:



Which gives two lots of 0.6, which is 1.2, and so a little bit too big...

And finally, three gates on:



Which gives three lots of 0.3, for a final output of 0.9. Good for showing troubleshooting and testing, but that incorrect value isn't right. Compensating for volume only works if it is right!

Now there IS a 'brute force' way of doing this type of calculation - a 'look-up' table. In Max this can be done using a 'coll' object and filling it with a table that contains the values on 'n', and the corresponding multiplier values. Here's the Max patch and the table inside the 'coll' object:


And here are the two windows in use to test it:


The left hand window is used to control the [X] selectors, whilst the right hand window shows what is happening inside the 'selpan_mr' object, using the number boxes.

We now have an object that is doing maths on the 'n' value for the number of [X] selectors, but all that it says is 'coll'. The actual operation that it carries out on 'n' is hidden inside the table inside the 'coll' object. This may work, but it hides what is happening rather too deep for my taste...

So back to the general formula: 1/n. How do you code that in Max? The way to do it directly is related to the way that Max maths objects have two inputs: one on the left-hand side that is an input for a value and also a trigger for the calculation, whilst the other (on the right hand side) is just an input for a value (or is the value inside the maths object). Let's consider the case when you want a fixed value inside the object. So if you want to add 2 to 3, then you send a value of 3 into the trigger input, and an object that contains '+ 2' will produce an output of 5. But for subtraction, then this way of working has a problem. If you want to divide one number by another, then an object containing '/ 2' will produce the result '3' if you send '6' into the input, so a calculation like 6/2 is easy. But how about if we want to calculate 1/n? The value inside the object is fixed, and so we would need to use a message box to send a '1'into the left hand input, whilst sending 'n' into the right hand input, and then we would need to trigger the calculation by sending a bang into the left hand input. It is a lot of work for a simple result!

Which is why Max provides a shortcut. You put '!/ 1.' inside the maths object, and any value of 'n' that you feed into the left hand input will give the result for '1/n'. Easy, yes, but confusing to beginners in Max, and this notation still makes me stop and think even after years of using it. Anyway, if we process the number of [X] selectors that have been set with a '!/ 1.' maths object then we get the '1/n' value that we want. Here's the Max patch:


So we finally have a relatively neat way of carrying out a '1/n' maths operation, although the '!/ 1.' inside that Max object still forces me to stop and think. Anyway, we now have a 'volume compensation' object that works for three inputs, and it can be extended for additional inputs relatively easily, with the main processing done by the '!/ 1.' object to carry out the '1/n' operation, and the hardest bit of extending it is finding a way to determine the number of [X] selectors that have been set - as you can see above, for just three selectors there are a lot of objects used to produce the value of 'n' that is fed into the '1/n' maths object!

Clutter Minimisation

You may be wondering why I have the 'selpan_mr' object there at all, since it just serves as a way of lumping all of the volume compensation into one place. Well, it is my ongoing attempt to try and tidy up my Max/M4L patching!

In the past, some of my Max/M4L patches have been a little untidy, and I have tended to put all of the objects at the same level. I'm now trying to do things in a more structured way, and one of the techniques is 'encapsulation', where you hide away stuff that isn't required. The 'selpan_mr' object is a perfect example - at the highest level, you need to know that there are three [X] selector switches that route the delay outputs to the auto-pan sections, and that is all. The details of the volume compensation are fine hidden away inside the 'selpan_mr' object. So here's another example:


At this level, we have the three delays on the left-hand side, and the delay time, feedback and cross-feedback rotary controls for one of the delays on the right hand side. Notice that the rotary controls are connected directly to the delay object ('p delayer'). But what is inside the 'p delayer' delay object?


Inside the 'p delayer' object is the standard M4L 'delay~' object from Cycling'74, but also a lot of maths objects that do all of the scaling and smoothing (using the 'line~' object) for the rotary controls. If all of these maths objects were on the higher level, then the three delays would not have been as obvious, because there would have been lots and lots of other objects everywhere. But moving the processing for the rotary controls into the 'p delayer' object, then the higher level shows the high level signal flow through the 3 delays, and this is not obscured by lots of objects just to get the rotary controls to have the right values.

Topology

Hex Echo enables quite a few different configurations of the six delays, so here is a quick guide to them:

1. Three delays in series




2. Three stereo auto-panning delays




3. Three delays in parallel, and in series




4. Three delays in parallel, and in series, and with stereo auto-panning per delay




Because the two channels are separate, then you can have different arrangements of the delays and the panner in each channel. The 'cross' feedback from one channel to the other can be quite confusing if you have different arrangements, and it can be quite hard to figure out what is where. My recommendation is to use the [X] selectors to turn off signal routings and to gradually turn them back on, one by one, so that you can hear what is happening. The two pairs of vertical signal meters on either side of the panner section can also help you to figure out what is happening to the audio signals.

Applications

Hex Echo can be used for ordinary echoes, but the parallel/series modes and the 'per delay' feedback controls make it very good at the sort of 'cluster' echoes that you get as 'early reflections' in reverbs, especially if you have different delay settings for the two channels. Another thing to try is to set two of the delay times short, and one long (up to 2 seconds), which can be quite unusual because most ordinary echoes don't have three delays in series... The 'Recycle' feedback goes from the output of the three delays all the way back to the input, which is a total of six seconds of delay to work with (or 12 if you 'cross' it over to the other channel.

If I can find the time, then I will try to put a video together, but this takes a lot of time to do properly...

Getting Hex Echo

You can download Hex Echo for free from MaxForLive.com.

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

     https://synthesizerwriter.blogspot.co.uk/2017/12/where-do-i-put-downloaded-amxd.html

(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 MaxForLive.com...

Modular Equivalents

In terms of modular equivalents, then the Hex Echo obviously requires three delay stages, plus some switching, and a utility/attenuator for the recycle feedback, giving a total of about 5 ME. One of the things that I have noticed with the current generation of Eurorack modulars is that many people do quite a lot of post-processing on the audio, and I have seen quite a lot of multi-delay echoes being used. So an interesting side-effect of Hex Echo is that it can make Ableton Live sound more like a modular, which might be useful to some people. I count myself as one of those, because I have always tended to fall into the 'Trent Reznor' grouping where if people can tell how your sound was made, then you aren't trying hard enough.


Sunday, 17 February 2019

Interviewed by Darwin Grosse of Cycling '74

Back in January, I mentioned that sometimes the music industry caught up with me, and I'm pleased to say that it has happened again! As a result of asking about gen~ in Live 10 for a blog article, I exchanged emails with Darwin Grosse, who is the Director of Education and Customer Services at Cycling '74, and he asked me if I would be interested in being interviewed for the 'Art + Music + Technology' podcast page.

And I said 'Yes, of course!'

So if you ever wanted to hear what I sound like, and learn a bit more about my background...


(I'm interview number 264, so Darwin has been very busy! It is well worth scrolling down to see some of the other people that he has interviewed...)

I would like to thank Darwin, Cory and all at Cycling '74 for all of their help over quite a few years. Their support has been consistently wonderful! I just wish that I had more time to develop more  MaxForLive devices - unfortunately I have a lot of other projects that also keep me busy...

Darwin Grosse's web-page contains a lot of useful and interesting links.








Monday, 11 February 2019

Fun with Frequency Shifting

Here's a surprise entry from the 'rapid gestation' pipeline - a hex frequency shifter that is totally intended to mangle spectra! This is not a scientific instrument designed to move technology towards ever higher fidelity. It joins the 'Ironic Distortion' device and a few of my other devices on the 'noise' side of the audio processing 'sine to noise' axis.


So that's the advert - but what is happening inside? (I would say 'behind the front panel', but I can't see this ever making it into real hardware!) Well, this is a 'true' stereo device, and so there are two parallel audio paths, each with 3 frequency shifters, and so it definitely qualifies for the name: 'Hex'.


But rather than follow the path forged by the many other frequency shifters that have already been created in M4L, I threw caution to the winds and went free-form, so the routing between the frequency shifters is not preset. The outputs from the upper and lower sidebands of the frequency shifters, plus the inputs to the next shifter, and the input to the auto panned outputs, all go into two routing matrices where you can connect them together as you like. The default is 'no connections', so all of those [X] toggles are dark, and there is no audio output (unless you turn the rotary control to 'Dry', of course!).

Probably a good starting point is to click on the [X] toggles for the '+' in the Left and Right routing matrices. This will route the upper sideband output of the first frequency shifter into the input of the second, and so on, through all three shifters. You won't hear anything at the output until you also route the auto-pans, which are the extra [X] toggles in the centre section between the two channels. So select the lowest of those [X] toggles to hear the full 'hex shifter' sound! This is probably a good time to set all of those pan rate controls to different values so that the stereo output will be fully spatialised!

(The two [X] toggles with arrows allow you to patch across from one channel to the other, so you can send audio back and forth between the two channels as you wish. As with many things, turning on all of the toggles is not necessarily the best approach!)

Each frequency shifter has two modes:

'Freq'  mode:

'Freq' mode does exactly what you expect - it shifts the incoming spectrum. If you click on the 'Mod' button so that the LFOs grey out then you will get the 'fixed' frequency mode where there is just a single frequency control that sets the amount of frequency shifting. If you turn on the 'Mod' button then the LFO rate and modulation depth controls will appear, and you can then wobble that frequency shift instead of it being fixed. (Oh yes, and this diagram above kind of gives the impression that there is only one LFO per pair of Frequency Shifters, whereas actually there are two...)

'Rate' mode:

'Rate' mode is slightly more unusual, and I haven't seen anything quite like it in any of the effects units that I've played with... What it does is sample-and-hold the incoming audio, and use this to shift the frequency - and it sounds really interesting and different... The 'Mod ' button has the same effect: 'off' hides the controls and mutes the LFO, whilst 'on' shows the controls and allows the frequency shift value to be modulated by the LFO.

Applications

You can use HexFrequencyShifter as a 'drone' processor, where it can turn rather ordinary bland sounds into something altogether more complicated. Frequency shifting tends to be rather destructive to sounds that have to be in tune with other sounds, and so, at first sight, this is not a device to be used for processing an instrument that will then be played alongside other tuned instruments.

But if you use the 'Wet/Dry' rotary control carefully (less than 25%, for example), then you can add small amounts of non-harmonically related distortion to your audio, which can be rather like adding pepper to food. Now, back in the 1970s and 80s, devices that added 'carefully designed additional spectral information' to audio used to be called 'exciters', and were often used to compensate for the aggressive low-pass filtering that people used to try and control tape hiss. As it happens, the HexFrequencyShifter is quite good at producing 'additional spectral information', and even to jaded ears such as mine, having spectral components of distortion moving around and across the stereo stage is quite cool! (Most of the distortion I have heard is often quite boring spatially) I will see what I can do about an audio demo on Soundcloud... But in the meantime, here's a video demo on YouTube (complete with a video titling error because I was rushing!): https://youtu.be/jeg-XMnnDmM

Getting HexFrequencyShifter

You can download HexFrequencyShifter for free from MaxForLive.com.

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

     https://synthesizerwriter.blogspot.co.uk/2017/12/where-do-i-put-downloaded-amxd.html

(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 MaxForLive.com...

Modular Equivalents

In terms of modular equivalents, then the 'Bode Frequency Shifter' was one of the modules that appeared on classic Moog modulars, although I'm not sure that they appear in many lists of 'basic' modules for a minimal modular synthesis setup! But since I added a 'Scale' device recently, then I'm going to add a 'Frequency Shifter' module as well. Based on this, then my estimate is that you are going to need 6 frequency shifters, plus 6 LFOs, plus three stereo auto-pans, which gives a grand total of about 18 ME.



Sunday, 10 February 2019

Scales and inverted keyboards

Some time ago, I looked at the 'factory' Ableton Live MaxForLive device called 'Scale', and in particular the 'Inverted and Useless' preset, which is both a good and a bad description. Behind the scenes, I was working on my own 'scale' device, and this has recently been updated to the point at which it is probably releasable. Yes, I know that I often seem to release things too early, but sometimes things that I don't release go through slow and tortuous development behind the scenes (Waverne 2 is one example), and there are also devices where the beta testing takes longer than expected. Anyway, NoteScalery is now at the point where I think it is ready for people to play with, and it will be followed by a number of other related devices that depend on having some way of controlling the mode/scale of the notes that they produce. All of the data spreadsheets that I produced in order to create NoteScalery will be made freely available for download.

Scales

So what's a scale (in the genre of conventional 'Western' music that MIDI 1.n kind of assumes)? For MIDI notes then it can be thought of as a mapping between all of the possible notes (128 of them, numbered from 0-127) and a smaller set of notes that follow a (normally) musical rule. So example rules might be along these lines: 'All of the white notes', or 'The notes in the key of C Major', or All notes except sharps or flats'...

Now because of the way that notes have an interesting property related to multiples of pitch, then, if you go up in semitones from a given note, after 12 semitones, you end up at the same note, but one octave higher, and this note has double the pitch or frequency of the note where you started. Octaves are very special intervals because of this doubling (or halving if you go down in pitch), and when you combine this with the equal intervals between the semitones (in equal temperament), then this hugely influences the way that people think about the way that notes work together. 12 notes in a familiar black and white pattern, and it repeats every octave, so everything must repeat every octave, yes?

Unfortunately, it isn't quite as simple as this. You can see this when a piano tuner 'tunes' a piano. Actually, whilst they do 'tune' the piano, they also have to make compromises because those 12 neat semitone notes are only an approximation that sounds reasonable in most key signatures - and the piano tuner is adjusting the notes so that various intervals sound okay 'overall'...

You can also see a problem when you have minor scales that are different when they are ascending or descending, and when you start to invert the notes in a scale then things can go very weird. So the idea that a scale applies to an octave of notes is a nice tidy approximation that works in a lot of cases, but it isn't perfect for all cases.

In musical terminology, the correct word for the mapping of notes is a 'mode', but scale is often used synonymously...

Implementation

So how are MIDI Scale devices typically implemented? Well, they use octaves - they show which notes are in the scale for an octave, and just apply this across the whole the note range. Simple.

And sometimes things really are that simple. If you look inside the MaxForLive PitchScaler device that comes with the M4L examples in Live 9, then you get code that fundamentally exploits octaves:


On the left is the raw Max code. In the middle I have marked up the main sections, and on the right is the block diagram of what is happening. So after the decoding of the incoming MIDI messages, then there is the split into two sets of numbers: Note numbers, and Octave numbers. Note numbers go from 0-11 and indicate which note in the octave has been received. To extract this from the raw MIDI Note Number you just do a modulo 12, which is what the '%12' object does - it just repeatedly subtracts 12 until the result is less than twelve. You probably know this as a 'remainder' - the number that is left when you do a division. The Octave number is interesting, because when you 'repeatedly subtract' in the modulo function to get the remainder, then the number of times that you repeat is the Octave number. So if the MIDI Note number that was received was 25 then subtracting 12 gives 13, and subtracting 12 from that gives 1, so we know that the Note number is 1 (if C=0, then 1 will be C#), and the Octave number is 2, because we had to subtract 12 twice to get a remainder which was less than 12. So the MIDI Note was a C# in the third octave.

Now that there is only one octave's worth of Note numbers, then mapping which input numbers produce which output numbers requires just a 12x12 table. Nothing needs to happen to the Octave numbers - they just pass through to the output. The output stage is shown as an addition with a '+' symbol, but actually there's two extra refinements in the code. First notice that the output of the map table has another modulo function, so if there is any unexpected value in the table, then the only Note numbers we can get out will be less than 12. Second, the Octave number is multiplied by 12, so that we undo all of the repeated subtractions. When we add together the mapped Note number and the multiplied Octave number, then we get the MIDI Note number for the mapped note on the scale - as defined in the map table.

So that's how Ableton's own example does it, and you might be forgiven for thinking that we are at the end. We have a working Scale device!


If you look at the standard 'Scale' device that is included with Live, then you can see the mapping table because Ableton made it part of the user interface (it is all those light grey, dark grey and orange squares!), and it is12x12 squares. So it seems likely that this is coded similarly to the PitchScaler MaxForLive example - and the 'Fold' function limits the output to just one octave, which is exactly what happens if the Octave number is not allowed to the output...

Unfortunately, this 'Split' approach is not perfect. As I have mentioned before, the behaviour of this type of scale mapping device breaks down if you want to invert MIDI notes, so that the high notes play low notes, and vice-versa. It is well worth going back and seeing how things can go very weird... But the main problem is those two 'modulo' functions that are cairned out on the MIDI Note numbers. You remember that these are just repeatedly subtracting 12 until they get a remainder of less than 12? Well, this requires a loop that repeatedly subtracts 12, and inside that loop is a check to see if the remainder is less than 12. For a typical MIDI Note number of say 60, then this is going to require quite a lot of operations to be carried out, and it turns out that whilst a '+' operation can be very quick, the 'modulo' function can be a lot slower. If we think what is happening here, then we have two slow operations being carried out on each and every MIDI Note message, and this is going to delay the start of the note being played by the instrument (synth, sampler...) in that channel inside the Live DAW. Unwanted delay is not good.

To remove the delay, then one method is to remove the modulo functions. This can be achieved by using a larger table - and to cover all of the MIDI Note range then we would need a table of 128x128.


Here's a conceptual diagram that shows the 12x12 tables from the Scale device, mosaic'ed together to produce a 128x128 table, so that we can map any incoming MIDI Note number to any outgoing MIDI Note number, and the only operation that is required is to look up the MIDI Note number and see what the output should be - easy to do, and fast!


Actually, most of the time, the inputs and outputs are going to be quite similar, and so if we look at a 'Chromatic' scale, where each input note maps to the same output note, then actually, most of those 'Scale' tables will not have any orange squares in them at all - the only orange squares are gong to be on the lower left to upper right diagonal. So the 'copy and paste'd Scale tables in the diagram are not a fair reflection of reality.


For an 'Inverse and Useful' mapping, then the diagonal just goes the other way. Unlike the 'Scale' device, this mapping works perfectly - it produces low MIDI note outputs for high MIDI input notes, and vice-verse, and with low delay time. In this screenshot the 'Scale' tables are not shown, and you can see that most of the table is empty. In this case, there will be just 128 orange squares along that diagonal: one for each input note (mapping it to the inverted output).

MIDINoteScalery

And that's what is inside my MIDINoteScalery device - a 128x128 table (mostly empty), plus a few utilities and an interesting way of visualising the scale and the way it maps the input notes to the output notes.


The 'zl lookup' object replaces the 'mapping' object in the previous example, and the inversion, transposing and folding are handled slightly differently, but the 128x128 table does all of the scale mapping with a single look-up operation - there are no modulo arithmetic or integer divisions required any longer... Well, as long as you don't use the 'Fold' feature, but I'm working on removing them from that as well - watch for a future release...)


Ableton's Scale device has the incoming MIDI notes going vertically, and the outputs horizontally. This isn't how MaxForLive normally shows keyboards, and so the table needs to be rotated along the diagonal - the input notes now match to the horizontal axis of the table. The orange squares have been replaced with a 'staircase' diagram that makes it easy to see if the interval between output notes is one semitone, two semitones, three, etc. For the 'C Major' scale shown here, the C# isn't present in the output, and so the interval between the C and the D is 2 semitones, so the 'tread' of the staircase is 2 semitones wide. The next interval is from D to E, which is 2 semitones again, and so the tread is 2 semitones wide. The next interval is from the E to the F, which is only 1 semitone, so the tread is only 1 semitone wide, and you can see this in the 'staircase' diagram.

So how do you make a mapping table? In this post I'm going to show you how to create the table, and all of the spreadsheets that I show will be available to download for free, so you can make your own custom tables, and your own scale/mode mapping devices if you want to.

Types of scale


There are lots of scales, and so I chose two sets: scales starting with capital letters are basic scales, whilst scales starting with lower case letters are more unusual. The scales are deliberately organised in this order, with 'invert' as the final scale.


The basic scales (or more correctly, modes) are shown above with a base key (or Tonic) of C. The 'Chromatic' mode is a 1:1 mapping - the output is the same as the input! The Ionian mode shown here only outputs the white notes; C, D, E, F, G, A, and B.


To be able to create the mapping table, then the notes need to be in a form where MaxForLive can work with them.  Here is the same table, converted to numbers instead of note names. When I did the conversion, I didn't subtract 1 from the numbers, and so you need to do this to get them into the form that is used to represent the notes in the octave: so C is 0, C# is 1, D is 2, etc.


In this table, then the numbers from the previous table have been converted again - this time into a form where the output note number is shown, and so there are always 12 outputs for the 12 note inputs in an octave. So, reading across the 'Chromatic' mode, the outputs are '0 1 2 3 4 5 6 7 8 9 10 and 11'. Reading across the 'Ionian (C Major) mode, the outputs are '0 0 2 2 4 5 5 7 7 9 9 and 11' - which means that and C# inputs will only produce a C output (the '0'), D and D# will only produce a D output (the '2'), and so on. Note that some of the modes only have a small number of output notes - the minor 7th has only 0, 3, 7 and 10, for instance.

Now this table is almost useful! If you use the 'Ionian C Major' mode, then the numbers indicate what the output should be for each input. So the numbers are '0 0 2 2 4 5 5 7 7 9 9 and 11', and this means that if the input is a C or C# (note numbers 0 and 1), then the output will be 0 (C). For the next two note inputs, D and D# (2 and 3) then the output is 2 (D), and so on. These numbers are a simple lookup table where you move horizontally for the input note number, and the number in the mapping table is the output note number.


To read this type of table into a MaxForLive 'coll' object, so that the numbers can be fed into a mapping 'zl lookup' object, then additional formatting is required. This is just a case of concatenating columns in the spreadsheet, as shown above.

The tables so far have only shown a single octave. Using a spreadsheet, it is easy to extend the table to higher numbers - all the way to 128 for all of the possible MIDI Note numbers that can be input and output. All you do is add 12 to each of the values in the first octave to get the values for this second octaves, then ad 12 to those for the third octave, and so on. This gives rows with 128 values: one for each MIDI input note number, and each number in the mapping table is the MIDI note number that will be output:


This table has entries from outputs of 0-127 for each of the 128 MIDI Note input numbers. The full table is in the downloadable spreadsheet, and contains complete tables for all of the basic and unusual modes. Note that there isn't any magic or deep maths in the mapping table - it literally is just horizontal rows of numbers that specify what the output number is for a given input number.

Utilities

The default setting for the MIDI NoteScalery device is a straight-forward mapping of input notes to output notes. The output notes are shown as colour (blue or orange - selectable), and when an accidental (black) note is output then that is shown in colour.



The '+' button (blue) allows the output notes to be transposed. If the transposition goes outside of the MIDI note range then the notes will be folded back into range.


The 'Fold' button (orange) allows the output notes to be restricted to a range of 1, 2, 3... octaves, with an offset. So if you want the output notes to be only in the range of 1 octave, then set the range to 1 and the offset to 0. As I mentioned earlier, the 'Fold' function still uses the modulo function internally, but this should be removed in a future version...


The 'Inv' button (yellow) allows the keyboard to be inverted - perfectly. High input MIDI notes will produce low MIDI note outputs, and vice-versa. This can be done for any of the modes, and it is recommended that the 'Chromatic' mode is used initially. inversion can be set to happen around any note - in the examples shown, a C input will be output as an F.


Summary


MIDI NoteScalery is one of a family of utilities intended for exploring scales and modes. All of the devices will be available from MaxForLive.com for free (and in fact, some of them are already available!).


The two devices that are included by Ableton in Live are 'Scale' and 'PitchScaler'.

Getting MIDINoteScalery

You can download MIDNoteScalery for free from MaxForLive.com.

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

     https://synthesizerwriter.blogspot.co.uk/2017/12/where-do-i-put-downloaded-amxd.html

(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...)

Getting the 'Scales and Modes' spreadsheet...

You can download the 'Scales and Modes' spreadsheet from here. It is stored in various formats to try and maximise availability. Whilst it starts out with just music theory turned into notes, the numbers rapidly become somewhat MAX-oriented, so this isn't a general-purpose 'scale development tool', although the mapping should be reasonably easy to apply to other environments. Note that there are three tabs - people often seem to overlook tabs on spreadsheets...

'Basic' - the first tab contains just the basic scales in a 'coll'-friendly format. Just a 'cover'-screen, really.

'One Octave' - the second tab has all of the data for a single octave for the basic and extended/extra scales, and contains just about all of the notes and numbers that should be useful for making your own scales and mapping tables. The data goes quite a long way across the the right... You can use this tab for developing and testing your own scales (and getting used to the 'CONCATENATE' function that is used all over this spreadsheet, and which is indispensable for assembling data into arcane formats...) and reformatting to suit your own development environment.

'Full Range' - the third tab is the 'One Octave' extended to cover all 128 MIDI Notes. This time the spreadsheet goes a very long way over to the right, and it then continues downwards. The final 'big table' actually starts at row 58, so don't miss it. This tab is where you will produce your final 'big table'...

If you are interested in how to use the Excel 'CONCATENATE' function, then you may find this spreadsheet useful - it is used everywhere to assemble numbers into the format that objects like 'coll' expect.

If/when I get around to recoding the 'fold' code so that it doesn't use the modulo function, then the table development spreadsheets will be made available for free as well.

Modular Equivalents

In terms of modular equivalents, then it depends if you count a 'Scale' module as a 'basic' module, and  once again you rapidly get to the point where you want to step outside of the 'basic modules only' rule and go into more specialist modules. I'm going to add a 'Scale' module to the 'basic' set, and so my estimate is that full functionality is going to require a scale module plus some additional CV processing (for invert and fold) and so this gives a grand total of 3 ME.