bmhal

I'm building a couple of footswitch controllers to use in conjunction with Ableton out of some modded USB keyboards (computer not musical) - like in the tutorial on the cycling74 site - and so far so good in terms of building most of the patch.

Only the patch doesn't operate when Ableton or any other program is in focus (i.e. when inside ableton & Max is in the background)

The controllers can just work without Max by just button mapping the keys to to things inside of ableton no problem.

But our setup for live playing will mean that one foot controller will be for the vocalist to turn effects on and off, and the other for me to change scenes etc

But we also use a monome for certain things which will require max being in 'focus' for those parts of the set so we can see what we are doing (e.g. MLR for those familiar) and then the keyboard - stomp boxes won't be working in ableton as its not in 'focus' - so the vocalist won't be able to keep doing his thing while I have Max selected - crucially he won't be able to turn this OFF - vice versa if it was a pure Max patch:

So my planned patch was to build a good key-to-midi patch - as midi seems to work independant of what applications are running - which would be able to have a 'kill' setting to normalise all things in Ableton - plus some modifier keys to be able to get the most amount of controls and mesages out. & possible talk to many applications or outboard gear down the line

But - it isn't working if I'm not actually inside Max. Basically my patch is just like the start of the tutorial one:

Key - some number boxes, a select object - then down to midi (haven't really finished the midi part yet - probably will need some advice on that if I run out of ideas)

Is there an object or a route to make the key device keep working like this - regardless of what I'm in

My monome Max patches which run on serial devices work great when Ableton is in focus etc, but I guess normally you wouldn't want a keyboard to be firing in applications in other windows - is there a way to make sure Max is reading and outputting key presses

getting-key-object-to-work-when-another-application-is-in-focus

I've successfully accomplished something similar to what you are trying to do recently... a patch that converts input from a wireless numeric keypad to OSC data while max is running in the background.

While the "Key" and "Numkey" objects only report input when Max is the front most application, the "Hi" (USB HID) object seems to remain active constantly. Did the trick for me..

While the "Key" and "Numkey" objects only report input when Max is the front most application, the "Hi" (USB HID) object seems to remain active constantly.  Did the trick for me..


@Adeyo: yeah cheers mate - that has the key presses working and showing up fine when I'm in other apps no problems there.

I did a little searching on the forum about 'Hi' & its working now - unpack 00 to get out my presses with keys like tab and shift showing up on the left and normal keys on the right this running into a select object to get my desired keys. And as long as I only press one normal key at a time its fine - or else the number i get is WAY too high - and it represses one of the keys when I release, but as long as I only press one normal key at a time its going ok. Maybe there is a way to filter these messages a little more - so just key on - not off when multiples are pressed

My next problem is working out how to get midi port, cc and channel info out to other applications - the 'ctlout' object isn't giving me much love right now, even after basically copying somebody else's patch and sub-patcher

By using [hi] instead of [key] you'll also get another nice feature: you can attach more than one keyboard at the same time and have them nicely seperated

But beware, that [hi] behaves different from [key].

There's no discrimination between control,shift,etc. and the other keys. You might got tricked by looking at the number boxes in hi help patch. Use [print] instead, because there are more than one message pairs reported per key event!

Seems like the Usage ID's 10-18 are special. I don't know what those are. But I think it's safe to just ignore them (f.e. via the "ignore" message to hi).

By using [hi] instead of [key] you'll also get another nice feature: you can attach more than one keyboard at the same time and have them nicely seperated 

But beware, that [hi] behaves different from [key].
There's no discrimination between control,shift,etc. and the other keys. You might got tricked by looking at the number boxes in hi help patch. Use [print] instead, because there are more than one message pairs reported per key event!

I know there's a more elegant way to do this, but this patch should give you some ideas...

I've tested this patch with an external keyboard on a MacBook Pro..

I'd rather not use the ID 10. It seems to be a 4 byte value with all momentarily keys pressed accumulated (this is where the big numbers come from). This works fine only as long not more than one key is pressed at a time.

I'd rather not use the ID 10. It seems to be a 4 byte value with all momentarily keys pressed accumulated (this is where the big numbers come from). This works fine only as long not more than one key is pressed at a time.
Here's a slightly different approach:

getting "key" object to work when another application is in focus?