Wavesurfer.js: 'ready' event only fires when using load() without the peaks parameter

[johnsq]

Hello,

When using load() without the peak parameter, the READY event is fired as expected.

Demo here.. https://codepen.io/johnsq/pen/wPMbPM

However, when loading in peaks from an array, the READY event is never fired.

Demo here.. https://codepen.io/johnsq/pen/KyVOLd

I understand that, with peaks, there is less processing to be done and the load time will be less, but it still would make sense to know when the file and peak array loading had completed.

Is this by design or a bug?

Tested on 1.4.0 and 2.0.0

Thanks

[mspae]

@johnsq Currently the ready event is fired if the audio was decoded, this isn't the case if peaks were provided because wavesurfer defers the decoding until there is an "interaction" (i.e. the audio should be playable). To remedy this there is a waveform-ready event which is fired if the waveform was drawn, but only when using the backend MediaElement.

@katspaugh @thijstriemstra I proposed to change this in #1210 but there wasn't a final decision in this regard because it would result in some form of breaking changes. (Relevant commits are https://github.com/katspaugh/wavesurfer.js/pull/1210/commits/ece8a56f6b00ffcd5e3d821bde42416477716a17 and https://github.com/katspaugh/wavesurfer.js/pull/1210/commits/78492178033264e3998e9b82849b22b18e4abf78) – I respect that this might be a problem since events are an integral part of the public-facing API of wavesurfer, so changing them will result in people's implementations breaking (even though I think that adding waveform-ready to the WebAudio rendering wouldn't necessarily be that dramatic – and I think this is more or less the only change necessary to make the events consistent)

I think we need to adress this issue (in some way) because the difference between MediaElement and WebAudio backends APIs are confusing.

Since I understand that backward-compatibility should be retained as much as possible I propose we add new events for a) a waveform is visible and b) the audio is decoded/playable (= media element's canplay event) – I think this would be good solution to this problem. (Although I think adding new layers of API in order not to break old APIs should be considered carefully otherwise there will undoubtedly be code bloat – I think in this case it is a good strategy)

So I propose:

• Deprecate ready and waveform-ready (and with that I mean: change absolutely nothing about the way they behave but encourage people to use the new, consistent events)
• Add two new events audio-ready and wave-ready (which behave consistently across both backends)

[thijstriemstra]

remind me to comment on this if i don't before the end of the week (would be a nice feature github!).

[mspae]

@thijstriemstra This is your reminder to comment :)

[thijstriemstra]

thanks @mspae your solution sounds good to me.

[rhaamo]

is there any fix planned for this issue ?

[but1head]

up

[thijstriemstra]

is there any fix planned for this issue ?

it's an opensource project, when there's a fix, there's a fix, if you can help, please do. Don't spam the ticket with things like 'up', thanks.