DSP Robotics Support

Here is my attempt for fixing the log..

that looks very cool! would we be able to do stuff like photosounder now with flowstone?

Youlean wrote:Here is my attempt for fixing the log..

Very cool Youlean! It is similar to what I've done inside ruby to fix it.

Jay wrote:that looks very cool! would we be able to do stuff like photosounder now with flowstone?

Off course it is. However, it is a very complicated thing to do. Trog made a streamFFT a while ago and it is not that hard to convert image into mem and then process that mem in stream.

KG_is_back wrote:

Youlean wrote:Here is my attempt for fixing the log..

Very cool Youlean! It is similar to what I've done inside ruby to fix it.

Oh, I didn't see that you fixed it already..
Thanks!

I've posted the fixed version to FS guru. Has some additional adjustments compared to the version here on the forum.

KG_is_back wrote:

Perfect Human Interface wrote:Hmm I have noticed another oddity in this. It seems louder (or higher amplitude) signals seem to push back the other drawn frequencies. So, for example, when the kick hits, the higher frequencies fade out (lower frequencies are generally greater amplitude at the same volume).

It doesn't look like this happens with the original version you uploaded, KG. Did you perhaps add something to limit the range of bar intensity?

I'm not aware of anything that may cause that. I didn't change anything that would affect Y input. What I've done though is that I now resize the Y array, so there is actually less strips and therefore they are wider.

Hey KG. I got back to looking into this. The difference is in the FFT array calculation. Immediately after the Float Array Section prim, in your original example you had multiplied the array values by .01 (which I bumped up to 0.5 or so for better visibility). In the newer version, instead of multiplying you put a Norm prim. This is what's causing it. The values are being actively normalized so the output scale is shifting based on the range of the input. Also Norm scales to a -1 to 1 range while your tooltip states that the graph expects a 0-1 range.

Perfect Human Interface wrote:Hey KG. I got back to looking into this. The difference is in the FFT array calculation. Immediately after the Float Array Section prim, in your original example you had multiplied the array values by .01 (which I bumped up to 0.5 or so for better visibility). In the newer version, instead of multiplying you put a Norm prim. This is what's causing it. The values are being actively normalized so the output scale is shifting based on the range of the input. Also Norm scales to a -1 to 1 range while your tooltip states that the graph expects a 0-1 range.

Oh yes.... the normalizing and scaling is there only for a basic show - don't consider it a part of the graph bar itself.
FFT outputs amplitude boosted by N/2 factor so I multiplied it by 0.01 to put it into reasonable range (I considered dividing by N/2 to be to small values). Next time I was even lazier and put normalize on it.
Don't get fooled by the normalize - it states it normalizes to -1,1 but in reality it finds the value with biggest absolute value and divides all other by it (so the value becomes either 1 or -1 and all others are in -1,1 range). The FFT graph outputs magnitudes which are always positive, so applying normalize will fit them into 0-1 range (since there are no negative values).

So if I go back to multiplying the values by .07 or something that be reasonable for use as an FFT display, yes?

Perfect Human Interface wrote:So if I go back to multiplying the values by .07 or something that be reasonable for use as an FFT display, yes?

Yes. And also it is wise to clip them so values above 1 will become 1, because values above 1 may produce unexpected results (extrapolating the color). It would not be a bad idea to try log-ing, exp-ing or square-root-ing the values. That's the field that may be experimented on - with visualizer like this (which is mostly made to look cool rather than be a scientific measurement tool) there are no rules.