billywm / jsmodplayer Goto Github PK

Recent update to Web Audio API caused speed issues. Other forks may have experienced and addressed these same issues. Check over their code. Probably has to do with sampling rate.

Portamentos often work accurately, but sometimes sound very off, or slide to high/low pitches that seem wrong

Sometimes fails to loop back at end of song - but only applies to some modules. Others loop fine.
Check whether this was a problem in the original code or if I broke something
Could be break, jump, and extended loop effects interfering

In one case this seems to result from a Dxx command at the end of the last pattern

Wean other browers off dynamicaudio.js. Unfortunately, support for the competing Web Audio API (audionode) is spotty. Opera currently supports neither.

• Web Audio API

Still not enabled on Linux and Windows in Chrome 12 (Canary). Requires --enable-webaudio flag anyway.
http://peter.sh/2011/04/web-audio-api-script-de-obfuscation-an-updated-ui-and-the-contentsettings-api/
Enabled in Mac Safari, Chromium (I think?). Have heard it's buggy, crashes

As support improves in coming months, use a library that abstracts over Web Audio API and Audio Data API

Now for the alternatives....

• Chrome:

Didn't use to support .wav for Audio elements, but now seems to according to:

http://www.jplayer.org/HTML5.Audio.Support/

Also didn't use to support .wav for Data URIs, but now seems to. May be problematic
Mar 2010: http://code.google.com/p/chromium/issues/detail?id=39713
Oct 2010: http://code.google.com/p/chromium/issues/detail?id=59367
First try to see if we can achieve gapless realtime playback.
Otherwise, try to see if we can pre-generate a whole .mod to .wav then play it
This should be possible with fast JS engines. Native players can do this in a few seconds

May have Data URI size limit

• Opera:

See about on-the-fly method. Failing that, try pre-generation method.
May have Data URI size limit

In some modules the notes don't ring out as long as they're supposed to. These could be due to use of extended periods. At least one module with this problem uses octave 6.

So-called XHR2 (now just a part of the normal XHR spec) allows specifying that an ArrayBuffer should be returned as the response. XHR2 is well supported across modern browsers.

Want to allow outside code interact more smoothly with the player, e.g. player.loadRemoteFile.then(.....)

A percentage of mods simply sound wrong, even without pitch bend effects. No clues on the cause as of yet (just generally poor sampling code?)

After many years of ScriptProcessorNode being officially deprecated without any actual replacement, AudioWorklet is finally live in Chrome 66 and Opera.

This should help with playback problems

https://developers.google.com/web/updates/2017/12/audio-worklet

Still an open Bugzilla ticket for Firefox support. Will want to feature-detect and allow falling back to the old system. Progress on other browser support unknown (At a glance, it doesn't seem to be coming to Edge soon).

Also need to revisit if these primitives are being used correctly for JSModPlayer. Good discussion about the difficulties of dynamic audio here: WebAudio/web-audio-api#1322

Communicate to outside world through either callbacks or events (callbacks probably preferable so that the player isn't tied to a browser environment. May like to support using this headless on Node)

A UI wants to know:

• Current row playing
• Samples(s) playing and positions within those samples

The containing page should be able to subscribe to changes in these properties.

ArrayBuffers weren't widely supported when this project started and does file-loading by processing a string to binary.

Do all loading and processing with ArrayBuffers directly.

Code seriously needs to be organized into one sane player object where user can instantiate it and just hit play. Do away with the globals and other practices.

Lay out player with CSS grid, make themeable (re-arranging into different styles like Protracker-esque via CSS)

See if typed arrays are useful for improving speed and memory use
Only supported on Chrome, Firefox, Safari(?). No Opera yet (?)
Can probably feature detect and store in normal array for Opera
Firefox and Chrome 11 both support almost all array types, except FF also supports Float64Array. Safari probably supports the ones Chrome does?

https://developer.mozilla.org/en/JavaScript_typed_arrays

A page about mobile safari (2010) says "Safari now supports the Blob class and many integer-type collections, like Float32Array, Int8Array, Uint8Array, Int16Array Uint16Aray, Int32Array and UInt32Array"

Add helper methods for inserting patterns, samples, etc into a mod file in memory.

New refactor uses import. For full browser support this still requires pre-building a package.

Provide a minimal Webpack setup that can transform and bundle the code.

Also commit a pre-bundled single file so people can just drop this into their project.