If so, how do you do it in v.1 vs v.2?
For instance, I have multiple wavesurfer instances in the same window, each that have different methods of handling playback rate (timestretch vs normal etc).
I experimented in "next" branch... is this correct?
https://gist.github.com/mdahlgrengadd/fb25657bb54ed9b2314e4c9f3ac552b3
But for version 1 I dont know how to do it without forking.
Thanks!
/Martin.
I think v. 2 is the way to go. If it works for you, then I would just keep using the beta channel until we release the next branch.
Ok, guess its time to move on to the "next" branch! Exciting :-) Thanks!
Actually since the backend is initialised in the wavesurfer instance after registerPlugins is called you could just monkeypatch a custom backend in like so: https://gist.github.com/mspae/34b6ad436608c1887f3e32bd4fc371e5 (e.g. replacing this.Backend with your own backend class, which is then instantiated by createBackend)
Pros: Super easy, Actually I'm thinking if we should make the init and destroy methods optional for the plugins since for use cases like this they're just boilerplate. โ Cons: This pattern means you can't use "hot" enabling and disabling of plugins (= this plugin can't be dynamically called after wavesurfer was initialised) โ But then again custom backends are probably not the kind of functionality people want to enable and disable the whole time.
Your approach would definitely work also.
I was also thinking if we couldn't change the backend wavesurfer option. Currently it can be a string (WebAudio|MediaElement) โ What if we add a check if it's an object and then just use that as backend. (Kind of like the renderer option but with backward compatibility) โ Then you wouldn't even need a plugin and could just inject your own subclassed webaudio backend as parameter.
@mspae Thanks! Very useful information, and nice to know I'm on the right track :-)
But then again custom backends are probably not the kind of functionality people want to enable and
disable the whole time.
No, probably not. Nice option to have, but atleast not a deal breaker for me.
I was also thinking if we couldn't change the backend wavesurfer option. Currently it can be a string (WebAudio|MediaElement) โ What if we add a check if it's an object and then just use that as backend.
This would be one way to do custom backends in v.1 anyways.
@mdahlgrengadd Yes, although v1 also does some things a little differently. For instance the Media Element backend extends the Web Audio backend by using the util.extend function and relies on the global window.WaveSurfer variable, so you wouldn't be able to use ES6 class extends in the same way.
@mspae can you create a ticket and PR for an alpha release of v2?
@thijstriemstra I think it was already released as 2.0.0-beta01 โ Why a ticket and PR?
I suggest we announce the beta version on the homepage and encourage people to try it out. Then, hopefully, release by the end of May, perhaps?
@mspae I had no idea ;) And a ticket for a new release (where people can place feedback) is never a bad thing is it..
I can't find it in releases. A note as suggested by @katspaugh would be essential.
@katspaugh @thijstriemstra Announcement issue is: #1092 โ I've also made a release
The announcement on the website could probably be extracted from the issue. I'm unsure how to proceed with the generated documentation โฆ I would very much like to publish it on the website at the same time as announcing the beta. Then we can just refer to that for more advanced info, otherwise it will be the doc-syncing game again. Maybe the person (probably you, k.) who builds and releases can commit the built doc directory and rebase the gh-pages branch on that commit. (I've been trying to figure out the proper git way of doing that but haven't come to a good conclusion) โ How do you sync the dist directory with the gh-pages branch at the moment? โ Am I maybe overthinking this and we should just move the generated doc dir over (good ole copy & paste) and commit that โฆ ?

@mspae see #1090 for the docs issue.
Most helpful comment
Actually since the backend is initialised in the wavesurfer instance after
registerPluginsis called you could just monkeypatch a custom backend in like so: https://gist.github.com/mspae/34b6ad436608c1887f3e32bd4fc371e5 (e.g. replacingthis.Backendwith your own backend class, which is then instantiated bycreateBackend)Pros: Super easy, Actually I'm thinking if we should make the
initanddestroymethods optional for the plugins since for use cases like this they're just boilerplate. โ Cons: This pattern means you can't use "hot" enabling and disabling of plugins (= this plugin can't be dynamically called after wavesurfer was initialised) โ But then again custom backends are probably not the kind of functionality people want to enable and disable the whole time.Your approach would definitely work also.
I was also thinking if we couldn't change the
backendwavesurfer option. Currently it can be a string (WebAudio|MediaElement) โ What if we add a check if it's an object and then just use that as backend. (Kind of like therendereroption but with backward compatibility) โ Then you wouldn't even need a plugin and could just inject your own subclassed webaudio backend as parameter.