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.