[key] code have changed with 5.0.8 ?

Sep 19, 2009 at 4:00pm

[key] code have changed with 5.0.8 ?

hello maxers,

so, with max 5.0.8, key code numbers of my macbook are not the same ; not a big problem but : is anybody can explain me what means platform specific/independent key code number ?

thanks.

#45519
Sep 23, 2009 at 7:18am

Hello maxers,

RTFM ? Smile

i done it and so platform-independant key code supposed to be :

delete 127 : i have -7,
return 13 : -4,
esc 27 : -3, etc …

Is the manual have to be update, or is it a bug ?
( white macbook, os 10.4.11 and it’s happened since 5.0.8 )

Purpose is to share, i would be sure everybody got same key code.

thanks.

#164132
Sep 23, 2009 at 7:26am

Have reported this too. Before starting to repair broken functionality in older patches, it would indeed be good to know if this is a switch or a glitch.

#164133
Sep 23, 2009 at 10:21am
vanille béchamel wrote on Wed, 23 September 2009 09:18
delete 127 : i have -7,
return 13 : -4,
esc 27 : -3, etc …

127 is the ASCII code for delete, 13 is ASCII for CR, etc. The “hardware” code was never supposed to be the same as the ASCII code. Jamais.

The hardware keycode is the code of the position of the key, independent of what keyboard layout you are using. As you are surely aware, the French keyboard layout is different from the US (and from Dutch, Russian, Greek, etc. etc. etc.)

The ASCII code is used to tell application software that, for instance, “the user pressed the letter ‘a’”, regardless of the position of the key on the keyboard.

The hardware code is used to tell application software that, for instance, “the user pressed the first key at the left of the second rank” regardless of what letter is printed on the keycap.

The hardware codes were well-documented in the past for both Mac and Windows (see, for instance, Inside Macintosh and zillions of web sites). However, when Mac OS X came around Apple/NeXT for some reason added an additional low-level abstraction that maps the real hardware keycodes that different keyboards might produce to a single set of “virtual” hardware keycodes. That is the distinction between “Platform Specific” and “Platform Independent” key codes (as I understand from various communications from DDZ & Co.) To be honest, I’ve not seen documentation of these two sets of codes, I just know that there have been issues with these codes since the very beginning of Max 5.

In general you want to stick with the ASCII codes (left outlet), unless you’re trying to build something like an ersatz piano keyboard using the typewriter keyboard. In the latter case you want the key positions, otherwise middle C may suddenly move because someone’s using a German keyboard layout instead of US.

#164134
Sep 23, 2009 at 12:19pm
Quote:
127 is the ASCII code for delete, 13 is ASCII for CR, etc. The “hardware” code was never supposed to be the same as the ASCII code. Jamais.

You say that before the right outlet reported wrong figures, and with the recent update that has been fixed. Could be. The latest support information doesn’t mention it, so this supposed fix came as a, well, surprise. Thanks for the additional info.

#164135
Sep 23, 2009 at 2:27pm

Hello maxers,

thanks Peter and sorry jvkr to dub your post.

Ok, so if i understand : platform_specific is hardware code and platform_independant is a kind of magic mix between ascii and hardware…

Sadly i can’t use just leftmost outlet (ASCII) because it does not send return key code (13) while i am pressing cmd key too (256) ; that i need.

So what i would like to know :
- is rightmost codes will change again (as jvkr asked) ?
- is rightmost key codes are the same for everybody (no matter of system, hardware, keyboard etc…) ?

thanks a lot.

#164136
Sep 23, 2009 at 5:33pm

Given that the rightmost (fourth) outlet from [key] isn’t documented in the Reference Manual, I’m not entirely sure what it’s supposed to do (let alone what it actually does do).

I would use it with utmost caution and not rely on any particular behavior until such time as the behavior is documented.

The key object was also never very reliable about Command-Key keystrokes. You’ll see the documentation still claims that command keystrokes are “never reported,” although with the current version of Max they are indeed reported in everything except the leftmost outlet. Probably the cleanest way to deal with command keystrokes–also from a Human Interface perspective–is to define a custom Menu Bar with the [menubar] object, although that’s not going to help with Cmd-Return.

If you really want Cmd-Return, you could test against (2nd outlet == 36) && (3rd outlet == 256). I If you want the keystroke to ignore the state of other modifier keys, you can modify the second condition to (3rd outlet & 256).

Since you’re using the Cmd-Key, Windows-compatibility is pretty much a moot question. However, the hardware keycodes for the Return key (and pretty much everything else) are generally identical between Mac OS and Windows anyway. I suppose there may be some wacko keyboard with a non-standard driver for Windows that could give you different hardware codes, though.

To be honest, I’ve ignored [key] since I wrote a replacement object. Thanks for making me look at it again.

#164137
Sep 24, 2009 at 6:05am

Hello Peter,

info about rightmost outlet is not so easy to find in the manual ; just a link at the end of the text :

http://www.cycling74.com/docs/max5/vignettes/core/keyboardcodes.html

Thanks, salutations.

#164138
Sep 24, 2009 at 3:44pm

Thanks for the pointer to the documentation.

Too bad the documentation doesn’t match the behavior in 5.0.8-(

Ironically, the “Platform-Sepcific” 2nd outlet seems to produce identical output on Mac OS and Windows (however only cursory testing, using the identical keyboard and Parallels). Since the location of the Return key doesn’t change for different keyboard layouts (I’m pretty sure it’s even the same for Kanji, etc.) you may find this the most workable solution for your task.

Good luck. We’re going to have to wait for a whole new release to see a change to the key object (if a change comes), since it’s an internal and not an external object where you could simply swap out a .mxo.

#164139
Sep 24, 2009 at 4:01pm

Hello,

so as usual, best is wait and see…

#164140
Sep 24, 2009 at 9:18pm

Here’s a quick summary:

Left outlet: Provides the ascii value of the pressed key. It tells you the text character as opposed to the key that was pressed.

Second outlet: The value reported is the same on Mac and on Windows, but it’s platform-specific in the sense that the values are derived from Apple’s key-code definitions (a=0, s=1, d=2, f=3).

You’d use it when you want to implement a patch where you don’t care about what key was pressed, but the *position* of the key (say, doing something like a musical keyboard using the a/w/s/e/d/f/t/g/y/h/u/j/k keys….). Regardless of the language chosen, and regardless of the modifiers pressed, the values reported for a given key position will be fixed. For example, the value reported when the key to the right of the left shift key is pressed will be 6 whether an English or a German keyboard layout is chosen.

Third outlet: No change from the current docs.

Fourth outlet: For alphanumeric keys, the values reported from this outlet correspond to the unshifted version of the pressed key. The other keys have now been assigned negative codes that are consistent across platforms. They’ll be in the next doc update.

#164141
Sep 30, 2009 at 10:11am

Thanks for this, Gregory.

It’s pretty much what I’d guessed, but even my guesses aren’t always right.-!

Look forward to the updated dox.

#164142
Sep 30, 2009 at 12:18pm
Peter Castine wrote on Wed, 23 September 2009 19:33
Given that the rightmost (fourth) outlet from [key] isn’t documented in the Reference Manual, I’m not entirely sure what it’s supposed to do (let alone what it actually does do).

rtfm?! Razz Razz

actually it is a good idea not to use “built-in” key triggers
when you want to share something, or at least use ASCII and
really only use standard keys like 0-9 and a-z. (err. a-y…)

when you want to make an application for others to use it could
be uebercool to have keyboard preferences which let the user
override the defaults – just in case they have a weird keyboard
or a weird keyboard layout like eastern gibberish they can at
least make it work again by themselves.

if you add something like [receive thisappskeys-04] to your
[key #1] abstraction you´ve already solved the puzzle.

edit:
oh no wait, [key] does not even have inlets, jesus,
maybe thats why people to use something else.

-110

#164143
Oct 1, 2009 at 12:41pm
Roman Thilenius wrote on Wed, 30 September 2009 14:18
rtfm?!

As pointed out earlier, the friendly manual has been read, to no avail in this instance. Gregory’s response (later in the thread) is the first ‘official’ documentation we’ve had so far.

Quote:
when you want to make an application for others to use it could be uebercool to have keyboard preferences which let the user override the defaults

This is, indeed, a good idea. The technique is not to try to send messages into key; the technique is rather to have an object (or abstraction) that maps key’s output to a vocabulary of messages, and this “mapper” object can be made user-configurable.

I’ve coded an object that does exactly this, although you could conceivably cobble together something constructed around coll.

#164144
Oct 1, 2009 at 4:01pm

Hello,

yes, it’s a good idea with [key] ;
but you can’t do this kind of mapping in “jit.window listener” ; there’s just three or four keys reported, and sadly one of them, cmd, is a nightmare for platform compatibility…

#164145

You must be logged in to reply to this topic.