Dear list,
I am trying to bring my knowledge of hid-related objects up to date for all three OSes.
On Linux I can install [hid] 0.7 via Deken and use it as a normal user as a member of the 'input' users group.
On Linux I can install [hidraw] 0.1.0 via Deken. The external loads without errors, but I am not getting any response clicking the "listdevices" message.
On OS X there is [hid] 0.7.3 thanks to Albert. Colleagues have tried to find [hid] for their newer apple cpu's without success unless they start Pd under the Rosetta emulation and install Albert's amd64-32 package. Interestingly there exists a hid Deken package for Darwin-arm64-32 http://deken.puredata.info/library/hid/0.1.0 but it is not displayed in Pd's built-in search engine on OS X as far as I can remember (maybe someone can check this?).
On Windows there is only [hidraw], correct?
General question: What would be a reason to prefer [hidraw] over [hid]? How do I parse the output of [hidraw]?
Thank you for any replies! best, Peter
On 12/03/2024 13:45, Peter P. wrote:
On Linux I can install [hidraw] 0.1.0 via Deken. The external loads without errors, but I am not getting any response clicking the "listdevices" message.
### about [hidraw] ###
strange "listdevices" works for me on Debian (10, 11, 12). Perhaps you tested it on a machine without any HID compatible device?.
note that to use the devices you must be a "member of the 'input' users
group" (or if you want a quick test run Pd as root via sudo pd
).
How do I parse the output of [hidraw]?
the help patch is plain simple. [hidraw] just outputs a list of floats.
Windows: for OS's security measures you can't access any 'mouse' or 'keyboard' (gamepads or joysticks will work out-of-the-box).
in general: [hidraw] is rather simple and raw compared to eg. [hidio]. you might find [hidraw] unsuitable for your purposes.
###############
On Windows there is only [hidraw], correct?
there is also [hidio] https://deken.puredata.info/results.html?name=hidio by Martin Peach.
--
Mensaje telepatico asistido por maquinas.
Dear Peter & all,
On Linux I can install [hidraw] 0.1.0 via Deken. The external loads without errors, but I am not getting any response clicking the "listdevices" message.
As Lucas reported in the other thread, this works just fine for me. (Do
you see any USB devices, HID or not, when you lsusb -v
on the command
line?)
Colleagues have tried to find [hid] for their newer apple cpu's without success unless they start Pd under the Rosetta emulation and install Albert's amd64-32 package.
Good to know, and sorry for making you depend on Rosetta. I don't have much time to finally get the build system for [hid] updated, nor have access to Apple Silicon. Some kind soul on this list even offered to compile things for me -- I've gotten nowhere with the required thinking and coding since, I apologize!
Interestingly there exists a hid Deken package for Darwin-arm64-32 http://deken.puredata.info/library/hid/0.1.0 but it is not displayed in Pd's built-in search engine on OS X as far as I can remember (maybe someone can check this?).
Deken on pd 0.52.1 (a self-built version IIRC) on Linux, when configured to *not* hide packages for foreign platforms, gives me this:
hidv0.1.0.dek Uploaded by critapec @ 2022-11-09 00:32:28
On Windows there is only [hidraw], correct?
At least there is no [hid]. The sources and makefile include mentions of "cygwin", but I don't have a Windows machine either. Even if I could build it with mingw, I couldn't test.
General question: What would be a reason to prefer [hidraw] over [hid]?
Quoting a previous thread on this list, https://lists.puredata.info/pipermail/pd-list/2022-11/131618.html
""" My comparison AFAICT (from working on [hid] a little [...]):
[hidraw]
event codes that you process in your patch yourself, whereas [hid] decodes many of the possible button presses and other events
only uses OS functions and headers iirc """
The mail goes on to suggest the creation of a wiki page "or other documentation item [...] listing the different possibilities of working with USB HID devices in Pd."
I sat down and tried my hand at this, what do you think? https://puredata.info/Members/albert/USB
Suggestions welcome, both content-wise and in terms where to best put this.
How do I parse the output of [hidraw]?
My own dabblings with [hidraw] have followed this approximate path:
.... will send
control lines.
Best regards, Albert.
On 13/03/2024 04:11, Albert Rafetseder wrote:
I sat down and tried my hand at this, what do you think? https://puredata.info/Members/albert/USB Suggestions welcome, both content-wise and in terms where to best put this.
cool.
May be you can link it in https://puredata.info/docs/articles ?
there is https://deken.puredata.info/results.html?name=hidio . This was the only version that worked for Windows. Martin had make it using pd-lib-builder (sources are in the deken pkg). I think he knew it would work on Linux and Mac because it used to. The nice thing is that you can send stuff to the HID (though i never even attempted to do so). My list is rather full for the upcoming days but may be you can tell if it builds on Linux? and that all is working? then we can ask somebody for a macOS build and test?
Then we can have a repo. I don't have superpowers on https://github.com/pd-externals but may be we can move it there to keep it alive. or somewhere else. I think it's the only way to have Windows to "decodes many of the possible button presses and other events" which somebody might need in the salad bar.
--
Mensaje telepatico asistido por maquinas.
Dear Albert, Lucas, list,
Dear Peter & all,
On Linux I can install [hidraw] 0.1.0 via Deken. The external loads without errors, but I am not getting any response clicking the "listdevices" message.
As Lucas reported in the other thread, this works just fine for me. (Do you see any USB devices, HID or not, when you
lsusb -v
on the command line?)
Yes, I see three HIDs amongst other usb devices.
I just found the problem: /dev/hidraw* were not assigned to the 'input' user group I am a member of. Now I just have to check if these permissions are persistent across reboots.
I didn't recongnize this as the source of my problem since [hid] uses /dev/input/* paths, which had the correct permissions already.
Colleagues have tried to find [hid] for their newer apple cpu's without success unless they start Pd under the Rosetta emulation and install Albert's amd64-32 package.
Good to know, and sorry for making you depend on Rosetta. I don't have much time to finally get the build system for [hid] updated, nor have access to Apple Silicon. Some kind soul on this list even offered to compile things for me -- I've gotten nowhere with the required thinking and coding since, I apologize!
No worries!
Interestingly there exists a hid Deken package for Darwin-arm64-32 http://deken.puredata.info/library/hid/0.1.0 but it is not displayed in Pd's built-in search engine on OS X as far as I can remember (maybe someone can check this?).
Deken on pd 0.52.1 (a self-built version IIRC) on Linux, when configured to *not* hide packages for foreign platforms, gives me this:
hidv0.1.0.dek Uploaded by critapec @ 2022-11-09 00:32:28
Yes, that's the package I was referring to. Did anyone install and use it on Mac M1 cpu's natively?
On Windows there is only [hidraw], correct?
At least there is no [hid]. The sources and makefile include mentions of "cygwin", but I don't have a Windows machine either. Even if I could build it with mingw, I couldn't test.
I just found out that there is also [hidio] for Windows by Martin Peach, which should get mentioned in the wiki page kindly created by Albert at https://puredata.info/Members/albert/USB
Excellent page Albert, thank you!
[hidio] also got compiled for Mac it seems: https://github.com/Benitoite/hidio forked from https://puredata.info/downloads/hidio
I think it should include some info about setting permissions (permanently) as well as a hint to security issues when logging keypresses all the time.
That page could furthermore include information about the [key] objects to only report key presses when Pd has the focus, and that automatic key repeats from the OS might be a major hindrance for certain cases (such as mimicing an organ keyboard). On Linux I it can be disabled using 'xset r off'. [hid] and/or [hidraw] might be able to circumvent this issue.
Btw, Gem offers [gemmouse], and there are certain 2D mousable canvas abstractins flying around the Pd world.
best, Peter
Hello
Le 13 mars 2024 à 08:11, Albert Rafetseder albert.rafetseder@univie.ac.at a écrit :
Interestingly there exists a hid Deken package for Darwin-arm64-32 http://deken.puredata.info/library/hid/0.1.0 but it is not displayed in Pd's built-in search engine on OS X as far as I can remember (maybe someone can check this?).
Deken on pd 0.52.1 (a self-built version IIRC) on Linux, when configured to *not* hide packages for foreign platforms, gives me this:
hidv0.1.0.dek Uploaded by critapec @ 2022-11-09 00:32:28
This version have been uploaded this week after seing this thread, that explains why it didn't appear yet, meanwhile I don't get why the date is 2022.
It has been compiled without using xcode project, from last hid version 0.7 sources, but I'm not sure that it works exactly the same, that's why version is 0.1.0
Are you allright with this?
I'm calling pd users using apple silicon to try if this works good on their computer.
This version also doesn't provide sources and Makefile, but it should in next version.
cheers
On 3/14/24 10:57, Patko nytkophilus wrote:
This version have been uploaded this week after seing this thread, that explains why it didn't appear yet, meanwhile I don't get why the date is 2022.
i do not really know.
however, inspecting the deken package with my trusted zipinfo
, i see
that the files within are also timestamped 2022-11-09:
$ zipinfo hid\[v0.1.0\]\(Darwin-arm64-32\).dek
Archive: hid[v0.1.0](Darwin-arm64-32).dek
Zip file size: 12879 bytes, number of entries: 2
-rw-r--r-- 2.0 unx 2690 b- defN 22-Nov-09 00:09 hid/hid-example.pd
-rw-r--r-- 2.0 unx 71386 b- defN 22-Nov-09 00:20 hid/hid.pd_darwin
2 files, 74076 bytes uncompressed, 12635 bytes compressed: 82.9%
the the .dek files are served as-uploaded, so i suspect that the wrongish timestamp comes from the computer that created the package.
gfamdsr IOhannes