hi,
as i got a wacom usb tablet lying around, i was wondering if it would be possible to use it as a controller for PD ?
so,
i found "many" things in archive but none "ready to use" solutions for PD...
even "dirty hacks" would make my happy ;) (like copying tuner.o to tuner1.o to get 2 different tuner cards work with pdp)
thnx@advance -andre
hi andre,
Am Dienstag, 8. April 2003 13:17 schrieb Andre Schmidt:
hi,
as i got a wacom usb tablet lying around, i was wondering if it would be possible to use it as a controller for PD ?
so,
[...snip...]
thnx@advance -andre
on linux that is very easy. basically, you just need to read out the usb event device. that is for example /dev/usb/event0 (but thats on my machine)
the event interface is really simple, it gives out the raw events of a usb hid device, like "pen move absolute 100", of course all as numbers, not ascii. its just a packet of int's for each event-message.
you may take a look at the usb object i started for jmax, as this just reads that event device.
of course you need to have a kernel with usb, hid and event support (or have them as modules)
greets,
chris
Unless I am mistaken there is a 'tablet' object distributed with GEM? I do not have GEM on my machine now so i cannot say for certain, but I am pretty sure I can remember playing around with it once?
Rory.
--- Christian Klippel ck@mamalala.de wrote: > hi andre,
Am Dienstag, 8. April 2003 13:17 schrieb Andre Schmidt:
hi,
as i got a wacom usb tablet lying around, i was
wondering if it would be
possible to use it as a controller for PD ?
so,
[...snip...]
thnx@advance -andre
on linux that is very easy. basically, you just need to read out the usb event device. that is for example /dev/usb/event0 (but thats on my machine)
the event interface is really simple, it gives out the raw events of a usb hid device, like "pen move absolute 100", of course all as numbers, not ascii. its just a packet of int's for each event-message.
you may take a look at the usb object i started for jmax, as this just reads that event device.
of course you need to have a kernel with usb, hid and event support (or have them as modules)
greets,
chris
PD-list mailing list PD-list@iem.kug.ac.at
http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
Yahoo! Plus For a better Internet experience http://www.yahoo.co.uk/btoffer
On Tuesday, Apr 8, 2003, at 07:26 America/New_York, Christian Klippel wrote:
hi andre,
Am Dienstag, 8. April 2003 13:17 schrieb Andre Schmidt:
as i got a wacom usb tablet lying around, i was wondering if it would be possible to use it as a controller for PD ?
[...snip...]
thnx@advance -andre
on linux that is very easy. basically, you just need to read out the usb event device. that is for example /dev/usb/event0 (but thats on my machine)
the event interface is really simple, it gives out the raw events of a usb hid device, like "pen move absolute 100", of course all as numbers, not ascii. its just a packet of int's for each event-message.
you may take a look at the usb object i started for jmax, as this just reads that event device.
of course you need to have a kernel with usb, hid and event support (or have them as modules)
I am currently working on a Pd_linux object called [rawmouse] which reads info direct from the Linux event interface. Once its done, it should be trivial to make a [rawtablet] object. But its not done yet...
.hc
hi,
Am Dienstag, 8. April 2003 15:20 schrieb Hans-Christoph Steiner:
I am currently working on a Pd_linux object called [rawmouse] which reads info direct from the Linux event interface. Once its done, it should be trivial to make a [rawtablet] object. But its not done yet...
.hc
if you read the event device, you can make a general purpose object. just read the event, and give it to either seperate outlets (type,code,value1,value2) or as list on a single outlet. there is an timestamp in the event message also, if needed, that could be given an outlet.....
that way it can be used with any event device, mice, tablets, joysticks, pens... its then just up to the patch to decode the needed events. one can make simple patches for a ready-to-use mouse decoder based on that, for example.
greets,
chris
what about using the xinput interface? this is the way x programs normally deal with having extra input devices that different programs interpret in different ways.
pix.
On Tue, 8 Apr 2003 16:12:48 +0200 Christian Klippel ck@mamalala.de wrote:
hi,
Am Dienstag, 8. April 2003 15:20 schrieb Hans-Christoph Steiner:
I am currently working on a Pd_linux object called [rawmouse] which reads info direct from the Linux event interface. Once its done, it should be trivial to make a [rawtablet] object. But its not done yet...
.hc
if you read the event device, you can make a general purpose object. just read the event, and give it to either seperate outlets (type,code,value1,value2) or as list on a single outlet. there is an timestamp in the event message also, if needed, that could be given an outlet.....
that way it can be used with any event device, mice, tablets, joysticks,
pens... its then just up to the patch to decode the needed events. one can make simple patches for a ready-to-use mouse decoder based on that, for example.
greets,
chris
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
There are already objects like that, [MouseState] from cyclone. My problem there is that you are limited to the resolution and size of the screen. I want to be able to move my mouse anywhere over long distances, like over a meter, and have the fine resolution that a USB optical puts out.
.hc
On Tue, 8 Apr 2003, pix wrote:
what about using the xinput interface? this is the way x programs normally deal with having extra input devices that different programs interpret in different ways.
pix.
On Tue, 8 Apr 2003 16:12:48 +0200 Christian Klippel ck@mamalala.de wrote:
hi,
Am Dienstag, 8. April 2003 15:20 schrieb Hans-Christoph Steiner:
I am currently working on a Pd_linux object called [rawmouse] which reads info direct from the Linux event interface. Once its done, it should be trivial to make a [rawtablet] object. But its not done yet...
.hc
if you read the event device, you can make a general purpose object. just read the event, and give it to either seperate outlets (type,code,value1,value2) or as list on a single outlet. there is an timestamp in the event message also, if needed, that could be given an outlet.....
that way it can be used with any event device, mice, tablets, joysticks,
pens... its then just up to the patch to decode the needed events. one can make simple patches for a ready-to-use mouse decoder based on that, for example.
greets,
chris
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
zen
\
\
\[D[D[D[D
The problem with writing a generic event interface object is that the number of outlets would change for every device, so for example, if you wrote your patch for a mouse with a wheel, that would give you three outlets for the x, y, and wheel axes. But then throw in a mouse with no wheel, and you'll get one less outlet, and your patch is broken.
This is the problem I have with J Sarlo's joystick object, the outlets are dynamically assigned based on the device. So if I want to write a instrument using a joystick controller so others could use it, they would have to be sure to have the same axes as my joystick. So if their joystick didn't have a hat switch, the patch would break.
The way to write a generic event interface object would be to have it use outlets for event types and codes. But this would be a pain to work with, since you would have to know about the Linux event interface types and codes, and you would have to [route] all those messages to where you want them.
.hc
On Tue, 8 Apr 2003, Christian Klippel wrote:
hi,
Am Dienstag, 8. April 2003 15:20 schrieb Hans-Christoph Steiner:
I am currently working on a Pd_linux object called [rawmouse] which reads info direct from the Linux event interface. Once its done, it should be trivial to make a [rawtablet] object. But its not done yet...
.hc
if you read the event device, you can make a general purpose object. just read the event, and give it to either seperate outlets (type,code,value1,value2) or as list on a single outlet. there is an timestamp in the event message also, if needed, that could be given an outlet.....
that way it can be used with any event device, mice, tablets, joysticks, pens... its then just up to the patch to decode the needed events. one can make simple patches for a ready-to-use mouse decoder based on that, for example.
greets,
chris
zen
\
\
\[D[D[D[D
hi,
Am Mittwoch, 9. April 2003 07:18 schrieb Hans-Christoph Steiner:
The problem with writing a generic event interface object is that the number of outlets would change for every device, so for example, if you wrote your patch for a mouse with a wheel, that would give you three outlets for the x, y, and wheel axes. But then throw in a mouse with no wheel, and you'll get one less outlet, and your patch is broken.
huh ? sorry, but you are completely wrong with that.
exactly that is the reason the event interface exists. you have uniform messages for every kind of (not only) hid input device, like mice, joysticks, keyboards, etc .....
and that is the reason i made "usbtablet" as object first, and no other "special" objects, but the the generic event object as this is enough.
you may want to take a look at http://www.frogmouth.net/hid-doco/x401.html there you can see the input_event structure, and that is the only data you get from the event interface. that is :
struct input_event { struct timeval time; unsigned short type; unsigned short code; unsigned int value; };
for mouse movement, it could be like type=EV_REL, code=REL_X, value=85 ... for a tablet it could be type=EV_ABS, code=ABS_Y, value=19282 .... or for a keybpard type=EV_KEY, code=KEY_SPACE, value=0 .... or for the mouse wheel type=EV_REL, code=REL_WHEEL, value=12 ....
as you can see, you have only 3 outlets, or four if you want to have the timestamp as well.
it should be really easy to decode that output in a patch by route or select. that avoids the redundancy of having multiple binary objects for more or less the same function. and, you dont need to add the input devices anywhere to access them, like with xinput. its simply a device file, thats it ...
greets,
chris
On Wed, 2003-04-09 at 14:51, Christian Klippel wrote:
it should be really easy to decode that output in a patch by route or select. that avoids the redundancy of having multiple binary objects for more or less the same function. and, you dont need to add the input devices anywhere to access them, like with xinput. its simply a device file, thats it ...
In my understanding this is the better solution except when you want to use the same device to control both the DSP and the rest of the GUI.
Sometimes would be useful to be able to switch between the approaches I don't know if X11 can disable a device temporarily. I think it's not but I'm not sure.
Maurizio Umberto Puxeddu.
hi maurizio,
Am Mittwoch, 9. April 2003 15:21 schrieb Maurizio Umberto Puxeddu:
[...snip...] In my understanding this is the better solution except when you want to use the same device to control both the DSP and the rest of the GUI.
the event interface can be opened multiple times with the same device, for example with serveral event objects opening the same device file. or, of course, x11 opening the event device (or the usb mouse device, or whatever) and a object opens it a second time later. i already tried that on my laptop with the jmax object i made, using a usb mouse for x and the object, as well as an additional mac keyboard and a usb tablet. you can have x accessing the usual usb-mouse or usb-keyboard device, while there is still the event device file for that, which can be accessed independantly.
this would also allow to put event reading objects everywhere you want and need, plus you can easily decode any part of the event without selecting any special type (like starting a patch with any button press, regardless if it is from a joystick or a keyboard or mouse ....).
maybe its possible to quickly use the jmax object source with flext to get it into pd ? its not really complete (like having one object opening multiple devices, or allowing to write to them ...), but i think its a usable starting point .....
greets,
chris
Hi Christian.
I know that but if I share the tablet with X11 and a control widget and I start to move the pen and click here and there I could end up launching Mozilla or reconfiguring kernel and ALSA drivers :) No?
Also I think that you cannot open a device twice and use it in absolute mode and relative mode at the same time. This is something that I sometimes wanted to do (I mean *switching* between absolute and relative mode).
Unless there is something that I'm missing...
Maurizio Umberto Puxeddu.
On Wed, 2003-04-09 at 15:59, Christian Klippel wrote:
hi maurizio,
Am Mittwoch, 9. April 2003 15:21 schrieb Maurizio Umberto Puxeddu:
[...snip...] In my understanding this is the better solution except when you want to use the same device to control both the DSP and the rest of the GUI.
the event interface can be opened multiple times with the same device, for example with serveral event objects opening the same device file. or, of course, x11 opening the event device (or the usb mouse device, or whatever) and a object opens it a second time later. i already tried that on my laptop with the jmax object i made, using a usb mouse for x and the object, as well as an additional mac keyboard and a usb tablet. you can have x accessing the usual usb-mouse or usb-keyboard device, while there is still the event device file for that, which can be accessed independantly.
this would also allow to put event reading objects everywhere you want and need, plus you can easily decode any part of the event without selecting any special type (like starting a patch with any button press, regardless if it is from a joystick or a keyboard or mouse ....).
maybe its possible to quickly use the jmax object source with flext to get it into pd ? its not really complete (like having one object opening multiple devices, or allowing to write to them ...), but i think its a usable starting point .....
greets,
chris
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list
hi maurizio,
Am Mittwoch, 9. April 2003 16:31 schrieb Maurizio Umberto Puxeddu:
Hi Christian.
I know that but if I share the tablet with X11 and a control widget and I start to move the pen and click here and there I could end up launching Mozilla or reconfiguring kernel and ALSA drivers :) No?
Also I think that you cannot open a device twice and use it in absolute mode and relative mode at the same time. This is something that I sometimes wanted to do (I mean *switching* between absolute and relative mode).
Unless there is something that I'm missing...
Maurizio Umberto Puxeddu.
ah, ok, sorry. i got you wrong then ;-)
for the abs/rel mode, if your device works in absolute, you can easily create the relative movement by substracting the previous position from the actual.
but for the switching of x input devices, not sure, i think i have seen some tool for that. because one can hot-plug such devices to x, there must be a way to unregister/reregister a certain input device for x .... i will look for that ...
greets,
chris
On Wed, 2003-04-09 at 16:48, Christian Klippel wrote:
for the abs/rel mode, if your device works in absolute, you can easily create the relative movement by substracting the previous position from the actual.
Oh yes, it's just few lines. It was a false issue.
but for the switching of x input devices, not sure, i think i have seen some tool for that. because one can hot-plug such devices to x, there must be a way to unregister/reregister a certain input device for x .... i will look for that ...
I guess you are right. Please post a pointer. It will save me some time.
Thank you very much.
Maurizio Umberto Puxeddu.
You misunderstood the kind of object I am building. Look at J. Sarlo's joystick object. What I am doing is like that except with fixed outlets for the axes rather than dynamically assigned axes. A generic version of that would not work very well.
As for the event interface object you specify, I personally would find it
less useful than specific (albeit very similar) objects for specific devices.
When I choose a controller, I don't think of what kind of event interface I am
using, but rather whether I am using a mouse, a joystick, etc.
Its a matter of different approach. Defining the interface and then implementing it, versus building the interface to mirror the implementation. I prefer to design the interface first, then implement.
Plus since I work on Windows, MacOS X and Linux, I want my objects to be cross-platform. And I am not sure how compatible the three different HID schemes are (I have only used the linux event system, and read about the MacOS X HID stuff).
.hc
On Wed, 9 Apr 2003, Christian Klippel wrote:
hi,
Am Mittwoch, 9. April 2003 07:18 schrieb Hans-Christoph Steiner:
The problem with writing a generic event interface object is that the number of outlets would change for every device, so for example, if you wrote your patch for a mouse with a wheel, that would give you three outlets for the x, y, and wheel axes. But then throw in a mouse with no wheel, and you'll get one less outlet, and your patch is broken.
huh ? sorry, but you are completely wrong with that.
exactly that is the reason the event interface exists. you have uniform messages for every kind of (not only) hid input device, like mice, joysticks, keyboards, etc .....
and that is the reason i made "usbtablet" as object first, and no other "special" objects, but the the generic event object as this is enough.
you may want to take a look at http://www.frogmouth.net/hid-doco/x401.html there you can see the input_event structure, and that is the only data you get from the event interface. that is :
struct input_event { struct timeval time; unsigned short type; unsigned short code; unsigned int value; };
for mouse movement, it could be like type=EV_REL, code=REL_X, value=85 ... for a tablet it could be type=EV_ABS, code=ABS_Y, value=19282 .... or for a keybpard type=EV_KEY, code=KEY_SPACE, value=0 .... or for the mouse wheel type=EV_REL, code=REL_WHEEL, value=12 ....
as you can see, you have only 3 outlets, or four if you want to have the timestamp as well.
it should be really easy to decode that output in a patch by route or select. that avoids the redundancy of having multiple binary objects for more or less the same function. and, you dont need to add the input devices anywhere to access them, like with xinput. its simply a device file, thats it ...
greets,
chris
zen
\
\
\[D[D[D[D
Hi all,
Sorry to bug the list with a question that came up a few months ago (April I think).
Has anyone had success with the following setup yet?
PD with 2 channels duplex audio + MIDI i/o using OSX, Digidesign MBox, and MOTU Fastlane... I'm using Adam Lindsay's 'unofficial' OSX installer...
I want to buy a number of machines with this setup but don't want to do it until I know it is ok (and I have to do it in a real hurry... groan)
Any advice/results appreciated.
Cheers,
Dr Nick Fells, Music Department, University of Glasgow, Tel: +44 (0) 141-330 4096 Glasgow G12 8QQ Fax: +44 (0) 141-330 3518 UK. http://www.gla.ac.uk/music/staff/nick http://www.gla.ac.uk/music/studio
Hi.
I have a version of [grid] modified to be controlled from the wacom tablet and I guess even a separate [wacom] object. I don't use them anymore because I wrote a stand-alone application (in Gtk, so using Xinput at the moment).
If you need them I can fetch them from my computer at school and send a copy.
These object are written as has been described in other mails (using /dev/input/event*) so they shoud work with other devices.
Let me know.
Maurizio Umberto Puxeddu.
On Tue, 2003-04-08 at 13:17, Andre Schmidt wrote:
hi,
as i got a wacom usb tablet lying around, i was wondering if it would be possible to use it as a controller for PD ?
so,
- what settings (and where) do i have to add to get tablet activated ? (but NOT as mouse for Xserver, you know; i want to use my normal mouse for Xserver and the tablet ONLY for PD)
- what external do i need for PD ?
i found "many" things in archive but none "ready to use" solutions for PD...
even "dirty hacks" would make my happy ;) (like copying tuner.o to tuner1.o to get 2 different tuner cards work with pdp)
thnx@advance -andre
PD-list mailing list PD-list@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-list