Infinity Foodpedal External for Pd

pd patch

pedal top

pedal bottom

pedal angle

Description

Features:

• Lightweight -- pd external, once installed, requires no external software.
• Free and open source.
• More than once Pd object instance per physical device. Sometimes it's just convenient to have more than one instance rather than dispatching from a single source. Well, this external supports that. A single thread will dispatch to all Pd [infinity-pedal] instances.

How to build:

• Ensure that you have libhidapi-dev and libhidapi-libusb0 library packages installed:
  $ sudo apt-get install libhidapi-dev libhidapi-libusb0
• Clone the repo from git:  
  $ git clone https://github.com/breedx2/infinity-footpedal.git
• cd to the directory:
  $ cd infinity-footpedal
• if your m_pd.h isn't in /usr/local/include, edit the Makefile and correct the INCLUDES line.
• invoke make:
  $ make
• If all goes well you'll have a infinity_pedal.pd_linux sitting there.
• Copy infinity_pedal.pd_linux and the help patch infinity_pedal.pd_linux to somewhere in your pd external path. Like:
  $ sudo cp infinity_pedal.pd_linux infinity_pedal.pd_linux /usr/local/lib/pd/external/

Note: I've discovered that libc < 2.9 may complain about pipe2(). If so, edit infinity_pedal.c and change:
pipe2(pfd, O_NONBLOCK);
to:
pipe(pfd);
or better still, give me a patch that solves this at build-time. :)

Troubleshooting

If you have difficulty, first make sure the device shows up in lsusb:

Bus 001 Device 005: ID 05f3:00ff PI Engineering, Inc.

If it does, at least the pedal is recognized. You can then try the readpedal program (included) to troubleshoot. Make sure your permissions are correct and that you can read the device. If readpedal works but Pd can't find it, make sure that your Pd path is correct and the binary external has been installed.

How does it work?

The quick and dirty explanation (or the code speaks for itself):

The first instance of [infinity_pedal] causes a thread to be started. This thread performs blocking reads on the device, specified as the first creation argument. Subsequent instances of the [infinity_pedal] are simply registered in the list of objects to be dispatched. When pedal data is available from the reading thread, it sends outputs to the outlets of each of the registered Pd objects. Only those outlets whose state has changed will have data sent to them. A mutex is used in order to protect the list of registered Pd objects from changing while the pedal state is being dispatched. When the final Pd object instance has been deleted, the reading thread is sent a message (via pipe) to terminate.

More

Like all software projects, this one has its shortcomings:

• Linux only. Likely to work on OSX, please let me know what you find out!
• Does not currently support more than one pedal at a time. This would be a little bit of work, but I don't have more than one pedal to try it with anyway. If you send me one I'll make it work. :)
• Changing the device at runtime is not possible. This is probably a bogus use case anyway, unless your udev is doing something odd an you're replugging the pedal a lot. Most users can just use the udev rule and hard-code the path.
• The libhidapi rewrite in 2014 introduced a busy-wait loop and, while still efficient, is not purely event/interrupt driven.  Shame that the libhidapi doesn't have an event/callback api?

And credit/mention is required for the following resources/links:

• http://code.google.com/p/footpedal/ - Python project used to read the pedal. The code here borrows heavily from that project. I wouldn't have known how to read the pedal otherwise -- so thanks!!
• http://www.jinvoke.com/USB-hardware-access-from-Java I didn't really peek at the source, and there are a lot of Winshit screenshots, but maybe if you're doing something creative with the pedal from Java (Processing anyone?), it might be a useful resource.

If you'd like to contribute to this project and make it more better, please fork the repo and submit a pull request...or contact me!