key event?

gtoledo3's picture

I was just writing a Processing routine, and it made me wonder about something in QC...

Is there a way in QC to generalize if a key event happens, and by that, I mean "any" key event? Given the way the keyboard patch works, I guess one would theoretically have to map out every possible key.

It looks like the Freeboard patch could handle this a little bit easier, but it still looks clunky.

I tried just adding a new port in the keyboard patch and not assigning it a key, hoping that by some miracle, that it would default to generalizing to every key, but instead it just doesn't do anything.

I'm thinking the answer is "no", but I figure I'll float it out there in case there's some non-obvious workaround I don't know about.

cwright's picture
Re: key event?

key events are a bit complex:

There's a keydown, possible repeats, and a keyup. whatever generalized them would need to expose all 3 (or at least up and down explicitly, instead of just toggling state).

This also gets tricky when dealing with modifier keys -- they're reported in a less expressive way (flagsChanged:) where you need to do the state bookkeeping yourself to know what actually changed.

There's probably some low-level keyboard IO path that makes this easier than dealing with stuff as Cocoa events (HID perhaps?), but then it stops working well with QC (which only deals with Cocoa Events).

gtoledo3's picture
Re: key event?

In processing, if I want to have a routine trigger when someone presses the keyboard, all I have to do is:

void keyPressed() { setup();

Repeats? So there is actually "double click" for keys? Is there any historical triple click code lingering around (I would highly doubt it.) I agree that up and down would be necessary, as you state.

Maybe the processing library is just taking care of the abstraction of it though.

cwright's picture
Re: key event?

gtoledo3 wrote:
Repeats? So there is actually "double click" for keys? Is there any historical triple click code lingering around (I would highly doubt it.) I agree that up and down would be necessary, as you state.

not so much double click - the key pressed event has a "isRepeat" flag or something like that (no count though, iirc) -- I'm a bit rusty on event handling, but I think it's something like that.

Now, when it comes to mouse events, each mouseDown: does have a click count property (I have seen that recently, and know it exists). so triple, quadruple, dodecahedral click, all possible by seeing if the clickcount is 3, 4, or 12 respectively.

gtoledo3 wrote:
Maybe the processing library is just taking care of the abstraction of it though.

Or not giving you the full story? ;) Simplifying makes things easy, but it also strips away possibilities. For instance, what if you wanted something to happen for each repeat key press (like inserting an extra letter when you held down ggggggggggggggggggggggggggggggggggg), or if you wanted something to happen when you released a key? Mouse events have a similar life cycle, and I think iOS touch events do too? (I think they follow the multitouch event life cycle, iirc). Buttons don't do anything until you've clicked down, and then released while still over them -- buttons that act immediately on click are weird and unnatural because of that. Text areas are the opposite -- they get focused on mouse down, not mouse up. There are a bunch of subtle things like that.

gtoledo3's picture
Re: key event?

Hmm, I know I can specify any given key, but I'm not sure about repeat key or release key.

I want to take a moment to point out that a button in OS X needs to perform exactly like you state, but if you put that kind of "button" on a many physical devices is on when you press, and off until you release (like A/B buttons on a NES, my remote control). So, all three behaviors are needed, imo (button doing something when you click up, button doing something when you click down, and the unmentioned but necessary "button does something when you press it, keeps doing it until the the next time". A toggle.

I guess semantically, one could describe this is three different functions, where maybe only one is "button"?

cybero's picture
Re: key event?

Can we not build a little Cocoa based keyboard event library, which would act much like the Keyboard event libraries in Flash, albeit not DOM referenced as per Flash?

usefuldesign.au's picture
Re: key event?

I posted a comp to do mimick key on/off/repeat with additional shift and option modifiers for x10 and x.1 factoring. Only for arrow keys from memory.

http://kineme.net/files/Forum/2010/06/Counter_from_Keyboard_Patches.zip

Also I just made this one to detect 'any' keystroke. But it's still not exactly the full any key is down thing your after, just detects the down event. Fully itemised Keyboard patch into a MathExp patch is best I can think off.

I agree Keyboard Patch in QC should be more powerful.

I don't want to threadjack but I had to resort to exporting a variable in JS patch and bring it back in via a splitter to get the Capslock Detector JS patch to function. I then got the 'remember' variable holding onto the value to next cycle but when I remove the redundant code it stops the patch from functioning as it should. Any pointers there — I'd appreciate them.

/*
Why can't I remove the rendundant code at the end of this script
*/
var remember = new Boolean();
function (__boolean Flag, __boolean REM) 
   main (__boolean CapsLock, __boolean REMEM)
{
   var result = new Object();
//   Detect change in state from last execution
   if (CapsLock ==  remember) {
//   if (CapsLock ==  REMEM) {
         result.Flag = false }
      else  {
         result.Flag = true }
 
//    Store the CapsLock state for the next cycle
      if ( CapsLock ) {
         remember = true }
      else {
         remember = false };
 
// OUTPUT remember state 
// As soon as I comment out the Following redundant code the patch stops functioning correctly
   if ( CapsLock ) {
         result.REM = true }
      else {
         result.REM = false }
 
   return result
}
PreviewAttachmentSize
Freeboard demo comp_alt.qtz19.39 KB

gtoledo3's picture
Re: key event?

Oh that's cool! It's interesting to see the key event handled in javascript.

I don't know if this is really the biggest issue in the world, but it strikes me as sort of cool in Processing that you can just set any key on the keyboard to reset a composition (or set it up, as the case may be). It's funny because the running paradigm has always been "expose more" as far as fine control goes, but I guess this shows that being able to "abstract more" is sometimes handy as well.

usefuldesign.au's picture
Re: key event?

Yes we can!*

* "Yes we can!" is a slogan and in no way commits me to any progress in this area. Nor does it imply I have the power, ability or knowledge to do anything whatsoever in this important policy area. You can live in hope though, for then you are blessed.

usefuldesign.au's picture
Re: key event?

I should bite the bullet and take a look at processing, it sounds cool.