Dust Analyzer (still "beta") [was: quickie signal analyzer proto]

[mystran]

I finally got fed up with none of the spectrum analyzers doing quite what I wanted, so I figured I'd glue one together. So here's my idea of a spectrum analyzer (this screenshot is a bit out-of-date, will update at some point):



download (win VST, both 32/64 bits, requires SSE2 & OpenGL)

Features:

• log-frequency (20Hz to 20kHz) dB-scale spectrum (also does linear now)

• fixed 8192 samples FFT (Nuttall window)

• vertical division 10dB/line (totals 100dB from top to bottom)

• left (cyan), right (magenta) and "middle" (beige fill)

• draws in subtractive colors (IMO easier for eyes than additive, but additive is now an option)

• additional modes for scope, phase-plot, "bargraph" averaged spectrum in the current version

• fast update rate, audio processing is data-collection only

• the CPU cost (which isn't trivial) counts towards GUI thread, so it doesn't slow down audio processing

• from 0.6.0 it now should work with any sample-rate (well, 44.1kHz and higher)

Update 0.2.0 adds:

• optional linear scale (for high-freq analysis)

• fixed: middle-channel (was broken)

• freeze option (stops data update, survives editor close)

• peak-hold (simple "unreliable" maximum, reset on disable or editor close.. the latter is implementation limitation which might go away)

• optional display weighting (all unity at 1k): none, 3dB/oct, 6dB/oct, dBA (last one not well checked), could add more (request what you need)

• very basic (and inaccurate) mouse-over display functionality

• some other minor tweaks..

Update 0.3.0:

• some performance optimizations, cleanup

• slight color adjustment (mostly obvious for curves on top of fill)

• very basic scope-mode (sort of "virtual phoshor" type affair, auto-correlation tracking for stable wave-form analysis)

• probably some bug-fixes I forgot

Update 0.4.0:

• line-draw mode for scope

• "waveform align" for scope (tries to align two signals in L and R channels visually)

• basic X/Y plots (also "squared" version)

• various fixes, hopefully performance improvements etc.. (some more likely to come later)

Update 0.5.0:

• reworked tons of stuff for better performance

• now runs in a separate thread to hopefully reduce impact on other stuff (since 0.6 we are back to only doing software-render parts in a thread, rest is host GUI, since it appears more compatible)

• probably plenty of new bugs (there's a ton of new code, which is why I'm updating this before other plugins)

• sadly no new features

Update 0.5.2:
- fix the "GetThreadId" thing on pre-Vista
- add "dark background" color mode to spectrum view
- there is a known issue with eXT and GUI-lag when mouse is over plugin window (let me know if you see this with other hosts)

Update 0.5.3:
- fix the GUI lag issue with eXT

Update 0.5.4:
- work-around to allow pre-NT Windows versions to work

Update 0.5.5:
- should work in Reaper again..

Update 0.5.6:
- fix race that was causing Studio One to fail plugin scan most of the time
- added another "phase-plot" mode left/right: works like "normal" but 45 degrees angled (left on y axis, right on x axis); mainly intended for things like wave-shaper debugging (eg plotting "almost memory-less" functions: feed "wet" to left, and "dry" to right, etc..)

0.6.0 has arrived:

- some general bug-fixes found in framework code and such

- now runs in host GUI thread again, hopefully for better compatibility (just offloads the software-render parts to a worker thread now).

- implemented resampling for data-collection (internally it now always runs analysis at 44.1kHz for efficiency reasons), so it should now work with any host sample-rate properly.. this isn't tested very well (my audio-interface appears to have a "difficult day" when it comes to changing sample-rates) but it appears to work anyway..

- another analysis mode for "cooked" spectrum view.. basically 1/12 octave averages, but derived from the FFT and somewhat "too wide" to keep it smoother.. this always has 3dB/oct weighting and essentially tries to measure "average energy" so generally shows much less peaks than the regular spectrum (which draws the raw peaks from the FFT).

0.7.0:

- widened GUI to 720px (was 600px) for more "relaxed" feel

- somewhat re-organized controls (most obviously freeze is now first)

- added 4.5dB/oct and 12dB/oct scaling modes to spectrum

- improved "bar-graph" scaling and selectivity (still not "correct" but better)

- added basic sonogram display (might need more work), which does stereo with red=right, green=left, blue="loud mid" and "conventional" total power palette, please note that the "fast scroll" doesn't really show more information, it just scrolls faster (with interpolation) for visual purposes

---
original description:

Specifically wanted both channels always visible and some basic stereo correlation information. Also wanted an analysis window without significant side-bands and accuracy that can be trusted for engineering purposes.

Some other features I'd want (there's quite a list actually) are still missing, but as of the time of this posting, the project is less than 12 hours old, so it's highly likely that there will be certain additional features later. For the same reason it's possible that there are some oddities going on (the "middle" component does some weird stuff, so there's likely a bug), but in general it seems to work.

The reason I'm posting about such an early prototype: if you happen to like the general idea here, but would like to see some specific feature, I'm willing to consider if you let me know. However, there are some things (mainly "aesthetic" features) that I'm unlikely to ever include: frequency-averaging (eg 3rd octave bars), time-averaging (eg "slow falling") and curve-smoothing (to hide the low-freq resolution) are some of the things that are unlikely to happen any time soon.

Oh and.. mouse-over tooltip for freq/level is one of the things that will happen.

edit: updated the thread title since this is slowly getting past what you could sensibly call a prototype

[murnau]

your spectrum analyzers looks interesting and promising! it have everything i need. thank you!

[antto]

nice
i have been searching for a realtime stereo sonogram and nothing really worked
i needed it during the developement of my 303 synth for realtime comparison with the real thing, so i needed a quite fast scrolling sonogram that prints one channel in one color (red) and the other at the same place (blue) with additive blending
couldn't find anything already available..
so i coded my own (very crappy one) written as a standalone app
it has serious bugs and whatnot

i wonder if you can add a sonogram mode to this?

[antto]

it'd be useful either as VST or standalone (or both)
unfortunately, i'm such a poor coder when it comes to sound/graphics synchronization
i could do a VST with SE but i don't think i can transfere so much pixel data from DSP to GUI via SE's functions, plus, the FPS would be limited to whatever the Host decides, right?

[Urs]

If I may have a feature request beyond the obvious (Mac support ):

I would like to have an analyser that finds the "true peak" of an arbitrary frequency between the bins, i.e. the loudest frequency (or a set of 3 or so peak frequencies) would be evaluated by measuring the peak(s) of the spectrum "between the bins". Maybe it could also visually represent exact frequency and magnitude of those peaks.

When we analyse the gain of a resonant filter at various frequencies we always have to revert to RMS measurements because none of the analysers we have gives us an accurate reading. We would have to tune it into the exact bin freqeuncies, which may be tedious.

- Urs

[mystran]

it'd be useful either as VST or standalone (or both)
unfortunately, i'm such a poor coder when it comes to sound/graphics synchronization
i could do a VST with SE but i don't think i can transfere so much pixel data from DSP to GUI via SE's functions, plus, the FPS would be limited to whatever the Host decides, right?

I have absolutely no idea how SE works, but you probably want some means of copying the pixels as images (rather than calling a function for each pixel). But didn't you already have a nice scope in SE? As for the FPS, if SE draws in the editor "idle" method, then yeah, it's limited to how often the host calls that (where normally you can just use a timer instead).

As for the feature itself.. the concept sounds cool, so thanks for the idea. I'm a bit divided about whether to make this thing into a full-blow multi-function analyzer (which I wouldn't mind having) or just keep it simple (and avoid wasting a lot of time on it). I'd guess if I go the "also comes with scope and phase-plot and correlation meter and you name it" route, then probably such sonogram would fit in there as well.

[antto]

that nice scope in SE which you mention, that was my attempt to make something like a CRT scope
it was there that i figured this limitation, i use SE's functions to send data (aka signal data) from the DSP to the GUI thread
maybe there's a more hack-ish way around this but i'm not so good
and yeah, the FPS in SE (at least the old version which i use) is determined by the Host

and i forgot to mention that it's important that sonogram to have a "Freeze" option.. so that it scrolls, but you can click it and freeze it to have a careful look (cuz it scrolls uber fast)

[mystran]

If I may have a feature request beyond the obvious (Mac support ):

I'll make sure all my plugin's support Mac the moment Mac supports me, or someone convinces me that I can do all the development and testing over an SSH terminal connection so that I can at least have a working keyboard.

I would like to have an analyser that finds the "true peak" of an arbitrary frequency between the bins, i.e. the loudest frequency (or a set of 3 or so peak frequencies) would be evaluated by measuring the peak(s) of the spectrum "between the bins". Maybe it could also visually represent exact frequency and magnitude of those peaks.

When we analyse the gain of a resonant filter at various frequencies we always have to revert to RMS measurements because none of the analysers we have gives us an accurate reading. We would have to tune it into the exact bin freqeuncies, which may be tedious.

So just to clarify: you want to automatically find the maximum point (in some "neighborhood") of the response? And you then want to know said frequency and the response at said frequency? I assume it would be "true" enough to interpolate the transformed data as long as the interpolation is "reasonable"?

I know the problem, and I actually have some sort of a solution in mind.

[Ichad.c]

A Peak Hold feature would be great - makes it easier to analyze transient data. Great job sofar!

[Ch00rD]

If I may have a feature request beyond the obvious (Mac support ):

I'll make sure all my plugin's support Mac the moment Mac supports me, or someone convinces me that I can do all the development and testing over an SSH terminal connection so that I can at least have a working keyboard. [...]

I've seen people using a similar approach, with a bunch of clever scripts and standard tools like GCC. In the early days of iPhone hacking some people used to do this quite a bit on iPhones as well (upload modified code, make, run tests, rinse, repeat).

[mystran]

A Peak Hold feature would be great - makes it easier to analyze transient data. Great job sofar!

Hmmh, yeah, I could do that.

[mystran]

Found the problem with the mid-channel, there was a mistake in stereo decoding so phases didn't match.. will be fixed soonish.

[mystran]

Update 0.2.0 adds:

• optional linear scale (for high-freq analysis)

• fixed: middle-channel (was broken)

• freeze option (stops data update, survives editor close)

• peak-hold (simple "unreliable" maximum, reset on disable or editor close.. the latter is implementation limitation which might go away)

• optional display weighting (all unity at 1k): none, 3dB/oct, 6dB/oct, dBA (last one not well checked), could add more (request what you need)

• very basic (and inaccurate) mouse-over display functionality

• some other minor tweaks..

regarding the peak-hold: it's true hold in the sense that it never decays unless reset, but "unreliable" in the sense that it will only update from "what's drawn" so if you want to capture transients (or maybe impulses?) I'd highly recommend running the data multiple times to improve chances that it gets noticed..

lin/log and weights can be changed while frozen and will apply to everything drawn, so one can take a "snapshot" and then cycle the options

please: suggestions on what "weights" are useful.. this are rather trivial to add but I'm not sure which ones to bother with..

[sinkmusic]

Once again, a nice tool from you, Mystran, thank you very much

[mystran]

Regarding the "middle" fill: it's calculated as the average of left and right channels (on the raw transform, not the amplitude values) such that in-phase "mono" signals measure "middle" at the same level as the individual channels (ie 3dB down from the "equal power" measure), since I thought it's visually more useful this way.