Thought I might as well repost this here: Measuring the elapsed time for GUI (hsl slider) object events in Puredata? - Stack Overflow:

Consider this patch (code below, tested on pd-extended_0.43.4-1, Ubuntu 11.04):

I basically just drag the slider about, and want to see what is the time difference between two consecutive values emitted by the [hsl] slider. The [trigger] help (Triggering_messages_with_trigger) notes that: "the messages sent from [trigger]'s outlets occur in ZERO time with no delay between the events...". Thus, a bang goes first into the right inlet of [timer] which outputs "elapsed logical time", and then a bang goes into left inlet of [timer], which resets the timer. I collect the elapsed time and the slider value with [pack], and I [print] those values. The problem, as the screenshot shows, is that I get values like this:

...
print: 10.1587 0.462312
print: 43.5374 0.396985
print: 0 0.341709
print: 0 0.306533
print: 0 0.276382
print: 23.22 0.271357
...

This tells me that the slider changed e.g. from 0.396985 to 0.341709 in 0 ms, which should not be possible: there must have been some time elapsed for me to move the mouse (which would trigger the required handlers in the OS and PureData) in order to set a new value for the slider?!

So, why does this happen; is it expected; - and is there a PD object (or external) that would allow me accurate measurement of time elapsed between two consecutive output values of [hsl] slider during dragging with the mouse (accurate in the sense that all elapsed times measured should be greater than zero)?

EDIT: just found [realtime], which is like [timer] (and can be used as a drop-in replacement in this patch), but outputs floating point values; so I get plain zeroes no longer - however, I get prints like this:

...
print: 0.029 0.361809 
print: 0.025 0.366834 
print: 47.714 0.376884 
print: 0.022 0.386935 
print: 14.988 0.39196 
print: 36.526 0.396985 
print: 40.294 0.40201 
...

... which is still kind of unrealistic: e.g. slider changed from 0.361809 to 0.366834 (approx 0.005) in 25 microsec; and then changed from 0.366834 to 0.376884 (approx for 0.01, twice the change from previous) in 47 millisec - 1880 times longer than previous interval! So I'm not sure this is all that accurate, either...

The code: test_slider.pd

@sdaau_ml shot in the dark: something's going on between the GUI - pure data connection. The GUI runs in a separate process so maybe multiple messages are getting queued up and resolved at the same time

@seb-harmonik.ar thanks for that; I am unaware of the Pure Data internals - such as whether the GUI runs in a separate process - so it's great to have this noted down; cheers!

For getting the correct result, you only need to correct your patch a little. Just cross the cords and behold a lovely string of zeroes.

[t b b]
X
[timer]

In this way, firstly, trigger emits a bang that resets [timer] from the left inlet. Secondly, trigger emits another bang that gets the elapsed logical time from the right inlet.

Consider [timer] to be an exception to Pd hot/cold rules.

Have a nice day!

Hi all, hi @LandonPD,

Landon is right here, with your patch in the way it is you are actually measuring the time it takes you to drag between numbers, not the delay from the slider itself. To prove this, have a look on this patch: patch.pd

By using [line,] you will get a constant speed between two consecutive points, which in this case gives the constant output of 20ms.

Take care,
Gilberto

Thanks for the comments, @LandonPD , @gsagostinho - indeed, if I cross the wires:

... I do get a string of zeroes:

...
print: 0 0.291457
print: 0 0.286432
print: 0 0.281407
print: 0 0.271357
print: 0 0.266332
...

... but I'm afraid there has been a misunderstanding: that is not the correct result: the correct result is not to have any zeroes at all! (and so, the wiring in the OP should be correct: first you output the current measurement, then you reset the timer - so by next time it is banged, it would have measured some elapsed time). What I want to do it, as @gsagostinho put it, "actually measuring the time it takes you to drag between numbers".

Say at time t1, the slider is at value v1. Say I move the slider, and after time Δt - at time t2 - the slider is at value v2. Then, I could calculate relative velocity of value change as

(v2-v1)/(t2-t1) = (v2-v1)/Δt

But, if Δt is zero - then I'd get "division by zero" error (theoretically, infinity for the value change velocity - which is impossible, since I have moved the slider only by a finite amount in finite time).

This means, that whenever I get a zero as time elapsed between two GUI events, the measurement has been inaccurate/unreliable. A reliable measurement would give always a time difference > 0 for two different values. In fact, [realtime] shows that in the original example, the zeroes are result of truncating 0.00XX float type of values, so the system does in fact register that Δt is not really 0 - however, as I mentioned in the OP, that isn't really all that accurate either (if you use [realtime] to derive slider value change velocity, it will still be jumpy, even if you drag the slider with as even speed as you can). What I wanted to know is, if there is a better way of obtaining the timing between slider events - in the sense that the calculated value change velocity would accurately describe the actual slider movement.

As @seb-harmonik.ar pointed out, this is likely due to message queuing - and as far as I can see, there is no way of getting rid of that artifact (at least not in PD vanilla) - unless someone knows a better way...

Cheers!

I think, your first connection is the correct one, since you want to measure

... the time it takes you to drag between numbers".

I don't know what causes problem on your system, because on my (Pd-extended on Win7 x64) it's working OK:

...
print: 32 0.0251256
print: 20 0.0301508
print: 12 0.0351759
print: 20 0.040201
print: 12 0.0452261
print: 9.33333 0.0552764
print: 18.6667 0.0603015
print: 6.66667 0.0703518
print: 8 0.0753769
print: 6.66667 0.080402
print: 10.6667 0.0904523
...

@xbarbie If one wants to measure the time it takes to drag between numbers, then indeed you are right. But in that case, my patch above shows that a line object, for instance, makes the output be constant. This means that any fluctuation is due to your control of the mouse, how fast you click and drag, etc., am I not right?

Take care,
Gilberto

@gsagostinho Yes, I think that's what he wants to measure:

sdaau_ml:

I basically just drag the slider about, and want to see what is the time difference between two consecutive values emitted by the [hsl] slider.

So your example using [line] outputs the correct answer (constant time). IMHO the question was, why he got those zero times, which I could not reproduce. But maybe I just don't understand?

@xbarbie I see now, thanks for (patiently) explaining to me what was his question. Well, in that case the answer could very well be that with a fast movement of the mouse, you are actually skipping several pixels (that is, Pd is not refreshing every mouse movement) so any intermediate value will be considered instantaneous. If I sweep very fast with my mouse, I am able to get those zeroes. Ex:

print: 210.431 1
print: 0 0.0393701
print: 116.1 0

To get it, I just basically moved my mouse as fast as I could from right to left while already holding the slider's needle. My guess is that the whole thing took 116.1 ms, and that's why the intermediate value gets 0 ms. But that's just a guess, of course, and the reason behind it is beyond me.

Take care,
Gilberto

@gsagostinho, @xbarbie - many thanks for the comments!

that a line object, for instance, makes the output be constant.

That is not the issue here; to clarify better, I made a new patch, test_slider2.pd:

And to show what I get on my system, I made a video capture:

test_slider2.ogv

Notice how I drag the mouse slowly, and the other fader generally follows - but then suddenly, it jumps? That is because of the very small times occasionally provided by [realtime] - which would be the zeros if [timer] is used. So it cannot be "that any fluctuation is due to your control of the mouse, how fast you click and drag".

I don't know what causes problem on your system, because on my (Pd-extended on Win7 x64) it's working OK: ...
IMHO the question was, why he got those zero times, which I could not reproduce.

Thanks for this - this helps narrow down the issue; would you mind running test_slider2.pd and reporting if you get the jumps like I do in the video?

Now I think probably the problem is in the behavior of X windows event queuing (at least the version on my old Ubuntu 11.04), and possibly the way it interacts with pd-extended-0.43.4; would be nice to read reports of the behavior on newer Linuces too, if the "jumpiness" occurs there too.

Thanks all for the discussion - cheers!

Oh, now I'm starting to understand what the thread is really about. It's a tricky business because there are various factors to be considered.

We have to remember that we control our mice partially...software usually corrects the movement speed. For example, it corrects the movement for short distances, or slow movements, and things like that. A mouse without that software behind the curtains is somewhat weird. See if you can get different results by altering your mouse settings.

I would like to know what you find out, please keep reporting on this. Maybe we can all learn sthg.

I've read the following. Maybe some of you will find it interesting too.

"When the mouse is moved a given distance slowly, the pointer will move a shorter distance than if the mouse is moved that same distance quickly".

http://guides.macrumors.com/Mouse_Tracking_Speed

"What does Enhance Pointer Precision do? It's a simple concept. When enabled, the pointer moves more precisely when you move the mouse slowly, and more nimbly when you move the mouse quickly. It decouples pointer movement ever so slightly from a basic 1:1 relationship with mouse movement, and introduces something called the mouse acceleration curve".

"mickey: the smallest unit of measurement that the mouse's hardware can produce".

"The good news is that fancy enthusiast mice always override the default 125 Hz USB update rate. Both of these mice bump it up to 500 Hz as soon as they're plugged in [...]".

http://blog.codinghorror.com/mouse-ballistics/

http://arstechnica.com/civis/viewtopic.php?f=19&t=212782

http://en.wikipedia.org/wiki/Mouse_(computing)

I ran test_slider2.pd using Pd 0.43.4-extended on WinXP sp3, and there are NO jumps like the ones you get.

The movement is weird but relatively predictable, a quasi 1:1 thing. There are some jumps but they are relatively short, (especially when I move the slider at the left extreme shakingly).

I have t confess I haven't really thought about what your patch is actually doing. But you can be sure I did all kind of weird movements and there was nothing like your results.

(As for the patch at the very head of this thread, moving the mouse very fast also produced some zeroes, but never more than one zero...never two or three consecutive zeroes, no matter the weirdness of my movements).

@LandonPD Many thanks for reporting - it seems now confirmed that this behavior does not occur under Windows. Would be nice to hear a report from a Linux user, or a Mac user as well (although I suspect Mac should work fine too).

(Actually, a possible workaround for this in PD would be simply to set a threshold, something like 0.5 ms (= 500 μs); if [timer]/[realtime] measures delta t any less than this, we simply refuse to bang the expr for velocity calculation; the timer keeps on measuring, and next time a slider event is received, we should have the most current value at the time, and definitely a delta t > 0 - which should provide a more accurate velocity measure, than if the short measurements are included. But I do not have the time ATM to develop a test for this; I hope to get back to this once I do).

Cheers!

I tested your patch now on my Linux Mint machine and I have the same behaviour as you have on Windows, maybe even worse than with your video.

@gsagostinho Thanks for the report, - btw my video is taken on Ubuntu Linux 11.04, not Windows So this is definitely something to do with Linux - my guess is, I think in most Linuces, it is X Windows which is the main arbiter of GUI events to user-space programs, so this probably has to do with the interaction of X Windows and Pure Data. (I seem to recall that X Windows, if it cannot deliver a GUI event in time, it queues it for later; and thus at a certain point, I have two events - the current one; and the previous one that was late, so requeued for the current time - reporting in a quick succession - but I am not 100% sure about this). In any case, if this is the root cause of the issue, I guess there is not much Pure Data can do about it... (apart from tricks like thresholding). But hopefully someone will come up with a more accurate understanding of the problem - and even a possible solution Cheers!

Ok, that makes sense then, and your possible explanation involving X sounds very possible indeed. But let me ask you, was this only pure curiosity or are you having some concrete problem regarding these things? I mean, is there any patch you are trying to create or implement for which you need to solve this "issue" or was that only pure hacking curiosity? Take care! Gilberto

i tested under mac and I got changes of 0. never more than 1 in a row, but ideally it shouldn't happen at all. As I said before I think it's happening between tcl/tk and pd.
What happens is that tk is built atop whatever windowing system/compositor the system runs, usually X in linux and Quartz on OS X and something else for windows, i wouldn't know. The GUI portion of pd runs tcl/tk in a seperate process and sends commands to pd through a unix socket on OS X and linux (again I know nothing of windows). If multiple messages were queued up and sent at once it might cause the messages to read as instantaneous although the GUI process actually registered them separately and queued them at different times.

And what if they are not zeroes?

See if you can turn metro on with this zero detector:

ZeroHunter_01.pd

I haven't been able to get a zero again, fortunately or unfortunately, which means I couldn't turn metro on.

@LandonPD yes, on OS X i got the metro to turn on almost immediately after opening the patch. At this point I think it is clear that this is happening on Linux and OS X for sure