BPM graphing

SpillerSpiller Senior Member
edited January 2012 in Code & Art
As I mentioned in another topic, I have made a small program which can create a graph over the BPM changes in a .sm file. This was just intended as a mock-up.
The result can be seen here (simfile is a piano medley):
[ATTACH=CONFIG]227[/ATTACH]
The horizontal line is the average BPM and the other line is the actual BPM at that time, measured from the bottom. The filling represent the difference between the average and actual BPM and the color shows how much this change is relatively.

Source + win32 binaries can be downloaded here: http://www.mediafire.com/?hic90ef78g4e49a
To show the graph for another .sm file, simply drag and drop it on the window. (Notice me if I forgot to include a .dll file, but keep in mind that it is a mock-up, bugs and/or incorrect graphing is likely.)
What do you think? How useful is this kind of graphing, which issues does it have?

Current issues:
  • I don't know how to read the total time of the file (without having to read the notes), so the program thinks the charts ends at the last BPM change.
  • STOPs are not yet implemented
  • Code is ugly...

Comments

  • RubberChickinRubberChickin Simfiler
    edited December 2011
    In the context of usage for Ts and rhythm games in general, i think it is pretty useless. No offense meant at all at the quality of the program but I just dont think it has a place in rhythm gaming. I hate bpm changes a lot and I try to avoid songs with them but rhythm gaming is not about being able read some information that tells you what is about to happen. It's about being able to "feel" the song and become "one" with the rhythm Any more information then provided would just distort the way the game is played. Yes bpm changes can be very hard to react to and, because of the speed mod, can make songs unplayable at your native speed setting but that just means you will have to spend more time learning the song. There are plenty of elements in this game that can make a song hard but we dont have features to accommodate for them. I don't see why bpm changes should be any different. Simply play the song more and practice and eventually you will master it just like every other element in TS.
  • Vote4NixonVote4Nixon BADministrator
    edited December 2011
    it might not be a bad addition to the rathstar chart previews if it's easy to implement
  • RubberChickinRubberChickin Simfiler
    edited December 2011
    Vote4Nixon;15543 said:
    it might not be a bad addition to the rathstar chart previews if it's easy to implement
    I could definitely see it being used in this way.
  • SpillerSpiller Senior Member
    edited December 2011
    Yes, this is intended as a chart statistics and not an in-game helper like Assist Tick or anything like that.

    I play mostly for my own enjoyment and not for scores/competition (as I'm not going to improve much anyway), so if there is anything which removes some of that enjoyment, I will do what I can to prevent that. If the BPM changes are stupid I use C-mod, if there is a lot of hands (as my keyboard doesn't support them) I uses a no-hands mod. If everything fails, I just don't play that chart. (Thirdstyle changed this a bit though.)
    So my ideal is something which tells me exactly what kind of chart it is, so I know if I need to apply any modifications or avoid that chart completely, before playing it.

    BPM changes is one part of this, but I would like to try graphing stuff like the density of certain patterns like stream, thrills, jacks and the like. It is hard for me to get this kind of overview with the chart previews, they are simply too large.
    How to properly detect these kind of patterns I have yet to figure out.


    Vote4Nixon,
    I don't know how easy it is to implement. I could port the parsing part to PHP easily, but I don't know if I can provide good results with GD... Anyway, even though I'm not doing this for use in Thirdstyle I can spend some time on modifying it or porting it to PHP if you guys could find it useful. It is not that much code after all.
  • cheezpuffscheezpuffs Senior Member
    edited December 2011
    the device seems both basic and effective, i like it! :D

    the problem is, that you stated, is that it can only detect different patterns in beats, shall i go find some others that might be able to help with this?
  • SpillerSpiller Senior Member
    edited January 2012
    Nah, I don't want help to this, that what makes it fun to me. I will try it out someday.
  • Vote4NixonVote4Nixon BADministrator
    edited January 2012
    Yeah if it's not too much trouble, it would be awesome to have this as people have often requested some type of BPM display for the charts. I'd imagine all you really need is the #OFFSET, #BPMS and #STOPS tags of the .sm files. What you'd need to do is write a php script that spits out a graph.

    If it is helpful, FFR already does this for NPS: http://www.flashflashrevolution.com/levelstats.php?level=1620, which comes from http://www.flashflashrevolution.com/tools/nps_image.php?id=1620
  • iskisk BADministrator
    edited January 2012
    For graphing in PHP there's a few decent looking libraries. Take a look at http://ezcomponents.org/docs/tutorials/Graph

    As for what the graph itself shows, I think the average BPM doesn't hold any real value. Maybe the middle line could be the mode BPM?
  • SpillerSpiller Senior Member
    edited January 2012
    I will give it a go on Friday/Saturday then.
    isk;15975 said:
    As for what the graph itself shows, I think the average BPM doesn't hold any real value. Maybe the middle line could be the mode BPM?
    'mode BPM'? Could you clarify?
  • iskisk BADministrator
    edited January 2012
    The most used BPM.

    e.g.
    40% at 120 BPM
    30% at 80 BPM
    30% at 60 BPM

    mode is 120 BPM

    It works well for most songs to get the BPM that is used as a base for x-mod.
  • SpillerSpiller Senior Member
    edited January 2012
    I see... I would say it depends on the type of BPM changes. The average BPM can be used to find the x-mod were the smallest total deviance will be. The mode BPM can be used to find the x-mod which will cause the smallest local deviance, at the cost of the global deviance. Personally I would rather base it on the average to avoid very slow/fast parts, but I guess it depends on both the song and the person playing.

    The line was actually intended to be related to the a-mod. The line is the BPM where aX * BPM = X, thus the BPM where the x-mod the a-mod generates the wanted BPM.

    But it would be rather interesting to program. The easy solution would be to make a list of every used BPM in the chart and then calculate the time those are in affect. Potential issues could be songs like the piano medley used in the first post. It contains over 750 BPM changes, where most of them are unique. Take a look at the file:
    #BPMS:0=111.396,2=119.712,3=119.593,4=120.64,5=119.853,6=119.577,7=120.508,8=119.372,9=119.62,10=120.404,11=120.673,12=120.185,13=119.431,14=120.114,15=119.555,16=120.596,17=119.35,18=120.855,19=119.815,20=120,23=120.06,24=119.119,25=120.371,26=120.404,27=119.902,28=119.81,29=120.442,30=120.098,32=119.864, ...
    It just goes on like that, I doubt this has been done by hand...
    Calculating the deviance of 750 different BPM values wouldn't be optimal (it probably wouldn't matter though) but it might cause some issues with finding the most used BPM. Since they are nearly all unique, the calculated BPM might end up completely wrong. This could be solved by combining similar BPM values, but how should this be done? If we try to round BPM values in this example, we would end up with 119, 120 and 121, which is not what we want. We could divide with 2, round it and then multiply it with 2 again to make a wider rounding, but just where should this limit go? Should it be +-0.5, or +-5.0?

    Another approach would be to create a list of BPMs ( 120, 140, 150, 160, 180 ) which could be based on the min/max BPM and then calculate the deviance from each of these with perhaps a Gaussian function? When the closest BPM has been found (lets say 140), this is repeated again with a new range ( 120, 130, 135, 140, 145, 150 ) and continue recursively until a desired accuracy has been reached. This as the opposite issues. If we have a song:
    40% @ 120 BPM
    35% @ 80 BPM
    25% @ 70 BPM
    then it might have grouped 70 and 80 BPM together, finding them larger than 120 BPM, and when it goes on recursively it selects 80 BPM which is the larger of the two.
    You would have to select the BPMs more carefully, but just how many and how large should the gaps be between them?

    In the end it is the same problem with both, so I would probably go with the first one as it is simpler and probably easier to get to work well, and I think the issues appears in fewer files.
    Well, I'm just thinking out loud here...
  • iskisk BADministrator
    edited January 2012
    A-mod currently uses the mode BPM, but it doesn't work for everything as you noted. For actual gameplay (as opposed to graphing the BPM) I would say the most useful value is the fastest BPM that contains playable notes. To find this an algorithm would need to take into account:
    - gimmicks
    - very small sections of notes, e.g. a single mini-jack
    - gradual slowdowns/speedups
    - similar, yet not the same, BPM values, such as in piano melody

    In this case, I doubt finding the mode, even with a tolerance, would be of any use. A 3 minute song that is 90% 120 BPM and 10% 600 BPM would need to use 600 BPM to allow for the entire chart to be playable.

    In the end, I don't see any practicality to displaying an average BPM. Using an x-mod based off anything other than the fastest playable section of a chart will result in a too-fast-to-read section.
  • SpillerSpiller Senior Member
    edited January 2012
    Sorry for the delay, RL just decided to trow some shit at me... I will start doing some work on this today.

    I tend to disagree, since 120 BPM when 600 BPM is used as base is about as unplayable for me as 600 BPM using 120 as base BPM. I would simply perform better at 120 BPM than I would at 600 BPM, as while both are unplayable for me at times, it is only 10% of the chart when using 120 BPM as base, as otherwise it would contain 90% too-slow-to-read sections. (Unless the chart is very easy when not considering the BPM changes, then I might do better with a lower x-mod. I simply can't read slow patterns which are dense.)
    But I guess it depends on the person...

    As I mentioned in a previous post, I think for a Thirdstyle related BPM grapher this line should be the base BPM that A-mod uses. This way you know the relative speed at the sections compared to the A-mod you use. I assumed this to be the average, but if this is calculated differently I would be interested to know how it does it.
  • kislerkisler Publisher
    edited January 2012
    I had the idea of a ten-percent drift a while ago, but I didn't know how welcome it was to the idea of a-mod. In simplest form, it takes the mode bpm, and also the bpms which define the range, and calculates the "percent deviation" (sorry, I don't know how else to describe it) in going from the mode bpm to the min and max bpms. From there it takes the larger of the two deviations and assigns an amod equal to either 90% of the player's amod (if the min was further distant) or 110% (if the max was further distant). Then it uses the smaller of the two deviations to assign an amod appropriately relative to the change it just made. If mode = min = max, of course, it just ignores this.

    I probably didn't describe that well, so here's an example using a song from TS:

    Monster in the Water has a mode bpm of 150 (the entire second half). It has a max of 465.5bpm and a min of 149.8bpm.
    Using min and mode: (150 - 149.8) / 150 = 0.00133333...
    Using max and mode: (465.5 - 150) / 150 = 2.10333333...
    Getting from mode to max is WAY LARGER than min to mode (as can be seen just from the bpms). So what the ten percent idea proposes is that the max, being the larger of the two changes, has a 10% increased amod. For example, I will use 1200 as the amod.
    a1200 * 1.1 = a1320
    Now we need to see how relative the min change is to the max change.
    0.00133333 / 2.10333333 = 0.000633913
    0.000633913 * 120 = 0.0760696
    So the resulting amod change would be practically nothing on the lower end, and the range for the chart (playing on 1200) would be 1199(TS floors numbers)~1320. This would make Monster in the Water and Magnum playable at higher amods, hehe. There's still slow/fast reading, but not nearly to the same degree.

    Oy. I can explain more if necessary.

    e: Found 2 problems.

    - Charts with small bpm changes become unintentionally aggressive (Everything Went Numb, Morty Miphon)
    - Charts with large but brief bpm changes become super easy (Destroyer)

    todo - find useful data from [min, mode) and (mode, max]; adjust tolerance so it's not jarring with smaller changes
  • SpillerSpiller Senior Member
    edited January 2012
    I do understand your idea but I'm not a big fan of it of two reasons:
    1) Using min/max BPM is a bad idea, as small gimmicks can trow it completely off. You can try to apply counter measures against those situations, but it will be very difficult to make sure it will work in every case.
    2) A magic constant is applied to the BPM. Just increasing or decreasing the BPM 10% in certain cases most likely isn't precisely what the user want. For example in Monster in the Water I need to decrease the BPM by 33% in order to get my optimal speed rate.

    So I don't think it will help much and I fear it might confuse the user at times by giving an unexpected x-mod. I think it is best to keep it simple if the user have to manually adjust the mod anyway.
  • iskisk BADministrator
    edited January 2012
    Spiller;16386 said:
    Sorry for the delay, RL just decided to trow some shit at me... I will start doing some work on this today.

    I tend to disagree, since 120 BPM when 600 BPM is used as base is about as unplayable for me as 600 BPM using 120 as base BPM. I would simply perform better at 120 BPM than I would at 600 BPM, as while both are unplayable for me at times, it is only 10% of the chart when using 120 BPM as base, as otherwise it would contain 90% too-slow-to-read sections. (Unless the chart is very easy when not considering the BPM changes, then I might do better with a lower x-mod. I simply can't read slow patterns which are dense.)
    But I guess it depends on the person...

    As I mentioned in a previous post, I think for a Thirdstyle related BPM grapher this line should be the base BPM that A-mod uses. This way you know the relative speed at the sections compared to the A-mod you use. I assumed this to be the average, but if this is calculated differently I would be interested to know how it does it.
    As I said, a-mod uses the mode BPM as the base, not an average. Originally it used an average (hence the name), then a weighted average, but both of those produced practically worthless values for anything but a constant BPM chart.
  • SpillerSpiller Senior Member
    edited January 2012
    So I'm asking, how do you calculate this mode BPM? I do not see the point if the mode BPM I implement isn't exactly the same as in Thirdstyle. So is there done any gimmick filtering and which BPM will be chosen if a song is 50% 120 BPM and 50% 240BPM, to list some examples. Or is the mode BPM computed in an entirely different way than what I was thinking?

    I ported the parser to php a few days ago, so I'm going to do the calculation parts today which I will redo from scratch. I will implement average, mode and median (SM5) BPM to see how they compare which each other. My plan is to do it like this:
    [list=1][*]Create a BPM chart based on the #BPMS and #STOPS info. The chart will be based on timestamps (instead of beats) and will contain stops as 0 BPMS. Use the position of the very last note in #NOTES to put a final BPM in the chart. (Parsing of #NOTES not yet done.)
    [*]Remove duplicate BPMs (as I see some sm files sets the same BPM again and again).
    [*]Create a list of the used BPMs containing for each the total time it is used and in how many parts of the chart.
    [*]Separate 0 BPMs from that list and store it separately (for stats).
    [*]Use this list to calculate the mode BPM and average BPM. (Mode BPM will use the highest most used BPM, i.e. 240 BPM.)
    [*]Sort the list by BPM and use this to calculate the median BPM (based on total duration of each BPM)[/list](Some of these steps will be combined though.)
    Future things to try is to filter out some of those gimmicks which do not affect the note rate. But that will mean comparing the BMP chart with the #NOTES and I do not feel like doing that yet...
Sign In or Register to comment.