Just an idea that popped up in my head while playing around with different controllers. I have a spare mac keyboard lying around and thought wouldn't it be great if I could turn that into a controller somehow. You know, have an object convert the incoming keystrokes to midi notes etc. My skills are limited, as are my knowledge and understanding i.e. I would not know where to begin... Is it even possible theoretically?
Noob question alert: Is it possible to turn a regular pc/mac usb keyboard into a controller?
strum
#2
Yes it is theoretically possible with the existing hardware but would require modification of the firmware.
MC_DETH
#3
It would be pretty awesome, one could select some widely available standard layout keyboard as the 'recommended' hardware device and then make a template patch to designate tons of functions to its keys. Should this go on the huge wishlist, then? 
My guess is it's not a priority issue
strum
#4
Yeah i think I read a post Johannes made about it he said it was not a high priority and that the differing keyboard layouts from country to country make it difficult from what I remember.
the firmware implementation is changing for the next version of axoloti, so not a bad time to ask 
i think the trick is to take the firmware out of the equation of 'keyboard layout', since it is a low priority, with very few users/patches needing it.
@johannes, how about we take out the keyboard 'trap' (in dev branch), and instead make it call the custom_cb handler? I recognise this is very low level, and is not ideal from a threading perspective, but it at least makes it possible for a patch/object to potentially handle events.
ideally, id recommend a callback chain too... just in case you have multiple objects using it, though we could implement this in the object itself.
(id be tempted to move the mouse implementation over to this too)
... I'm also not too keen on putting in a patch keyboard handler, like the mouse one... its not going to work well without a queue for simultaneous keystrokes, and then seems like we are adding a firmware overhead (memory) for something used by a tiny minority of patches.
strum
#6
Is it possible to optionally load extensions of the firmware is a similar way the linux kernel loads modules?
no - the structure is not similar to linux kernel/userland ... check out the STM and Chibios docs if your interested.
but this is not really needed, we already have the HID registered, its just about how we get the data too a patch, without overhead ... and in this game every byte counts. (its trivial for me to create a ring buffer for events, its just it costs memory)
I did propose to allow users to recompile the firmware with 'extras modules', but this means the user has to be concerned if a patch is compiled with the right firmware, which is a support nightmare, and difficult for users to track.
instead, the next release, tries to push more resources to be made available to the patch side, and Ive added a new 'modules' features, which allows libraries to be compiled in.... so this kind of gives optional features, but one that objects have dependancies on.
... anyway, all change here 
strum
#8
Ok, good to know.
I've started looking at the STM stuff and chibios docs, I don't really know where to start with it all though.
I see.
I can understand that though perhaps patches could be made so they load the appropriate firmware automatically. A modularised system might free up memory.
Sounds reasonable.
Into patches? or the firmware?