Before it was running a 1Hz oscillator for 10ms which caused a huge DC
offset when it was done.. Turns out it works if you just immediately
stop and disconnect it, without causing DC offsets or other problems.
The sample offset was incorrectly computed, and was including the sample
headers for all samples after the first one into the first sample's
data, causing various glitches at the beginning of the sample.
Fixes#10.
Closes#3.
The code which defines what the buttons do and downloads songs and so
forth are now completely separated from the player, which has the
following API:
- `XMPlayer.initAudio` -> starts up audio context; it's available as
`XMPlayer.audioctx`
- `XMPlayer.loadXM(ArrayBuffer)` -> returns `true` if loaded, otherwise
barfs randomly
- `XMPlayer.playXM()` -> starts playing
- `XMPlayer.pauseXM()` -> obvious
- `XMPlayer.stopXM()` -> obvious; call this before loading a new one
Loading trackview.js is now optional; without it, the player won't do
any visualizations. Or, you can override the following to get callbacks:
- `XMView.pushEvent(e)` -> push an audio event onto the queue. Called
once per tick (about 50Hz, controlled by song). `e` contains fields:
- `t` - audio timestamp
- `vu` - Float32Array of RMS power (volume) for each channel
- `scopes` - [Float32Array] of oscilloscope data, one array per
channel; `XMView.scope_width` contains # of samples to produce here
- `songpos` - position in the song (# patterns played)
- `pat` - pattern number currently playing
- `row` - row within pattern
- `XMView.pause()` - pause visualization
- `XMView.stop()` - stop/reset visualization
Also disabled iOS hack, as it seems to be causing issues, and fixed a
minor drag-n-drop bug (wouldn't load if track was already playing past
length of newly loaded track).
To play without a viewer, you still have to stub it out. Not sure the
best way to handle that case yet.
