Aha, sorry I didn't realise that you meant the pointer on the screen. /Stefan On Thu, Oct 23, 2008 at 10:05 AM, Joel Matthys wrote:

Actually, this is an interesting question. Hid tracks mouse motion rather than mouse position, so it's not so easy to create a ChucK patch that depends on the mouse's position on the screen. (ie trigger a sound when the mouse is in the upper left hand corner.)

I modified the mouse.ck example below. It prompts you to enter the screen size (one could easily set this up as an argument; is there any way for ChucK to access this property without user input?) and calibrates the mouse position from the upper left hand corner.

This works fine if I move the mouse slowly, but it's not absolutely correlative to the pointer position on the screen. Any suggestions on how to refine this?

Joel

Chuck code follows:

// mouse-pos.ck

// make HidIn and HidMsg Hid hi; HidMsg msg; // make ConsoleInput ConsoleInput in;

// which mouse 0 => int device; // get from command line if( me.args() ) me.arg(0) => Std.atoi => device;

// open mouse 0, exit on fail if( !hi.openMouse( device ) ) me.exit(); <<< "mouse '" + hi.name() + "' ready", "" >>>;

int atZero, mouseX, mouseY, screenWidth, screenHeight;

// prompt user to enter screen size in.prompt( "enter screen width:" ) => now; in.getLine() => Std.atoi => screenWidth; in.prompt( "enter screen height:" ) => now; in.getLine() => Std.atoi => screenHeight; in.prompt( "mouse mouse to upper left corner and press enter.") => now;

/* alternative method - calibrate via mouse click

<<< "Move mouse to upper left corner and click" >>>;

while (!atZero) { hi => now; while( hi.recv( msg ) ) { if( msg.isButtonDown() ) { 1 => atZero; } } }*/

// infinite event loop while( true ) { // wait on HidIn as event hi => now;

// messages received while( hi.recv( msg ) ) { // mouse motion if( msg.isMouseMotion() ) { if( msg.deltaX ) { msg.deltaX +=> mouseX; } if( msg.deltaY ) { msg.deltaY +=> mouseY; } } // keep values within area of screen constrain(mouseX, 0, screenWidth) $ int => mouseX; constrain(mouseY, 0, screenHeight) $ int => mouseY; <<< "Mouse Position:",mouseX,mouseY>>>; } }

fun float constrain (float test, float v1, float v2) { Math.min (v1,v2) => float bottom; Math.max (v1,v2) => float top; Math.max (test, bottom) => test; Math.min (test, top) => test; return test; }

// end of mouse-pos.ck

eduard aylon wrote:

...

Hello list,

is there a way to track y-position of the mouse pointer. It's not in the manual. I know I can track the x-position with HidMsg.fdata

thanks,

eduard _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

Hello, thanks for you replies. However it seems strange that fdata tracks perfectly the pointer position (in range [0,1]) on the horizontal axis with fdata, so I'd expected that there would be a data member for the vertical axis. (i.e. fdata being a tuple) Check the attached patch that outputs fdata. Hid mouse; HidMsg msg; if (!mouse.openMouse(0)) me.exit(); while (true) { mouse => now; while (mouse.recv( msg )) { if (msg.isMouseMotion()) <<< "which: ", msg.which, "data:", msg.fdata, "Delta:", msg.deltaX, msg.deltaY>>>; } } eduard On Thu, Oct 23, 2008 at 10:29 AM, Kassen wrote:

2008/10/23 Joel Matthys

...

Actually, this is an interesting question. Hid tracks mouse motion rather than mouse position, so it's not so easy to create a ChucK patch that depends on the mouse's position on the screen. (ie trigger a sound when the mouse is in the upper left hand corner.)

Indeed, the cursor position is something to be dealt with by the graphical shell of the OS, not the HID device. They are related but still different things. It would be interesting to be able to poll the OS for various things; it's there to take care of the basics, as far as I'm concerned it can earn it's stay... the downside is that I understand that calls to the OS tend to be slow and typically not realtime; some realtime OS's have been made but the large two OS companies don't seem to think this is particularly important. There are realtime versions of the Linux kernel (and running one can make lots of sense for ChucKing) but I'm not at all sure that also means the X-windowing system will be rt as well.

On the other hand; some pointing devices *do* have absolute locations; tablets and touch-screens do and in that case the absolute position on the tablet should correspond to the absolute position of the mouse pointer and that's something we *could* poll HID for. Another potentially interesting angle might be the touch-pads on most laptops. I could see Laptop-Orchestra style uses for reading absolute locations from those as well as data like the amount of pressure used. Sadly the more exciting features are there, the less likely they'll be to be standardised. Multi-touch surfaces would be great to be able to talk to, as would be pressure sesitivity (finger drumming, anyone?) but I'm sure we could support those things (where available) across devices and OS's.

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

hmmmm.... actually in the src there's the following: <...> // for case: CK_HID_MOUSE_MOTION: if( CGGetDisplaysWithPoint( cgp, 1, &display, &displayCount ) == kCGErrorSuccess ) { CGRect bounds = CGDisplayBounds( display ); msg.fdata[0] = ( ( t_CKFLOAT ) ( p.h - bounds.origin.x ) ) / ( bounds.size.width - 1 ); msg.fdata[1] = ( ( t_CKFLOAT ) ( p.v - bounds.origin.y ) ) / ( bounds.size.height - 1 ); } <...> which tells me there exist fdata[1] tracking the y-axis position, but chuck complains when accessing fdata[1] as exceeding its dimension.. eduard On Oct 23, 2008, at 7:37 PM, Stefan Blixt wrote:

I agree that it is strange. It looks like a half-implemented feature. A commented out part in mouse-fm.ck backs this up:

msg.deltaX * .001 + a0 => a0; //else if( msg.which == 1 ) msg.fdata => a1; msg.deltaY * .001 + a1 => a1;

Judging by Eduard's example, which can never by 1, at least not on my computer. There should be some y companion to fdata.

/Stefan

On Thu, Oct 23, 2008 at 11:56 AM, Aylon Eduard wrote: Hello,

thanks for you replies. However it seems strange that fdata tracks perfectly the pointer position (in range [0,1]) on the horizontal axis with fdata, so I'd expected that there would be a data member for the vertical axis. (i.e. fdata being a tuple) Check the attached patch that outputs fdata.

Hid mouse; HidMsg msg;

if (!mouse.openMouse(0)) me.exit();

while (true) { mouse => now; while (mouse.recv( msg )) { if (msg.isMouseMotion()) <<< "which: ", msg.which, "data:", msg.fdata, "Delta:", msg.deltaX, msg.deltaY>>>; } }

eduard

On Thu, Oct 23, 2008 at 10:29 AM, Kassen wrote: 2008/10/23 Joel Matthys Actually, this is an interesting question. Hid tracks mouse motion rather than mouse position, so it's not so easy to create a ChucK patch that depends on the mouse's position on the screen. (ie trigger a sound when the mouse is in the upper left hand corner.)

Indeed, the cursor position is something to be dealt with by the graphical shell of the OS, not the HID device. They are related but still different things. It would be interesting to be able to poll the OS for various things; it's there to take care of the basics, as far as I'm concerned it can earn it's stay... the downside is that I understand that calls to the OS tend to be slow and typically not realtime; some realtime OS's have been made but the large two OS companies don't seem to think this is particularly important. There are realtime versions of the Linux kernel (and running one can make lots of sense for ChucKing) but I'm not at all sure that also means the X-windowing system will be rt as well.

On the other hand; some pointing devices *do* have absolute locations; tablets and touch-screens do and in that case the absolute position on the tablet should correspond to the absolute position of the mouse pointer and that's something we *could* poll HID for. Another potentially interesting angle might be the touch- pads on most laptops. I could see Laptop-Orchestra style uses for reading absolute locations from those as well as data like the amount of pressure used. Sadly the more exciting features are there, the less likely they'll be to be standardised. Multi-touch surfaces would be great to be able to talk to, as would be pressure sesitivity (finger drumming, anyone?) but I'm sure we could support those things (where available) across devices and OS's.

Yours, Kas.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos! _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users