new shiny hammer- or Universal comp

[mediatechnology]

Cool. 10-4 on the through-hole part requirement.

[JR.]

I need to make this like a plug in, where the comp faceplate and controls comes up in a computer program so the hardware is super simple , bal in, VCA, bal out. perhaps with a level and VCA status meter but not necessarily. I could use USB port to communicate between comp and PC or MAC.. Of course more stuff I have to figure out how to do.

A x2 and a x8 version could be made.

Problem with a x8 is that people "ASS"ume that anything packaged more than a x1 or x2 is somehow compromised... Like mic preamps in consoles. Some are as good as can be done, but people just don't believe it.

JR

[JR.]

There are two directions to go with this.. "Value" where I could probably manage a by 8 comp with 1 micro proc and 4 cheaper dual VCAs. I might be able to squeak in a couple side chain inputs.. maybe 8 +2 inputs 8 outputs.

This can be fully computer control but with flash memory you can disconnect the computer and comp will keep trucking in it's last setting.

other direction to go is uber high end- 2 inputs, 2 side chain inputs, two outputs, a faceplate full of controls and LEDs, "AND" the USB port for computer control, automation, whatever.

I still want to build my old dream compressor that can mimic at least the dynamic characteristics of "any" of the classic comps out there. It can't mimic the distortion but pretty much anything dynamic.

I also want to make my unconventional "no threshold" comp... essentially compress the entire signal dynamic range by the compression ratio with an additional hard limiter at the top end and a downward expander at the bottom, to scrub off excess compression at low level. This should be more natural sounding than a compressor that acts differently when you sing loud than when you sing less loud.

I have a few other angles to pursue with this i can't talk about yet.

JR.

[jdbakker]

For jollies, I coded up a true RMS algorithm for the VU portion of my simultaneous peak/VU meter. It wasn't that hard.. I multiply the signal by itself to square it before I integrate it over time to simulate meter attack/release time constant's, then I compute the square root, before mapping the integration result to the LED display.

I have no experience with PICs or their ADCs, but on the AVR side I find that implementing a digital high pass filter before the square/integrate stage is an easy way to get rid of the converter's DC offset. IME, this aids in getting a lower minimum useable level for the RMS-detector (as you're otherwise RMS-detecting your DC offset).

The square root was a little tricky since the cheap micro has no square root function[...]

Why bother? You have a fixed (maximum) number of LEDs, right? With an n-entry threshold table and a binary search you can find which LED to light in O(log(n)) time, probably lots faster than any sqrt()-function, be it iterating or dividing.

How do you handle LED supply current fluctuations? Assuming a dozen or two LEDs all biased at ~2V@20mA, a LED VU meter on a drum bus can spike from 20mA to 500mA if your LEDs are in parallel, or you'd need at least 50V if you run them all in series. The usual tricks to keep the total current constant (shunt regulation, one big series string) get quite inefficient for larger numbers of LEDs.

JDB.
[working hard not to re-hijack the thread]

[JR.]

Good point, for the simple meter and fixed thresholds it is far more efficient to do the math only once. As it is now, I actually compute the 3 dB meter thresholds on power up, but only because I'm too lazy to key in the data,,,(and thresholds may change... it's not my application)

My RMS experiment was just messing around to look for a difference in side by side comparisons between RMS and simple average, and I didn't want to use two different meter routines which would have changed the architecture of the program too much.

To my eye there was no difference so I left the square and sqrt out of the release code.

I built a peak/VU meter using a hardware RMS (transistor array) back in the '70's but i never did a rigorous side by side comparison with ave.

I may revisit this (RMS) in a comp to see if the ear is more sensitive than the eye but i've been skeptical ever since the old DBX NR days and their wondrous claims about their tape NR because of rms detection. I did a lot of work with NR and many other more practical things mattered a lot more than that IMO.
----------
I don't do a HPF per se, but do a full wave rectify. using an AD input zero that I accumulate over many samples. On my current project using 6 inputs there is something like 9 codes difference between the worst case highest and lowest channel input, likely from the resistor divider's tolerance. I basically inc or dec a 16b ad_zero_accumulate word with every eighth sample. If there are 65k more samples net above or below, my ad zero bumps one bit.. not very fast but pretty accurate. I guess that's effectively a HPF but with a damn low pole freq. So indeed this component tolerance would degrade my meter's dynamic range if I didn't account for it.

AFAIK In FFT not tweaking zero before the multiply dumps energy into the 0 Hz bin, does it cost you resolution too? I'm just dipping my toes into a DSP platform for possible application to drum tuning. I do the precision rectify anyhow so no worries.

JR

[JR.]

Here's a snapshot of the meter proto I just finished for a console company (that shall remain nameless for now). It's based on a PIC24H.. In this design we're feeding 6 audio inputs and using a solo logic pin to tell it to steer inputs 5 and 6 to meters 3 and 4 and light the red SOLO LED on bottom.

The wire and resistor tacked on top, is not a mistake but a feature added after the PCB was finished. It is another logic line input to command "emergency all mute". and blink the bi-color mode LED red. The meter is shown in Peak/VU mode but it can be told to work in Peak only, VU only, or both.

I also do an auto-zero calibrate to make meter zero agree with faders, etc...

This is the PIC i plan to use as guts of digital controlled analog comp...

JR

meter_pix.JPG (241.32 KiB) Viewed 15069 times

[mediatechnology]

That's very cool JR. DSP is the new blinky hammer. I want one.

(I re-sized the image for you so we don't have to scroll L-R.)

WK

[JR.]

Thanx... If I was to make a stereo version, I would probably use an even smaller part. I'm using every pin on that 28 pin part, but a dedicated meter won't need 6 analog inputs, solo logic, etc,,, I think there's an 18 pin part that would probably work. 2 a/d inputs, 3 lines for serial data out to a handful of latches.

I could organize it so the end user could customize the number of LEDs in the display by how many latches they hang off it. If I organize the data in 4 bit pairs of L and R data per 8 bit latch, the user could define the length of display in 2x 4 led increments. The serial data would push out LSB first , MSB last, and latch after the MSB is sent. Serial data daisy chains through all the latches so extra LSB data is just dropped if no latches connected to receive it .

2x8 LED display would cover 24 dB range in 3dB steps, 2x12 LED display 36dB, and 2x16 LED 48 dB.

Peak or VU could be selected by shorting a pair of port pins to ground (peak, or VU, or both.) A linear or log range could be selected with a single port pin, but for linear range you need to know length of display.

JR

[mediatechnology]

FWIW We had more than a few build options on the original gain meter and it generated lots of support. Sell a Pico Compressor and a meter and the meter board generates the e-mail. Once Roger did a dedicated GR meter support virtually stopped other than the occasional backwards LEDs.

I love the flexibility but you may find that too many options will result in support issues. It may be better to provide the universal PIC meter IC and different boards based on the number of LEDs. I'd love to have all those features in a one-size-fits-all board but it may create work for you if you decide to sell kits. It's the K-I-S-S principle.

[JR.]

No the layout was done by the lead engineer at the console company, to fit in the specific model console. While I have known him for decades, I have been collaborating with them on this meter for less than a year. So the original console definition involved a bunch of analog circuitry. Their standard meter approach was VU only and less LEDs. This digital approach allowed them to expand dynamic range to the display (more LEDs) and provide more meter options that would be impractical in analog, for less cost than the pure analog approach.

It was a real pleasure working with them on this project because I didn't have to show them how to do 99% of the design. My involvement was the microprocessor specific stuff. This was my first project using serial communications and this particular PIC family so I had some learning curve, related to that, but I am pleased the first cut is 100% functional.

JR