[PD] HID APIs and PlayStation Move LED support

[Mikael Bouillot]

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)

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Threading in Pd/libpd

[Giulio Moro via Pd-list]

It looks like I am not very lucky in getting attention, so let me try to re-up 
this. Can we implement a threaded [block~] ? see details below


 
  From: Giulio Moro 
 To: Pd-List  
 Sent: Sunday, 18 September 2016, 2:23
 Subject: Threading in Pd/libpd
   
Hi all,if I understand correctly, using the [block~] and [switch~] objects to 
increase the blocksize for a given subpatch, means that the DSP computation for 
that subpatch is delayed until the moment when enough input samples have been 
collected, at which point the entire DSP stack for the subpatch is performed at 
once and the outputs are written to the output buffer.This means that the DSP 
load is not spread over time, rather it is concentrated in that single audio 
driver callback when the buffer for that subpatch happens to be ready to be 
processed.
Now, if what I say makes sense, then this approach has the disadvantage that 
the CPU load is not spread evenly across audio callbacks, eventually causing 
dropouts if whatever computation takes too long in that one callback, forcing 
you to increase the internal buffering of Pd (``Delay'') to cope with this. At 
the same time, though, the CPU will be pretty much idle in all the other audio 
callbacks.
If we could spread the load of the expensive, but occasional, computation (say 
fft) over multiple audio callbacks, then the CPU load would be more even, with 
no spikes and there would be no need to increase Pd's internal buffering.This 
would require to have the output of the fft available a few processing blocks 
after the one where it was started, while the current approach allows to have 
it immediately available. A fine tuning of the system would be required to 
understand how much this latency should be, and worst case it would be the 
number of overlap samples as set by [block~] (as in: if the system cannot 
process these blocks fast enough, then you should lower your requirements, as 
your system cannot provide the required throughput). Now this may seem a 
downside, but the actual overall roundtrip latency of the Pd subpatch would be 
not much larger than the one currently achievable (if at all larger), with the 
added advantage that the rest of Pd could work at smaller blocksizes, and with 
a ``Delay'' set to 0.The ultimate advantage would be to have a more responsive 
system, in terms of I/O roundtrip for most of the patch, except those 
subpatches where a longer latency is anyhow imposed by the algorithm. Think for 
instance of having a patch processing the live the sound of an instrument, 
which also uses [sigmund~] to detect its pitch to apply some adaptive effect. A 
low roundtrip latency could be used for the processed instrument while the 
latency imposed by [sigmund~] would only affect e.g.: the parameters of the 
effect. I see how this approach may be useful in many cases.Multi-core hardware 
would take extra advantage from this way of spreading the CPU usage.
I am in the situation where I hacked together a threaded version of [sigmund~] 
for use with libpd on Bela which works fine and I am wondering if it is worth 
going down the route of making threaded versions of all objects with similar 
requirements (which I really would not want to do) or I should rather try to 
create some higher-level objects (say [blockThread~] ) that perform the 
threading strategy mentioned above.It may be that [pd~] could probably(?) 
provide the solution requested, but it seems to me there is lots of overhead 
associated with it, and I do not see how to easily integrate it with our use of 
libpd.
So, probably this point has been discussed previously, I'd like to know:- are 
there any existing objects doing this already?- what are the pitfalls that 
prevented such an approach from making its way into Pd?- how can I help?
Best,Giulio   
 ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] PdParty Release Candidate 1

[Dan Wilcox]

Howdy all,

I’m please to announce that PdParty version 0.5.6 is out to beta testers. It’s 
considered Release Candidate 1, so please test fit and finish towards a full 
release on the App Store. I’ve been using it for a number of things the last 
couple of months and feel that it’s pretty much ready to go.

Also, I actually finished version 0.5.5 in August but forgot to send it out to 
testers. Whoops! The major changes were replacing CocoaOSC with liblo 
(increased performance), usability improvements, & bug fixes. All changes are 
listed in the change log: 
https://github.com/danomatika/PdParty/blob/master/CHANGES.txt 




Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Tcl error for [knob] and [mknob]

[Christof Ressi]

Thanks for your efforts! I'm willing to test and I've already tried to compile 
but got a few errors. I posted the results on your repository (spacechild1). 
Let's continue there.

Christof
 
 

Gesendet: Montag, 26. September 2016 um 00:16 Uhr
Von: "Antoine Rousseau" 
An: pd-list 
Betreff: Re: [PD] Tcl error for [knob] and [mknob]

ok, seems resolved now !But I had to use some tricks about dynamic symbol 
resolution, that should be tested on windows. Any volunteer ?.. 
(https://github.com/MetaluNet/moonlib)

 
 
2016-09-25 21:13 GMT+02:00 Antoine Rousseau 
:
the pd version is only known at runtime.yes that's the point.
I'm looking for a kind of dlsym() working for already loaded symbols.

 
2016-09-25 20:02 GMT+02:00 Christof Ressi 
:Because in his case, the pd 
version is only known at runtime.

> Gesendet: Sonntag, 25. September 2016 um 19:21 Uhr
> Von: "patrice colet" 
> An: pd-list@lists.iem.at[pd-list@lists.iem.at]
> Betreff: Re: [PD] Tcl error for [knob] and [mknob]
>

> Hello,
>
>   why not using preprocessor expression like
>
> #if PD_MINOR_VERSION < 47
>
> ...
> iemgui_all_loadcolors();
>
> ...
>
> #endif
>
> ?
>
> Le 25/09/2016 à 16:25, Antoine Rousseau a écrit :
> > Hi all
> >
> > in order to try making a mknob that would be compatible with any Pd
> > version, I still have a problem, with a function that didn't exist
> > prior to 0.47 (iemgui_all_loadcolors). Would someone have an idea to
> > "hide" the call of this function when linked by an older version of Pd?
> >
> > Anyway I now have a version of mknob that is working with 0.47. I'll
> > push it soon.
> >
> >
> > 2016-09-24 5:16 GMT+02:00 Billy Stiltner 
> >  > >:
> >
> >
> >         while on the subject subject of knobs, would be great to hav
> >         option for integer snapping
> >
> >     its easy to do with a few objects in  a patch
> >
> >     ___
> >     Pd-list@lists.iem.at[Pd-list@lists.iem.at] 
> > mailing list
> >     UNSUBSCRIBE and account-management ->
> >     
> >https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
> >     
> >
> >
> >
> >
> >
> > --
> > Antoine Rousseau
> > http://www.metalu.net[http://www.metalu.net] 
> >  __
> > http://www.metaluachahuter.com/[http://www.metaluachahuter.com/]
> > 
> >
> >
> >
> > ___
> > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>
> --
> Patrice Colet
> fr: 0632660357
>
>
> ___
> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>

___
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]


--

Antoine Rousseau 
  http://www.metalu.net[http://metalu.net] __ 
http://www.metaluachahuter.com/[http://www.metaluachahuter.com/compagnies/al1-ant1/]
 


--

Antoine Rousseau 
  http://www.metalu.net[http://metalu.net] __ 
http://www.metaluachahuter.com/[http://www.metaluachahuter.com/compagnies/al1-ant1/]
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list