[PD-dev] making a libusb object (expanding on [hid] toolkit)

[Hans-Christoph Steiner]

On Jan 20, 2006, at 1:15 PM, Christian Klippel wrote:

> hi all,
>
> Am Freitag 20 Januar 2006 06:37 schrieb Hans-Christoph Steiner:
>> On Jan 19, 2006, at 7:21 PM, B. Bogart wrote:
>>> Hans-Christoph Steiner wrote:
>>>> Then just like how [mouse], [joystick], [keyboard], etc. are Pd
>>>> objects
>>>> based on [hid], there will be [multio], [arduino], etc. which will  
>>>> be
>>>> Pd objects based on [usb], [serial], etc.
>>>
>>> Hey Hans,
>>>
>>> I would really urge you to forget the IO specific objects, unless
>>> unifing them is impossible. I think [hardware/analog] and
>>> [hardware/digital] would make a lot more sense and possible allow
>>> patches made for multiIO analog in to work on arduino as well...
>>>
>>> If they *have* to be different then they should have the same  
>>> interface
>>> (accept the same messages).
>>>
>
> yea, good idea, but impossible to do. you can be sure that whatever  
> interface
> you take, it will send its data in a different way. each unit has  
> different
> resolutions, different amounts of i/o, and for that reason, a different
> protocol.
>
> even just saying "let make a general hid object for hid-speaking  
> devices" is
> almost impossible. just because something talks hid, it doesnt mean it  
> sends
> the data in the same format .....
>
>>> I think the use of those objects will really take off, so its best to
>>> do
>>> it right first. Also the names of the projects may change, they may
>>> die,
>>> but to have a standard way to interface with (analog in/out and  
>>> digital
>>> in/out, maybe PWM as well) would be the best way, and new HW projects
>>> could be added in the future...
>>
>> I was thinking of trying to have an generic objects as possible.  For
>> example for [hid], I was thinking of maybe [axis] and [button].  My
>> original intention was to make general interface objects for things
>> like arduino and multio, but I think that they might be two different
>> to be able to do this well, especially if you throw in the MIDI-based
>> ones like the miditron.
>>
>
> what about doing that in 2 pieces? one object/abstraction specific for  
> the
> used device, which in turn "translates" the messages to a uniform  
> format,
> refering to uniform id's for stuff like axes, buttons, etc....
>
> this is neccesarry because of the differencies in the devices. it is  
> even
> possible that you take two different joysticks, and both pack their  
> messages
> in completely different ways: one could put all info in just one
> report-descriptor, the other may use serveral of them, or even one for  
> each
> axis/button.

So far, from my experience, these kinds of differences are totally  
obscured in the combo of the [hid] object inside of the [joystick]  
object.  I suppose it would affect the order in which the data comes  
out.  But the [joystick] object works for all of the different  
joysticks I tried.  Mostly, the issue I have seen is that manufacturers  
choose different, often non-standard, element types for their devices.

For example, a joystick's twist should be "Rz" type in the "Generic  
Desktop" page, but sometimes joysticks label it "Rudder" in the  
"Simulation" page.  Or the throttle should be "Slider" in the "Generic  
Desktop" page, but sometimes its "Throttle" in the "Simulation" page.

(FYI: I say joysticks should be using only the "Generic Desktop" page  
because the "Joystick" type is also in the "Generic Desktop" page.  The  
"Simulation" page was intended for more complicated devices intended to  
model specific situations like "SailingSimulationDevice" or  
"HelicopterSimulationDevice".

But this makes me wonder... with [hid], I used the Linux input event  
scheme, which is not USB HID, but close.  Its much cleaner, but I  
wonder if there is possibility for confusion in a substantial way?

.hc



> then, general-purpose objects to handle stuff like mice, joysticks,
> interfaces, etc... in a way that is usefull for them. "user-patches"  
> should
> only access the uniform interface or the general-purpose objects.



________________________________________________________________________ 
____

"Terrorism is not an enemy.  It cannot be defeated.  It's a tactic.   
It's about as sensible to say we declare war on night attacks and  
expect we're going to win that war.  We're not going to win the war on  
terrorism."
                                     - retired U.S. Army general,  
William Odom