5

From my basic understanding, JavaScript audio visualizers are reflecting the music based on the actual sound waves. I would like to build something like a metronome (http://bl.ocks.org/1399233), where I animate some DOM element every x beats.

The way I'm doing this now is I manually figure out the tempo of the song, say it's 120bpm, then I convert that to milliseconds to run a setInterval callback. But that doesn't seem to work because the browser performance causes it to be imprecise. Is there a better way to make sure a callback is executed exactly at the same tempo a song is in?

If not, what are some other strategies to sync JavaScript animations with a song's tempo that's not an audio visualizer?

Update: something like this it looks like? https://github.com/bestiejs/benchmark.js/blob/master/benchmark.js#L1606

Lance
  • 75,200
  • 93
  • 289
  • 503

2 Answers2

7

I had a similar problem, in that setInterval could not be relied on to "keep time" over a long period. My solution was the snippet below: (in coffee script, compiled js is in the link at the end)

It provides a drop in replacement for setInetrval that will stay very close to keeping time. With it, you can do this:

accurateInterval(1000 * 60 / bpm, callbackFunc);

See my use case and example that syncs visuals with a provided BPM to a youtube video here: http://squeegy.github.com/MandalaTron/?bpm=64&vid=EaAzRm5MfY8&vidt=0.5&fullscreen=1

accurateInterval code:

# Accurate Interval, guaranteed not to drift!
# (Though each call can still be a few milliseconds late)
window.accurateInterval = (time, fn) ->

  # This value is the next time the the timer should fire.
  nextAt = new Date().getTime() + time

  # Allow arguments to be passed in in either order.
  if typeof time is 'function'
    [fn, time] = [time, fn]

  # Create a function that wraps our function to run.  This is responsible for
  # scheduling the next call and aborting when canceled.
  wrapper = ->
    nextAt += time
    wrapper.timeout = setTimeout wrapper, nextAt - new Date().getTime()
    fn()

  # Clear the next call when canceled.
  wrapper.cancel = -> clearTimeout wrapper.timeout

  # Schedule the first call.
  setTimeout wrapper, nextAt - new Date().getTime()

  # Return the wrapper function so cancel() can later be called on it.
  return wrapper

get the coffee script and js here: https://gist.github.com/1d99b3cd81d610ac7351

Alex Wayne
  • 178,991
  • 47
  • 309
  • 337
  • Doesn't really answer the question though. You might be able to get the tempo exactly right, but you're off by a fixed time because the music took some unknown time to load; I don't think there is a guaranteed way to know when the music starts playing. – Jason S Jun 21 '17 at 18:56
3

This post might be relevant:

The gist is that you run a function in your setInterval() slightly faster than your tempo, for example, every 100ms. Long example short, you can track whether or not it's time to play a "beat" by checking the value of (new Date()).getMilliseconds() and seeing if the equivalent of one beat in milliseconds has passed instead of relying on the not-so-accurate setTimeout or setInterval functions.

Even with that, music itself, unless generated by a computer, might not have perfect or consistent tempo, so accounting for mistimed beats could be a hurdle for you, which may be why using audio analysis to find where the actual beats are going to happen could be a better route.

Community
  • 1
  • 1
Cᴏʀʏ
  • 105,112
  • 20
  • 162
  • 194