Look very nice, I may end up using for https://museeks.io, gapless playback has been on the roadmap for a while, but WebAudio APIs have always been super cryptic, a higher-level API is very much welcome.
Thanks! Please do share if you choose to implement it (you can open a Github issue). I'd be glad to add any projects using it to the README.
Maybe you should use shorter example songs, so that you don't have to "skip to -2s" and can have the emotional experience of gapless playback.
How does this relate to https://github.com/regosen/Gapless-5 - looks like that is also recently updated.
Gapless 5 was actually the precursor to this library over a decade ago, so Rego deserves full credit. They built the first example of gapless playback on the web and I took inspiration from their techniques.
Gapless 5 has a built in UI and style. Our library is headless: you bring your own UI and controls. It just depends on what your use-case is.
Really appreciate you using XState!
really appreciate you building and maintaining it! state machines are the truth!
Perfect use case for a web based sample sequencer!
In the second demo, the audio for “Mama Tried” ended up in the track titled “Row Jimmy” instead of the track titled “Mama Tried” ;)
Also, the demo UI drops the playback state if you switch from one tab to the other; if you play a track in one tab, switch to the other tab, and switch back to the first tab, there's no option to pause the already-playing song. Thanks to this I'm currently listening to five instances of the Grateful Dead singing “Mama Tried” offset by about 5 seconds lmao
It's not gapless on firefox latest.
I run Firefox latest so it should work. There's always a risk when going from HTML5->Web Audio. There's an occasional blip that's impossible to avoid (or at least, I have never found a solution). It doesn't happen every time though. Try going from track 2 to track 3 in the second tab of the demo (if both are "READY" as web audio).
The problem with exclusively using the web audio API is that the entire track must be loaded into memory before playing it, whereas HTML5 loads progressively. So we use both to balance the techniques.
In prior versions of the library, we'd load the track in parallel to HTML5 and make the switch mid-track so it's actually far less noticeable even if it does blip. I'm considering adding that to the new version.
Another alternative is building a custom buffer using RANGE requests to exclusively drive it via the web audio API. But obviously that is a far more complex undertaking (and requires the server to support RANGE requests). I'm open to implementing it, though.