@flextUser after is probably accurate enough for most uses of these sorts of control curves. If you made this into a gui plugin you could use plugin-dispatch to communicate between the plugin and patch to cut out the UDP and if you wanted you could also clock it from pd as well then and have local patch saving. There is a plugin on the iem git (probably in deken as well) called plugin-dispatch-receiver if memory serves which shows how to use this barely documented/known feature if you need it. While it seems a little round about for something you can do with arrays or data structures this way it has some advantages which would be a fair amount of work with those methods, like easy window resizing which resizes the curves to suit. Luapd is also an option, but is slower than pd abstractions or Tcl/Tk in my experience, shouldn't be a problem with the limited amount of redrawing which this would require, perhaps a brief lag on loading curves if you have a lot of tracks/points visible.

@flextUser Changing your mind about avoiding Tcl? It and Tk are pretty great for these quick little apps.

In pd we have arrays and data structures for doing this natively. Data structures where pretty much designed for doing just this sort of thing and more, the manual has a section on it. But I do see some worth in a standalone application which does just control curves and nothing else. What does it use for a clock?

@cfry [expr $f1*180/3.14159265359]?

@KMETE Assuming you mean [cyclone/scope~] just right click on it and open the properties, set the trigger mode to either up or down and you can also set the trigger level if needed. Should be able to figure out how they work with a few minutes of playing around.

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.

@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.

@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 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.

@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.

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,