madbutter

I need to make an 8 band peak meter for a jitter overlay on some video so I was trying to search the forums for a simple example of how to draw one as a jitter matrix, and am challenged by knowing nothing about MSP or audio processing. I found a few things and ended up with a patcher that uses fffb~ to cut the audio up into different frequency "blocks" that I can use to visualize any sound fed from fffb~ into 8 meter~ objects placed right next to each other and it looks pretty good.

So I took a parallel path and sent the same data going to each meter~ obj and put it into a peakmeter~ object, clipped it from 0. to 1., and I'm trying to draw rectangles (black on white) using mgraphics by using the 0. to 1. value and scaling each rectangle to the height of my matrix. This does work, but when I put it next to the clumped together meter~ objs, my mgraphics example has "flatter" values then the meter~ objs. (the two examples move together when processing the same audio, but the meter~ objs scale better). So I guess meter~ scales the raw values (the ones it reports itself in its outlet) using some exponential curve when drawing the visual display of colored boxes.

Do I just need to play with the scale obj, for instance, until I find the right exponential value so that my mgraphics version matches my meter~ version or is there some commonly known or documented way that meter~ uses to take the (linear 0 to 1) signal values and map them to visually to light up the colored boxes?

(As a side note, I do not need accuracy in recording these values, I'm not doing anything with the audio data other than trying to "visualize it" in standard "graphic equalizer look" as video overlay, and for now the clump of meter~ objs more compelling visualize the audio then my mgraphics matrix). Thx!

making-8-band-peak-meter-w-mgraphics-what-exponential-scaling-does-meter-use

The mapping is shown in the Inspector, and is configurable. By default there are 12 LED segments (plus the red clipping LED), 3 dB per segment.

I read up on dBs (I warned you I know nothing about audio!) and learned that they scale logarithmically, which is why my "unscaled" use of the peakamp reading looked so flat. I got my mgraphics version of my 8 band peak meter to look good, after some experimentation, by taking my clipped (0. to 1.) peakamp values and running each through this expr obj: [expr log10($f1*9+1)] then multiplying that by the maximum height of each "meter bar" to get the current height of each bar in pixels.

Thanks Christopher,
I read up on dBs (I warned you I know nothing about audio!) and learned that they scale logarithmically, which is why my "unscaled" use of the peakamp reading looked so flat. I got my mgraphics version of my 8 band peak meter to look good, after some experimentation, by taking my clipped (0. to 1.) peakamp values and running each through this expr obj: [expr log10($f1*9+1)] then multiplying that by the maximum height of each "meter bar" to get the current height of each bar in pixels.


Can you explain this to me? I tried using your expr and it is giving me negative values when I use the output of peakamp as the input into the expr. The expr I used takes input from 0. to 1. and returns values from 0. to 1. but the middle values are logarithmically scaled. When I use these scaled values to draw my rectangles for my eq meter simulation it looks the same as when I use the meter obj, like so:

Hi Roman,
Can you explain this to me? I tried using your expr and it is giving me negative values when I use the output of peakamp as the input into the expr. The expr I used takes input from 0. to 1. and returns values from 0. to 1. but the middle values are logarithmically scaled. When I use these scaled values to draw my rectangles for my eq meter simulation it looks the same as when I use the meter obj, like so:


arrg - uses this attached pkr abstraction - sorry

the above is what all audio software uses, and yes, db/A is indeed going from -90. to -0. though it can go over 0., too, (as long as we are in a 32 bit signal or have otherwise overflow bits available)

of course for a slider you can scale it back to 0. to 1. again now. thats probably what you did. :D ... but i was reading "expr log10($f1*

)" and so i though ok, he is using *10, but it should be *20. ... sorry, my fault.

i dont know is they fixed that i later version of maxmsp ... but dont trust [meter~] as a reference for comparing output! in max v.4 meter reacts to the following values:

which is not what it says in the helpfiles, where it is stated that it would be steps of 3 db/A.

peakamp~, then convert to decibel, then truncate/map/select the values you need for your GUI display is perfect.

hint: when academic precision is not relevant, you could downsample the peakamp~ object using poly~. for 8 or more meters that is exactly what i do. (but dont use interpolation/filtering/dithering in poly~ in this case, as we need the peaks...)

of course for a slider you can scale it back to 0. to 1. again now. thats probably what you did. :D ... but i was reading "expr log10($f1*(9+1))" and so i though ok, he is using *10, but it should be *20. ... sorry, my fault.

0
-2.5
-6
-8.5
-12.
-14.5
-18
-24.11
-30.08
-36.11

making 8 band peak meter w mgraphics, what exponential scaling does meter~ use?