Hi list,
I'm working on an installation with a keyboard as an input for words, that on their turn are sent to a projection. I started with the [gemkeyname] object to avoid keycombinations like ctrl+Q. (As for the keyboard is completely in the hands of unknown users.) But in this case there are a lot of limitations considering the textoutput, like the unpossibility (?) of getting undercase letters. Since I'm especially interested in the manipulation of the text within the Gemwindow, which works quite nice up to now, I'd like to work without these limitations, so working with [keyname] and [key] seems to be a logical solution. Except for the keycombinations like ctrl+Q again. At this point I have no idea how to work around this.
Is there anyone who could point me a way to solve this problem? Or in other words: is there a way to get rid of most of the limitations in [gemkeyname] and to keep the splendid limitation towards ctrl+Q etc, or better to use [keyname] and get rid of ctrl+Q etc? Anyone has any experience with this. That would be great!
Thanks in advance,
Yorick
Yorick Phlypo wrote:
Hi list,
I'm working on an installation with a keyboard as an input for words, that on their turn are sent to a projection. I started with the [gemkeyname] object to avoid keycombinations like ctrl+Q. (As for the keyboard is completely in the hands of unknown users.) But in this case there are a lot of limitations considering the textoutput, like the unpossibility (?) of getting undercase letters. Since I'm especially interested in the manipulation of the text within the Gemwindow, which
i don't know which Gem you are using, but here (linux) [gemkeyname] works fine with uppercase, lowercase and special characters (e.g. Ctrl-x): each gets a separate identifier, according to its name.
as far as my testing went, [gemkeyname] worked fine on linux and w23 (though the naming of special keys like "Left" might be differing across platform (but this might as well be fixed already)), and though i have not done any testing on os-x, i believe that a lot of other people have...
it would be interesting to know what system you are on (and whether it allows you to use upper/lowercase characters anyhow - afair the zx80 does not have lowercase characters; please tell us that you managed to run pd/Gem on it)
if this is really a bug, please file a bug-report at http://sf.net/projects/pd-gem
works quite nice up to now, I'd like to work without these limitations, so working with [keyname] and [key] seems to be a logical solution. Except for the keycombinations like ctrl+Q again. At this point I have no idea how to work around this.
i have once posted a patch to add a "kiosk" mode to pd which disables all the menus and keyboard-shortcuts in pd. you should still be able to find it in the sourceforge patch-tracker (of pd that is: http://sf.net/projects/pure-data) (it won't get accepted into main pd though, as there are other better as in: more granular) ways to acchieve this)
otoh, if you are doing an installation with Gem you will most likely want to run it in fullscreen mode, so that people do not see the underlying pd and OS. in this case [keyname]/[key] won't help you, since they only work when they have the keyboard focus (which they don't when the gemwindow is before them).
a good way to get the keyboard regardless of the the window-focus is [hid] (and probably [hidin])
oh, and don't forget to remove the Control, Alt, Meta keys from your keybaord, as people will likely keep rebooting your machine....
mfga.sdr IOhannes
On 12/06/2007, at 8.45, IOhannes m zmoelnig wrote:
Yorick Phlypo wrote:
Except for the keycombinations like ctrl+Q again. At this point I
have no idea how to work around this.
[snip]
oh, and don't forget to remove the Control, Alt, Meta keys from your keybaord, as people will likely keep rebooting your machine....
Isn't it possible, like generally, to instruct the operating system
to ignore (or similar) unwanted keys (or key combinations)?
As i understand what Hans says, then HID and friends basically just
listens to the operating system. This motivates the above suggestion.
it would be interesting to know what system you are on
Formerly I was using OSX 10.4, but since a couple of weeks I've been working on Windows XP. On OSX I used [gemkeyname] exclusively to trigger movement. So I don't know if this problem of lowercase/uppercase was there on OSX as well. I suppose it wasn't, since it shouldn't be a problem at all.
I ran Ubuntu Studio on this pc through VirtualBox but there I had a problem with the channeling of the USB ports. So the Arduino I'm planning to implement in the installation can't be seen by pure data in Ubuntu Studio. Since this computer i'm working on isn't mine, partitioning and risking problems with that is not really an option. Once a week I do some testing on both platforms OSX as wel as WindowsXP. I'll try to test the uppercase/lowercase problem on OSX tomorrow. Eventually the installation will be running from OSX, so I hope that in the end [gemkeyname] can be used without a problem.
in this case [keyname]/[key] won't help you, since they only work when
they have the keyboard focus (which they don't when the gemwindow is before them)
I'll be projecting the gemwindow on a surface, so maybe there's a way to use a split screen (on OSX) and to have the keyboard focus? Since the computer screen will not be visible for the user.
a good way to get the keyboard regardless of the the window-focus is
[hid] (and probably [hidin])
Seems to be a problem on WindowsXP? I could try this on OSX, because that's where the patch should be running smoothly in the end. Would this (hid/hidin) be the best option?
And o yeah: The version of pd is pd039ext, so I thought maybe this could be the problem. I needed the update to get the Arduino to work properly. I've read recently about problems with Gem in combination with pd039ext. Could this be the main cause? If this is so ... it's a shame :)
And at last (for now): I found the "kiosk" patch. Looks very interesting, thanks a lot. But I don't know what to do with the kiosk.diff file. I'm sorry if this is a newbie question. It would be great to be able to use this function.
Thanks all,
yorick
2007/6/12, Steffen stffn@dibidut.dk:
On 12/06/2007, at 8.45, IOhannes m zmoelnig wrote:
Yorick Phlypo wrote:
Except for the keycombinations like ctrl+Q again. At this point I have no idea how to work around this.
[snip]
oh, and don't forget to remove the Control, Alt, Meta keys from your keybaord, as people will likely keep rebooting your machine....
Isn't it possible, like generally, to instruct the operating system to ignore (or similar) unwanted keys (or key combinations)?
As i understand what Hans says, then HID and friends basically just listens to the operating system. This motivates the above suggestion.
-
IOhannes m zmoelnig -
Steffen -
Yorick Phlypo