This one's a tad better:

I'm not sure I could duplicate your issue, despite your beautifully put-together patch. I tried a different approach to detecting key presses and releases that seems simpler to my simple brain. I think it works; give it a go and see if it solves your problem.

Thanks Holland! :-) I won't have time to try out your patch till tonight, unfortunately. Will let you know, of course.

OK Holland, I've used a couple of your ideas to re-do my patch. It now works reliably and doesn't annoy me like it used to, so thanks! :-)

I used [zl group 2] and the logic surrounding it, including the idea of having the [delay 300] object in a different place. But I still had to add my [match] objects to figure out what number each 2-integer list (i.e. 2 q-key presses) from [zl group2] represented, and there were problems there that were very similar to my original patch. Still dunno why. It just seemed that clearing all the [match] objects immediately after a match was found didn't work reliably in all cases, even though it should. Using the [delay 300] object in a different way avoided the problem so I'll just leave it.

Cheers, Bill

Hi Bill, Here's another version with the [match] objects included that doesn't appear to require "clear" messages. I separated the single numbers from the lists of 2 numbers, that way [match] doesn't get as confused. If this doesn't work, another approach to consider is sending all the [match] objects some arbitrary placeholder value (i.e. 9999) after each button press is successfully decoded. That would effectively reset the [match] objects.

Thanks mate! I've had a good play with all ideas - yours and mine - and now have a patch that's rock solid reliable. It uses your [zl group 2] object, [delay 300] position and now also uses "2" instead of "clear". So it's been much improved with your help. :-)

There still seems to be something weird about clearing the [match] objects a nanosecond after one of them has found a match, whether with the word "clear" or a placeholder number (which in my experiments was the number from the trigger object immediately after each match object). No matter which way I tried it, just as I started to think "Hey, it works!" I'd find, for example, that a 3 after a 5 would always come out as a 4 and a 3 or something.

So I'm using a "2" after [delay 300] (which, after timing my key presses several times, has become [delay 140] ) to reset them; it's already sitting there doing it's thing a few dozen milliseconds after a 2-press number has been found, so I might as well use it. In my original patch I couldn't, but the way you used [delay 140] means that there is a small gap that enables it to work reliably.

If you're curious here's 3 of them in one. On the left is the final version; the other 2 are fails. Faults can be seen if you, for example, *quickly* select 4 (long short) repeatedly, or 5 (long long) followed by 2 (short short) or 3 (short long), etc.