Support alternate audio vizualizers

[mbklein]

I did this so that I could plug in audioMotion-analyzer and make use of its full range of options. And it has a lot of options. Sample implementation of an alternative visualizer can be seen here, and how it integrates with the Viewer here. It's a bit clunky with all the refs and casting, but I couldn't find a way around it.

Here it is in action, with the same 15-second audio clip (redacted) and three different configurations:

audioviz1.mp4

audioviz2.mp4

audioviz3.mp4

The AudioMotion implementation could also just be pulled directly into Clover, but it would add another dependency you might not want.

[mathewjordan]

This is a pretty cool idea. I think we can figure it out but just need to document it.

Would be to cool to see this idea with https://wavesurfer.xyz/

Now that you have spent some time in the code, how do you think we can cleanup the Viewer Context and the config for the better? It seems like we have a highly customizable Viewer here, which is great, but I'm just trying to figure out the best way to let it be malleable without it becoming unwieldy.

[mbklein]

wavesurfer looks fun, and it already has a react hook. It's different from the other visualizers in that it represents the track as a timeline from left to right instead of a changing point-in-time graph – not a problem; just a different approach. I wonder how it would deal with streaming audio not loading all at once, especially for long streams.

I wonder if the context and config could be pluggable? Let different pieces (like the information panel) register themselves and be responsible for their own config/event logic? I don't think it would be that difficult to delegate.

[mathewjordan]

Hey @mbklein, I put some eyes on this again. I think we just need to add some docs for these options to push it through -- unless we wanted to tidy up configuration as noted above first.