New Style of Spectrum Analyzer - 33 Band

[wlangfor@uoguelph.ca]

Hi all, well I'm working on a more efficient spectrum analyzer and I am a real fan of the style with just squares.
I still need to add the square effect though So You will have ti use Your imagination.

It's probably going to require an efficient envelope for smoother peaking etc but maybe not, we'll see. I'm hoping I can avoid it altogether because right now I'm at only 0.25% CPU. And that's the goal.

So, be warned there is no prettying up yet but here it is:
(bottom post)

[wlangfor@uoguelph.ca]

So, I needed to do the math differently. It was the overall width / 33 and then that /1 for the db detector.

But, the problem was; Even when that was fixed the spectrum was all off. The results were not reliable and it's why I turned My attention to My LA School Shelf EQ.

It had a great spectrum analyzer which I'd found.

Anyways, If You want to make Your own don't make it using this simple prim. I'll do some testing using other methods and update this one as soon as possible.

[wlangfor@uoguelph.ca]

OK, well I was doing something else and I'd had the chance to pop in so if You want to finish this for Your own uses You can and here's the half updated schema:

[new file in last post]

So I was realizing too, resizing from a view tag is not always possible but cropping is. So that means If You make every band module wide You can then dynamically crop so that each one fits into a perfect 33'rd.

Just an idea, would look very pro.

[wlangfor@uoguelph.ca]

I really don't have much time to work on this; But I was able to get the automatic resize done.
Only for the first band though. Also, it's improved slightly - the only thing You'll have to do though is check the amount of entries in the array. An interesting idea is dropping all other items in the array other ones being utilized, would be quite efficient.

I guess the question comes down to would deleting the entries cost more than to continually loading them, and is there any latency caused.

So, that aside; This is now seem like something which could be utilized for a professional app. You'll have to divide by the number and the window to decide each relevant array number; And I have not done that.

Here's the newest version of the beta:
[download on last post]

[wlangfor@uoguelph.ca]

OK, nearly at the point where this is no longer a beta.

However, it uses more memory than I would like. I have a feeling that this has something to do with something I had to use two area clips. But, maybe it's the best route.

Have a look because it uses fft and it is fast and nimble. I question however how accurate it is. But maybe it's close to being something professional. I was just curious to see whether or not prims could beat ruby as I often do not find the ruby analyzers seem very accurate.

Here's the new file:
[file on last post]

[wlangfor@uoguelph.ca]

OK, here it is:

Still a pre-release, I find it's a bit sensitive and sometimes bands aren't shown. So I was thinking I could use a differentiator, like an average smoother which is not so destructive.

Here's an image (click to watch the Youtube Video version):


And here is the file:
[latest on last post]

[lalalandsynth]

I could definitely use one of those if its light on CPU.

[wlangfor@uoguelph.ca]

I've gotten this new version down to 0.2 - 0.3%

Here's the DL:

LA School - CPU Light 34 Band Spectrum Analyzer (Prototype) 20.fsm

Latest Beta, fixes issue with zero having negative value, defaulted to 40 hz

(67.26 KiB) Downloaded 880 times

The readings regarding CPU usage were a little misleading until I outputted to a vst. Once I had that was the result. I'll be adding a peaking with slower decay rate. That will be an option soon as well as speed and wether or not You want the band's squares to be rounded.

Pretty cool right? And it uses no images.

Best of all though is soon it will be totally vector. So it will automatically resize width and height, line thickness too based upon main module size. I do not think there has been anything like it. Supports any sample rate btw, automatically delineates dependent on width of module on a plain logarithm starting at 40 hz.

EDIT: updated so that the zero at the beginning is set at 40hz.

But I wondered does anyone know of a way to ascertain the exact array locale so that from a float decimal it con be converted to int more effectively? The rounding I'm using right now is too broad. And I would be more comfortable with the math if it were more decisive. I suppose My inability to find the relevant fix is I can'nt think of the correct terminology.

Thanks in advance.

[lalalandsynth]

Would it take less cpu to have a globel 25 tick rather then having one in each module ?

[wlangfor@uoguelph.ca]

Would it take less cpu to have a globel 25 tick rather then having one in each module ?

I changed that over to a 100 that's shared. But sometimes there are contradictions