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

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

@seb-harmonik.ar Great! So it seems that you were right from the start.

In my case, I'm sorry for my delay~ in understanding the the heart of the matter, dear forumites.