[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 .....

Not quite impossible, but difficult.  But you can chip away at the  
problem in the way I did with [mouse], [joystick], [gamepad], etc.  
objects.  The output from [hid] is autoscaled to 0-1, so even tho the  
data that comes from the devices varies widely, the data that comes out  
of [joystick], for example, is always 0-1.


>>> 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.
>
> 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.

The unified format is one of the essential themes of the [hid] toolkit  
objects.  All of them expect input data in the range 0-1 and output  
0-1.  So even if you use the [hid_polar] object, which converts  
cartesian coords to polar coords, the angle is also output in a range  
from 0-1.  While this might seem like blasphemy to some mathematicians,  
it makes it so that you can chain hid toolkit objects without having to  
think about the rescaling the data each time.  And there is [hid2rad]  
for the mathematicians ;).

Also, the [joystick] object has a standard number of axes.  Its a basic  
set that basically all joysticks should support.  Then if you want to  
use any extra axes, you can use [hid] directly, but you loose the  
cross-joystick compatibility of the patch.

But the idea of having device-specific objects which then translate  
into standard elements is interesting...

.hc




>
>> I will experiment with the idea tho, we'll see where it goes...
>>
>> .hc
>>
>
> greets,
>
> chris
>
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

Using ReBirth is like trying to play an 808 with a long stick.
                                               -David Zicarelli