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.
Many, many fixes found after posting this on my website.
- drag n drop supported
- plays on OSX and iOS safari now
- random other hiccups fixed
there seems to be some remaining issues cleaning up when loading a new
song.
