Best way to track the timing of user interactions

spikey

Whats the best time to measure the time of a user interaction? To be able to replay it properly?
I will need this to replay music (not audio, just playNote() ) in programs that may have a dynamic fps, because of more or less cpu load. I said not audio, because the played audio seems to be already independent of the current fps. What is a great thing to have already.
Had this problem, for my "Da Bean" game, where the jump animation took some time, and I wanted to make the jump duration independent of the current fps. I took the c) approach but, still not sure if my joy-con misses a button press sometimes or if my code has a glitch.

a) Just assume every loop run takes 1/60 = 0.016667 secs?
The approach from the music tutorial is, adding the assumed amount a loop takes to a timer variable. I guess this works well as long a run through the loop takes 1/60 = 0.016667 secs.
b) Just counting the loop runs and not bother about time?
as long I am staying in the same program, my first tests with just counting the loop runs was ok
c) sum up the return of the ~~timeDelay()~~ deltaTime() value, at the end of the main loop?
There was an inspiring approach from @Willpowered https://fuzearena.com/forum/topic/165/timers-produce-wired-errors-and-also-some-fuze-crashes/13 . It was to avoid timer issues, but could be used for the use case mentioned here as well.
d) just save compare the output of the time() function?
in every loop, to check if the replay action shall be executed.
e) set a timer with setTimer() to call the function to play the note, right after the time needed

I already invested a lot of time to think and experiment about this, but I would appreciate some input of you, because I think some of you have a lot more experience. Maybe also theoretical background. Maybe I am looking at it from the wrong point of view and it is a no-brainer: "Just go with 1/60 secs per loop, and you will not be able recognize the timing issues, because they are to small, or appear only rarely and go away?"

My experience:
b) counting the loops (is it the same as frames?) worked as loong I stood in the same program (recording and playing).
e) setTimer() is a bit tricky: there are a few things that it does not like (I do a separate post later). But the timing was the best I could get. Still not in every loop the same accuracy.
c) Because I had settimer() parameter passing issues I tried c) with my own timer related to the measured time a loop takes. Result: sadly its less accurate than the setTimer() execution
The problem I have with the timedelay() is, I do not know when it is the best time to call it: at the beginning of the main loop or at the end, or several times in the code to adjust accuracy (because it returns me always something different).

I appreciate any feedback.

PickleCatStars

I dunno but there’s a deltaTime() function in the 2d help section. It’s what you use if framerate isn’t constant, afaik...

pianofire

I did a bit of testing:

This has 3 counters:

Counting loops and / by 60
time() - start (where start = time() )
setTimer with a counter every 0.1 secs

1. seems to drift pretty quickly so I suspect that the interval is not very precise
1. and 2) seem pretty synced but when I put a heavy load on the loop 1 drops off (as expected)

So for real time recording 2) seems best to me

spikey

@pianofire Thank you very much, this is very helpful and it somehow explains, why my in-project tests (twiggling) were not yet successful. In my current project I did not try time() yet. So, thats hope to get closer to what I am looking for.