I am a Mac-ANSI-American.
I am now faced with the need to optimize (i.e., rewrite) some of my ChucK programs so that the user interfaces will work in other platforms (e.g., PC-ISO-Norwegian). Obviously, the ideal is to have a single version that will behave the same in any platform. Below are some of the things I have discovered in confronting OSX vs. Windows, ANSI vs. ISO, and USA keyboard layout vs. other languages.
Please: a) correct me if there is something which I got wrong or misunderstood
b) share with me any additional tips or advice for things I have overlooked
KEYBOARD:
Here is what I understand about HidMsg for keyboard devices.
msg.which produces the machine key code (in decimal); msg.key produces the USB scan code, msg.ascii produces an ascii value (sort of)
On Macs, msg.which and msg.key produce the same numbers. On PCs, they produce different numbers.
Cross-platform, msg.which produces different numbers on Macs vs.PCs; msg.key produces the same numbers for both machines.
Pressing 'a' on a Mac: msg.which == 4, msg.key == 4, msg.ascii == 65
Pressing 'a' on a PC: msg.which == 30, msg.key == 4, msg.ascii == 65
As such, a ChucK script using msg.which for key mapping is platform dependent. If you want it to be consistent always use msg.key instead.
(Unless I am missing something, there doesn't seem to be a good reason for using msg.which for keyboard input)
.ascii produces an ascii value (but not necessarily the same as the actual ascii character mapped to that key)
a) for letters: the ascii number for the UPPER-case letter associated with that key for English layouts (even though it is actually the lower-case character which is getting pressed)
b) for numbers/symbols: the ascii number for the lower-case character associated with that key for English layouts
It doesn't seem to matter what keyboard language layout you specify for your laptop. That is, if you are using a German keyboard layout, you won't get ascii values for the uniquely German keys. However, it does seem to matter what kind of physical keyboard you are using.
If it is an ANSI (American) keyboard, the .ascii results for are based on a standard US English keyboard layout.
If it is an ISO (European) keyboard, the .ascii results are (sometimes) based on a British-PC English keyboard layout.
In other words, unlike KBHit (which appears to give different ascii values for different upper and lower case characters), msg.ascii seems to use fixed tables for the ascii values. Since it doesn't give the true value of the character, it also doesn't seem like there is much point in writing programs which use msg.ascii for key mapping. The only advantages might be: a) if you already have the ascii values memorized or b) if you want quasi-random MIDI pitch generators that are already in a reasonable octave register (e.g., CliX).
MOUSE/TRACKPAD:
Cursor position:
On a Windows PC, msg.cursorX and msg.cursorY (and the scaled versions) do not appear to work. Is there some other way of obtaining the absolute X-Y coordinates for the cursor?
msg.deltaX and msg.deltaY work in both platforms, but appear to behave differently.
if( msg.isMouseMotion ) { <<