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.
Posts
No comments:
Post a Comment