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!

@ArturJD said:

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'm afraid that I can't reproduce the discrepancy (in Linux). I always get "a)" behavior.

UI issues are coupled to the OS and window manager, so especially for UI issues, it's helpful to report your OS.

Based on my test in Linux, I have to assume that a) is the "correct" behavior. Or at least, your patch needs to be prepared for OSes where it is impossible to get your desired behavior.

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

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

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

@ArturJD said:

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.

The problem is that when the left outlet emits a 0, you don't know if it's valid or not until the outlet either does or does not emit a 1.

If you're disturbed by this, I suspect that's because it's a general problem with dataflow environments. It's easy to react to the presence of a message, but here we need to react to the absence of a message (send 0 if there was no 1). As far as I can see, this will always be a little kludgey. (This is not the only time I've had to make something happen when there is no output -- cyclone [zl filter] for instance has the obnoxious behavior of outputting nothing, not even a bang, when its operation results in a zero length list. I figured out a workaround with a three-stage trigger and a spigot -- it's cute! -- but it did highlight for me how awkward it is when the absence of data is a condition that requires action.)

hjh

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

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

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

@ArturJD said:

A parallel to you observation is the fact, that PD has no notion of undefined/None/null. 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).

Sure, e.g. the Pd [list xxx] operators fairly consistently use bang to indicate an empty list (a good convention, I think).

However...

But this doesn't necessarily mean, that we must be left to deal with asynchronous absence of message detection.

In this case, it is asynchronous because the condition that distinguishes valid-0 from invalid-0 is asynchronous. That is, the reason why I used delay is because the distinguishing signal is literally in the future, and you can't know the future at the moment of receiving a 0. If the 1 0 1 0 problem can't be resolved in the backend, then there is no choice but to wait and see if the latest 0 is a real key-up or not.

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

Look at the available information... In the "bad" case, you get alternating 1 and 0; in the good case, you get a stream of repeated 1s. You can't know which you will get in advance, but you can detect the "good" status upon the first repeating keystroke and switch to the streamlined logic at that moment (and keep it that way for the lifetime of the patch).

EDIT:

You might also add logic to detect the bad state and also switch off the right-branch check, though I think the check is not terribly expensive ("premature optimization is the root of evil").

Pd vanilla can do "gate" by [list prepend] --> [list trim] --> [route] but I'm lazy this morning.

hjh