FTAP is a Linux-based program (written by
for tapping and music performance experiments.
It connects to a standard MIDI input device
(e.g., a keyboard or drum pad) for
collecting MIDI keystroke data, and sends MIDI signals
to a MIDI tone generator or sampler for audio output;
MIDI messages are processed with
millisecond accuracy and precision.
FTAP is described in an article
in Behavior Research Methods, Instruments, and
Computers (Finney, S.A. (2001a),
FTAP: A Linux-based program for tapping and music experiments",
v 33, pp 65-72).
Please cite this article when writing up any research which makes use of FTAP.
FTAP is open source software and is available at no cost (but without warranty) in source code form under the GNU PUBLIC LICENSE. If you find it useful, let me know. If you have suggestions for improving it, let me know. If you find or fix bugs, let me know. I will try to respond to questions, and am prepared to fix bugs, clarify the documentation, etc. If FTAP looks interesting to you but you're having trouble getting it to work, please contact me.
The types of experiments FTAP can run includes, but is not limited to:
In addition, two different labs have modified FTAP to sent signals to the parallel port and have used this to synchronize with EEG data collection; see, e.g., Maidhof, Kastner, and Makkonen (2014). This capability may appear in a future official FTAP release.
The 2.1.07b distribution is basically a cleanup release: it
compiles on 2016 vintage Linux systems, some resource limits have
been increased, the documentation has
been updated, and there have been other minor fixes and enhancements.
See the Release Notes
for more detail.
I also created a cleaned-up and more rigorous version of the loop test (again, see the Release Notes ). It runs for a longer period (60 seconds rather than 4 seconds), and can show up problems with MIDI interfaces that do not occur in the shorter test (see MIDI Interfaces). It continues to allow the user to verify on their own system that FTAP processes MIDI input and output messages with millisecond precision and accuracy, as it did in 2001 (Finney, 2001b). The 2.1.07 looptest parameter files may not work well with earlier FTAP releases.
The FTAP distribution can be downloaded as a gzipped tar file (about a megabyte). Extract it by first using "gunzip" and then the "tar" program; you will be left with a directory hierarchy named "ftap.2.1.07" (or something close). The README files and the included documentation should then get you started. You can also directly access the current User's Guide and Reference Manual in .pdf format.
See the News section below for bug reports/notes.
Download the FTAP 2.1.07b distribution
The MD5 checksum for the ftap2.1.07b distribution is 3038716858e0856bcb5bbdac6864a395. Run "md5sum ftap2.1.07b.tar.gz" on your downloaded file. The result should match.
NOTE: Although I have done a fair amount of testing, the 2.1.07b release should be considered preliminary until a few people besides me have compiled and run it on their systems (that's why I gave it an "b" suffix). I don't expect to have to make any significant changes, but you never know :-). If you have problems, please contact me. If you successfully run the looptest (see the Release Notes), or if it fails, please let me know what Linux release you're running and what MIDI hardware interface you used so I can add it to this web page. Thanks.
Older FTAP releases:
See the User's Guide for an introduction to FTAP. You'll need a Linux PC with a hardware MIDI interface, a MIDI input device (keyboard or percussion pad), and a MIDI output device (a tone generator); see Configuration for some considerations. A trial is specified by a simple format ASCII text file, usually about 20 lines long. The easiest way to get some sense of how FTAP works (and its flexibility) is to look at and modify the samples file provided in the "params" directory in the distribution. Although actual data collection needs to be done with Linux "root" privileges to get millisecond accuracy and precision, I recommend doing initial evaluation as a normal user to avoid potential security issues. If you decide to collect data, you should run FTAP on a dedicated experimental machine. See the documentation for further details.
The FTAP software runs on a Linux PC, running some version of
the Linux OS (including drivers for USB, and the ALSA
MIDI implementation), and uses a hardware MIDI interface (e.g.,
a USB-MIDI interface); I will refer to this collection of
components as an "FTAP-MIDI" system. A properly configured
FTAP-MIDI system performs with reliable millisecond accuracy
and precision, and the user can (and is required to) confirm
this with their own configuration by running the provided "looptest"
parameter file (see the documentation and Release Notes). It is not necessary
to install any custom Linux real-time patches (note that
a millisecond is glacially slow on a 2 GHz processor).
To run an experiment, the FTAP-MIDI system must be attached to a MIDI input device and a MIDI output device; these devices will add some, hopefully small, latency. Some devices are known to be flawed (see the Devices section); it is the user's responsibility to choose appropriate devices for their requirements.
See Benchmarking for the gory details on validating the performance of an FTAP-MIDI system.
As described above, by "FTAP-MIDI" system I mean the system comprised of FTAP software, a PC, the Linux OS and drivers, and a MIDI hardware interface. Such a system demonstrated millisecond accuracy and precision in 2001, and (not surprisingly) still does so on faster systems in 2016. My guess is that any recent PC and contemporary Linux distribution (using the default ALSA sound system) will be fine, but since you will be testing your own configuration with the loop test anyway, you'll be able to determine this for yourself. The loop test will also test your MIDI interface; as described below, some work better than others.
In 2001, driver choice (OSS vs 4Front) was an issue,
and the FTAP looptest showed that some
soundcard/driver combinations gave inadequate
(10 ms resolution) MIDI performance. In 2016,
the ALSA system used in current Linux system
handles MIDI better, but individual
MIDI interfaces still need to be verified
with the loop test. I have tested 4 different
USB-MIDI interfaces with FTAP 2.1.07a; three are acceptable,
while one gave occasional errors and would best be
avoided. These tests were run in a configuration
in which my system (a quad-core Athlon running Ubuntu
14.04) was running in normal multi-user mode with
networking and all services enabled; the worst-case performance would
have been a little better if the system had been quiescent
(as I recommend for data collection).
The 4 USB-MIDI interfaces I tested were:
The results from 10 minutes of error-free, full-throttle MIDI throughput (using the "run_looptest.sh" and "run_loopcheck.sh" scripts included in the 2.1.07b release) are as follows; these statistics are based on the times between received input MIDI events (NOTEON and NOTEOFF).
Mean (ms) Standard Deviation Roland: 1.00 .22 VicTsing: .96 .26 Edirol: 1.00 .22
The particular M-Audio interface I tested would often pass the short 4 second looptest, but would give errors on the more rigorous test (MIDI errors reported on the screen, or non-termination due to a dropped input event). Newer M-Audio devices may perform better; let me know. I will gladly add data on additional MIDI interfaces when provided by users.
Schultz and van Vugt (2015) point out that the MIDI
input and output devices will add some latency to
data collection in FTAP; in particular, they provide data
that a Roland HPD15 Handsonic percussion pad adds
between 9 and 15 milliseconds of latency. They do
not report data on any other input devices.
On the other hand, Mills, van der Steen, Schultz,
and Keller(2015) (apparently the same Schultz)
report that the mean latency of the Roland Handsonic
10 percussion pad is less than 5 ms. Currently,
there is a dearth of concrete data on the latency
between tap and generation of the MIDI signal
on both MIDI percussion pads and MIDI keyboards,
as well as the latency between receipt of a MIDI
signal and sound production on a specific tone
generator (given that tone generators are purely
electronic, my intuition is that the latency will
be very low for a sharp-onset voice, but I have no
data). Like USB-MIDI interfaces, there is likely to
be a range of behavior.
(See Finney (2016a)
for additional discussion).
For now, I suggest not using
the Roland Handsonic HPD-15 pad (or any other device
that obviously misses and duplicates taps, as Schultz and van Vugt
reported of the HPD-15). I will gladly report
any data on the measured latency of specific MIDI input or output
devices on this web page. Unfortunately, making such
measurements is non-trivial, and I am not equipped to do it.
Benjamin Schultz and Floris van Vugt published a
Behavior Research Methods
claimed that FTAP had poor latency
(see the PubMed entry for
Schultz and van Vugt, 2015
which also includes a reply
comment from me. I made sure that
both Benjamin Schultz and Floris van Vugt were aware of this
comment, so their lack of response in PubMed suggests that they
have no arguments against my statements)
They arrived at their (Alternative Facts!) conclusion
by using a single input device that they knew to be flawed (a
percussion pad with
high latency that missed and duplicated user input) and then attributing
the percussion pad latency to the FTAP software package. Such confounding
of conditions (and the use of a known flawed device in a paper
purporting to do an objective technical comparison of
be grounds for rejection of a research paper.
However, the two manuscripts I submitted to correct their errors (e.g., their demonstrably false claim that USB-MIDI processing on a PC adds significant latency) were both rejected by the editor of Behavior Research Methods. You can read them and make your own evaluation.
My first submission provided a fair amount of background information about USB and MIDI devices, described FTAP's loop test, and tried to gently explain why Schultz and van Vugt's claims were incorrect. It also discussed why Linux continues to be a good operating system for millisecond-resolution data collection (addressing some of the concerns repeatedly raised in BRM by Richard Plant), and why MIDI is a good interface for sensorimotor experiments:
Finney(2016a) , "In defense of Linux, USB, and MIDI systems for sensorimotor experiments: A response to Schultz and van Vugt (2015)".
In response to the concerns raised by the editor (see below), I submitted a second, shorter manuscript that more directly addressed the factual errors, poor experimental design, and misleading claims in Schultz and van Vugt (2015). It was also rejected by BRM. Anyone who reads the Schultz and van Vugt paper should also read this manuscript:
Finney (2016b) , "Latency in sensorimotor synchronization experiments: Comments on Schultz and van Vugt (2015)".
My initial submission ( Finney, 2016a) attempted to follow the editor's suggestion to be constructive, and had 3 reviewers. One reviewer was strongly positive ("Its points regarding the precision and accuracy of the Linux-FTAP-USB/MIDI connection are all valid and worth publishing"), while a second reviewer (anonymous, but clearly Schultz and/or van Vugt) was strongly negative (reviewer 3 was somewhat neutral). The manuscript was rejected as "correcting only a potential minor misconception". The editor also raised concern about "the broader reach of the paper".
The shorter manuscript
that limited itself to correcting the factual errors
and misleading claims
in a published (and peer-reviewed)
was rejected without any
indication of textual review at all.
Schultz and van Vugt (2015)
suggest that their "Tap Arduino"
is an inexpensive replacement for FTAP, which it is not.
Tap Arduino is simply a button
box that needs to be attached to a PC system to run any experiments
at all, while an FTAP-MIDI system handles everything
except the physical input and output devices.
SVV provide no data that
a complete experimental
system using "Tap Arduino" has millisecond timing accuracy,
and explicitly note (p 11) that this is an
unresolved problem that may require "expensive options...for synchronizing
responses and stimuli".
A validated Arduino device with a MIDI interface that could be attached to FTAP or MAX would be a useful contribution; unfortunately, Tap Arduino is not that device.
The claim that an FTAP-MIDI system (see definition above, and
Figure 2 below) has
millisecond accuracy and
precision may surprise those who are aware of the potential issues
with a multi-tasking operating system such as Linux, or who have
read Schultz and van Vugt (2015). However, this was established
in 2001 on a 200 MHz Pentium running Redhat 6.1 (see
and it is no less true on a 2016 vintage PC with a 2 GHz
multi-core processor running a contemporary version of Linux
(I'm using Ubuntu 14.04). For the skeptic, I will detail the
argument here; see also
First, it is necessary to establish that the clock that FTAP uses to timestamp input and schedule output (the Linux "gettimeofday" system call) is accurate and precise at well below the millisecond level. This was established in Finney (2001b) using a set of simple C programs; these are included with the FTAP release in the "utils/gettod_test" directory. As shown in Finney (2001b), and as can be easily re-verified in 2016, this clock has resolution and accuracy at a little over 1 micro-second (since this clock is usually based on the same hardware clock that drives the multi-GHz processor, the accuracy is not surprising). FTAP uses these clock values as offsets from a fixed starting time, so the relation of the system clock to external time (e.g., UTC or whatever) is not important. Therefore, the millisecond times that FTAP uses (and reports in the output file) can be accepted as accurate and precise.
Second, it is necessary to run (and understand) what the supplied "looptest" parameter file is doing (this would be clearer with a diagram, but I don't have the resources for that right now; see Finney (2001b) and Finney (2016a) for further discussion). Because the connectors used for both MIDI input and output are identical, and because the MIDI message format for both input and output is identical, it is possible to connect the MIDI output back to the MIDI input using a cable or connector; by doing this, FTAP's output "tone" messages immediately reappear as "keystroke" messages. Since one of FTAP's most basic capabilities is providing synchronous feedback to keystrokes, it is possible to immediately send the received "keystroke" event back out as a "feedback" event. As a result, a single initial "output" event will be cycled through the system indefinitely. There are any number of possible sources for delay in this system: e.g., scheduling preemption in a multi-tasking operating system, hardware issues with the MIDI interface, or driver issues. Any of these issues, if important for millisecond resolution, will show up as delays in the output file of the "looptest".
However, if events (both input and output) are processed consistently once a millisecond (1000 events per second simultaneously on input and output), then FTAP can be claimed to be both precise and accurate at the millisecond level (note that the maximum hardware speed of MIDI transmission is 1,040 events per second, so it is not possible to go any faster than that). Finney (2001b) demonstrated that FTAP achieved this goal 15 years ago, and Schultz and van Vugt(2015) and Finney (2016a) both report that this was achieved in a more contemporary configuration. Further confirmation is provided in the USB-MIDI test results reported in the Configuration section above. Any FTAP user is required to perform this test on their configuration, as some MIDI interfaces may not work properly. Those who are concerned about validating with an external time reference can simply use a stopwatch to time the loop test.
I know of no other system for sensorimotor experiments that has been shown to pass such a rigorous test.
FTAP has been a one-person project (me!). It is a fairly complex program, but one that I thought was of enough potential general use to be worth making public. I think it does a lot of stuff that no existing programs do (and some manuscript reviewers have expressed the same opinion), but I have discovered there is a huge gap between a useful program that the programmer can use and a program for public distribution. Two particular concerns:
I would like to give a big "Thank you!" to Caroline Palmer and members of her lab, and to Pete Pfordesher, for both moral and logistical support (particularly in 2016). (An earlier postdoc with Caroline also enabled the initial FTAP port from SGI to Linux). I would also like to thank Clemens Maidhof for his published and GPL'd modifications to FTAP (Maidhof et al, 2014). Finally, I'm pleased to thank Saul Sternberg (who describes himself as an "enthusiastic FTAP user") for his ongoing assistance and encouragement, particularly with respect to trying to get a BRM correction published in 2016.