B2417 Bug report: dropping key strokes

Probably the same issue we used to have with the "0" and being able to get to defaults with the encoders & parameter groups.....now that it is "." I would guess that it is the same. Personally it bothers me a lot less as "." than as "0"....."0" made patching and fixture selection much more burdensome......I LOVE the default shortcut though & use it constantly.

Maybe there could be an option to disable this in user prefs if you use a lot of point cues?

Marty,

This particular issue with the "." key popped up about 9 months ago. It went away in the last V2 build, but has come back in the V3 release.

For me, it doesn't matter what keystroke it's dropping, by the fact that is dropping keys, it slows the process down. And that's no good if you need to change the fade time of a cue in a hurry or goto a cue and realize that it has dropped the decimal.

I have seen this on multiple desks, so I don't believe it's hardware related.

Some technical detail on what's happening:
Most of the keys on the number pad work on key-down events; That means the key is added to the command line when you press the key. But, the keys that can be used as modifiers work on key-up (when you release the key).

In older versions, the decimal point key worked on key down. But when "set defaults was added", it changed to acting on key up.

In most cases, that works fine. But fast typists will have multiple keys down simutaneously. So, if you type 12.3 quickly, the 3 will sometimes be pressed before the "." is released, and you'll end up with 123. on the command line. So, technically keys are not getting dropped; they're ending up in the wrong order (either result is just as frustrating when you're trying to work quickly).

So what's the "right" solution to this? One option is the ability to turn off set defaults (thereby moving "." back to working on key-down), another option is to move set defaults to another key.

Eric,

Thanks for the clarification on this. Either solution you suggested would work. I just hope one is implemented in the near future. This is a pretty big issue for me right now as I feel like I'm having to make my self slow down and be very deliberate when typing as opposed to working at a speed I'm comfortable with.


EDIT
The more I think about it, I would tend to say move it to another key. A key that isn't used as much, or is as critical (in my opinion) as the decimal. Perhaps the "/" key? I know this is completely subjective to the user as what key they feel like would work for them. Maybe the answer would be to let it be user definable between 4 or 5 different keys. So many of the other buttons on the desk are user preference, maybe this is a place where we need another set of options?

Pretty much what I thought it was then.

Personally I like the idea of being able to turn this off in User Prefs, but have it on by default.

The "/" is already used as a shortcut to force a selection to the same median value if they are spread accross a range (I use this one alot too;) ).

I feel your pain about slowing down.....it was the same thing that bugged me when it was assigned to "0".

While we're on this topic what ever happend to the idea of being able to SET an encoder value (#9072)....see this old thread:

forums.highend.com/showthread.php?t=1755

I still think this would make things much faster.