is there any way to count in pure data in ms but have the option to pause count and not only reset it?

[count~] can't pause. same with [timer]. There is no object such as stopwatch in pd?

I try to start counting in ms based on message 1. message 0 should pause count. message 1 again should resume. message 2 should reset the count to 0.

ok I found a solution

Edit: this is not so precise... how can I max it more presice?.

1, no need to use [zl reg] for a single float... just use [f].

2, AFAICS in Max [clocker] doesn't pause -- a bang or "1" always resets the counter to 0. A pausable timer implies the ability to resume without resetting -- this is not the same as [clocker].

hjh

FWIW, as far as I can see, this is what clocker does (though this abstraction doesn't implement tempo control -- could be done, I'm just out of time for now).

clocker.pd

^^ EDIT: Actually change the "select 0 1" to "select 0" so that any nonzero acts as a "go." I won't re-screenshot but I'll try to update the patch.

However this is different from pausing -- I'm sure it's possible to do that too, with a different abstraction -- it's just not clear to me right now what the desired behavior is.

hjh

I found a way like this. seems to work although looks massy

The problem with a [metro]-based approach is that the [metro] puts a hard limit on time granularity. You can get more accuracy by increasing the [metro] speed, but this uses more CPU.

IMO if you want real accuracy, then [metro] isn't the way to go.

At first I was going to keep a [timer] running continuously, and also accumulate a "total pause time" value to subtract from the [timer].

But then I realized... at the moment of pausing, it could "freeze" the pause time -- then, when you resume, reset the timer to 0 and add the last frozen time -- so at that moment, 0 + frozen time = last-paused value, 1000 ms later = 1000 + frozen time etc.

This type of thing is IMO much easier to do in a programming language, but with some clever traffic policing, it does work:

pause-timer.pd

For this type of abstraction, it's good to have a unit test -- provide a controlled input and make sure the output is as expected.

1, clear; 2, init the sequence; 3, "0 1000" to go.

input:  0 stop
input:  0 reset
input:  0 1
input:  0 bang
print: 0            OK
input:  250 bang
print: 250          OK (250 ms later)
input:  350 0       Pause at 350
input:  450 bang    Poll 100 ms later
print: 350          Still paused at 350, OK!
input:  600 1       Resume 250 ms later (time should not have changed)
input:  700 bang    +100 ms after the moment of resuming, then poll
print: 450          Result = 350 ms + 100 ms = 450 ms, OK!
input:  900 0

Unit test passed The paused duration between 350 and 600 ms does disappear as expected.

So you'll get full [timer] resolution without running a busy-counter loop.

hjh

Except... I just noticed the unused [t f f f] branch... I won't do a new screenshot, but this updated pd file removes that.

pause-timer.pd

hjh

thanks for that abstraction! however - Is there any way it will output the timer numbers constantly and not only when pressing poll / bang ?

edit: and my reason is that if I want to do comparison of two numbers - lets say if the timer that s running is larger then constant number - if the timer will not output the numbers constantly I might miss this logic when th timer is larger then the constant but the [>] object couldn't know it because the timer number was not flowing in real time. How can this issue can be solved?

edit2: I could bang the poll message every 10ms using metro but then we again have an issue on cpu?

@KMETE said:

edit: and my reason is that if I want to do comparison of two numbers - lets say if the timer that s running is larger then constant number - if the timer will not output the numbers constantly I might miss this logic...

What you're talking about is a timeout situation -- checking whether something did or didn't happen within x amount of time.

In the normal case, in Pd, you can do a timeout like this (no [metro], no constant polling):

Here, I'm using the word "start" and "stop," but they can be any messages being generated for any reason.

• If the user hits only "start," then the [delay] time expires, [delay] generates a bang, and you know that the elapsed time >= threshold.

• If the user hits "start" and then "stop" within the time limit, then 1/ you have the trigger from the user and 2/ the [delay] gets canceled (no erroneous timeout message).

When you're talking about a timer that can pause, that complicates it a bit (because [delay] wouldn't know about the pause).

But, to be honest, based on your requirement from the other thread -- when audio playback pauses (because of user action or the 30-second(?) timeout), you're always resetting the timer. When the timer goes back to 0, then pause is irrelevant. So I kinda wonder if the original question in this post stems from an unclear requirement rather than an actual need (though it is a kinda cool abstraction, and I'll add it to my library later).

After all, if you only want to stop checking for the timeout based on user pause, you can just stop banging the [timer] at that point... then, no check, no false timeout, and no need to over-engineer. Or using the [delay] approach, just "stop" the delay.

So there's a polling timeout that is aware of paused status, without using a special pausable timer. So this idea that you have to keep banging the timing object and the timing object should be responsible for not advancing when paused is perhaps overcomplicated.

edit2: I could bang the poll message every 10ms using metro but then we again have an issue on cpu?

[timer] shouldn't use much CPU... it's probably fine, and if it's more comfortable for you, feel free to go that way. I'm just pointing out that brute force is not the only way here.

hjh

Thanks. That makes much more sense to bang the poll message only when it needed (track is playing - message 1)