Beat unstable in graphic animation

Dear p5 community,

https://editor.p5js.org/byxx/sketches/EuJCp1iVI

Although the basic functionality is there, it seems that the beat is not really(!) stable, which I considered to be cared for by p5 accurately…

thanks for help here!!
BX

1 Like
 if (frameCount % 60 == 0) blip.play();

the frameCount counts frames, so when the frameRate is not constant…
you could try a timer…
https://editor.p5js.org/kll/sketches/zenbBhwf7

1 Like

Great!

seems to be, but why? thought it to be a relyable system ressource…

will do.

Its a great help to walk through your example:
Maybe you would comment a tiny bit :slight_smile: on the animation logic. I am completely new to creating time intervals with the timer
Maybe I can ask just regarding this aspect:
Where in the code do you create a constant time interval and how does the rectangle know when its colour change is triggered.

maybe there is a danger to know about to let the transition only execute once and let it “wait” until the next timer trigger.

As far as I know the transition changes are running on frames in p5´s backgroud

THX
BX

ok, make a better one,
but not forget, my title was

MULTI TIMER

just a experiment


also you run on a PC,
not a industrial control with a realtime operating system
so, every time you start a other browser window
or other program, even only select a other open window,
the JS makes a HICKS ( or is even disabled for not focused windows? )
possibly you play little bit with FPS recording…

https://editor.p5js.org/kll/sketches/rkIQz9LhQ

1 Like

I once had the case that a transition once started never stopped, so this is pretty working in your example, but I don´t get how you achieved this. So its just a question getting a bit used to the behind the scenes working of frames and timers in p5. One new aspect for me is that the examples I know from the “MAKE- Getting started[…]” - book they don´t use time for the length of a transition but rather it´s intended to use a kind of var x += 10 concept (and constrains) with animations…So I try finding the overall traps for that programming concept in p5. Again, thanks!!!

1 Like

if you make a timer, your TICK is the millis() however good that is.

if you make a compare >= setpoint
you will never loose one, only it can be late…
still will recover to the millis tact.

any counter ( also frame count ) are not connected to a system time.
more to program execution time. these timer might “run away” over time.

1 Like

I remember that a Coding train tutorial example comments advantages of using millis() rather than frames… Will try to change it in my code, kicking the frames out…
starting animations on the setpoints, understood.

As far as i remember it seems not to be possible to reset the timer during runtime, once the program is executed.

THX

you talk about millis tick? , yes it is the millis since program start.


your OWN timer function
( you actually should start as a extra little project )
should have all that possibilities you expect.
esp:

  • one shot
  • auto restart
  • manual restart == reset
  • show time elapsed / to end ( also in % to make like a progress bar graph )
      • many more
2 Likes

makes sense. Thanks for the list: looks like powerful properties of the timer concept. Great!!

1 Like

If you don’t need to synchronize the graphics to the sound, you could just play an audio loop with https://p5js.org/reference/#/p5.SoundFile/setLoop

1 Like

I tested the graphic only by recording a screencast. i imported the video into a audio software to check the video sync to a stable click (120 bpm).

-> After a short while the video is running behind the audio…
So the frameCount in p5 at least is not stable for accurate bpm based timing with graphic animation. Running on my laptop with less cpu power the changes are more obvious while occuring larger.

as Kll mentions above, the solution might to be found in triggering the animation starting points with the help of the millis() function rather than using the frameCount concept… I have to test that in the future, starting out here:

function draw() {
var timer = millis();
print(timer);
}

hope, that millis() runs more accurate than frameCount

EDIT:
Also the millis() approach stays not in sync to a comparable stable bpm = 120 beat in a dedicated audio software.

https://editor.p5js.org/byxx/sketches/KUi1Xayag

A main problem is that you cannot write something like
if (timer % 1000 == 0){//do something} This -of course- would make sure to exactly count multiples of 1000 (which is one second).

So this obviously is followed by a workaround:
In the coding example the method of subtracting 1000 from the current timer value leads to a inherited error increasing over time with each computation by a repeated tolerance.

The result is also delayed if you test the screencast of the p5 editor´s graphical representation of the metronome on a audible (stable) beat after a short runtime…
With code like this we get the “impression” of timed events, but they are not “really” stable in depth in the above example found on coding sites…

At least I cannot really say if the timer runs absolutely stable, which would be the “#1”-directive for a perfect bpm.

Thx for help
BX

1 Like

-a- i expected you start with a function
-b- using >= dt allows being late: GOOD
-c- using time = millis(); allows being late adding up: BAD
-d- where you check your timer against what info?

https://editor.p5js.org/kll/sketches/g1wj1ZX66

but please note what happens if you play other browser window and come back to it!!!
well: windows and firefox browser and p5.js is NOT “RTOS” [555]


anyhow this would now be independent from frameRate (processing performance ) compared to your first approach

if (frameCount % 60 == 0){
1 Like
  • Screenrecording of the p5 editor
  • importing that video into Sequoia (DAW)
  • checking the visual information against the click of the audio software

Your version of the timer runs pretty stable.
Perfect!!

THX
BX

1 Like

ok, heavy testing,

i leave it open in a extra browser window and let it run 30 min
and the console print was all i needed.


now play incl. your “blip blip blip blop .mp3” too.

anyhow my metronome was first a proof of timer concept
now make the BPM user friendly adjustable?
https://p5js.org/reference/#/p5/createSlider

check again.

2 Likes

Kll!
Yeah, most important part. Stable bpm. Tested it so far. Looks good!!

Next things would be assigning fadeIn and Outs of the graphics. Each graphic should stay for some beats, then been faded out, while next graphic is faded in.
Better to assign certain beats or certain timer values? I tend to code like:
Just sketching the logic here:

// bpm = 60 or 80, 90, 120, etc. // to have the chance to set different tempos for the animation

//show graphic1from start of runtime
//(a graphic in this case is an array of characters spread over a grid, somehow would be nice to have a variable (object?) for a graphic to animate as one and not its individual elements of the array)

if (beat == 7){
//fade In graphic 2 
fade out graphic 1
} else if (beat == 14){
//fade In graphic 3
//fade out graphic 2
} else if (beat == 17){
//reset beat to 1
}

//repeat with graphic3 until last graphic

This would be pretty much it

THX
BX

1 Like

i not get what the metronome BPM have to do with the animation…
and what is “beat”
but for a state/screen thing best is to have a counter 1 … n
and that counter set ++
on a other timer who get the setpoint from a setpoint array

int[] screen_dt = { 7000, 14000, 17000 }

and that you can compare to millis again but now use

if ( millis() > screen_dt[state] ) state++;

UNTESTED

1 Like

the animation is triggered when a counter (beat) has a certain value.
the counter (the beats) runs faster when having higher bpm.

At least only a counter value should trigger the animation, not the bpm…

EDIT: It would be cool to say that a fade In (fade Out) animation can run for (1/2 beat, 1 beat, 2 beats), but it can have a fixed value, too. Not too important.
Most important would be to start a animation on a certain counter (or beat) value…

BPM is “beats per minute” and says that you have 60 (80,90,120, etc.) counts (beats,blips) per minute.

-> higher bpm, the counter (beats, blips) runs faster, so the animation time intervals from one to another are shorter

THX
BX

ok, misunderstanding, good so the animation goes with the BPM.
my timer_event counts, but that value is reset when it reaches the setBPM.
so you might use a extra counter what counts all events. YES, call it beat

check again just for show also a state concept…

let texts =" screen ";
let state = 0;

function screens() {
  if ( state == 0 && beat >= 7 )  state++;  
  if ( state == 1 && beat >= 14 ) state++;  
  if ( state == 2 && beat >= 17 ) state++;
  if ( state == 3 && beat >= 25 ) { state=0; beat = 0; }
  text(beat+texts+state, width/2-35, 150);
}

1 Like

will do, but I need some time to bring in the new timer/counter/beat trigger in the old code

THX!!
BX

1 Like

The Metronome runs great, working on the fade Animations…Is it correct to write everything in one file in the online p5 editor?

THX
BX

1 Like