I am currently working on the next generation of the [hid] toolkit. Its going to be split into two libraries: an IO lib, which will include [hid], [serial], [usb], etc. Then the [hid] mapping objects will be combined with Cyrille Henry's sensor/datastream objects into a mapping lib. The IO objects will have all the same options and the interface will be as similar as possible, so if you know how to use [serial], you'll know how to use [hid] or [usb] basically.
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.
[hid] and [serial] are basically done, [hid] works on GNU/Linux and Mac OSX and is being ported to Win32, and [serial] will be based on [comport], thanks to Wini for that. For [usb], I am think of basically making a Pd interface to libusb, since it runs on all Pd platforms, there is even a Win32 port (which seems to be a fork, unfortunately).
Anyhow, I am wondering if anyone has done any work towards making a libusb object? Also, ideas, comments, criticisms are always welcome.
.hc
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hi!
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.
You may want to look at the current [multio] external (made by mamalala + myself) in externals/hardware/multio
[hid] and [serial] are basically done, [hid] works on GNU/Linux and Mac OSX and is being ported to Win32, and [serial] will be based on [comport], thanks to Wini for that. For [usb], I am think of basically making a Pd interface to libusb, since it runs on all Pd platforms, there is even a Win32 port (which seems to be a fork, unfortunately).
for the [multio] we used libusb for linux/osx and libusb-win32 for windows and they work exactly the same way.. ok not extactly but almost!
Anyhow, I am wondering if anyone has done any work towards making a libusb object? Also, ideas, comments, criticisms are always welcome.
you can surely take most of the code from [multio] external to create a more general [usb] one, i am thinking at the threaded reading/writing stuff (it really need to be threaded)
ciao!
.hc
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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).
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...
.b.
.hc
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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).
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.
I will experiment with the idea tho, we'll see where it goes...
.hc
.b.
.hc
__ ____
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
Hmm, I'm not familiar with miditron, but if its midi based, then I think it should be seperate anyhow, unless it actually gives you values in a normal A2D or digital range.... If its just midi why does it need its own interface object?
I was really thinking serial and USB (serial over USB)...
I guess one could look across the board and see what functionality crossed over, but it does make more sense to me that there would be a consistant way to get analog input or PWM output on one of these things.... (to make workshops and PDDP stuff easier, depending on the HW context).
.b.
Hans-Christoph Steiner wrote:
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.
I will experiment with the idea tho, we'll see where it goes...
.hc
.b.
.hc
__ ____
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
¡El pueblo unido jamás será vencido!
Yes, serial and USBserial are close enough to have the same object. But the MultIO uses HID, right? Is the libusb interface to MultIO USBserial?
.hc
On Jan 20, 2006, at 8:26 AM, B. Bogart wrote:
Hmm, I'm not familiar with miditron, but if its midi based, then I think it should be seperate anyhow, unless it actually gives you values in a normal A2D or digital range.... If its just midi why does it need its own interface object?
I was really thinking serial and USB (serial over USB)...
I guess one could look across the board and see what functionality crossed over, but it does make more sense to me that there would be a consistant way to get analog input or PWM output on one of these things.... (to make workshops and PDDP stuff easier, depending on the HW context).
.b.
Hans-Christoph Steiner wrote:
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.
I will experiment with the idea tho, we'll see where it goes...
.hc
.b.
.hc
¡El pueblo unido jamás será vencido!
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
¡El pueblo unido jamás será vencido!
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
hello hans and all,
Am Freitag 20 Januar 2006 17:38 schrieb Hans-Christoph Steiner:
Yes, serial and USBserial are close enough to have the same object. But the MultIO uses HID, right? Is the libusb interface to MultIO USBserial?
.hc
about sending usb stuff .....
first, regardless if you send stuff as hid, serial or generic format, the raw data packets that get sent are always the same (in the case of the multio). hid just means it gets some extra descriptors during enumeration, that makes the host understand it as hid device. same for serial devices. if you use the cdc class descriptors, the host will see it as serial interface, while the data you send/receive on the side of the microcontroller is still the same.
now, for the multio in special: the old (=current) firmware defaults to hid all the time, and can be set to non-hid afterwards by issuing the usb command to select the right configuration of that device. this was a bad idea as i found out: some systems claim the multio in hid mode and block it for access by other apps.
the new (=future) firmware, that im working on right now, will have 3 modes: usb-hid, usb-cdc (to enumerate it as normal serial port), and finally the generic raw mode for direct access by libusb. furthermore, the box will remember the last choosen config and defaults to that each time the unit is powered on or connected tot he usb bus.
i think that by also implementing the usb-cdc class, it should be even more easy to access the multio. i mean, hey: hid, serial or generic: im sure that this way any computer with usb can talk to it "out of the box".
greetings,
chris
hi again,
btw, with libusb, you just send or receive buffers with up to 64 bytes, independant of how the device is enumerated. so you can send/receive data from a hid device the same way as from a non-hid device, by usb_interrupt_read or *_write ..... serial devices usually have bulk endpoints (higher transfer rate), so it just changes to usb_bulk_read and *_write.
greets,
chris
On Jan 20, 2006, at 11:52 AM, Christian Klippel wrote:
hello hans and all,
Am Freitag 20 Januar 2006 17:38 schrieb Hans-Christoph Steiner:
Yes, serial and USBserial are close enough to have the same object. But the MultIO uses HID, right? Is the libusb interface to MultIO USBserial?
.hc
about sending usb stuff .....
first, regardless if you send stuff as hid, serial or generic format, the raw data packets that get sent are always the same (in the case of the multio). hid just means it gets some extra descriptors during enumeration, that makes the host understand it as hid device. same for serial devices. if you use the cdc class descriptors, the host will see it as serial interface, while the data you send/receive on the side of the microcontroller is still the same.
now, for the multio in special: the old (=current) firmware defaults to hid all the time, and can be set to non-hid afterwards by issuing the usb command to select the right configuration of that device. this was a bad idea as i found out: some systems claim the multio in hid mode and block it for access by other apps.
the new (=future) firmware, that im working on right now, will have 3 modes: usb-hid, usb-cdc (to enumerate it as normal serial port), and finally the generic raw mode for direct access by libusb. furthermore, the box will remember the last choosen config and defaults to that each time the unit is powered on or connected tot he usb bus.
i think that by also implementing the usb-cdc class, it should be even more easy to access the multio. i mean, hey: hid, serial or generic: im sure that this way any computer with usb can talk to it "out of the box".
Sounds like you are covering all possibilities. So for a usb-cdc device, is that the same as a tty? I.e., could you use [comport] to access a usb-cdc device?
.hc
greetings,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin
hello,
Am Samstag 21 Januar 2006 06:58 schrieb Hans-Christoph Steiner:
[...snip...]
i think that by also implementing the usb-cdc class, it should be even more easy to access the multio. i mean, hey: hid, serial or generic: im sure that this way any computer with usb can talk to it "out of the box".
Sounds like you are covering all possibilities. So for a usb-cdc device, is that the same as a tty? I.e., could you use [comport] to access a usb-cdc device?
.hc
exactly. it shows up (under linux) as /dev/ttyUSB1 for me, and i then can access it with anything that can talk to a serial device ....
greets,.
chris
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.
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.
I will experiment with the idea tho, we'll see where it goes...
.hc
greets,
chris
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
hi,
Am Freitag 20 Januar 2006 20:48 schrieb Hans-Christoph Steiner: [...snip...]
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.
ok, lets examine that. when hid is used, we _can_ refer to the hid-name to map axes & buttons, but this can be done easily only if the hid api from the os is used. this is because the hid driver knows what values refer to what axes/buttons.
now, if you want to have a generic access to hid devices, you need to put the complete descriptor parser inside the object/abstraction as well. and it is only this descriptor(s) that tell you what is what. if you dont look at them, but only at the data packet that is sent (i.e., the buffer that you receive when issuing a usb_interrupt_read() on that device), its no longer clear what is what.
a report descriptor is like:
i'm a mouse i have relatives axes two of them i have three buttons arranged this way done.
the resulting data packet would be <axis1><axis2><bitmap for buttons>
however, it could specify itself that way also:
i'm a mouse i have three buttons ..... there are two relative axis .... done.
wich, of course, results in a packet of <button-bitmap><axis1><axis2>
to make things even more complicated, each axis could have his very own report descriptor as well .... then it looks like:
i'm a mouse this is report #1 for one relative axis end of this report this is report #2 for one relative axis end of this report ..... .....
now, the data packet looks _completely_ different, actually there can be serveral different packets, only distinguished by their report id as specified in the descriptor: <report-id 1><rel.axis x> _or_ <report-id 2><rel.axis y> _or_ <report-id 3><button #1> etc, etc.....
while the access will be always the same via hid, it is differently by means of the layout of the actual data.
im not sure that it is the best idea to re-implement the hid interpreter stuff. in case of "always same functions but different brands" stuff like mice, joysticks, etc. it may be more usefull to give the object the mapping of the data either as argument, or as cfg file. this would be a big performance gain also, since the whole interpretation stuff is gone. sure, for simple things that may not matter, but what if you have 32 faders to fiddle with? thats already quite some traffic....
for "custom devices" like cui, arduino, multio, .... i dont see any other way than to have seperate "core drivers" for each device ....
[...snip...]
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 ;).
yes, i think thats a very good idea. btw, its also no problem to do the conversion to/from float inside the firmware as well. im going to do that ;-)
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.
right, but as said above, if it is wanted to bypass the os's hid system and directly access the device, the object needs a way to know what is what ....
of course, when the hid-system is accessed from those objects, than it doesnt matter because of hid doing the naming/numbering already .... so, if it is not intended to drop "real hid access" and use libusb instead, you can forget about all that ;-D
But the idea of having device-specific objects which then translate into standard elements is interesting...
.hc
greets,
chris
On Jan 20, 2006, at 4:02 PM, Christian Klippel wrote:
hi,
Am Freitag 20 Januar 2006 20:48 schrieb Hans-Christoph Steiner: [...snip...]
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.
ok, lets examine that. when hid is used, we _can_ refer to the hid-name to map axes & buttons, but this can be done easily only if the hid api from the os is used. this is because the hid driver knows what values refer to what axes/buttons.
now, if you want to have a generic access to hid devices, you need to put the complete descriptor parser inside the object/abstraction as well. and it is only this descriptor(s) that tell you what is what. if you dont look at them, but only at the data packet that is sent (i.e., the buffer that you receive when issuing a usb_interrupt_read() on that device), its no longer clear what is what.
a report descriptor is like:
i'm a mouse i have relatives axes two of them i have three buttons arranged this way done.
the resulting data packet would be <axis1><axis2><bitmap for buttons>
however, it could specify itself that way also:
i'm a mouse i have three buttons ..... there are two relative axis .... done.
wich, of course, results in a packet of <button-bitmap><axis1><axis2>
to make things even more complicated, each axis could have his very own report descriptor as well .... then it looks like:
i'm a mouse this is report #1 for one relative axis end of this report this is report #2 for one relative axis end of this report ..... .....
now, the data packet looks _completely_ different, actually there can be serveral different packets, only distinguished by their report id as specified in the descriptor: <report-id 1><rel.axis x> _or_ <report-id 2><rel.axis y> _or_ <report-id 3><button #1> etc, etc.....
while the access will be always the same via hid, it is differently by means of the layout of the actual data.
im not sure that it is the best idea to re-implement the hid interpreter stuff. in case of "always same functions but different brands" stuff like mice, joysticks, etc. it may be more usefull to give the object the mapping of the data either as argument, or as cfg file. this would be a big performance gain also, since the whole interpretation stuff is gone. sure, for simple things that may not matter, but what if you have 32 faders to fiddle with? thats already quite some traffic....
For the goal of "just working" when you using [mouse], for example, the config file idea would make things much more complicated. Personally, I think that USB HID has far too many element types, there is a lot of redundancy which is more likely to cause problems than help, IMHO. That's what I followed the Linux input event example, where they simplified things. Perhaps this should not be called HID then.
I have been thinking that sequentially numbered types might work for the MultIO-style multi-axis controller. Otherwise, how do you spec out 88 specific axes in HID? Here's what the USB spec has to say about they think a "Multi-Axis Controller" is:
"An input device used to orient eyepoints and or objects in 3 dimensional space. A Multi-axis Controller typically consists of six, variable axes (X, Y, Z, Rx, Ry and Rz) and is used by CAD/digital content creation applications for model manipulation and visualization in 3D space. The device may incorporate zero or more buttons."
Is the MultIO using the "Ordinal Page" stuff? That seems even more obtuse than the rest of USB HID. Ug... design by corporate committee... I am starting to think that maybe we should just define a new standard for sensorboxes, maybe based on OSC. But then you'd loose the nice plug-n-play aspect of HID, like making your own joystick, mouse, etc.
.hc
for "custom devices" like cui, arduino, multio, .... i dont see any other way than to have seperate "core drivers" for each device ....
[...snip...]
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 ;).
yes, i think thats a very good idea. btw, its also no problem to do the conversion to/from float inside the firmware as well. im going to do that ;-)
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.
right, but as said above, if it is wanted to bypass the os's hid system and directly access the device, the object needs a way to know what is what ....
of course, when the hid-system is accessed from those objects, than it doesnt matter because of hid doing the naming/numbering already .... so, if it is not intended to drop "real hid access" and use libusb instead, you can forget about all that ;-D
But the idea of having device-specific objects which then translate into standard elements is interesting...
.hc
greets,
chris
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
¡El pueblo unido jamás será vencido!
hi all,
Am Dienstag 24 Januar 2006 18:59 schrieb Hans-Christoph Steiner: [...snip...]
For the goal of "just working" when you using [mouse], for example, the config file idea would make things much more complicated. Personally, I think that USB HID has far too many element types, there is a lot of redundancy which is more likely to cause problems than help, IMHO. That's what I followed the Linux input event example, where they simplified things. Perhaps this should not be called HID then.
true, using some kind of config file would make it more complicated at the start. there arent that many element types, dont confuse that with the hid names of the elements. there are either bitfields for stuff like keys, indicators, etc, and numerical elements whose range/size is defined in the descriptor as well. plus, they can be either absolute or relative values.
after all, it just boils down to what bits belong to buttons, lights, etc, and what bytes belong to numerical values. how they are named from hid can be completely disregarded when it comes to the raw data packet. its just important to know how the value fields are arranged in the incomming report.
I have been thinking that sequentially numbered types might work for the MultIO-style multi-axis controller. Otherwise, how do you spec out 88 specific axes in HID? Here's what the USB spec has to say about they think a "Multi-Axis Controller" is:
"An input device used to orient eyepoints and or objects in 3 dimensional space. A Multi-axis Controller typically consists of six, variable axes (X, Y, Z, Rx, Ry and Rz) and is used by CAD/digital content creation applications for model manipulation and visualization in 3D space. The device may incorporate zero or more buttons."
yeah ... i must admit that i didnt found anything that could be nearly describe the unit, so i stuck with the multi-axis controller, wich it is kind of, just with a bit more axes....
Is the MultIO using the "Ordinal Page" stuff? That seems even more obtuse than the rest of USB HID. Ug... design by corporate committee... I am starting to think that maybe we should just define a new standard for sensorboxes, maybe based on OSC. But then you'd loose the nice plug-n-play aspect of HID, like making your own joystick, mouse, etc.
yes, because if i would use the generic desktop page, the sliders would move your mouse actually.... well, at least two or three of them ....
also, the multio is really a pid device (as per definition), but i choosed hid becasue that is what most systems have implemented. the pid classes were not that well supported under linux at the time i wrote the first firmware.
in fact, the multio has way too much i/o capabilities for (at least the linux) hid / event system. for example, not all inputs are supported by default, becasue of some #define's in the linux drivers ... like, "#define ABSMAX 64", so that axes from > 64 arent rtecognized anymore. led's are even worse, becasue only a few are possible...... but this comes into play only if you really want to use 4 userboards at once ....
besides that, hid limits the functionality of the box in a way that there is no way to send setup-messages to the device, unless i would pack them into some really obscure report descriptor ...... not to forget the need to work around the hid specifics of value settings .....
after all, using hid was done only to have a simple, out-of-the-box way to use the device, without needing any special drivers ....
probably the most flexible and simple way is to enumerate such devices as usb-serial adapters with the cdc class. that way, any serial port accessing application can use the device..... and, i think that generic drivers for cdc devices are also available on any os ..... however, the multio will do 3 types ...
.hc
greets,
chris
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
hi,
Am Samstag 21 Januar 2006 06:28 schrieb Mathieu Bouchard:
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.
well, that is what the hid driver (in the os) does already by inspecting the report descriptors that the device sent during enumeration..... the question is just: is it planned to have, at some time, the [hid] object replaced by some more generic objects that use libusb instead and will decode this stuff on their own, or will the libusb stuff just an extension to it?
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?
dont have any joysticks at all. but i have already seen two usb mice that use different "data layouts" to send the same information, so there is a chance ... altough im sure myself that most devices stick to some kind of "common sense" .... well, at least i hope that ....
greets,
chris
On Jan 21, 2006, at 2:25 AM, Christian Klippel wrote:
hi,
Am Samstag 21 Januar 2006 06:28 schrieb Mathieu Bouchard:
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.
well, that is what the hid driver (in the os) does already by inspecting the report descriptors that the device sent during enumeration..... the question is just: is it planned to have, at some time, the [hid] object replaced by some more generic objects that use libusb instead and will decode this stuff on their own, or will the libusb stuff just an extension to it?
I think this sounds like a good grand plan, but would probably take a while to get there. If there was a USB HID object that received data in the Pd space and parsed it into [hid]-style messages, then it could be used in combo with a libusb object to replace [hid] in perhaps a more flexible way.
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?
dont have any joysticks at all. but i have already seen two usb mice that use different "data layouts" to send the same information, so there is a chance ... altough im sure myself that most devices stick to some kind of "common sense" .... well, at least i hope that ....
I have 5 different mice from four different manufacturers and I can say that they all work fine with the [mouse] object. I don't know what is going on at the USB level, but I know that the data is coming out of the [mouse] object where its supposed to. The order in which the data gets outputted might be different tho.
.hc
________________________________________________________________________ ____
"Computer science is no more related to the computer than astronomy is related to the telescope." -Edsger Dykstra
Am Dienstag 24 Januar 2006 19:05 schrieb Hans-Christoph Steiner:
[...snip...]
I have 5 different mice from four different manufacturers and I can say that they all work fine with the [mouse] object. I don't know what is going on at the USB level, but I know that the data is coming out of the [mouse] object where its supposed to. The order in which the data gets outputted might be different tho.
.hc
yes, because the hid defines these names/positions & ranges.
the raw data that gets sent usually contains all axes and buttons always. it is the hid/event system that filters out unchanged stuff and forwards only what has changed. but the datapacket (again, usually) is one single report descriptor containing all fields. contrary to that, the multio uses seperate report descriptors for each axis, preceeded by a report-id (first byte of the packet).
and i was only refering to how the fields are layed out inside the descriptor. for sure every mouse behaves the same when used the hid way, after all, thats what the descriptors are for. its just then when accessing it directly, bypassing hid/event at all, the incomming data may have different layouts for different mice.
btw, the linux even system also uses hid, it just re-packs the incomming data and filters out unchanged fields. but of course it refers to the hid names and types for doing that....
greets,
chris
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@iem.at http://lists.puredata.info/listinfo/pd-dev
Hello All,
I'm trying to determine what arguments are used by PD to create a canvas.
I've determined the following:
A "parent" canvas (i.e. top-level window) has the following arguments:
#N canvas ( 0 = top 0 = left 772 = width 532 = height 12 = font-size )
As in: #N canvas 0 0 772 532 12;
However, a canvas created as an object inside a window has the following arguments: #X obj ( 0 = top 0 = left cnv = ( 15 = selectable area size 768 = width 22 = height cnv_heading_S = send name cnv_heading_R = receive name All_About_Canvases = title 12 = title-left-offset 12 = title-top-offset 0 = font-face 14 = font-size -233017 = background-color -1 = foreground-color 0 = UNKNOWN????????????????????????? );
As in: #X obj 0 0 cnv 15 768 22 cnv_heading_S cnv_heading_R All_About_Canvases 12 12 0 14 -233017 -1 0;
I have three questions:
1. What is the LAST argument of cnv used for (the "UNKNOWN" one above)? My best guess is that it's an integer which indicates Graph on Parent? Or perhaps it's an "id" of some kind?)
2. What format are the colours? -1 = black? 1 = white? What standard is this? (it's not hex, it's not RGB)?
3. By the parenthesis above, you can see that I assume that the "obj" structure accepts three arguments (with the THIRD argument being the cnv structure). -- is this observation accurate?
Thank you. Dave Sabine
Check out "Pd File Format" at the bottom of this page:
http://puredata.org/docs/developer/
Also, that document is included in the Pd-extended distro.
.hc
On Jan 22, 2006, at 3:40 PM, Dave S wrote:
Hello All,
I'm trying to determine what arguments are used by PD to create a canvas.
I've determined the following:
A "parent" canvas (i.e. top-level window) has the following arguments:
#N canvas ( 0 = top 0 = left 772 = width 532 = height 12 = font-size )
As in: #N canvas 0 0 772 532 12;
However, a canvas created as an object inside a window has the following arguments: #X obj ( 0 = top 0 = left cnv = ( 15 = selectable area size 768 = width 22 = height cnv_heading_S = send name cnv_heading_R = receive name All_About_Canvases = title 12 = title-left-offset 12 = title-top-offset 0 = font-face 14 = font-size -233017 = background-color -1 = foreground-color 0 = UNKNOWN????????????????????????? );
As in: #X obj 0 0 cnv 15 768 22 cnv_heading_S cnv_heading_R All_About_Canvases 12 12 0 14 -233017 -1 0;
I have three questions:
- What is the LAST argument of cnv used for (the "UNKNOWN" one
above)? My best guess is that it's an integer which indicates Graph on Parent? Or perhaps it's an "id" of some kind?)
- What format are the colours? -1 = black? 1 = white? What
standard is this? (it's not hex, it's not RGB)?
- By the parenthesis above, you can see that I assume that the "obj"
structure accepts three arguments (with the THIRD argument being the cnv structure). -- is this observation accurate?
Thank you. Dave Sabine
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
There is no way to peace, peace is the way. -A.J. Muste
Hello all,
In regards to my earlier question: "What is the last argument of [cnv] for?"
1. Here's a blurb from the "Unofficial Documentation of PD File Format" at http://student-kmt.hku.nl/%7Etjeerd/pd/pd_fileformat.html#r369 which is an excellent paper by Simon Asselbergs and Tjeerd Sietsma:
Syntax: #X obj [x_pos] [y_pos] cnv [size] [width] [height] [send] [receive] [label] [x_off] [y_off] [font] [font_size] [bg_color] [label_color] [?]; [?] - unknown value, default is zero Remarks: We couldn't find the purpose of the final value.
2. And Miller's description of PD's File Format doesn't appear to give us any clues (or I haven't yet found a clue).
So, the question stands: What is the last argument of [cnv] for?
AS IN: #X obj 0 0 cnv 15 768 22 cnv_heading_S cnv_heading_R All_About_Canvases 12 12 0 14 -233017 -1 0;
Does anybody know?
Regards, Dave S
Dave S wrote:
Hello all,
So, the question stands: What is the last argument of [cnv] for?
AS IN: #X obj 0 0 cnv 15 768 22 cnv_heading_S cnv_heading_R All_About_Canvases 12 12 0 14 -233017 -1 0;
Does anybody know?
yes, thomas, who is the author of this object should know (tomorrow, when he is in the office i could ask him)
apart from that, the source-code should know....
the arguments for the iemguis (these are the ones where you get the fancy properties dialog) have undergone several generations of change. so it could be, that the last argument is just there for compatibilites sake. (i tried talking thomas into putting an "API-version"-argument into the argument list to make the parsing simpler, but to no avail)
furthermore, parts of the argument-handling are handled by a general "iemgui_args"-function. it might be, that this general approach has some leftovers, e.g. unused arguments.
looking at the c-code of the [cnv] (g_mycanvas.c, g_all_guis.c) it seems, like the latter case is at least "not wrong". the value of the 13th argument is used to turn on a "loadinit"-value (important for [loadbang]-behaviour of e.g. [bng]; should be totally unused in the [cnv]-case) and a "scale"-value (i think this turns on/off the "scale" at the [vu])
anything clear?
mfg.asd.r IOhannes
IOhannes m zmoelnig wrote:
Dave S wrote:
Hello all,
So, the question stands: What is the last argument of [cnv] for?
AS IN: #X obj 0 0 cnv 15 768 22 cnv_heading_S cnv_heading_R All_About_Canvases 12 12 0 14 -233017 -1 0;
Does anybody know?
yes, thomas, who is the author of this object should know (tomorrow, when he is in the office i could ask him)
apart from that, the source-code should know....
the arguments for the iemguis (these are the ones where you get the fancy properties dialog) have undergone several generations of change. so it could be, that the last argument is just there for compatibilites sake. (i tried talking thomas into putting an "API-version"-argument into the argument list to make the parsing simpler, but to no avail)
furthermore, parts of the argument-handling are handled by a general "iemgui_args"-function. it might be, that this general approach has some leftovers, e.g. unused arguments.
looking at the c-code of the [cnv] (g_mycanvas.c, g_all_guis.c) it seems, like the latter case is at least "not wrong". the value of the 13th argument is used to turn on a "loadinit"-value (important for [loadbang]-behaviour of e.g. [bng]; should be totally unused in the [cnv]-case) and a "scale"-value (i think this turns on/off the "scale" at the [vu])
anything clear?
Almost. The function my_canvas_save in g_mycanvas.c stores the x_isa field of x_gui as an int. x_isa is a 32-bit struct named t_iem_init_symargs, made up of the following (from g_mycanvas.h):
typedef struct _iem_init_symargs { unsigned int x_loadinit:1; unsigned int x_rcv_arg_tail_len:6; unsigned int x_snd_arg_tail_len:6; unsigned int x_rcv_is_arg_num:6; unsigned int x_snd_is_arg_num:6; unsigned int x_scale:1; unsigned int x_flashed:1; unsigned int x_locked:1; unsigned int x_reverse:1; /* bugfix */ unsigned int dummy:3; } t_iem_init_symargs;
...so x_loadinit is one of 9 elements; are any of them actually used?
Martin
Hallo, Dave S hat gesagt: // Dave S wrote:
I'm trying to determine what arguments are used by PD to create a canvas.
I've determined the following:
A "parent" canvas (i.e. top-level window) has the following arguments:
#N canvas ( 0 = top 0 = left 772 = width 532 = height 12 = font-size )
As in: #N canvas 0 0 772 532 12;
However, a canvas created as an object inside a window has the following arguments:
Note that the [cnv] has nothing to do with the canvasses in a patch. A [cnv] is just an object. Pd saves all these objects as "obj x-coord y-coord OBJNAME OBJ_ARGUMENTS". The meaning of OBJ_ARGUMENTS depends on the specific object created. For an object "osc~" the argument is just the frequency, for a object "cnv" it's something else.
A real new canvas is created by creating a meta-object called "pd", as you know. This is *not* saved as "obj 100 200 pd subpatch", but instead will create a construct like:
#N canvas 726 183 454 677 subpatch 0; ... (contents of subpatch) #X restore 75 95 pd subpatch;
Ciao
hi all,
Am Sonntag 22 Januar 2006 20:45 schrieb B. Bogart:
Hey all,
[...snip...]
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]
you can drop [pwm] ... it is basically the same as [analog] ..... that the _real_ output is a pwm signal (whose average equals to an analogue dc voltage) is a matter of the used chip .....
Can we simulraneously read and write to any of these devices? (that would be a nice feature)
usually yes .....
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)
you mean analogue in, right? at least for the multio, the next firmware will have the option to turn off the auto-update of thechannel(s). polling is alway possible.
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.
right ......
[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)
you mean output, right? if you need to meassure an incomming pwm signal instead of an anlogue voltage, you just need to make a simple rc lowpass filter (one resistor and one capicator) to get an analogue voltage from a pwm signal.
again: setting or reading a pwm signal with a 50/50 cycle (0.5 in the 0..1 range) is the same as reading an analogue voltage at 50% of Vmax for an analogue input ....
greets,
chris
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@iem.at http://lists.puredata.info/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________________________________________________ ____
News is what people want to keep hidden and everything else is publicity.
- Bill Moyers
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
On Fri, 20 Jan 2006, Hans-Christoph Steiner wrote:
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.
We've already had a discussion about HID in the past, and your opinion was that the MultIO shouldn't use HID. What has changed since?
[note: I was also the one who had requested that the MultIO gets a non-HID mode, but that happened much before and that was because the HID driver in the ordinary Linux kernel was really lame.]
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 19 Jan 2006, B. Bogart wrote:
If they *have* to be different then they should have the same interface (accept the same messages). [...] 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 think that this is the key. Also the interface should be documented in a common help file. What I say isn't limited to those objects in particular. It can apply to the whole PDDP. See my previous mail titled "macros" (yeah the mail isn't really about macros).
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Thu, 19 Jan 2006, Hans-Christoph Steiner wrote:
[hid] and [serial] are basically done, [hid] works on GNU/Linux and Mac OSX and is being ported to Win32, and [serial] will be based on [comport], thanks to Wini for that. For [usb], I am think of basically making a Pd interface to libusb, since it runs on all Pd platforms, there is even a Win32 port (which seems to be a fork, unfortunately).
GridFlow already wraps most of libusb. If you want to make something that wraps libusb but directly for pd (instead of through ruby), you could reuse some of the code.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 20, 2006, at 4:46 AM, Mathieu Bouchard wrote:
On Thu, 19 Jan 2006, Hans-Christoph Steiner wrote:
[hid] and [serial] are basically done, [hid] works on GNU/Linux and Mac OSX and is being ported to Win32, and [serial] will be based on [comport], thanks to Wini for that. For [usb], I am think of basically making a Pd interface to libusb, since it runs on all Pd platforms, there is even a Win32 port (which seems to be a fork, unfortunately).
GridFlow already wraps most of libusb. If you want to make something that wraps libusb but directly for pd (instead of through ruby), you could reuse some of the code.
I am interested in libusb for Pd. I've never used Pd and I want to keep these objects as simple as possible. Is your libusb code in C or Ruby?
.hc
________________________________________________________________________ ____
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
On Fri, 20 Jan 2006, Hans-Christoph Steiner wrote:
On Jan 20, 2006, at 4:46 AM, Mathieu Bouchard wrote:
GridFlow already wraps most of libusb. If you want to make something that wraps libusb but directly for pd (instead of through ruby), you could reuse some of the code.
I've never used Pd
Are you sure? ;-)
and I want to keep these objects as simple as possible.
Depends on what kind of simple you want...
Is your libusb code in C or Ruby?
It's all C++ but uses the Ruby API and some of the GF API. Those calls have to be replaced by ordinary Pd API equivalents.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
B. Bogart -
Christian Klippel -
Dave S -
Davide Morelli -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Martin Peach -
Mathieu Bouchard