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
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 
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…
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