For the sake of having something in this thread, here is mine.

keyhold.pd
keyhold-help.pd
Edit: punctuation marks and numbers can cause it to hiccup, seems to be a bug in [keyname] and it does not give the same symbols for keyup and keydown on those. And the odd stuck key is now fixed,

@oid Another.... does not use [keyname] so it only returns the key numbers, which can be different on different keyboards....... key-debounce.zip
Created a while ago, because when holding a key down in windows a sequence such as 33, 34,33,34,33 is sent.
Probably @oid was solving the same, or a very similar problem, but [key-debounce] does not depend on an arbitrary timer and the value is returned as soon as the key is released.

Add a [sel 0] if modifier keys are being used (unlikely)....
David.

@whale-av said:

Probably @oid was solving the same, or a very similar problem

I was solving the issue that all the externals and abstractions I tried for using a computer keyboard as a polyphonic music sort of keyboard had issues will dropped and or stuck notes. My solution does still have the occasional stuck note which I have never been able to sort out. So a bit different with a difference in output from yours.

Edit: and I sorted it out, realized what the issue was with the stuck notes as soon as I posted.

weird I deleted this thread and youve kept my thing at the top??? do you know why my patch is having errors?

@willblackhurst anyway I dont see why yours would work. because the thing doesnt allow the two inlets for the key objects into a subpatch without an error

@willblackhurst You would have to reupload your patch if you want to know why it failed. I glanced at it but it was difficult to parse due to the lack of triggers and I could not quite figure out the logic based off your picture, you deleted it before I downloaded it.

here is an explaination of the actual problem - I would bet your patch doesnt work either. because it uses a subpatch.key_subpatch_test1.pd

@willblackhurst I am not sure why yours occasionally errors when in an abstraction/subpatch, the logic of it is a little convoluted and has a fair amount of redundant code, here it is simplified:

I can not get this simplified version to error. Mine has worked for years without issue other than the odd stuck note that I solved last night.

Edit; Actually my simplified version does error at times but less often, I think it is just that the timings line up occasionally, being in a subpatch/abstraction must add some overhead or something which causes issues. Either way increasing the delay time seems to solve it, I get reliable operation from your patch and my simplified version as long as the [del] is greater than my key repeat rate so each key repeat resets the delay.

And here is your patch with triggers added in, makes it easier to see the redundant paths and why it can be simplified down to just a few objects. Always use trigger unless you have a good reason not too.

@willblackhurst A sub-patch is simply part of the main patch that has been hidden.
You will have had to create inlets and the outlet when you copied the logic part to the sub-patch but as [keyname] is determining the order of operations it should behave in an identical manner.
So the difference is an enigma.

@oid is right about triggers.
The major reason for always including them is that when you come back to the patch much later on you will not remember the order of operations that you determined at the time... and cannot see it on the patch window.
The minor reason is that the patch cannot be read by others trying to help on the forum unless they read it as a text file.... which is seriously brain damaging.... and just means that you will get less help.
David.

I changed it to the tbf version and now the error has dissapeared from my own version! and the delay time is now donwn magically to 5 ms from 25 !! which I thought is impossible!
Thanks!
Willsuperfast1.pd

@willblackhurst This method is very susceptible to cpu load for me and starts to fail as load goes up, I only get reliable output when [del] is greater than key repeat rate or load is low and I suspect it would error even more frequently with dsp on but have not tried it. Probably why it just started working for you, your load is less than it was when you were testing before. But, we can combine this with my method so it will respond to more than one key at a time which will make it more efficient, mean keydowns have zero delay and keyups will only have delay when needed. I have the [del] set to 50 here but it worked as reliably as the simple single key (fails as load increases) version at lower settings.
keyhold2.pd

Edit: as a sidenote, a delay of 50ms on keyup doesn't really matter much.

I did a good number of keypresses and the bulk ended up around 90ms, I got one at 52 and that was the only one below 60ms, went as high as 220ms.

This one works reliably for me to 2ms for single keys, might be more portable than the [t b f] version which is quite unreliable for me. This one is very picky regarding the patching to make it work with my keyhold setup, maybe later I will sort that out.