I think array "mouse hit" detection is more expensive than it used to be... I need to go back and optimize that code.

Assuming that a window system can generate 100 mouse-motion events a second, the moment the code takes more than 10msec to execute, no amount of latency will fix it! But your experience meanse that arrays are now at least a factor of 10, and perhaps a factor of 100, to do mouse detection on than they were in 0.38. This is certainly because of the extra options in specifying graphical variable ranges (e.g., you can specify "y(0:100)(0:50)" to constrain vaules to between 0 and 100 and graph them using screen coordinates ranging from 0 to 50.) I'm not yet sure if this is useful enough to be worth all the bother it's causing...

cheers Miller

On Sun, May 22, 2005 at 07:15:43PM +0200, Tim Blechmann wrote:

hi miller, hi devs ...

i just tested the HEAD branch in cvs concerning low latencies ...

the is a BIG problem with the arrays and low latency (not sure, if it's the gui communication or something data structure related). moving with the mouse on the displayed array results in audible glitches ...

using devel_0_38 and jack in rt mode, i can use a period size of 64 samples on my hdsp without any glitches.

using HEAD and jack in rt, i have to set the period size to 4096 (the hardware maximum, resulting in 171ms latency!!!).

i think, there is some room for improvements :)

cheers ... tim

-- mailto:TimBlechmann@gmx.de ICQ: 96771783 http://www.mokabar.tk

latest mp3: kMW.mp3 http://mattin.org/mp3.html

latest cd: Goh Lee Kwang & Tim Blechmann: Drone http://www.geocities.com/gohleekwangtimblechmannduo/

After one look at this planet any visitor from outer space would say "I want to see the manager." William S. Burroughs