Stock keyboard patch forces a node for each key and no modifier keys so yes. If the Export-to-Application module happens this will be even more useful. (kiosks/games)...
Use the HID input patch. You can add an output for every key on the keyboard (and all modifier keys, even things like the FN key, i believe)...ALSO you can use more than one keyboard (each with it's on HID input patch)
All USB keyboards and mice, and most USB joysticks/gamepads will work with this.
unfortunately, the HID patch isn't particularly portable -- it identifies a single type of device (i.e. a Dell Dimensions 5-button, 2-axis mouse), and any "similar" but not identical device (a Microsoft 5-button, 2-axis mouse) gets rejected. for some things (space navigator) that's ok, for others it's not :(
I've had a fair few troubles with the HID patch. Mainly my tablet not working with it, at all.. but also my mouse missing buttons.
The main problem with both that and the keyboard patch though is the spaghetti mess you end up with if you want to use the whole keyboard, plus the nightmare of dealing with it all if you want free text input. When I did that, I ended up using about 10 keyboard patches in macros, with javascript to combine all the inputs into a single string. The output of that was then fed into another combiner to give me the actual key pressed. Urgh!
With the standard keyboard patch, you get one output per key. So for a fairly simple setup, you'd have 26 keys, plus 10 numbers, plus a load of symbols. Call it 50 outputs. That's one hell of a big and unwieldy patch (I know from experience, i wrote a simple text editor once in QC :( ) I can't remember how modifiers work off hand, but I had at least caps working.
So yeah, I'd definitely find this useful. I need to write a proper tablet plugin at some point, as the tablet support in QC is horrible (not sure if it's QC or system related.. I get the same problems elsewhere but only slightly, in QC it breaks my app pretty much).
Perhaps the two things could be tied in together? I've had no time to look into it at all yet (too busy writing iphone apps instead lately :)
There's a folder on my desktop ("cwright filing system") called "freeboard", which would eventually grow up into a patch that outputs a string of all characters pressed since the last frame (so you could grab them all with a single output). No one's really mentioned this functionality before, but the built-in keyboard patch sucks for free typing input. Any interest?
(I don't think this is what Daniel had in mind when he started this topic/feature, but I can't be certain..)
... that would be great... I remember trying to figure out a decent way of typing on the fly, but so that you could pre-write text, and doing something with image in string and multiplexer (so that I could type in one box, then do the switch), but it kind of sucked, and I had to pretend like I was playing piano to get decent speed!
-this actually just brought up a thought for a qtz though... instant inspiration :o)
sounds like it would at least be massively better than the built-in keyboard patch. One question though, how would "string output" work with things like modifiers and the delete key? Modifiers are pretty critical for non-english languages, and delete is pretty critical for non-perfect typers like me :)
I guess if shift + p are detected the patch would output a P, but if only the delete key is pressed, what would happen? Guess the character code for delete could be passed as the string? Alt-r (®) would be manageable, but how about alt-u (¨)? With that, you'd press alt-u, then u to make ü...
I guess really, we need a real "text input" patch that can handle it. Perhaps just use a NSTextField, and have it hidden but given first responder when the QC view is active? No idea if that would work, but it'd handle the keyboard nicely.
Maybe one for a rainy day sometime, unless there's a lot of demand for it. For most cases, you can just publish a string port and use that :)
(that's why it's sitting on my desktop, and not in our source repository -- lots of technical problems to deal with that I've not even attempted to grapple yet...)
I do like the NSTextField idea though... that would handle all the trickiness
I'd imagine mouse control would be pretty hard to do, but not impossible (it's common for remote control software at any rate).
But do you really need that level of control? It would be pretty dangerous (if the composition takes control of the mouse, it could delete files, break things, etc.) You'd need to explicitly know what was where on the screen.
If you only need to move the mouse around to demonstrate things (i.e. no clicking), it would be pretty easy to hide the real mouse cursor and add a fake one, and move that around.
Stock keyboard patch forces a node for each key and no modifier keys so yes. If the Export-to-Application module happens this will be even more useful. (kiosks/games)...
Use the HID input patch. You can add an output for every key on the keyboard (and all modifier keys, even things like the FN key, i believe)...ALSO you can use more than one keyboard (each with it's on HID input patch)
All USB keyboards and mice, and most USB joysticks/gamepads will work with this.
unfortunately, the HID patch isn't particularly portable -- it identifies a single type of device (i.e. a Dell Dimensions 5-button, 2-axis mouse), and any "similar" but not identical device (a Microsoft 5-button, 2-axis mouse) gets rejected. for some things (space navigator) that's ok, for others it's not :(
I've had a fair few troubles with the HID patch. Mainly my tablet not working with it, at all.. but also my mouse missing buttons.
The main problem with both that and the keyboard patch though is the spaghetti mess you end up with if you want to use the whole keyboard, plus the nightmare of dealing with it all if you want free text input. When I did that, I ended up using about 10 keyboard patches in macros, with javascript to combine all the inputs into a single string. The output of that was then fed into another combiner to give me the actual key pressed. Urgh!
What is there that can't be done with this now (I'm having a dense moment).
What is meant by "no modifier keys" as well? You can add extra keys with "settings" but I don't think that's what your saying...
With the standard keyboard patch, you get one output per key. So for a fairly simple setup, you'd have 26 keys, plus 10 numbers, plus a load of symbols. Call it 50 outputs. That's one hell of a big and unwieldy patch (I know from experience, i wrote a simple text editor once in QC :( ) I can't remember how modifiers work off hand, but I had at least caps working.
So yeah, I'd definitely find this useful. I need to write a proper tablet plugin at some point, as the tablet support in QC is horrible (not sure if it's QC or system related.. I get the same problems elsewhere but only slightly, in QC it breaks my app pretty much).
Perhaps the two things could be tied in together? I've had no time to look into it at all yet (too busy writing iphone apps instead lately :)
Ah ok. Heheh, that never phased me!
There's a folder on my desktop ("cwright filing system") called "freeboard", which would eventually grow up into a patch that outputs a string of all characters pressed since the last frame (so you could grab them all with a single output). No one's really mentioned this functionality before, but the built-in keyboard patch sucks for free typing input. Any interest?
(I don't think this is what Daniel had in mind when he started this topic/feature, but I can't be certain..)
... that would be great... I remember trying to figure out a decent way of typing on the fly, but so that you could pre-write text, and doing something with image in string and multiplexer (so that I could type in one box, then do the switch), but it kind of sucked, and I had to pretend like I was playing piano to get decent speed!
-this actually just brought up a thought for a qtz though... instant inspiration :o)
sounds like it would at least be massively better than the built-in keyboard patch. One question though, how would "string output" work with things like modifiers and the delete key? Modifiers are pretty critical for non-english languages, and delete is pretty critical for non-perfect typers like me :)
I guess if shift + p are detected the patch would output a P, but if only the delete key is pressed, what would happen? Guess the character code for delete could be passed as the string? Alt-r (®) would be manageable, but how about alt-u (¨)? With that, you'd press alt-u, then u to make ü...
I guess really, we need a real "text input" patch that can handle it. Perhaps just use a NSTextField, and have it hidden but given first responder when the QC view is active? No idea if that would work, but it'd handle the keyboard nicely.
Maybe one for a rainy day sometime, unless there's a lot of demand for it. For most cases, you can just publish a string port and use that :)
(that's why it's sitting on my desktop, and not in our source repository -- lots of technical problems to deal with that I've not even attempted to grapple yet...)
I do like the
NSTextFieldidea though... that would handle all the trickiness! Ah. That's a cool idea.
That's what I though, but wanted to make sure :)
I'm not sure how easy/difficult that'll be -- I'll try to check it out sometime.
I'd imagine mouse control would be pretty hard to do, but not impossible (it's common for remote control software at any rate).
But do you really need that level of control? It would be pretty dangerous (if the composition takes control of the mouse, it could delete files, break things, etc.) You'd need to explicitly know what was where on the screen.
If you only need to move the mouse around to demonstrate things (i.e. no clicking), it would be pretty easy to hide the real mouse cursor and add a fake one, and move that around.