making 8 band peak meter w mgraphics, what exponential scaling does meter~ use?
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!
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.
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:
----------begin_max5_patcher---------- 2201.3oc4c1siqaaD.95M.4cfvHWzj5Zvg+IodWuLWkfdaPvBs1xd0I1RtxZ ytoA8f9rzGs7jTJR+ir2U+SKMGDr.16QV9vgeyvgCmgT6u+0e0CydJ8snCyH +cxOQd3geWekGLWq3JOb5BOLaW3aK2FdvbiyVuMM4kcyle7yz+d5K4aixMeJ 6zkWmljmDtKx7U9GYwgaO+MhWYtX5Se5uI4mup8+j7eaejUbJZmv7YyIydJL YyLxOe5F2Glu743jMOlEsL2duAJwBpGH.XNADrEz4DIs3Ul90xeyLsDkGk8X TR3SaMMDsr.eH9eatHT7ewk9WbxotGXt3+4q+ph20uMeZnlvITyG9yE0TN2V SEzKno6hw6zcqBzbAYZfc5pzEiEfShdUylyfIO5MS2bVza6yHaS2.z+x2rF9 t.xek.eaE5Ani5A+p0CcXXN0qf5.i+d3+EjQoh57gx+Ywn7a+NF0MVjJVesH uxE5QKRZvnaQtLc2tnj72SL9BxO9RNINIOkrOK5f9lByiSSH6RWEc912FmDs L8kj7qLfuFozNNH+BR+.rAfFBxibiyAC2rVrbQa315rMOciM40n7biWpSWo. vLZL5wWH+r60CrEjUYguRLi9NPdMN+YxtMYg6eNd4g6pd.pUOP4Amw.S4O95 gqD.O5B48UO.KH62F9ajCZJuZlaHLsNBKUxy8OATz8fOxybu4q6Qz5rn+EIq PQ4F9Hj0wG9wwgBVgmSSLnJuOXlqRlOuyA+8vvTH09DnJsjo0alwEdvEwx8T ea5qQGxIEv2MXGBpC6Ll2BV.mxmSBjldW.BfN2mdOf9tnCGB2D8dneHJ+Qsm frkQOpk7PBk.E+LmrOTOi4bx6+7hef4tIpCu9FzAPEJiK5.Cc3FU.A76b.GL mGg19eIS6fyM7go5cTYAWlbWDHJniPL5AkUKiDtgQ7duVJesMDxYD2QLJn2L hRwNiXtgQBZeYjmjicFANhQPuYD7d6HNtXjiVIsn2qjVoDH2NJvQHh2aDwj2 hHtGpPjuiPjnuHR5yQNh7bTvQ81YjTHPNhTNBQ81Wjjh8AZtJD6dOPSnTmW2 NNQjihvlI6MhXlkvhS53nXqgdu9CtuOxGi4nPqgduNetH.4HxQQVC8dk97iQ ViW2PNJv5dGzXQR0QoWnbxSNx5oFOzsnb91boINtfLwWzUSVJcR0jKkcXgGF 2VH4oa1rMpIymxqnnFOLwE0aqVSDaJxOVeLVWYwcdbjtcyRIRG4mAfAMXxRJ tsD3R+dNXhcOb1PVGucq9sp75H5FnBZfS5AZEM34Aby6B+Dl2jAE0KbTcF8o 37E6eMNYU5qM4Qp79mnlIml23l5w1mk9lpX3aFcoZWcn5TwkrS.Bbi6dlz7F .ACpxRUYtUfwyk2m.ppySaGcvWy50zs4i6Byyheq8LmejBvWzy5I7cxrdbp0 BgU8NgrJCw1twpXKfOXiUAKTci5cn109pa6L3Pk44l.Uj2cUlO8C2LbPm2Mb cn12NToU4RSB+EylM3eVHGEMh1JzQYuk0+0pXia.T7RZ0d3VhOfsJf1h3ycH vRViFxMloQS.SV63xSJ41Y+XVXBduqcFQV4OHVETp7G2efw4hIGX7RA0+bp9 VWcsu19PQOwPoXdz93UmjEY+rFsd3lV3BCajqZLsFYb+oGXrAAL+QEXb.A.i OHfo7KCL981BylmvoEXpgYgQGUKL5zOiJeXQenF0YTOErtCAVUQ2td85m9bw 5tKBrksn5xkp5Vns0D.yg3MIglz8fveqsY6kA1LcxL6Tc8qUE4M24IDn5Moa d5dGkaydWI2.aMBLVtblYW7W8tsUyt.I3643TaVCfByxqMmcc8.50+JdytvI ul1Ux2INU4Vr+O9u+Ome3Of5O7GVep91sxdS63ua4w86reTkayUgK+ri3RsG +KIXmIPZGPEzQvbmqUv2+CtIGW.uCyVT+ZMNxK6ALTuT.4Tvq8gIQaax7nb+ WTmMfvFfNSZiCPXyGc49zSoYqhxVltMMy9Uz8XeFWxKNcXBNv8r+F.dpBOxW 8c2T56YOdgke4xM9wQvXa5QNURpgE8q8Tfvs4x+NFFWvzmWDFcPjRvKc1Ou6 7hQm9bcvBbehjXxKmbu9QQGjHIPhfk4KFj0n2PwX2N2yHXU9xAwKt2XN5EBl dfIG1p7gfxVXz6MvDSeZQjACyBCF0gjdS+DppgkKbfOp.i0xITsMr4opvsOh qLchhO3FLZOsuG64md9rPJ0EVEcHON4bO3mt7.Do7c8b7pUQIWEX7p3CEkY1 vbZ0Z1VKXEOMiZVvJdV6LxB1srnBASL9DyuUBFezErVIWiuXUruZwnbwaiXI lDsHzjXAJjpFmBASgWEIqQd4gUE4DHXd3UQxajW9XUQNABlOdUjhlDKlDoJx IPvXR7pHkMxKAVUjiufcaShIEopQdwvphb7ELFCuJRuF4EfUE43KX21jXRQ5 2nXgUWqSffIPrq0fFEKrlNfIPvDXNg.MKWXcRxIPvDHdRRnwb6Hv5rjSffIP 7rjPiI2QPwplb7ELAEwZxFytSwy9Qbl17wWvtsIQklrwz6vwZd5l.Aii37zA MmeGrVCjIPvXHsFHHMi9AsIi9dShXgTZA3SrZ05tUSBsZtreRbt6.TJbVlTE fyZLHCvY0HkdHMMEbOrFguBmE+fKw4NPgi0zmv4XckGLblCXNfzzmvoHcGBD f0UD4iyxEw7PZ8HGeCLY6VAI+ZWvigf0p8RTytv1EuZeZbR9gSmQJ6erxDly KfjwO+uJ0VtdgA9slwrwcEKdHU4KZU5CfInJ4splbSPJ89hVt.1zHXPqDrw0 zGZUEllfz+ee7Ga9SRQgGX9U9i4s0e7wyBS398+ZT1giRisWLaW3mrGUZ6SC khGyg1+s8j3LKK5WiO8UrGp7YgYKeNNOZY9KY1SA+a9pY5Owzf5W9+.Lr3xM -----------end_max5_patcher-----------
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*(9+1))" 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…)