1

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

test_slider_timer.png

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 screen-shot 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 Pure Data) 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 zeros 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 microseconds; and then changed from 0.366834 to 0.376884 (approx for 0.01, twice the change from previous) in 47 milliseconds - 1880 times longer than previous interval! So I'm not sure this is all that accurate, either...


The code:

#N canvas 160 223 312 218 10;
#X obj 47 19 hsl 200 15 0 1 0 0 empty empty empty -2 -8 0 10 -262144
-1 -1 10500 0;
#X floatatom 98 48 12 0 0 0 - - -;
#X obj 44 88 timer;
#X floatatom 92 122 12 0 0 0 - - -;
#X obj 44 62 t b b;
#X obj 44 173 print;
#X obj 44 152 pack f f;
#X connect 0 0 1 0;
#X connect 0 0 4 0;
#X connect 0 0 6 1;
#X connect 2 0 3 0;
#X connect 2 0 6 0;
#X connect 4 0 2 0;
#X connect 4 1 2 1;
#X connect 6 0 5 0;
Max N
  • 1,134
  • 11
  • 23
sdaau
  • 36,975
  • 46
  • 198
  • 278

1 Answers1

1

you are staring into the depths of Pd's scheduler: messages are worked through in bursts, between DSP-processing. so even if the GUI would send data continuosly (e.g. every 2 ms), Pd (core) will still process either within one tick (very short after each other) or in two sequential ticks (with a larger time span).

apart from that: never ever do a fan-out (connect a single outlet to multiple inlets), like shown at the output of the [hsl]: it's undefined behaviour. always use [trigger]

[hsl]
|
[t   b   b    f]
|        |     |
[realtime]     |
|              |
[pack    0    0]
|
[print]
umläute
  • 28,885
  • 9
  • 68
  • 122