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

[Hans-Christoph Steiner]

If sensorboxes all spoke USB HID or even [hid]-style messages, then  
what you describe would be quite possible by [route]ing the data, just  
like [mouse], [joystick], etc.  I am thinking more and more the answer  
lies in making the sensorboxes speak a common format.  This should be  
possible with any USB, serial, ethernet, etc.  MIDI would probably be  
an exception, that could be handled by a Pd object doing the  
translation.

Oh yeah, about range, Pd uses 32-bit floats, so its resolution will be  
bigger than any sensorbox, which generally use 10-bit or 12-bit ints).   
The 32-bit float's 23-bit mantissa gives you 7 decimal digits of  
accuracy.  In [hid], the possible range is then 0.000000-to-1.000000,  
which is basically the same as 0 to 1,000,000.  For a 10-bit int, its  
0-1023, for a 12-bit, its 0-4095.  The current [hid] scheme can  
represent up to 19-bits, and almost 20-bit (0-1,048,576), so I think  
that'll hold us for a while.  Once Pd starts using 64-bit floats, then  
[hid]'s range will be in effect 0-to-100,000,000,000,000 (52-bit  
mantissa, 15 decimal digits).

.hc

On Jan 22, 2006, at 2:45 PM, B. Bogart wrote:

> Hey all,
>
> Damn, what a thread.
>
> Of course I'm only expecting the "common" interface to work on those
> things that do make sense on all devices.
>
> And remember I'm always talking from the user perspective, not the
> developer one.
>
> I also like HC's talk about a standard range of 0-1 for outputs. I do
> belive the resolution of a float is bigger than the resolution of these
> HW devices. Also for the user the range of 0-1 is much easier to deal  
> with.
>
> An approach would be to list all the common atributes:
>
> * analog in
> * analog out
> * digital in
> * digital out
> * PWM out (maybe?)
>
> based on this we could have three objects:
>
> [analog] [digital] [pwm]
>
> Can we simulraneously read and write to any of these devices? (that
> would be a nice feature)
>
> You send the message [set 0 0.5< to set the first analog output of the
> device to half way up its full range. [set 1 1< would set the second
> analog output to its full range (5v).
>
> Maybe the analog out has modes for say, internal polling, or external
> polling, and for the range of pins to poll. [poll internal< [poll
> external<, [range 0 5< polls the first to the 6th outputs)
>
> The messages we get from the analog object would be something like:
>
> [0 0.5<   # first input is 2.5v
>
> So we just need to [route 0 1 2 3 4 5 6] or some more complex method  
> for
> an unknown dynamic number of inputs.
>
> digital would act the same, except the argument would be a 0/1 rather
> than a float to turn pins on and off.
>
> [pwm]
>
> would have only an input, and we set it with [set 0 0.5] to set pwm pin
> 0 to half way through the PWM range of that micro.
>
> The relative pwm may be a problem, so we could use the hz as the
> argument to control a servo for example. (where say 1000hz is stop)
>
> So thats my thinking.
>
> s\*\b\g
>
> Mathieu Bouchard wrote:
>> On Fri, 20 Jan 2006, Christian Klippel wrote:
>>
>>
>>> 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.
>>
>>
>> I'm sure that Ben is talking about having a common interface for  
>> things
>> that objects have in common, and not for the things that they don't  
>> have
>> in common. Just because the commonality can't be total doesn't mean it
>> can't exist at all.
>>
>>
>>> each unit has different resolutions, different amounts of i/o, and  
>>> for
>>> that reason, a different protocol.
>>
>>
>> The commonality between objects may be increased by specifying that
>> classes in particular should have a query interface in order to
>> figure out how many sensors there are, how they are labeled if they
>> are labeled, and what is the type and possible values of each sensor.
>>
>>
>>> 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.
>>
>>
>> Does this happen in practice? Do you have an actual situation where  
>> three
>> joystick models do exactly that?
>>
>>  _ _ __ ___ _____ ________ _____________ _____________________ ...
>> | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
>> | Freelance Digital Arts Engineer, Montréal QC Canada
>>
>> _______________________________________________
>> PD-dev mailing list
>> PD-dev at iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>

________________________________________________________________________ 
____

News is what people want to keep hidden and everything else is  
publicity.
                                                                          
                      - Bill Moyers