See baudline's color picker as reference: https://www.baudline.com/manual/color_picker.html

The color scheme could be stored as plugin state. Then, we could get rid of inih.

There are no license headers and no mention of the license. I see the unedited GPL3 license but is the code GPL3 only or GPL3 or later?

I guess it could be nice to have the grid add more values in-between the basic ones if the window is big enough.

If the numbers won't fit, smaller grid lines without captions could also be useful.

I think this could be useful to increase the perceived resolution of the spectrogram.

If I run my own build of the v1.0.0 release of Wolf Spectrum inside a GTK 2 host, I am unable to resize the window by dragging the resize handle in the bottom corner. Yet, for some reason, the official Arch build of Wolf Spectrum resizes fine...

Right now, they disappear. I guess the stroke width needs to be scaled so that it's bigger at higher frequencies.

Right now, the UI can block the audio processing.

When resizing UI window, wolf-spectrum doesn't act correctly:
a black (empty) band appears on the window anf if I reduce the window size,
the spectrum only show the top of the spectrum window, it's not resizing the entire window.
Maybe related to #31
I made a video : https://exode.me/videos/watch/23dd18a3-05e1-456b-afad-00b16907c8e4

Could it be possible to allow selecting different window functions?

I have two ideas for automatic scrolling control:

1. Sync to host or JACK transport (with optional stop delay to add some tail).
2. Use an audio threshold and hold time to pause when no audio is being fed into the spectrograph.

This could help the user analyse what have just happened, without the need to use a separate scrolling control within the spectrogram. It'd also make sure no space is wasted for useless "black" spectrum.

Instead of scrolling/moving the whole graph like a piano-roll just keep it static and update it line by line. Once at the end start at the beginning again overwriting the existing graphic buffer. This might be much more comfortable for the eyes (less motion sickness).

Look at how slow Wolf Spectrum gets after 20 minute of non-stop use:
https://youtu.be/C92wFP0CG7c?t=1739

Could this be some problem with non-freed image memory or something?

• The last release that worked was v.0.1.1.
• wolf-spectrum-vst.dll found during plugin scan, but does not show up in plugin manager.

Sometimes working with a vertical spectrograph is easier than a horizontal one, and vice versa.
Most that we have (built into EQ10Q and such) are vertical but I personally would prefer a horizontal one.

Also bring able to flip the scrolling direction would be great.

The ruler lines and captions are obsured by bright bins. Maybe it'd be good to draw that on top of the spectrograph?

Also: maybe some drop shadow could be useful for improved readability?

it might be nice to put Wolf Spectrum full-screen sometimes.

Right now it seems to be impossible under Plasma Desktop.

I also can't drag the window to screen edges to make it fill 1/4 or 1/2 of the screen, like I can with other windows.

Maybe it's because it's a dialog window?
Could this be changed? At least for standalone version?

Reproduced in Renoise.

It's hard to see the 1K label here:

The captions should probably be located outside of the spectrogram.

It seems to jump around in scaling levels, I think it's often showing wrong frequencies :)

The rulers are hiding the most recent data...

Here's comparison of how Log scale looks with different window sizes:

Using 2048:

Using 4096:

Using 8192:

Using 16384:

It's a bit strange, but only the highest window gives me clear view on the low frequencies.

I wonder if this could be improved somehow? I don't remember something like this form using say - Sonic Visualiser. I need to do a strict comparison though.
This makes me want to ask for even bigger windows sizes, since the time resolution is still pretty ok at 16k.

The spectrograph could be very useful as a studio tool in fullscreen mode - on a separate dedicated monitor or potentially a Raspberry Pi device.

The Wolf Spectrum windows VST crashes FL Studio when deleted, reloaded or when I open a different project file while Wolf Spectrum is in the previous project file. It closes FL Studio instantly and no crash log is created.

I tested and v1.0.0 and v0.2.0 has this issue but v0.1.1 does not.

Apologies if this is not the correct way to use issues, I have never reported an issue on github. FL support told me to report this to the developer.

I think some mouse-over highlight/on-click flash would be good to know if the menu registered my actions.

I guess it could be useful as some point to be able to render a spectrograph to a video file based on an audio file input. The original audio file could be muxed with the video.

Being able to select an arbitrary image resolution for potentially very high detail would be great.

Also a custom FPS (usually 30 or 60 FPS).

I could use this in videos to generate nice spectrographs in post-production to show users what a sound looks like in a video.

This is obviously a very low priority function, as it can (somewhow) be just worked around by recording a video from the spectrogram window (though the screen resolution is limiting the detail then).

Ideally, using a context menu.

Currently, the drawing code is very unclear. It needs to be refactored before going further.

For instance, the interpolation and scaling code should be removed from drawPixel.

One great thing Baudline and z Sound Visualizer have is the option to change the gradient used to draw the spectrogram data.

It could be grayscale, rainbow, thermal camera style etc...

Being able to define a custom one would be great.

I think being able to hide all the GUI elements and draw just the data is a useful feature - especially for creating videos about sound design, or just focusing on the data, and not control widgets.

Harmor and Renoise's spectrograms look more eye-popping IMO.

Right now, we can clearly see that the spectrogram moves in steps. There should be some vertical interpolation, so that changes are less abrupt.

How low an it go?

Smaller block size gives more time information, and faster scrolling.

I guess 128 or even 64 could be useful sometimes.

I compiled the plugin with:
MACOS=true BUILD_VST2=true BUILD_LV2=true BUILD_JACK=false make
I then copied the bin/wolf-spectrum.lv2 to /Library/Audio/Plug-Ins/LV2/ and the bin/wolf-spectrum.vst to /Library/Audio/Plug-Ins/VST/
When I launch REAPER and add the plugin on a track, it crashes (with both the LV2 and the VST).

I am running REAPER v6.47 and macOS 12.2.1. My other LV2 and VST plugins work fine.

The line width of the bins seems somewhat incoherent. Also, I would expect less dark purple, and more black. Not sure if there's really an issue here, of if it's just me.

Apparently, it's not really safe to use FFTW in a plugin. Perhaps switching to KissFFT would be better: https://github.com/mborgerding/kissfft

I would fix this using the usual translate(0.5, 0.5); trick, but it creates a gap between the textures...

(Checked elements have been fixed)

• It doesn't close itself on focus out
• It doesn't indicate the selected entry
• It doesn't indicate hover on items
• There should be some sub-menus

I wonder if it would be possible to create a generic, header-only context menu library 🤔