Help needed with [match] object or something
G'day all,
I've made a patcher that gives me a number from 0 to 5 with 1 or 2 short or long presses of a key. It's for use with a little game controller. Because there are only 8 ASCII characters I can send with it this patcher will enable me to do more with each of those 8 keys.
Help isn't exactly "needed" - "desired" is more accurate. It works as is but I don't know why or whether there's a better way to do it. I'd like to do it without resorting to a [delay 1] object that seems to inelegantly force things to happen in the correct order, "things" in this case probably (but not definitely) meaning "clearing [match] objects".
Here it is for anyone who'd like to have a look, rearranged and with a stack of comments to make it as clear as possible:
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.