Bring back audio-reactive visualizer

[WoxTheFox]

The old Electron version of Nuclear had a built-in Butterchurn-powered visualizer with shuffle presets. It doesn't seem to exist in the rewrite, and the current plugin SDK doesn't offer a path to rebuild it: Playback exposes seek/duration/status but no raw audio signal, and Shell is limited to openExternal() for OAuth - there's no analyser/frequency-data hook and no supported way to mount a custom panel into the UI.

Would it be possible to add an audio-analysis hook (e.g. exposing an AnalyserNode or periodic frequency/waveform data from @nuclearplayer/hifi) via the plugin API, and a UI extension point (similar to how Dashboard lets plugins add home-screen sections) for plugins to register a visual panel/view?

This would let the community (or just me honestly) rebuild the visualizer as plugin.

[nukeop]

Hey, thanks for the suggestion, and for remembering butterchurn! I want to do it, but there's a technical obstacle: butterchurn needs HTML5 audio, and as Nuclear has been migrated to Tauri, from Electron, I had to disable that because on Linux it causes issues with bluetooth. That unfortunately rules out AnalyserNode or any nodes in fact as we don't have the audio graph, only raw volume up/down.

So I'll have to figure out how to either do the visualizer without HTML5 audio, or how to enable it without breaking things on Linux. And this was cause by upstream issues in Webkit, so it'd be hard to push a PR there within any reasonable amount of time.

[WoxTheFox]

That makes sense, thanks for the explanation, I missed that it been moved because of the bug

Given that, would it be worth exposing frequency/waveform data from the Rust side instead of trying to route back through the Web Audio API? Since playback is already handled outside the WebView, it seems like the native audio backend could run an FFT on the raw samples and expose that data through Nuclear's own API, so a visualizer could read frequency bins directly from Nuclear rather than needing an AnalyserNode in JS at all. That would sidestep the WebKit issue entirely rather than waiting on it upstream.

I don't know what you're using for the native audio backend (rodio, cpal, GStreamer, or something else), so I've no idea how easy or hard it'd be to get raw samples out of it for an FFT.

[nukeop]

Rust doesn't handle any audio. It just handles streaming.

[WoxTheFox]

Ah yeah, my bad I must've read it wrong. Well, evermind then, thank you for fast answers.