Hi Kassen,

Hey, Les!


Actually, yes I do have such an example, specifically the number keys (the ones above the keyboard).  On British and Belgian keyboards the number keys return completely different message.which() codes.  The Belgian keyboard is particularly tricky as it's number keys are all replaced with special French characters.  So when I made a numeric menu, my Belgian friend couldn't work the program.  He eventually played around with it and found that some of the letter keys gave numeric codes, and gained access into the program that way.  Also the British numbers didn't work, and I haven't had a German user yet but I expect a similar problem.

Hmmm, yes, and out of interest I just questioned a Australian correspondent of mine who reported that her keyboard too was unlike the US layout with regard to number placement (for example no key to the left of the "1" / "!" key).
 

So I made number / letter combinations for the menu like 1 or a, 2 or b, 3 or c, etc.  and that helped a lot, but still there are problems.

Yes... for example the French saw a need to swap two plain letters on regular keyboards. I think it's important to respect everyone's culture and traditions but at times the French keyboard has challenged that belief of mine. I'm sure many of our French friends have had the exact opposite experience, know exactly what that feeling is like, and will forgive my fit of intolerance there :¬).
 

When we get cross-platform MAUI, I'll make the program graphical again and that will solve the keyboard issue, but I really do think it is something that is not quite kosher.  I mean, after all we want our ChucK programs to work in the UK and Belgium, right? :)

Oh, yes, and China and Arabia as well, if at all possible.
 

Maybe I should use message.ascii(), do you think that would solve it?  Maybe that's *why* message.ascii() exists?

I think so. I think it's important to start with thinking about *what* you want. For example; on my sequencer the lower row of keyboard keys affects effects on the drums. On a NL keyboard this runs like;
]zxcvbnm,.-

while on a US one it goes;
zxcvbnm,./

In order to be able to use the same interface in terms of key-positioning on both I use msg.which() there and skip the "]" on the Dutch one, that way it's the same. For other applications, like yours, the labeling on the keys is more important and I'd use the ascii value since that is actually what you are trying to refer to.

It's my opinion that Spencer did a amazing job at the updated HID implementation (which includes the keyboard) and that this is one of the cleanest aspects to ChucK. I find it very pleasant to work with and to me it seems like it's been done with great care, I'm quite sure these options are there on purpose and with exactly this type of question in mind. So far you haven't encountered a UK DVORAK keyboard but I bet those exist and anticipate those would throw off your "numbers or letters" plan completely.

It's very easy to overlook the tricky nature of this problem since we are all so intimately familiar with our own keyboards. I remember I was looking at a (Dutch) television quiz years ago and the hostess asked "what character do you get when you press shift plus 2 on a computer keyboard". According to her that should be a "@" and whatever the contestant answered was wrong (for me it's a quotation mark). Somehow whatever process determined those questions completely overlooked the bewildering range of keyboard layouts that are out there (I thought it was a bit unfair). If you think it's tricky now; have a look at the keyboard layout settings in your favourite OS; there are different models from various manufacturers and most of those can come configured for a huge range of languages. I wouldn't be surprised if there were 5 digits worth of keyboard layouts that we might encounter in the world.

So... yes, ascii should be the way to go, I think that would make your problems go away, at least until you get users that have a different character set configured. I have no idea at all how to deal with that.

Yours,
Kas.