Blog Archives

AutoHotKey – create custom macros, and remap your computer inputs

A brief post about a fantastically useful little utility – AutoHotKey. This is a small, free, very flexible and powerful program for Windows which has potentially unlimited usefulness. It allows the user to either a) define a string of mouse/keyboard inputs (i.e. macros) which can be triggered with a single key-press, or b) re-map a particular keyboard/mouse/whatever input to act as if it’s any other kind of input. All this can be achieved either with a fairly simple scripting language, or by the use of AutoScriptWriter – a means of ‘recording’ a sequence of inputs that can then be ‘played back’ at much faster rates.

I use it for some of my fMRI stimulus programs. The MRI scanner sends out a TTL-like pulse at the beginning of every functional volume acquisition (or ‘TR’) and this can be used to synchronise with external equipment – in fMRI it’s important to know exactly when your stimuli were presented (relative to the volume acquisition sequence) in order to generate an accurate statistical model. The pulse from the scanner goes into a little USB adapter doo-hickey, which is plugged into the computer running the stimulus program – the USB box simulates a joystick button-press every time it receives a scanner pulse. This works great, except that when I’m writing my programs in my office, I don’t have a joystick, and also sometimes I want to start my programs manually (for demo purposes, or whatever). The solution? I write all my programs to start with a left-mouse click, and run an AutoHotKey script on the stimulus-program computer in the scanner room which transforms the game-port input to a left-mouse-click. This is the script in its entirety:

Joy1::Send {LButton}

Simple, huh? In this way, my programs can start either with a left-mouse-clickorwhen they receive the input from the scanner on the game-port, and I don’t have to change them at all when I move them from my office machine to the scanner-room computer. It works perfectly. There’s loads of good help, advice and sample scripts on the AHK website/forums – a quick search will usually bring up something at least somewhat-related to what you want to achieve.

It’s also possible to play a very mean prank on somebody by running a script on their computer re-mapping several (or even all) of their keyboard keys to other random keys, but the less said about that the better…

Mac users are out of luck with AutoHotKey I’m afraid – it’s Windows only. However the built-in Automator application in Mac OS X has a lot of the same macro-like functionality, and is pretty easy to use once you get the hang of it. For the input re-mapping side of things IronAHK looks like a good (and very powerful) free option, and KeyRemap4MacBook also looks good – less powerful, but a much more user-friendly interface.

Happy key-hacking! If you find a good use for AHK, then let me know in the comments. TTFN.

Running Experiments 2: Response Hardware

We have the tools, we have the talent!
– Winston Zeddemore

In the last post I talked about timing of experiments in general, and mentioned that timing of responses is critical for success in a reaction time-type experiment. This topic will discuss some of the options for hardware that’s available for collecting responses.

The simplest solution is just to use the human-interface hardware which you’ve already got i.e. get your participants to click a mouse button, or a key on the keyboard as their response. However, there are several reasons why this will generally be undesirable. Most mice and keyboards on modern computers connect via USB, and this introduces a slight lag. The computer ‘looks at’ or ‘polls’ its USB-connected peripherals at a standard rate of 125Hz (meaning 125 times per second, or every 8 milliseconds). This means that if you make a response, there may be a (variable) lag of anywhere between 0 and 8 ms between the response and the computer actually ‘seeing’ it. USB-keyboards have a similar problem. In addition, mice (and keyboards) have a lot of internal circuitry which can also introduce timing lags of variable durations. This paper (Plant et al., 2003) presents the results of some bench-testing of a set of mice. The best mouse they tested had a minimum button-down latency of just 0.4ms, whereas the worst one showed a minimum lag of 48ms! Running timing-critical experiments with the latter mouse (where the effect you might be chasing could be in the range of 20-30ms) would clearly be disastrous. Read the rest of this entry