This is, of course, not particularly good, but it's where I'm at for the moment so it's happening.
I've spent most of the last two months not coding, so, not a lot to say here.
However recently I've picked up an idea for comparing track rollercoasters on Audiosurf that someone was interested in a while back.
The original thread is on the Audiosurf forums here and is basically asking for an easy way to sort tracks by the amount of traffic they have.
Retrieving traffic information involves digging through a .ash file locally or asking the servers for it. I've not done any experimenting in pulling that data from the Audiosurf servers yet, however I already had the code for retrieving the track shape, which is a good indication of the traffic a track will have and the speed it will run at.
So, in a few hours I put together a very quick program to pull the track shape (and global scores) for a named track. Very easy to do, and the result is posted in the thread mentioned.
But that doesn't technically compare the tracks, or order them or anything, it just allows for quickly viewing multiple songs outside of Audiosurf. Useful, but not ideal.
For a long while I left the application there, then I picked it up again a week or so ago and began work on a 'playlist' section of the application. This downloads a track shape for every song in a playlist with the eventual idea being that it will show an estimate for how 'quick' the track will be, allow sorting and re-tagging of [as-steep] to slower tracks.
It quickly became obvious once I had the "download lots of track shapes" code implemented that the Audiosurf server is struggling to stay up at the moment (indeed, whilst making the screenshots below, I had significant issues with the Audiosurf server timing out, even for single-song lookups). This is noticeable if you use the forums much and/or play the game a lot as the forum, scoreboards and logging in are often down. Obviously I don't want to make this workload any worse, so I've implemented a cache for the track shapes that stores this data locally as presumably a track shape shouldn't change unless the picked user is cheating.
To avoid accidentally pulling out cheaters, the app always goes for the last global score of the 'Elite' category, if there's no elite scores it goes for the last of the pro, then last of the casual. The assumption being that a cheater will hold the top spot and not be lower down on the scoreboard. Additionally the "single song" searcher that was initially implemented (and will be launchable from the playlist window) will allow you to store which rollercoaster you want to see locally.
Possibly will take it as far as YAAP (Yet Another Audiosurf Player) with tagging features, etc, not decided yet.
Oh, have an example image that's rather sparse. Much will be added, hopefully (click to view full size):
