Need some logo for the game…

Chai is clearly more extensible and has more cool stuff such as chai-as-promised.

With commit message format. For good example, see Angular's CONTRIBUTING.md.

Something is wrong with gulp-gh-pages

It probably involves invoking a server AND browser AND receiving the test results.

It is released!

Wow! io.js comes with many ES6 features by default. When it's released let's try switching to io.js!

Let's start with v0.0.0 and follow semantic versioning!

By enforcing strict equality, we have to worry more about the type, leading to code that is clearer in types.

To prevent legal issues in contributed code.

To prevent the root directory from overflowing

To keep the code clean, always perform a gulp lint on committing.

prfun add bunches of useful methods to promises, so I can be less verbose.

bundle-loader totally breaks debugging!

Existing Web Audio API abstractions I found (SoundJS used in the prototype version, and blip) are not fit for the use case of BEMUSE. Therefore, a custom sampler is needed.

Ideas:

Unloading Sounds

In the prototype version, the game is a separate page, therefore there is no problem when about unloading sound.

However, in this version, it will be a single-page application. Samples from BMS files should be unloaded in order to save memory.

Playing Blobs

Existing solutions mainly plays sounds from URLs. Since we will be loading samples from .bemuse files, they are embedded in blobs.

Contexts

To easily load and garbage collect sounds, a notion of contexts is introduced. A context can hold samples, and all audio nodes associated with it. When it is destroyed, all samples loaded inside that context are released. All audio nodes are disconnected.

The sampling master

Eventually, this Web Audio abstraction shall be extracted into its own project, maybe call it "sampling-master".

Currently travis doesn't build bemuse because of some problem with Esprima parser.

Have to update deps and try building locally.

By moving complicated logic to task/support folder.

To quote from the MDN:

One of the main design goals of IndexedDB is to allow large amounts of data to be stored for offline use.

And let's name that library, "Cachier!"

This is to allow referencing BMS files based on object hash. We can also checksum the payload.

Playable area aspect ratio: 9:20

Since we have different environment for unit tests (NODE_ENV=test) and building for production (NODE_ENV=production), we should also test if the production build works.

Jasmine's asynchonous tests support, even though it is improved in 2.0 (I'm very excited about that: no more runs and waitFor mess), but compared to Mocha, is still horrible.

We generally have two ways of signifying asynchronous operation state (successful or failure)…

The first is Node-style callback — callback(err) with null err to signify successful state. The second is to return a Promise.

Well, Jasmine uses neither! It expects you to call Jasmine's expect() function, and then call a callback. This is just unintuitive.

Therefore, it will be replaced with Mocha. Since Mocha is also more friendly towards Node.js.

By utilizing bms-js and process the song without any channel mapping specification. This puts the whole song on autoplay.

Make the default route "coming-soon" and display coming soon message. And publish it to GitHub pages.

Maybe just integrate with LiveReload

Also, display Growl notifications when tests pass or fail.