[PD] big [hid] changes...

[Jerome Tuncer]

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 at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
> 
>