[L2Ork-dev] hello, and a request for mentoring for a simple add-on

[Jonathan Wilkes]

> Hi people!
> I have been watching the Pd-l2ork and Purr-Data projects for a while with much interest, and decided to finally give a shot at contributing to the project. I have some experience coding externals for Pd, from previous projects with art installations and my personal interests, and have read up on some of the changes (mainly regarding GUI) that happened when switching from Tk to NW.js.

> My intention is to make an object to make use of the Gamepad API present in Chromium (https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API) in a similar fashion to the [hid] and [hidin] objects, for Linux/OSX and Windows respectively. From reading up pd/nw/pdgui.js and the uses of gui_vmess() I get the sensation that I could just have a set of callbacks in pdgui.js that hook to the gamepad* events in javascript, and those hooks by themselves send data to the class object using pdsend(). Would that be the recommended approach?

Hi Tiago,That's an interesting idea-- I was just looking at the gamepad api and thinking it would be nice to have an interface 
that leverages that in Purr Data.
A couple of caveats to begin with:1. Such an external wouldn't work in -nogui mode. I can imagine some other web apis (like bluetooth) which 
would similarly have such a restriction.
2. To have a usable interface, you won't be able to query the state of the controller by sending a method to 
your gamepad class. For example, the hid object has [info(--[hid] which outputs a message to its right outlet. 
But if you have to send a message to the GUI and wait for a response in order to get that info, the output 
won't appear at the outlet in a predictable manner. Consequently a user might try to store that info in a list and 
trigger it in another part of the patch, and get surprised at an empty list because the response didn't arrive in 
zero logical time.
On the other hand, I *think* you can get away with changing gamepad state (like polling rate) using the object's 
methods. My assumption is that the user/patch author would either be setting the polling rate once, or throttling it 
in a way that doesn't require block- or sample-accurate synchronization between such controller state changes and 
Pd's clock.

I'm guessing the big benefit here would be that the API is compatible with all three of Pd's platforms-- OSX, 
Windows, and Linux-- while [hid] doesn't work on Windows. Do you know if there are other benefits to this API 
over [hid]?  I haven't gotten a chance to play around with it yet.

-Jonathan

> Cheers,
> Tiago Rezende



   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/l2ork-dev/attachments/20170802/3871831e/attachment-0001.html>