FFT-based Audio Analyzer

[MyCo]

@MyCo = the Ring Bus that's deployed for F Bus (frequency control) is tricky. Most of the time if you disconnect and reconnect the ring, it doesn't work anymore. One need to be very careful, connecting a F-pad before another F-pad, also connecting the "listener" (the MainView) at a certain stage. Only a few combinations work. Most combinations don't work. When it doesn't work, the Log pad and the Lin pad still control the frequency parameters - you see them changing in the detailed F-pad - unfortunately the "listener" (the mainView) doesn't grab the changes. How to improve this? Is there a connecting sequence to be observed on the Ring Bus?

Haven't discovered the problem yet. The connection order is somehow important. The "F Control" has some kind of sample&hold in it, so that changes in the bus don't run in an endless loop. So when you look at the bus as a loop with one output, the "F Control" has to be the one that is connected to the loop output.
You can see the "F Control" as: it stores any changes on the bus, but only outputs to the bus when the user interacts with it.

[steph_tsf]

Currently there are five identified bugs or annoyances in the FFT-based Audio Analyzer (and Spectrum-Meter)

1.
When using the Analyzer as single-channel Spectrum-Meter, fort avoiding recurrent annoying "nil" errors you need to set "Reference" to "ch1" instead of "Off". The "nil" errors are coming from the "Quadrant Fix" Ruby code, still alive (it should not), expecting some data at the input.

2.
I can't figure why the 64K FFT is malfunctioning. Of course I'm using a very slow timebase (5.00 sec) for ensuring all audio data arrived before computing the FFT. The easiest way to spot the bug is to use the Analyzer in single-channel Spectrum-Meter, inputting the audio signal on ch1.
Let's use the Flowstone Sine primitive as signal generator, and plot the spectrum.
For all FFT sizes excepted 64K, the resulting spectrum gets correctly plotted.
For a 64K FFT size, it looks like the window gets set to "rectangular". Is there an array size limitation in Ruby, like 32K perhaps? What's an integer in Ruby? +32k to -32k ? 0 to 64k ? Anything else?

3.
Vertical scale in decibels when using the Analyzer as Spectrum-Meter.
I'm considering the audio to be "full scale" hence a having a 0 dB amplitude when a sinus (or any other wave) is evolving from -0.999999 to +0.999999. Am I correct ?
When inputting a -20 dB sinus signal into the Spectrum-Meter, I'm expecting to see a -20 dB spectrum ray.
Actually, the Spectrum-Meter is plotting a -26 dB ray instead of the expected - 20 dB ray.
Can you please tell me what are the industry-standards in use, for clearing up this matter?

4.
The program freezes when the user overloads the CPU by selecting a long FFT combined to a fast timebase.

5.
When using the Spectrum-Meter, most of the time the information you are looking at, is at the bottom of the plot area, like the noise floor or any spurious spectrum ray that may emerge from it. In such context it would be great to have a button enabling to show/hide the Frequency control pads. Is there a simple way for doing this?

Steph

[MyCo]

1. When using the Analyzer as single-channel Spectrum-Meter, fort avoiding recurrent annoying "nil" errors you need to set "Reference" to "ch1" instead of "Off". The "nil" errors are coming from the "Quadrant Fix" Ruby code, still alive (it should not), expecting some data at the input.

In the "Quadrant Fix" code, use this:

Code: Select all

@in_phase.length.times do |i|

instead of this:

Code: Select all

for i in 0..len-1

Or even better, take a look at Ruby Array map method and use this with a block instead of the loop

2. I can't figure why the 64K FFT is malfunctioning.

When I remembered correctly, the FFT primitives have a size limit. But I'm not sure at this, maybe only the GraphFFT has this limit and the newer FFT primitives don't have that. That's worth a test.

3.Vertical scale in decibels when using the Analyzer as Spectrum-Meter.
I'm considering the audio to be "full scale" hence a having a 0 dB amplitude when a sinus (or any other wave) is evolving from -0.999999 to +0.999999. Am I correct ?

You can define 0dB as what ever you like. Decibels are relative. But yeah, for single signal amplitudes it's common to define 0dB for (-1to1 signals).

When inputting a -20 dB sinus signal into the Spectrum-Meter, I'm expecting to see a -20 dB spectrum ray.
Actually, the Spectrum-Meter is plotting a -26 dB ray instead of the expected - 20 dB ray.
Can you please tell me what are the industry-standards in use, for clearing up this matter?

The reason for that is, the FFT only displays the correct amplitude for frequencies that are centered in the FFT bin. You can do STFT and phase correction and other weird stuff to correct that. But I don't think it is worth the trouble. Maybe this is something for Martin, I think that's something that he'll like He did a similar thing for the pitch shifter he posted last week.

4. The program freezes when the user overloads the CPU by selecting a long FFT combined to a fast timebase.

yeah, you need to block triggers until the calculations are done. But your project is so terrible complicated to read, so I can't help you there anymore... I spend most of the time with scrolling through your schematic to find out, where a connection comes from

5. When using the Spectrum-Meter, most of the time the information you are looking at, is at the bottom of the plot area, like the noise floor or any spurious spectrum ray that may emerge from it. In such context it would be great to have a button enabling to show/hide the Frequency control pads. Is there a simple way for doing this?

This is actually pretty easy. You just need a button with a boolean output and a multiplexer that switchs the view and requests a redraw. But for this to work you'll need a view connector on your controls. I'll make an example... shouldn't take very long... just wait some minutes.

[MyCo]

Here is the display overlay switch as promised. I've added the "Quadrant Fix" fix, too

[steph_tsf]

So here is the bug/annoyances status after a few changes :

1.
MyCo fixed the "nil" annoyances when using the Analyzer as Spectrum-Meter (Ruby code "Quadrant Fix" edited).

2.
64K FFT is not anymore in the selection box, as rapid fix.
We still need to investigate why a 64K FFT/FFTGraph/iFFT is malfunctioning.

3.
Vertical scale in decibels when using the Analyzer as Spectrum-Meter.
A sinus evolving between -0.999999 and +0.999999 is now displayed as a 0 dB spectral ray.
Putting a -20 dB attenuation after the Flowstone "Sine" primitive, you'll see a - 20 dB spectral ray.
Actually this is only true when using the "SRS Flat Top" Window.
I guess most users will feel home. We keep it simple. We don't discount decibels because of RMS etc ...

4.
The program freezes when the user overloads the CPU by selecting a long FFT combined to a fast timebase.
Some time ago I tried adding a "busy_curves" Boolean managed by the "Draw Curves" Ruby code.
The idea was to use the "busy_curves" signal for masking any new timebase trigger.
Of course this was not enough. A lot of computing time is also taken by the Green FFT/GraphFFT/iFFT code.
Each "signal slice" could generate a "busy" signal. The "signal slices" are : ref, ch1, ch2, ch3, ch4.
Some logic like an OR gate would combine the busy_curve, busy_ref, busy_ch1 .... busy_ch2, elaborating a "busy_global" signal.
A new trigger would only be unmasked, when 25ms are elapsed after "busy-global" becoming False.
I'm hoping that doing so, Flowstone will behave nicely, allocating at least 25ms to the operating system after each computation cycle.
Having played with such scheme, I can say it is extremely dangerous.
As soon as Ruby detects a fatal "nil" error in the flow, Ruby interpreter stops, and your "busy" signal never becomes false. The trigger source gets masked forever. In such case, what we think to be a solution, is a real annoyance.
If we can't get rid of spurious/random "nil" errors, like Ruby needing time for creating float arrays when changing the FFT size, a discrete "reset error" pushbutton is conceivable, as last resource.
Shall we implement this? Are the foundations valid?

5.
MyCo provided an elegant way for showing/hiding the F control pads.
I moved the switch out of the plot area, close to the "delay" control area, adding a "F" label on top.

Let's name this version v1.00 (see attached .fsm)
Thanks MyCo

Steph

[steph_tsf]

I am now running Flowstone 3.0.3
Specifically inside the Analyzer area, the mouse doesn't transform into a hand when hovering on the knobs and buttons.
This is because we have the frames, and it seems they are considered a different way by Flowstone 3.0.3.
I tried modifying the layer stack using "bring to front" or "bring to back", without luck.

[steph_tsf]

Here attached, is a standalone version using the PC sound card Audio inputs and outputs.

[steph_tsf]

Added a few features.

[steph_tsf]

Today I did Analyse measurements on a loudspeaker, using a high-sensitivity microphone connected on a high sensitivity mike preamp connected to the "Right In" input of my sound card. The high frequency response curve appeared to be "hairy" and unstable.
Actually, the analog input of my sound card went overloaded.
I thus added VU-meters in the "assign Channels" department, for checking the levels during the setup.

Later on I repeated a few Analyze measurements, unfortunately I could not reproduce the results. The frequency response was barely recognizable, unstable and corrupt by random spikes.
Did I forgot to define the reference channel, which is the most common mistake? Not at all.
Actually, for ch1 to be used as reference channel, I selected "Gen" input instead of "Left In" input.

It is important to know what reference signal the Analyzer is actually using in his computation.

"Left In" is the analog loopback (done through a special cable or dongle), telling the Analyzer what's the actual reference signal present at the D.U.T. input. In theory, this must be the voltage on the loudspeaker. Practically, if you trust your power amplifier, you can use the voltage at the input of your power amplifier.

"Left In" is thus coming 1) from a DAC processing the digital Ref signal, and 2) from an ADC processing the "Left In" voltage. So, why-Oh-why shall we use a possibly distorted signal like "Left In" as reference, instead of the "Gen" digital signal that's available, internally inside the Analyzer?

When selecting "Left In" as reference channel (ch1), there is no delay between the reference channel and the analyzed channel (ch2). This is a decisive advantage. This is the configuration to be used.

When selecting "Gen" as reference channel (ch1), there is a delay counting in hundreds of samples, between the reference channel and the analyzed channel (ch2), caused by 1) the DAC transforming the Ref signal into a voltage, and 2) the ADC digitizing the analyzed channel (ch2). The Analyzer has a difficulty extracting the transfer function when there is a such delay between the reference signal and the analyzed signal.

I'm considering adding a .bmp inside the "assign Channels" department, showing the special cable or dongle to be used for re-injecting the sound card physical "Out" into the physical "Left In" (reference signal), when the signal to be analyzed is actually entering "Right In".

[Tronic]

I believe that the delay is generated by use of a card that is not ASIO.
and in any case you have to take into account the buffer of the sound card driver,
how much latency adds to the input.