DSP Robotics Support

Hi all,

I'm building an XY pad for a parametric EQ. Currently it works OK, but CPU jumps on mouse dragging.
A single point XY pad example is attached.

(Only) when 'catching' the point and grabbing it around, the CPU jumps to ~30%.
I wonder if I can limit the CPU jump. The issue is that the 'XY pad' and 'mouse control' prims are in RUBY, so I can't just add a "redraw limiter'.

Is there a smart way I can limit the Ruby based 'mouse control module' to restrict the data sent (let's say ~20 commands per second) - to cut down CPU? Maybe using 't' (event i,v,t) ?

Any other CPU save or other remarks and comments, BTW?

Appreciated,
Rocko

yes, you can do something like this:

Code: Select all

def method
if (time-(@t||0))<0.05) #time difference between current and last call is less than 0.05
return #prematurely return from function
end

@t=time
####your code####
end



Hi,

Thanks for the answer... But I'm having some issues with this solution.
When moving the mouse at fast speeds, the system does filter the data out (less triggers counted), but I've noticed that the last position (in which mouse movement has stopped) - is not correct since the filter uses 'return' (data is simply thrown away).

The attached schematic is a good example. The 'display window' can be used as an XY pad, for dragging the mouse in all directions.
'mouse' module will output X and Y coordinates.

See image:http://imgur.com/uqiBO92

There are two 'trigger counters' before and after the 'trigger filter'. these show that the 'trigger filter' really works and how effective is it.
However, even if 'trigger filter' is set to 1/1000 - the last value might not always be correct.

Can I build (in someway) a system similar to 'De-Zipper' which (I believe) transfers all the data but slowly?

I'm out of my knowledge here...

I'm not very good in Ruby,
so I don't know how to implement it,
but maybe what you need is a last final trigger on 'mouse button up'?

i throws an error, its because @f is nil...

i did a xypad a while ago, here is it, i also included an trigger limiter ...
the ruby code can be optimized if you like, but normally it shouldn't be any problem...

Hi,

Thanks for sharing appreciated.

On my machine, my original 'EQ_pad" takes upto 40% CPU on crazy dragging of mouse, while your "XY PAD 2" takes around 7. Impressive.

I'm no learning the difference between the two codes.

Let me ask you please what does this mean:

Code: Select all

@valx ||= 0.0
  @valy ||= 0.0

I'm not acquinted with that sign.

I also wonder why your code has a "mouseMoveCaptured x,y" command within the "mouseLDown" part?

Code: Select all

def mouseLDown x,y            
  captureMouse
  [b]mouseMoveCaptured x,y[/b]
  output 1,true
  redraw 0
end

It is followed by a mouseMoveCaptured x,y part anyway ?

|| means logical or, and is used as a trick here. The line is shortened, in full length it would read

Code: Select all

@valx = @valx || 0.0

And the trick is that the value only gets initialized to 0.0 if it doesn't exist yet. Any not yet initialized value is NIL and logical or of NIL and 0.0 will result in the non-NIL value. Any other number logical or'ed with 0.0 will result in the number.

Try this in a RubyEdit:

Code: Select all

b = nil
a = b
a.class #will tell you that a === NIL

And now this:

Code: Select all

b = nil
a = b || 0.0
a.class #will tell you that a === Float (which is the class of number 0.0)

And lastly this:

Code: Select all

b = 2
a = b || 0.0
a.class #will tell you that a === Fixnum (which is the class of the integer 2, as opposed to the Float 2.0)

The line you wanted to set in bold is a call to a method. The method definition follows later in the code (def mouseMoveCaptured x,y)
Calling this method from the mouseLDown method doesn't make sense anymore, but was needed pre 3.0.6.

Hi...

So I'm learning this.
I noticed that the pointer jumps to the X,Y point which is pressed, even if it is far from the original pointers location.

I'm trying to limit the mouse to 'capture' the pointer only if it is at the area of the pointer (pointer gets "sticky" only if mouse is on it). However I failed to do it. I get initialization errors all the time.

;-(

Without Ruby, from Parametric EQ in FlowStone.

Rocko wrote:When moving the mouse at fast speeds, the system does filter the data out (less triggers counted), but I've noticed that the last position (in which mouse movement has stopped) - is not correct since the filter uses 'return' (data is simply thrown away).

this isnt a filter, it is how a mouse work.

and it is a regular problem with the mouse -> parameter game.

i dont know how to do that in flowstone (yet, as i am using it for only 30 minutes) but you can solve that like this:

- get the mouse (down) coordinate data from outside the gui element, too

- then limit the range of the data using min(max(0, input), 120)