So my bruising experience of porting [hid] to Windows has lead me to
a new approach for [hid] on all platforms. Currently, as it is now,
[hid] is not a HID API, but really an input API like the Linux input
API. I think it is useful to have a real USB HID API as well as a
Linux-style input API within Pd, so I plan on changing things in a
big way to support this, and I wanted to get some feedback on the
ideas before forging ahead, especially considering that none of this
will be backwards compatible with [hid] (though the input-style API
will be very similar and based on the same code).
First off, [hid] will become a Pd object version of libhid, so it'll
be a regular USB HID API, but with some Pd-style specifics. Yes,
there is some pain to this conversion, but I think we'll all be
better off in the long run. I hope to make a corresponding [usb]
object based on libusb which can be used in conjunction with the new
[hid]. This will be a much more flexible approach, but there is
still much design work and research to be done before I know how
feasible it is.
Second, what is now [hid] will be renamed and I'll implement some
biggish changes that I have been meaning to do which are not
backwards compatible. The idea for the new object is to fully
embrace the idea of the Linux-input-style abstraction layer. I am
not sure whether this should be a separate object with its own C
code, or whether it should also be based on [usb] and [hid]. Then
the existing [joystick], [mouse], [tablet], [gamepad], etc. objects
will be based on this new object and _will_ be backwards compatible.
So only more advanced users of the [hid] objects will be affected.
But the first step is to find a name for this new object. I have
been thinking either [human->pd] or [you->pd] to highlight that its
meant for getting data from people into Pd. Plus I think that "->"
makes a nice conversion symbol.
Ideas, thoughts, criticisms, comments are all welcomed and are in
fact what I am after.
.hc
If you are not part of the solution, you are part of the problem.
-
Eldridge Cleaver
i never really had a chance to use it on os x , cos it was prone to crashing. .... hopefully the new code will fix that up a bit.
good luck hans.
Hi HC,
I'm very interested in the [hid] object's future development. As it basically allows virtually any computer peripheral to become an interface for musical expression (I enjoy practicing graphtablet music myself, as u know (-:).
Nervertheless, being no coder myself, I don't understand everything you say about the changes that are going to occur.
What I understand is:
A Linux-style input API sort of includes USB/HID input.
USB/HID is a more specific kind of input system.
You'd like to code a USB/HID specific input for Pd
Correct me if I'm wrong.
As far as I'm concerned, backwards compatibility is not a real issue. I can re-patch the stuff... I like it (-:
++
Jé
Hans-Christoph Steiner a écrit :
So my bruising experience of porting [hid] to Windows has lead me to a new approach for [hid] on all platforms. Currently, as it is now,
[hid] is not a HID API, but really an input API like the Linux input
API. I think it is useful to have a real USB HID API as well as a
Linux-style input API within Pd, so I plan on changing things in a big way to support this, and I wanted to get some feedback on the ideas before forging ahead, especially considering that none of this will be backwards compatible with [hid] (though the input-style API will be very similar and based on the same code).First off, [hid] will become a Pd object version of libhid, so it'll be a regular USB HID API, but with some Pd-style specifics. Yes, there is some pain to this conversion, but I think we'll all be better off in the long run. I hope to make a corresponding [usb] object based on libusb which can be used in conjunction with the new [hid]. This will be a much more flexible approach, but there is still much design work and research to be done before I know how feasible it is.
Second, what is now [hid] will be renamed and I'll implement some
biggish changes that I have been meaning to do which are not backwards compatible. The idea for the new object is to fully embrace the idea of the Linux-input-style abstraction layer. I am not sure whether this should be a separate object with its own C code, or whether it should also be based on [usb] and [hid]. Then the existing [joystick], [mouse], [tablet], [gamepad], etc. objects will be based on this new object and _will_ be backwards compatible. So only more advanced users of the [hid] objects will be affected.But the first step is to find a name for this new object. I have been thinking either [human->pd] or [you->pd] to highlight that its meant for getting data from people into Pd. Plus I think that "->" makes a nice conversion symbol.
Ideas, thoughts, criticisms, comments are all welcomed and are in fact what I am after.
.hc
If you are not part of the solution, you are part of the problem. -
Eldridge Cleaver
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Hans-Christoph Steiner -
hard off -
Jerome Tuncer