Why is Live's Session View Immune to the Java Robot Class??????!!!
Mar 6, 2013 at 2:22am
Why is Live's Session View Immune to the Java Robot Class??????!!!
Now thinking it might be a Max-only issue, I downloaded Eclipse & the JDK, and learned enough Java to throw together a quick app to run Robot in a loop, spitting out Cursor Downs every 500ms. All the other programs hear and obey. Again, Live does not.
Here’s the fun part: I can throw together a script in Autohotkey that does the exact same thing, and Live recognizes the emulated Cursor Down keystrokes, navigating downward through the scenes…
What the heck is the issue w/ Live & Java? I have found threads as far back as 2005 (google “ableton java robot class”, without quotes), and NOBODY has ever answered this, more disappointingly, no one from either Ableton or Cycling74 has ever commented on it that I have been able to find.
Look, I’m not a programmer, just a hack who will learn as much as I need to of whatever I need to in order to realize my writing/performing visions. I’m afraid of the extra layers of potential vulnerability by using Bome’s or Autohotkey to do something as critical as a cursor navigation or delete in live performance. I’m a guitarist, planning on using this for live looping without needing my eyes glued to the monitor, and I need to do this stuff with my feet. Max I would trust, if I can just find some way to emulate the missing MIDI to keystroke functionality in Live.
Sorry for the rant, I’ve just been spinning my tires for days on this, and I’m a bit frustrated, mostly with myself for not coming up with any solution…
Thanks for reading.
Mar 6, 2013 at 2:58am
OK, so it looks like I can partially answer my own question, for the benefit of anyone who stumbles on this with the same problem. It appears there’s a bug in the actual Java Robot Class which causes it to send cursor control keys, del, insert, etc., as if they were being typed on the numeric keypad. I tested it by turning off numlock on a desktop keyboard, and Live does not recognize the keypad for navigation. Lovely.
Mar 6, 2013 at 12:50pm
I don’t think Bome’s+AHK would be any more fragile in this situation than Max TBH.
Bome’s is near universally used for the purpose, as you gathered . . . and while my experience with AHK (scripting) is quite limited I’m using a couple of what I’m convinced are compiled AHK scripts as background utilities that function and perform as well as a native Win32 app.
Clearly you’ll want to torture-test any such setup before walking out on stage – but you’d do that anyway.
Mar 7, 2013 at 1:56am
Sorry for the delayed response. I can’t find a way to turn on email notification for subscribed threads…
I’m a big believer in AHK, and I’ve used it successfully. It has an incredibly rich script language for what it is. I prefer it to Bome’s because it has the critical ability to call focus to a specified windows/app, last time I checked, Bome’s didn’t. Between AHK & Bidule, nearly anything that can be imagined can somehow be hacked together re: MIDI & remote control. The problem for PC-based Max users is that I don’t think we have anything similar to Leigh Hunts’ MIDI_In/MIDI_Out externals. I’m very new to Max/Live, and honestly, being limited to one MIDI port/channel per track is a big step backward from how I usually work. The fact that Live isn’t mulit-timbral per track amazes me. Yeah, I know there are “workarounds”, but they shouldn’t be necessary in a product this mature. There are a lot of things I’m using Bidule & AHK to do within Live that I’d rather do w/ Max, but I’m gonna use up a lot of tracks/virtual ports in the process without the ability to address multiple ports/channels per track from within the Max environment.
But back to the original issue, I’ve got a passable workaround. I’ll post it for the benefit of anyone who winds up here searching for a way to send keystrokes to Live, particularly cursor & delete keys in Session View. It ain’t pretty, but it does work.
Basically, we can use Autohotkey to remap the rogue simulated numeric keypad variants of the cursor & delete keys generated by Autobot back to the “normal” keystrokes that Live needs. Here’s the AHK script:
If you’re already using AHK, add this to your script, otherwise this is all you need. Assuming you’ve already installed the Autobot.class in Max’s javaclasses folder, create a new session in Live, create the device below & drag it into a MIDI track. You’ll need to map the buttons in the device to a h/w MIDI controller generating NoteOn/Off to test it properly, since the Live window, of course, needs to retain focus for any simulated keystroke solution to work.
Here’s the demonstration patch (also commented internally):
– Pasted Max Patch, click to expand. –
Copy all of the following text.Then, in Max, select New From Clipboard.
I sure hope this saves someone some head-banging
Mar 7, 2013 at 5:12am
Oh hey man hells yeah!
Live, as brilliant as it is (and it is) – has some bone-jarring design issues. But I mean . . . it’s only 9. How mature were you at that age?
Why Live hasn’t even got hair on its Behles yet!
^ That would make more sense if the man was bald.
I’m an absolute novice when it comes to AHK. The limit of my prowess is a little compiled .exe to remove the titlebar from windows (Windows) so I can run apps pseudo-fullscreen and still keep the menubar visible. Originally this was specifically for Live, but I’ve found it occasionally useful for other apps where pixels are at a premium. Handy for laptop use.
In the spirit of leveraging many small tools, it kinda requires another utility for moving the window sans titlebar (avec mouse / ctrl-key mod) – but it’s all quite slick to operate.
For all I know, the tool I use for the window moving could have an AHK lineage of its own. The .exe compiler feature is fantastic. I’ve pondered the notion of compiled AHK stuff as part of Max standalones or otherwise . . . vague ideas on domain-specific problem-solvers for distribution stuff.
^ Like I said . . . vague.
Thanks a whole bunch for this, very useful indeed! :)
Mar 9, 2013 at 11:57am
Been trying to create mouse clicks using mxj autobot for a day or so, simply doesn’t work… Aka.mouse doesn’t seem to be 64bit compatible either… Any other ideas?
Mar 10, 2013 at 2:57am
None other than the theme so far, AHK for Win (and I suppose Automator for OS X?).
I’m curious now to wonder if / how etc.one could or would go about making .mxe externals from compiled (to .exe) AHK scripts? Is this possible . . . feasible . . . am I on crack?
Mar 12, 2013 at 2:42am
S4racen: PC or Mac? Is your device throwing errors in the Max debug window? Aka.mouse is mac-only, I believe. Can’t help you there (I’m in windows). If you want to post your autobot device here, I’ll try it on a PC.
Johnny: I’m not aware of any way to “package” a windows .exe in an mxj, however, it might be possible to find some type of a java class to act as a wrapper for the exe and then present it to Max through the mxj. But that would probably be pretty tricky. But then again, I know almost nothing about Java/Max at this stage. That hasn’t kept me from having some fun trying to learn it though…
Mar 12, 2013 at 12:05pm
Hi FC . . . I didn’t mean packaging or wrapping the .exe as Java anything (I am not a fan).
I was just speculating (idly) about the possibility of converting or otherwise . . . I don’t know the jargon or procedure > .mxe (the Max equiv of an .exe External?).
I suppose the idea was that AHK is extremely useful for many kinds of interaction outside of Max I currently see people using other methods to access – could it become an almost standard method, can it be incorporated within the patcher structure itself etc.
I’m not addressing these questions at you specifically, rather just throwing them out there for general perusal. Cheers.
You must be logged in to reply to this topic.