When I added four extra levels to MIDI ccQuant so that it had 7 levels instead of 3, I already knew that the user interface was going to be a challenge. The original design for MIDIccQuant had three levels because the available vertical space in a MaxForLive device is fixed: there are 170 pixels to play with... For live.dial this means you can have 4, 3 or 2 stacked vertically...
Now I'm not the greatest fan of the 'tiny' live.dial rotary controls (or the rather sparse live.slider when used at this size), and the 'panel' dials are often mistaken for the Macro Controls, which leaves the three standard 'vertical' sized live.dial rotary controls. Which means that most of Max For Live devices have at most three horizontal rows of controls - and those that have 4 (the <x>_Freez series, for example) don't use live.dial rotary controls.
MIDIccQuant used the standard 'vertical' live.dial rotary control, which meant that choosing the number of levels of quantisation was easy: 3. That way I could have three dials for setting the main parameters for the quantisation. Unfortunately, this also meant that there would be four output settings, and so I compromised to the live.dial mode that I really, really don't like: the 'bare' view:
In the 'bare' view, you turn off all of the labels and numbers (you can have labels or numbers at the top or bottom, but it looks weird) and you put the number next to the dial, as you can see above (and below). It is possible to have 5 dials squashed into the vertical space, but it isn't pretty, and it can get worse...
For the 8 output levels that I needed in MIDIccQuant8, I rejected the use of eight 'tiny' dials without labels and numbers, and instead I went for live.sliders, which normally I avoid because they are very plain and don't have the characteristic 'Ableton' look that the live.dial has. I also oriented the sliders so that they match the two parameters: horizontal for the levels, and vertically for the outputs. Finally, I colour-coded the sliders so that they matched the lines in the display:
Hopefully it should now be more obvious that you move the orange sliders from side to side to influence the horizontal spacing of the orange lines, but you move the light purple sliders up and down to move the purple line segments vertically. It worked for me, and I did consider going back and reworking MIDIccQuant so that it had the same metaphor.
Whilst I was doing all of this user interface consideration, a crazy though did pop into my mind, and I wondered about taking the quantisation to the limit, with 127 levels and 128 outputs - which stops being quantisation and becomes a transfer function, or a mapping. So watch MaxForLive.com for another device...
"It worked absolutely fine...right up until I tested this..."
I have heard those words so many times, but it was quite a surprise when it was me doing the talking. Somehow, in the development of MIDIccQuant, and it's bigger sibling, MIDIccQuant8, an avoidable problem found its way into the quantiser, and a user found it a few days ago. In response, my testing and debugging was just a little intense - and eventually I found the problem.
I had broken one of my own rules, and now it was biting me. Badly.
What was happening was that both quantisers would occasionally output a MIDI Controller message with zero as the value, even though that wasn't what was supposed to happen, and especially because a quantiser shouldn't be able to output anything other than the allowed values. But the zeroes were there when you looked for them. Time for a diagram:
So what did I do wrong?
It's simple really, in the quantiser itself (yep, the core of the devices!) I had two things happening simultaneously, and as a result, in certain circumstances, the quantiser stopped being a quantiser. Rather than bore you with Max code, I'm going to use an analogy to give you an impression of what was happening, an suffice to say, the replacement code (a more or less complete re-write of the quantiser) doesn't have the problem any longer.
So, here's a scenario for you to think about. Imagine if inside the quantiser there were two switches and an output. Switch 1 connects to the value 80, whilst Switch 2 connects to the value 10. Both switches meet and produce the output at point A.
Obviously, if Switch 1 is closed and Switch 2 is open, then output A has the value 80. Similarly, if Switch2 is closed and Switch 1 is open, then output A has the value 10. Traditionally, logic designers would summarise this behaviour in a 'truth table':
However, this isn't the full story. There are two switches, and so there should be four different ways of setting them, so let's extend the table:
Aha! There are now two interesting additional settings of the switches, and they don't give useful results. When both switches are closed, then both 80 and 10 are connected to point A, which might produce an output of 90... When both switches are open, then nothing is connected to point A, and so it is difficult to know what the output value might be... Zero, perhaps?
In my original quantiser design, each of the levels had its own detection 'circuit', and so when the input crossed from one level to another, two separate 'circuits' did two things to change the output from one level to another. If those two weren't exactly in sync, then you got an output (zero, in the case in question), and actually, keeping two things exactly in sync is pretty difficult.
In the revised design, there is only one switch changing at any time, and only one value available at any time. The switch is either open or closed, and so you get either the value, or you don't get anything. If you want a different value, then another switch gives you that, and only one switch can be active at any time. In the quantiser, this means that now you only get the quantised output values that you are expecting, and getting anything else is kind of 'designed out'. And yes, this is how I should have designed it in the first place, but in my defence, there was quite a lot going on, and it was very difficult to spot what I had done wrong.
Just in case you think this is an isolated example, and that 'real world' examples of 'two things not needing to happen at the same time' are difficult to find, think about the 'shift' key on a computer keyboard. What happens when you press down on the 'shift' key? Does anything happen when you press the shift key? Or does something only happen when you keep holding the shift key down and press another key, and then release that other key and then finally release the 'shift' key. The shift key gets pressed before the other key, and only gets released after the other key has already been released. There are lots of other things where what at first sight appears to be two things happening at the same time is actually one event happening and a second event happening inside that first event. And don't try releasing the shift key whilst you are holding another key!
Whilst I was rewriting the quantiser code, I also had another look at the user interface, and so the 'fixed' versions (0.03) now have more colour coding for controls, so the 'levels' are now in orange, and the quantised outputs are in light purple. After a lot of devices that only use various shades of light purple, this is a big change! Here's the revised look in one of my deliberately eye-catching ads:
As usual, you can get all of my Max For Live devices from maxforlive.com.
Forums and Groups are interesting places to lurk. If you ignore the incessantly repeated questions and the obvious trolling, then you occasionally get a query from someone who wants to do something unusual and interesting, and can't see how to achieve it. Recently, just such an enquiry turned up on on one of the popular synthesizer forums, and here, belatedly, is a response.
The enquirer asked about how to make a movement-sensing MIDI controller more predictable or repeatable. If you have ever tried to use any location-dependent controller that relies on where you hold your hands in the open air, then you may already be resonating with the difficulty. If you have ever played a Theremin, then you probably already know one of the challenges: making rapid, precise and repeatable movements of your hand between a small number of locations in 3D space is difficult. There's also the 'two different actions at once' problem: making the 'pitch-controlling' movements as rapid as possible (but don't forget precise and repeatable!) with one hand, to reduce the portamento between notes (and making the pitching as accurate as possible), whilst at the same time, making slow back and forth 'volume-controlling' expression movements with the other hand. It's tricky to master, and one of the ways that the 'not in tune' pitch variability can be mitigated is to apply 'quantisation': constraining continuous values to a small set of fixed values. For note length then DAWs have quantisation as a standard function. For MIDI controller messages then I assumed that there would be lots of utilities readily available...
MIDIccQuant
MIDIccQuant_mr is a utility device for Ableton Live, produced using MaxForLive, which quantises MIDI controller messages. Version 0v01 is the first release, and quantises to 4 levels, mainly because the UI for more than this starts to get awkward - but feedback should tell me if this is not enough levels.
Here's the overall flow diagram for what is happening, with the relevant bits of the UI above or below:
MIDIccQuant can process any one of 15 inputs, and the choices are the basic low-end simple controllers: Modulation, Breath Controllers, Foot Controller, Data Entry, Expression, and the general purpose controllers. These are the sort of controller numbers that a lot of MIDI Controller devices will be mapped to. I have always disliked the way that many utilities expect you to know what the controller numbers are, and so MIDIccQuant shows a number in the lower left hand corner that indicates what controller number incoming messages are from. Assuming that you don't have more than one controller active at once, then all you do is wiggle the MIDI Controller (or move your hand if it is a movement/position sensor) and look at the number that is displayed. To make it even easier, then clicking on the 'Copy' button will set the 15-button pad to that controller. If you prefer, and you already know the controller number, then you can just select the appropriate number on the pad!
The big 'CC' button controls the output of the processed controller value. When it is bright, then the controller value is quantised and sent out as a controller message. When it is dim, then the controller value is not quantised, and passes through the device unchanged. There's a big vertical indicator that shows the controller value.
There are seven rotary controls for the quantiser: three that set the levels at which the quantisation happens, and four that set what value is output for each of the four output states. This is slightly different to the way that note length quantisation does, because for that there is an assumption that you want to quantise a note to either slightly shorter or slightly longer, and so if you have an input that is just slightly longer than an 8th note, then you would expect it to be quantised to an 8th note, or a dotted 8th note, or maybe even a quarter note, depending on the quantiser settings. But MIDIccQuant allows the result of the quantisation to be any of the 128 MIDI controller values, and so if you set the lowest level to 15, then that output will be active for any incoming controller values between 0 and 15, and this could be set to output anything from 0-128. Rather like the Theremin, this might require some getting used to, and so the recommendation is that you set the outputs to get higher as you move up in the device UI.
Let's look at levels and outputs in more detail. The three 'Limit' rotary controls divide the 0-127 MIDI Controller values into 4 Levels:
So the lowest level (Level 1) is from 0 to Limit1 (0-18 in this example). The next level is Level 2, from Limit1 to Limit2 (19-65). Level 3 is from Limit2 to Limit3 (66-103) and finally, Level 4 is from Limit3 to 127 (104-127). Note that although the Levels are always arranged from 1 to 4, where Level 1 always starts at 0 and Level 4 always ends with 127, the same is not true for the Outputs - you can put any value you like (0-127!) for any level. If an output always has steps that increase as the input increases, then it is called 'Monotonic', and so this quantiser is non-monotonic. So if you want Level 1 to output 127, and Level 4 to output 0, then MIDIccQuant will do this.
In the above example, on the left hand side, as the input controller values increases, the output jumps UP from 30 to 48, then jumps UP to 82, then jumps UP to 101. So it always goes up as the input goes up - this is monotonic behaviour.
The right hand side has swapped the outputs for Levels 2 and 3, so Level 2 is 82, whilst Level 3 is 48. So as the incoming controller value increases, it starts out outputting 30, then when the input reaches 18, the output jumps UP to 82. As the incoming controller continues to increase, the output stays at 82 until the input is 65, at which point the output jumps DOWN to 48. When the input reaches 103, then the output jumps UP to 101. This is non-monotonic behaviour.
All you then need to do is make sure the whatever device you are controlling is getting the quantised controller value. Remember that if the 'CC' button is bright, then it will be receiving quantised controller values, and so the usual 'just testing' technique of waggling the mod wheel (et.) may not work if your quantisation is set with extreme values. So, slightly counterintuitively, you need to click the 'CC' button so that it goes dark, which bypasses the quantisation, and then do the testing. When the target device is confirmed to be receiving the controller values, then just click again on the 'CC' button to restore the quantisation.
To make the utility more useful, then there is a second output. The right hand side is my standard controller mapper, which lets you optionally invert the controller value, add an offset, scale it with the 'Depth' control, and map this to any controllable parameter in Ableton Live (and unmap it, of course). The 'Quant' button controls if the output from the parameter mapping is quantised or not, which can be useful if you want to have different consequences from the controller in two different places. The big 'Param' button disables the parameter output when dim, and enables the output when bright.
To visualise the quantisation levels, there's a display that shows the four levels - it builds up as you input values, so if you change the levels, then you can click on the 'Clear' button to clear the display. This can also be used as a simple MIDI controller debug facility.
More than just MIDI Controllers...
Version 0.02 adds a small input number at the top of the input bar indicator. This allows you to map any controller so that it can be processed by MIDIccQuant. So you can now take an LFO (or any other MaxForLive device that has a 'Map' button) and quantise its output! I'm expecting some interesting applications of this from my users...
(In Live 10, you can also just double-click on the .amxd file, but this puts the device in the same folder as the factory devices...)
Modular Equivalents
In terms of modular equivalents, then reproducing this functionality in my modulars was quite a challenge to achieve using standard 'basic' modules. My best simplistic solution required 4 separate 'brute force' quantisers plus several utility voltage processors, so I would rate this version as being about 9 ME. I'm intrigued that many modular quantisers assume that you want to quantise to fixed identical steps and monotonic levels, but I'm sure that there are loads of exception devices out there... Buy me a coffee
Posts
