Project Logs

Collapse

• Game vs visualiser comparison (and other updates)

  laurens.weyn • 06/13/2016 at 19:31 • 0 comments

  I once again have free time to work on this! Unfortunately I missed the deadline for the anything goes part of the hackaday prize. Oh well.

  Anyhow, here's some notable changes:

  • Data sent to the light strip no longer gets corrupted! It used to sometimes go off sync somewhat and display random gibberish until it figured out where packets start again, but this is now fixed.
  • This also allows for higher framerates, though I haven't tested anything beyond 60fps (and I honestly don't have much of a reason to yet. Perhaps just to see how far it will go...)
  • Stop parsing is less "violent", and will no longer burn out your retinas when playing songs like Brain Power.
  • The camera setup has been upgraded! There's a paper diffuser and the exposure has been turned way down. Unfortunately, this means the camera can pretty much only pick up the light strip and not much of the room it lights up behind it, making videos pretty 1 dimensional. I guess you can't have everything.

  I've tried to explain how patterns are read, but I think seeing it visually might make it easier, so I've made this video with a stepfile in both a rhythm game (as intended) and visualised on my light strip side by side:

  
  

• How to determine when each note happens in a stepfile

  laurens.weyn • 04/27/2016 at 09:51 • 0 comments

  This was probably the hardest component of the software to get working. In order to read a step file, you need to know when each key happens with respect to time. (as a side note, it seems the Stepmania wiki has recently taken down the only resource on the internet on the format of .sm files. It's available on the wayback machine here: https://web.archive.org/web/20150506065854/http://www.stepmania.com/wiki/file-formats/sm )

  The beats of keys

  steps are stored in sets of 4 characters (one for each arrow), which are held in measures separated by commas. Each measure is passed at 4 beats per second, so if there are 4 sets of 4 characters, each one lasts a beat. If there are 8 sets, there's half a beat between each, etc.

  Alright, so we know the time in beats for each key, but we can only measure seconds since the start of the song, so we'll obviously need to convert that to the current beat number based on the BPM. Sounds simple enough.

  If only it were that simple.

  Seconds to beats

  As I've mentioned in the description, the BPM can change all over the place. These changes are given in a list, in the format <beat>=<BPM>. So, 0=200 means that the song starts off with a BPM of 200.

  But things get difficult when you encounter something like 24=100. So after beat 24, the BPM changes to 100. Note that this is beat 24, not the 24th second. This gets confusing.

  Your first instinct to solve this problem is probably an "as you go" approach. Increment a BPM counter proportional to the BPM of 200 as time passes (updated every 60th of a second or so) and when the counter hits 24, halve the speed to 100. This... might work, but it's very imprecise as these BPM changes won't all conveniently happen at exact multiples of a 60th of a second, so you'll begin to drift offbeat. What's worse, some gimmick/dubstep songs stack lots of these changes very closely together, which is sure to throw this off completely.

  Clearly, we need to make a function that takes in the seconds (as a double) since the start of the song, and returns the current beat (also a double). This is not straightforward. Eventually though, you might come up with a solution, at which point you'll read on to BPM stops and realise just how that solution won't work at all.

  Stops and negative BPM

  Stepfiles also let you stop the BPM. Of course, this can't be done with BPM changes, because if you have, say, 10=60, 20=0, 21=60, then at beat 20 the BPM will become 0 and beat 21 will never be reached. Therefore, stops are seperate from BPMs, and are stored in the format <beat>=<seconds>, where beat is on which beat the stop happens, and seconds is how long it stops before the BPM returns to normal.

  Now we're throwing seconds into this mess, and suddenly all that code that relies on everything being measured in beats falls apart.

  Then you learn that there's also "negative" BPM. When a negative number BPM is given, it will look for the next positive BPM change and jump forward the difference in beats when the beat becomes positive again.

  How the heck do I make this work...

  Clearly, this isn't an easy problem to solve. I tried 3 different solutions, and all of them failed on anything beyond a very simple or conveniently laid out song. Debugging this wasn't straightforward either, so I took a song's BPM changes and stops and I drew a graph on paper of beat vs time, so I could figure out if my functions were giving the right output. They weren't. Nothing was working.

  And then it hit me. "Hold on a minute", I thought, "Didn't I just solve this problem in drawing the graph of beat vs time?"

  The solution that was literally right in front of me the whole time

  At this point, I didn't know whether I should feel like an idiot or a genius. Nonetheless, I wrote code that converted each BPM change and stop to a BPMLine object, which is basically a set of line segments in the classic form of y=mx+c, and stored them in an array. Each BPMLine is valid for a range of times, and the array as a whole makes up the graph. To find the...

  Read more »

View all 2 project logs