Stream Deck 7.0.3 has just come out. It includes some quality of life improvements, but I think the big change is support for multi-tap (press, double press, or press and hold, for Stream Deck buttons.) This suggests to me that Stream Deck actions (only the ones using the new Key Logic plugin) will now have to trigger upon release of the key, rather than upon pressing it. This means a small amount of latency has been added to all buttons.
Stream Deck for iOS or iPadOS is not expensive (about $2/month, with the first month free) but it is completely free if you use a maximum of 6 buttons. However with multi-tap, you could argue that those 6 buttons have now become 18 buttons.
What you refer to as āpressā is triggered when a key is released, down, up, then the software waits to see if another key is pressed. If not, āpressā is triggered.
This means that a āreleaseā trigger would work as follows: I define the trigger as key up. I press the key, hold it for a minimum amount of time, then release it.
Long press actions would trigger with key down, a key is held for a certain minimum amount of time.
Most reasonable SDK / APIs will send events (key up key down) for every action, and along with the payload some kind of data that indicates if the tap count is a single / double / triple tap etcā¦
If they didnāt do that and their just waiting to trigger events after the double tap āfailsā (which might be something like 350ms after the end of the first key-up) thatās just shitty behavior, and thereās no reason for that.
Unfortunately, I don't understand exactly what that means. But it seems certain to me that no software can recognize a double tap before it has been executed
The issue isnāt whether software ārecognizedā the double tap, itās whether it knows if it should care or not.
What it means is that if itās done correctly then there is no need for a button that just does a single press to wait for a specific amount of time for a second tap. Only if you specifically add an action for a second tap should it wait. If implemented poorly then yes, this will effect all single presses and cause a delay, which would be very bad (imo).
I think @Airy's point is that when a button is set with the new keypress logic, single presses will trigger on release (rather than press), which will introduce slight latency. It's negligible in most instances, but I can imagine situations (gaming etc) where this could be an issue.
How would you design multiple press detection mechanism that doesn't rely on delays to determine whether a single press is all that was input? That's not rhetorical; if you know of a way, I'll implement it into KMDeck.
I want to go on record to thank #Airy for the original post about this Stream Deck update. I dutifully upgraded to the new version, but I didnāt look at the release notes and was completely unaware of this new feature, which I certainly can use. Although #Airyās avatar is āGONE,ā Iām thankful #Airy is right there,
I appreciate the joke there. I originally had a reason for using that avatar, but the reason itself is now "gone." And I kinda like how it stands out now. It's silly, but silliness isn't banned... yet.
Can anyone confirm that on Stream Deck 7, the keys arenāt recognized as trigger for āUSB device keyā anymore?
This definitely used to work. I still have some macros with the registered keys and they still work.
It just doesnāt seem to be possible to assign them anymore?
I have "Stream Deck 7.0.3 (22071)" and it still works. Of course, my case is a bit different from yours because my Stream Deck hardware is probably different from yours, but I don't see that that should make the macOS Stream Deck software fail.
My only theory is that you are trying to use the Hot Key Trigger instead of the USB Device Key trigger. I know you said otherwise, but I have to try to come up with a possible explanation. If you show your macro, we may spot the problem.
