My issue is that when I drag a number box or slider quickly it is missing much of the data between the beginning and end of the drag. How can I get a number box or slider to output more of the information? I have tried using [line] and [line~], like with a volume control, but without any luck. It is also an issue when using [snapshot~] to convert [osc~] output to a stream of numbers. Much of the data is missing, even with a high [snapshot~] sample rate, like 3ms. The attached screenshot is a printout of a quick vertical drag of a number box. I would like to have more data, especially between 16 and 355.

@CalBassist Follow it with a [pack f 50] and then a [line] or [line~] depending on if you need message rate or audio rate, if you are doing message rate, be sure to set the grain size of [line] to suit your needs. Pd's UI has to quantize to pixels so there will always be gaps even if you drag slowly. Replace the 50 in [pack f 50] with what ever rate works for your need, 50 is good for most situations but occasionally 50 is too slow or fast.

Edit: I did not read closely enough, if [line]/[line~] is not working for you, can you give an example patch of when it fails for you? I can't think of a situation where this solution will not work, but maybe someone else can.

@CalBassist If [snapshot~] every 3 mS is too coarse-grained for you, the next and fastest thing you can get at control rate is 1.45 mS. Otherwise you're gonna have to switch to audio rate, which is what @oid suggested above when he mentioned [line~]. Another way would be to put [sig~] after the slider and then [slop~] or [lop~] its output. Edit: Note however that if you use [lop~] the output value may not reach its input value. I don't think [slop~] has that issue.

Thanks! Your help got me pointed in the right direction. [vline~] > [snapshot~] ended up giving me my desired results.

Sorry to hijack this topic, but here's what I thought should be a simple control rate solution, but it looks like a slider only updates its own value every 8 mS. I was expecting to see 2.9 mS intervals.
slider update rate.pd

@jameslo wtf I expected 64 samples. It can go down to zero:
slider-min-update-rate.pd

Is this related related? [Pd-list] pd-gui update rate (2011)
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/thread/NFL5EIGEJQII7G5X5FXGM2WXDM6W4263/#KJSQGTRBJVBZGMQPHFYRGYBQXN7GSOZL

@jameslo And when filtering zero, there are different timings at different samplerates and dsp on/off also differs.
At 48kHz samplerate and dsp off, lowest is 4 ms but very very rarely goes as low as 2.66667 ms.

slider-min-update-rate-nonzero.pd

@jameslo My test........ as I remember [timer] reporting "The timer object measures elapsed logical time. Logical time moves forward as if all computation were instantaneous and as if all "delay" and "metro" objects were exact."
try.zip
All values are sent by the slider banged at a 1msec rate, and are fast in 0.55.2
Keep the slider sub-patch open or [metro] cannot be stopped.

Much earlier versions of Pd were not so fast, with some values repeated or not sent.
Pd better? Wish86 better than Wish85?.

It looks as though a [metro] fine tuned to the actual reported time could maybe achieve a stable [realtime] value... I will try when I get a moment..
It gives 3 values per 3msecs with jitter.
DSP off.

With DSP on the timings are very stable though and suggest 10 sub-divisions per block.... but none of the maths I have tried so far correlates to samplerate and/or screen refresh.
10 values per 10msecs, so not per block either.

Some thoughts I wrote before actually testing.... which seemed correct at the time of writing but are not confirmed by the control rate test..... so a large pinch of salt required....

"As said above, the intermediate values cannot be recovered, but can be approximated by an audio rate object.
As @jameslo says [lop~] will not arrive at the final value, and introduces a delay (phase shift).... https://forum.pdpatchrepo.info/topic/11850/explanation-for-lop-object-in-this-patch-requested

[line~] and [vline~] will approximate in "realtime" at the samplerate. [vline~] better than [line~] as it works across boundaries and so values between ticks can be obtained.

And anyway, the audio samplerate is 64 values every 1.45msecs.
The control rate samplerate is 1 value every 1.45msecs.
If you drag your number box fast enough then you will exceed even the audio rate possibilities for capture, in much the same way as the values generated by your [osc~] at a high enough frequency.
It is only once back in the analog domain via [dac~] that you can have a smooth waveform.

David.

@jameslo Comms starts to fail with the console below about [metro 0.125] but all values are still produced by the slider........

David.

@whale-av Let me rephrase your answers to test my understanding:

My test doesn't cause the slider to produce more intermediate values because I'm moving the slider really fast, and the logical time values are not meaningful because the slider is moved in real time, whereas the computer is free to process logical time faster than real time.

I've always suspected I was living in real time, but it's reassuring to have hard evidence

I combined your last test with mine, and got the same result. I'm concluding that metro intervals shorter than an audio tick preserve the order of processing, but the evaluation of the following graph may be bunched up in-between audio ticks, i.e. so fast that the slider is effectively not moving as it is being polled.

How did I do?

slider update rate 2.pd

@jameslo Not sure..... if you are banging the slider and moving it at the same time then it is hard to interpret.
The fader can be moved by hand fast enough to cause trouble as the OP found.
Yes, certainly, if moving the slider faster than the speed that would create an output every 0.125 msecs it might not be reliable, but your test is mixing 2 effects so....?
I found that all data points were produced by my test at higher speeds than [metro 0.125] but the console print was failing.
Caveat.... was [tabwrite] still writing to the array?
I will try again at higher rates but if [tabwrite] fails to update the [array] then I will never be certain of the limit without console output.
Except that if a whole 400 point table is written it should indicate success.... unless the screen fails to update because Pd has effectively hung of course.

No idea whether cpu speed has relevance at todays speeds..... probably not.
Mine ... Processor Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2301 Mhz, 4 Core(s), 8 Logical Processor(s)

David.