FFT-based Audio Analyzer

[digitalwhitebyte]

this is for single variable.

Code: Select all

my_Var = 0.0 / 0.0
my_Var = 0.0 unless my_Var.finite?
# => 0.0

[MyCo]

I wouldn't correct infinite and -infinite to zero... in most cases that isn't what you want.

[digitalwhitebyte]

your implementation is more correct,
I just wanted to illustrate an alternative method, of course, depends on what is your purpose.

[steph_tsf]

Just updated the .fsm with MyCo NaN eradication solution concerning the [imp] array. The Graph Curves module doesn't issue any warning anymore, when the analyzed signal is zero audio data. Thanks !

1. Unfortunately when the time-domain (IIR BiQuad) filtering is ON (I mean, the curve smoothing filter), there appears to be an issue when the analyzed signal is zero audio data. There is no issue when the IIR BiQuad output is not exploited. I assume thus that the problem is localized inside the IIR BiQuad. It looks like a denormalization issue. Such BiQuad got implemented using Green code. Can we add a denormalization protection using Green code, leaving a "non zero" audio strictly untouched, and eating a very small CPU time?
Thus, for reproducing the issue : a) set the "LPF Fb Hz " filter to 0.100 and b) double click the red - green - blue knobs in the D.U.T. control box. The problem only shows when before double clicking the red-gree-blue knobs, the CPU usage is above 40% or so. You thus need to select a quite fast timebase (say 0.10 s), and a quite long FFT (say 4096 samples) for taking more than 40% CPU usage, before zeroing the audio data. As soon as you zero the audio data, the program freezes - this is indeed a major issue. The above figures concern a Core2Duo at 1.8 GHz. If you run on a QuadCore i7, you need to select more ambitious settings like a 0.02 s timebase and/or a 32768 FFT size. When the program freezes, there is no decent escape. It is a crash. You need to quit Flowstone, and reopen the .fsm hoping the settings that caused the crash, don't get restored upon initializing. On the other hand if before zeroing the audio data you consume less then 20% CPU, you will see that just after zeroing the audio data, the system appears to continue working, in a degraded mode. Indeed, the phase curve and the impulse response curve don't appear anymore. For restoring a normal operation you need to change the FFT size, or change the IIR BiQuad "LPF Fb Hz" setting.

2. The centralized style is now working fine, accessible through the View property. By the way, how can I add transparency to a given colour, using Ruby code instead of Green code?

I'm attaching the updated .fsm

Cheers,
Steph

[MyCo]

the problem with the filter is the same as the problem with the minmax. There are #IND values in the phase array, that cause that the filter can't do its calculations anymore. Just because:

#IND + Value = #IND
#IND - Value = #IND
#IND * Value = #IND
#IND / Value = #IND

I've added the fix that I gave you before in extra modules and inserted it between FFT and further calculations. I've added arrow comments, so that you can spot them. With this inplace you could remove the error correction from the Ruby code that you've added earlier, because it doing the same twice doesn't make it better.

I've also attached a schematic that shows you how to work with colors in Ruby... very simple stuff

[steph_tsf]

@MyCo : thanks again ! By the way, what toolkit do you use for spotting irregular data in an array? And the "synchronised" attribute showing on your correction modules, what are they? Are they determinant in the error correction solution ?

[MyCo]

Well, when a module doesn't do what I want, I do check the inputs first. In this case I just used a Textbox on the Array input. For more advanced stuff take a look in the "MyDebug" section of my old S|M Toolbox:
http://synthmaker.co.uk/forum/viewtopic ... 83&p=89745

I synchronize all modules that I duplicate. This makes life easier, when you update your schematic. A change in one of the synchronized modules, is automatically done in all of the others. It's like a function that is used several times.

[digitalwhitebyte]

I measured the trig as the schematic, step by step.
too many triggers are accumulated when using double sources for the calculation,
you should delete the inquiry to static or variable data for user data, with a sample&hold primitive,
and eliminate excess trig, always using the sample&hold but taking the trig from one source only.

I hope you understand.

[steph_tsf]

Thanks again. Things are progressing rapidly.
- No more issues caused by NaN.
- Transparency (alpha) of the grids is now controlled from the centralized Properties.

What protection can we provide against the user selecting a fast timebase, combined to a long FFT, exceeding his CPU capabilities ? I tried implementing a "busy" return line from the Graph Curves module, blocking the timebase trigger, but that's bringing no advantage. With or without such device, in case of exceeding the CPU capabilities we still run into the "Flowstone not responding" status.
Instead of being trapped into the "Flowstone not responding" status, I would prefer the user getting a visual warning like "CPU overload - please reduce FFT length and/or use slower timebase".

For lighting the timebase LED, I'm using a 1/2 timebase divider, as quick fix. Is there a good one-shot (say 100 ms, duration not critical) that I can borrow from somewhere/somehow?

At the moment I'm still suffering from a fuzzy mental representation of the trigger matter in Flowstone. I have the diffuse sensation that the present .fsm is far from optimized what's regarding Trigger Galore and Back Trigger Propagation. The exact nature (and effect) of the two Sample&Hold after the two NaN eradication modules remains fuzzy for me. I feel uncomfortable because it seems to me that sampling the arrays over there looks quite random. Actually, when the sampling pulse happens (this is the timebase), you don't know what's happening in the previous module. Is the data available or not? In a "real hardware" circuit, by doing so you would run the risk that your sampling pulse comes while the the array gets updated, thus you would get corrupt data at the output. Just a feeling. I know it's different in Flowstone. No need to say, if you see a few rapid fixes for optimizing the trigger structure, please explain to me.

I sill don't know if I must eradicate unnecessary public variables here and there, for avoiding trouble when running multiple instances.

And last but not least, I still have not figured how to transform that workbench into a neat executable using the PC audio resources. How to transform this into a .exe installable software running inside a Windows (resizeable?), or running in Full Screen? How to connect on the Windows Audio system? Ideally, one would grab the audio after the Windows mixing console, which enables to mix/select the sources and the volumes of Analog Line-in, S/PDIF-in, etc.

Any help much appreciated.

[tester]

When I change "samples" (fft control) from 2048 into something higher (16k and above) - FS hangs (both cases, audio on, audio off). Can someone confirm?