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