How to get accurate mouse capture values

[billv]

I built a ruby version of the on/off matrix trigger.
when dragging at high speeds its not accurate.
can anyone help me avoid the empty spaces on a fast drag...?

Ruby Matrix Trigger.fsm

(82.49 KiB) Downloaded 1053 times

[trogluddite]

Hi Billy,
To be fair, a "green" version would do the same thing. The mouse is only polled at a relatively slow speed - so if the mouse has moved more than one box width in between "samples" of the position, there may be boxes where the 'x' position was never in the box. The problem will get worse the smaller you make the boxes
To make it reliable, you need to memorise previous mouse positions, so that you know the complete range of boxes which the mouse passed over.
In "psuedo-code" it would be something like this...

Code: Select all

def mouseLdown(x,y)
  if (in a box)
    @last_box = (calculation using x)
    @box_setting = (make boxes on or off)
    @boxes[@last_box] = @box_setting
    captureMouse etc.
  end
end

def mouseMoveCaptured(x,y)
  box_now = (calculation using x)
  (@last_box..box_now).each{|x|  @boxes[x] = @box_setting}
  @last_box = box_now
end

[billv]

Great...thanks Trog...

[billv]

Have made zero progress on this Trog, just havn't got the skills to apply your "psuedo-code"
to my modules.. I understand the principal, same issue
I had back in green many years ago when myco fixed it with the Float Array Draw Prim.
So I need some more help here if possible..
Trog, I'm defiantly not asking for a full fix on my fsm....
I need to get this technique 'down', otherwise my new draw wave/matrix trigger/modulators
are all dead in the water, with my main project.

Can we ditch my fsm and break the issue down somewhat.....?

My real question seems to be...

How do i get correct output for this one variable

Code: Select all

def mouseMoveCaptured x,y
    @x = x.to_i
    output 0, @x
end

[KG_is_back]

Try this one. You manually enter the x step. When you are draging the mouse and x difference between current and previous position is greater then the x step, the schematic automatically interpolates the missing values, sending outputs on each one.

[billv]

x difference between current and previous position

Sounds like what Trog was trying to tell me in a way, to "memorise previous mouse positions".
Seems to work ok....code looks easy too work with...
I should be able to get a result with this...
Thanks KG...

[tester]

I think you don't need to complicate things, just change the method. Use the whole area (and not individual ones), and simply calculate distances between mouse drag and mouse release (start-stop points). This will tell you from-where-to-where turn on or off, and unnoticable inaccuracy will be only on border release.

Mouse rate under windows is not that fast (by default around 100Hz? but it's "green" 100Hz), especially if you use faster pointer.

[billv]

Thanks tester....yeh method is wrong..even the basic on/off(single switch) dosnt
work right. new alt methods arn't coming easy...I spent a lot of last week trying just that,
and ended up rewriting the same way all over again...
I try, but just don't have the brain of a "coder"....it's not a good sign....
Just spent my first few hours with KG's fsm... trickier that i thought...
Hopefully i can work it out eventually and avoid plan B.

[billv]

It's a couple of months down the track now and i still can't get this technique right.
Closest I've got is with KG's fsm...
But have a problem i can't work out...
Below, the top line is mouse capture from dragging left to right
the bottom line is mouse capture from dragging right to left

ScreenShot014.png (1.83 KiB) Viewed 19822 times

Draw issue.fsm

(1.26 KiB) Downloaded 1015 times

simply calculate distances between mouse drag and mouse release (start-stop points). This will tell you from-where-to-where turn on or off

Though about this method a lot, but If I have to use the mouse release to calculate, how do I
draw the mouse capture while the mouse is still down?
i havn't made the attempt with this method cause i still can't get my head around that...

[tulamide]

But have a problem i can't work out...
Below, the top line is mouse capture from dragging left to right
the bottom line is mouse capture from dragging right to left

The right to left issue could have given you a hint: Indeed it's your code. You use a range to iterate, but ranges only go from left to right (or up, if that's the better image for you). So, a range of -5..0 works, while 0..-5 can't work. Catching the mouse delta will go negative in your calculation (x-@a) when moving to the left (x gets smaller).
I've corrected your code by splitting it into two parts. With numeric.angle (which returns 0 for positive and pi for negative) the ranges are either 0..shift for positives, or shift..0 for negatives.
I hope this description wasn't confusing!

Though about this method a lot, but If I have to use the mouse release to calculate, how do I
draw the mouse capture while the mouse is still down?
i havn't made the attempt with this method cause i still can't get my head around that...

[/quote]
This is not suitable for what you intend to do, so don't think about it anymore