@whale-av said:

@ArturJD You might find this useful...... key-debounce.zip

Thank you! Unfortunately, for me it doesn't work unless I edit the patcher and create a new object due to the same issue — the keyup fires constantly. However, this might introduce more insight to the problem.

@ddw_music said:

it's a general problem with dataflow environments....

I had once exactly the same struggle with [zl filter] (but in M*x though)! A parallel to you observation is the fact, that PD has no notion of undefined/None/null. But this doesn't necessarily mean, that we must be left to deal with asynchronous absence of message detection. Many objects already have the "carry bang" or "bang when done" feature which avoid the whole trouble altogether – and bang is often the thing that works as "null" ([route] object is a good example).

But using [delay] is better than nothing of course I would rather prefer to have a method, which flags out the patcher state causing this discrepant behaviour and routes [keyname] output to a sub patcher with a proper message handling – but this hidden mysterious parastate needs to be known in advance somehow.

Thank you for your answers!

@ddw_music said:

it's helpful to report your OS.

I am using macOS Big Sur 11.6.6. My MacBook is from 2013 so Apple doesn't let me update any more!

@ddw_music said:

So then the problem becomes one of filtering out the zeros. To do that, you need to be able to distinguish "0 = key was released" and "0 = key is being reset for repeat." AFAICS the second of these (the one that you don't want) is very brief, like < 3 ms until the next keystate = 1. [delay] could help, then. However I found experimentally that it wasn't reliable with less than 60 ms delay on the key-up. This won't be noticeable in practice.

hjh

Thank you, this is a very elegant implementation. However I am disturbed by an idea, that distinguishing key repetitions from its release asks for asynchronic solution (using delay with an arbitrary number of seconds). I know its more practical, it is just my preference.

If this is the only solution to the problem of "a )" situation, I would like to "route it away" when "b )" happens: thus, a method of checking the patcher state (which cause behaviour change) would be useful.

@seb-harmonik.ar said:

actually iirc the version without 0s has been the normal behavior on MacOs (from the bug report)

I hope so, that would be more useful. I am going to check my version of tcl/tk (later today, now I am AFK).

Hello! It's my first post here and a beginning of my adventure with PD

I am writing an external using [keyname]. I understand that when a key is pressed, this object (and [key] as well) interprets that the key press is being repeated.

BUT

When holding a keyboard key and printing its left output, it turns out that the same object behaves differently when:
a ) the patcher has been just opened: prints 1 0 1 0 1 0 1 0 1 0 1 0 ....
b ) user manually created an object: prints 1 1 1 1 1 1 1 1 1 1 (0 when depressed)
I reported it here: https://github.com/pure-data/pure-data/issues/1845

Solving this issue is beyond of the scope of my question. I'm asking: how can I simulate the situation "b )", when patcher is initialised/opened? What kind of "flag" does [keyname] waits for to be initialised correctly?

Sad enough, I cannot just dynamically create a "dummy" object – it must be created manually. Also deleting object manually doesn't work. Only manual creation.

Also, the [keyup] object has the same flaw – its output repetition when "a )" and filters them out when "b )".

Thank you for your input/insight/sights!