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

[B. Bogart]

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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20060122/cf1a211d/attachment.pgp>