Hello list,
I need to get access to a PlayStation Move Motion Controller [1] from Pure Data. All inputs (buttons & sensors) and outputs (LEDs & rumble) should be accessible. Basically, I need the equivalent of the [pd-wiimote] object, but for the psmove.
I have spent the last few days exploring the various libraries, drivers and APIs that relate to my problem, but now I need some help to make sense of it all.
First, I'm on Linux. So I connected the controller by bluetooth, and after loading the hid-sony kernel module, I got my input devices (/dev/input/jsX and /dev/input/eventX). I found out that LED support for the Move controller was added in kernel 4.2, so I upgraded my kernel.
I then tried accessing it with [hid], and it worked fine but only for inputs. The doc says "For those interested in output support, checkout the alpha [hidio]", so I tried that next, but I couldn't seem to find the LED controls on my device.
That's when I realized what's wrong:
First, both [hid] and [hidio] use the Linux input API as backend ("evdev"), rather than the lower-level "hiddev" or "hidraw" APIs. Basically, that means that *all* communication from PD to the device *must* pass through the hid-sony driver.
Second, the hid-sony driver doesn't seem to expose the LEDs through the evdev API. Instead, what it does is register the LEDs through the Linux LED subsystem (with led_classdev_register(), accessible through /sys/class/leds/*). That's why I wasn't seeing any LEDs on my device with [hidio].
Third, even if the hid-sony driver *did* expose the LEDs through the evdev API, this API only supports binary (on/off) LEDs, not variable brightness ones like on the Move controller.
The net effect of this is that it's effectively impossible to control my LEDs using [hidio]. I did write a quick hack to control the LEDs through /dev/class/leds and it worked fine, but that's not a realistic option: I would like the whole device to be controlled through a single object.
So here I am, wondering what to do next:
a) I could use the existing [hidio] to get inputs and control force-feedback, but I would then need a second object to control the LEDs, b) I could write a dedicated object ("pd-psmove") that would bind to a low-level API (hidraw) and get me all that I need but would much less general, c) or I could write a general input interface ("pd-hidraw") that would provide lower-level access to the HID stack than [hid] or [hidraw].
I have read the hidio paper [2], but that doesn't seem to address my main problem of being restricted by the limitations of the chosen backend. I would very much appreciate any suggestion, especially from the hidio authors.
Thanks in advance,
Mikael
[1] https://en.wikipedia.org/wiki/PlayStation_Move#Motion_controller [2] A Unified Toolkit for Accessing Human Interface Devices in Pure Data and Max/MSP (http://alumni.media.mit.edu/~dmerrill/publications/dmerrill_NIME07-HID.pdf)
On 2016-09-26 13:46, Mikael Bouillot wrote:
I would like the whole device to be controlled through a single object.
may i ask why?
(e.g. Pd offers two distinct objects to read and write samples from your soundcard ([adc~] and [dac~]) and this seems to work for most people :-))
fgmasd IOhannes
On Tue, Sep 27, 2016 at 09:57:33AM +0200, IOhannes m zmoelnig wrote:
I would like the whole device to be controlled through a single object.
may i ask why?
Well, the controller is a single physical device and as such, it feels like it should be represented by a single object in Pd. For example, I could need to connect four controllers at once, and I would like each to be represented by its own object.
Also, each object needs its own context (the connection to the device), so for a single device, the [in] and [out] objects would need to share that context. Otherwise, I would need to connect each [in] and [out] separately.
(e.g. Pd offers two distinct objects to read and write samples from your soundcard ([adc~] and [dac~]) and this seems to work for most people :-))
Well, that's true, but in my case it's a bit uglier than that: not only would I have two distinct objects, but each would be in its own distinct module.
The [in] object would be an instance of [hid] (or [hidio]) and the [out] object would be from a new external dedicated to controlling LEDs on Linux. Because of this, it would require each input and output to be configured separately.
From a usability standpoint that's probably not going to fly with my client,
but I'll give him a demo tomorrow and we'll see how it goes from here.
On 09/27/2016 12:47 PM, Mikael Bouillot wrote:
I would like the whole device to be controlled through a single object.
may i ask why?
Well, the controller is a single physical device and as such, it feels like it should be represented by a single object in Pd.
this might sound obvious, but in case it is not: you can use abstractions to form semantic groups (e.g. a single "object" to represent a single device)
whether the actual communication with the device's functionality is handled by one or multiple low level objects is an implementation detail.
gfmards IOhannes
-
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Mikael Bouillot