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@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli