VL.Audio Spectrum

I’ve recently watched the nice workshop by @kathi (https://discourse.vvvv.org/t/soundreactive-graphics/21379), and thought it would be nice to have an extension that quickly visualizes the spectrum.


Added it as a pull request here:

I have now actually added it as another extension inside VL.Audio.HDE.vl, is that considered good practice? And one question regarding that - are VL libraries automatically pulling in an HDE file if it is placed in the folder? I could not find out, where it is referenced. In any case, please let me know if you have suggestions for improvements!

And by the way: Really enjoyed the extension patching experience and working with ImGui :)


Nice one! Suggestions for further extension : Would be cool if you had some more control over the channels that are being displayed…

What do you mean by this? It is currently simply visualizing the input that is specified in the “VL.Audio Configuration” extension.

Well, the input count is usually 2 (or more), so what am I seeing here in the spectrum? A downmix of all channels? Only the first channel? I’d expect a channel selector or (maybe even checkboxes, one for each channel, to make a sum from it) and the display would be showing the selected ones.

I’m really happy you started this, it makes me dream a little :)
My audio interface (MOTU) comes with a set of really helpful audio meters like FFT and spectrogram, Oscilloscope, X-Y Plot, Phase analysis, … Those can be nifty to have in the right situation (and some of them should not be too hard to add with existing nodes…

What I really like in my interface is a combined view for FFT (line) and spectrogram that looks like this (ignore the EQ curve).
So, if you are ambitious… ;D

1 Like

Ahhh, yes, I see what you mean now! I thought you were referring to the new channel concept. Yes, indeed, it has to have a channel selector, will add it :)

A spectrogram would be best achieved with a DynamicTexture, right?

yes, that would be one option.
there is even one already (implemented as compute shader) in the FFT 3D Waterfall of an audio signal example patch (coming with VL.Audio).


this one displays linear frequencies. a logarithmic view would be even better…

I wanted to do a line view anyway but was asking myself half way, what additional info it would bring. Combining it with the spectrogram, and providing a switch in the extension to toggle between both views seems like a cool idea!

would it be possible to have a “scope” node/mode, then you could have various meters to show what is going.

  • oscilloscope
  • waveform
  • vu meters
  • lufs
  • spectrum

and probably more

1 Like



When adding VL.Stride to VL.Audio as a package (to include the spectrogram), I am getting this error inside the the Record BufferWidget of VL.Audio.HDE

Can I ignore this? Or is there a way how I can deal with this? The type of the pad is set to Buffer, can I somehow specify that the Buffer of VL.Audio is meant in this case?

Would Buffer [Audio.Buffers] work ?

It also accepts the notation of Audio.Buffers.Buffer I think.
But on another note, is it sane to have VL.Audio depend on Stride? Just thinking of export size etc, forcing a package as a dependency on users which they might not need / only in the IDE … or does the compiler somehow get rid of it if the dependency is not used in the exported code?

1 Like

I really don’t know and thanks for bringing it up! I actually just needed it for displaying the spectrogram shader… I guess that could also be done in Skia? But I really don’t know how and would need some help here on how to proceed. Otherwise I will simply remove the view for now and do it sometime in the future.

I also think having VL.Audio depending on stride is not a good idea.
unless it can be decoupled when exporting as to not add too much bulk.

the VLAudio package itself and VL.Audio.vl should not depend on Stride or Skia, but the .HDE file is allowed to reference Skia or Stride, it won’t be in an exported executable.

And the Buffer ambiguity needs to be resolved by specifying which buffer exactly, as mentioned by others above.


Yes, that works, thank you very much. Audio.Buffers.Buffer is also converted into that.

thanks for this! now shipping with latest vvvv gamma previews!