itsjoesullivan

Very fun! Only cheated a little.

Picked one of these up last week. Sending it back this week. Had I known the current state of the Android tablet experience, I would have been more upset when ChromeOS lost the Pixel team.

It's interesting to see that Apple is still putting serious thought and effort into tools for musicians.

I put together iago[1] a little while back, from a few people's work, including a great article[2] by Hot Cashew on how he uses Emscripten to transpile the Ogg/Vorbis library to javascript.

[1] https://github.com/itsjoesullivan/iago

[2] http://hotcashew.com/2014/02/chrome-audio-api-and-ogg-vorbis...

Thanks! Yes, it looks like in Firefox (and some Chrome situations) the sound is effectively being scheduled in the past. Something to look into.

Richard Feynman provides a little color to Bohr's visit.[0]

[0] https://books.google.com/books?id=7papZR4oVssC&pg=PA132&lpg=...

Thanks! re: corner frequency, ha, yeah I maybe oversimplified the example code a bit. That code will, however, work, because the Web Audio API specifies a default frequency of 350Hz ( http://webaudio.github.io/web-audio-api/#attributes-17 ). You can also dig into the source code of the page for the code that makes the audio examples happen (search for "click", which will give you the click handlers).

I think we'll circle around and try again in a less naive way :)

Thanks! I think the answer is that it would fall down pretty hard if the tempo started varying, the reason being that the algorithm seeks out interval modes instead of averages, with only a little wiggle room.

In the testing section, the songs that we fail to identify correctly are usually those we couldn't get a "handle" on in the form of identifying common intervals. A varying tempo would exacerbate that problem.

Additionally, the question becomes: what is the tempo of a song that has an inconsistent tempo?