something on compressor/limiter blocks

HI dragoimir:

On the low frequency bug found on some peaking compressors with zero cross:

The issue with distortion at lower frequencies has been solved in 3.92 Beta.

On the compressor with externally control decay:

I don't recall if we have compressors that allow you to control the decay based on the input signal. If this is a requirement; what measurement of the input signal should you use to control the decay? Like I say, I don't recall there is already a compressor that already does this, if you don't mind looking at those available, perhaps we have others that you could find useful.

On the connection of compressors in series:

You can wire a slow (RMS compressor) that contain long/slow time averaging followed by an fast peaking compressor with fast release time certainly. This is somewhat what the RMS/Peaking combo already does however wiring both yourselves would provide more flexibility (depending on the application, let me suggest you do your Peaking compressor both look ahead and with zero crossing). This use case for multiple compressors in series is a common use case among our users. Unfortunately the external control of many of our compressors do not feed the decay, instead it feeds the compressor detector.

On the availability of data to be read:

You can read any data available on the DSP as long as it is contained in the address map generated by SigmaStudio. All readback cells and some compressors cells, during the compilation process, generate and report this data. What DSP are you considering using? I ask because there are differences on how you readback data depending on what DSP you use.

On the ability to change parameters at runtime:

Yes, just like SigmaStudio, users can change parameters in runtime. They must however be careful, please read threads related to SafeLoading parameters. This process is DSP dependent, some SigmaDSP have different ways to perform this safeloading.

Some compressors already allow you to show the compression level to the users, some don't if the ones you select to use, you can always recreate this functionality with other blocks that allow for readback.

Hope this helps.

Miguel

MigCha wrote:

On the compressor with externally control decay:

I don't recall if we have compressors that allow you to control the decay based on the input signal. If this is a requirement; what measurement of the input signal should you use to control the decay? Like I say, I don't recall there is already a compressor that already does this, if you don't mind looking at those available, perhaps we have others that you could find useful.

There is a compressor with an extra input pin that controls the speed of the decay. You could use some kind of envelope on the input signal to feed a lookup table and maybe change the decay on the fly. However, we haven't experimented with this at all, so I don't know how it would perform/sound.

Thanks Miguel,

On the low frequency bug found on some peaking compressors with zero cross:

The issue with distortion at lower frequencies has been solved in 3.92 Beta.

ok, i downloaded 3.9.2 and i'll give it a try in the next days

On the compressor with externally control decay:

I don't recall if we have compressors that allow you to control the decay based on the input signal. If this is a requirement; what measurement of the input signal should you use to control the decay?

i had a quick glance at most compressor/limiter blocks you have.

The only block that has an external decay control is the peak envelope detector but, unless i then design my compressor block, i don't get how to use it with the other dynamics processing blocks (also because many are lacking documentation...but this might be due to the beta version).

Having an external decay control allows you to make the compressor to adapt to the incoming signal in a smarter way.

You could provide an input on the compressor block which scales the decay times: 1.0 is the nominal value you put into the boxes, 2.0 everything is doubled, 0.5 everything is halved.

Then the user might want to use this pin driving it with a detector and some conditional branches (or a continue function) to "map" the decay speed to the input signal level.

perhaps we have others that you could find useful.

cool...where can i find them?

I'll then try the series connection of some compressors.

Last words about reading/writing parameters: i didn't read it in deep, but into a post it seemed that with

the basic compressor /limiter, although everything is shown while sigmastudio is connected so you can see input level, compression level and so on, it was not possibile when disconnected, maybe because some reading addresses were not exported by sigmastudio.

To be more clear, i'm convinced that everything can be read both by sigmastudio (you see the addresses and values it is peeking into) and the eventual board controller, the thing i don't know is if all addresses are exported correctly into the parameter file now.

Ok for safeloading, i already was using it.

Thanks.

Hi,

i ended up in wiring my compressor/limter blocks and i would like to suggest some modifications

to your blocks if possible: i just want to be useful and constructive.

-give the ability to set an attack time: on most of your compressors/limters this is not possible

and having an immediate attack is not always desirable.

-put a control signal output pin so the user can connect a realtime display to see how the

limiter is working over time or feed this signal to other slave limiting blocks.

-would be nice to save / load the compressor/limiter curves to disk for recalling and comparing.

I would also suggest to make your dynamics processing toolbox more uniform

(i'm using the 3.9.2 beta and i guess it is something "under construction". Isn't it?)

giving some detectors (taking input audio and giving rms, peak, look ahead etc),

some gain processing (where you take the detector input, set attack, decay,

hold, threshold etc and a control signal is output) and the controlled VCA (this could be just a multiplier).

That "standard peak compressor" interface is very nice and very useful for immediate debug,

but i think that having those blocks i suggested or the ability to combine also the gain control

output of your existing blocks would add more flexibility.

But, as above said, it's just my opinion.

Bye

Hi,

These are some nice ideas. Thanks for taking the time to write them down.

We have a few new products coming down the pipeline and that doesn't give us a lot of time to update or refine the current library. A lot of the limitations (no attack time, for example) are due to hardware architecture limitations as much as anything. It's a fine balance of performance vs. cost (memory and instructions) when we develop each algorithm.

Luckily, some of the new SigmaDSPs that will be released to the public quite soon will have updated architectures that allow for much more refined compressor and limiter algorithms!

Luckily, some of the new SigmaDSPs that will be released to the public quite soon will have updated architectures that allow for much more refined compressor and limiter algorithms!

Thanks Brett,

this is very interesting, so...

i'm designing a multiband processor, which will use 2 adau 1442 (or a 1442 and a 1446...it depends on the

final cost / benefits of having 2 parts or just one).

Should i wait for these new devices?

New devices on the market means that "old" devices will go quickly into obsolescence?

SigmaDsps are, for sure, a good idea: quite the power of a "real" dsp, which you can immediately use

and go to market. I almost forget how to design an analog filter and, for a tone control, i would surely use a sigma

You surely accounted for costs of these components and there is a logic behind your choices,

but, again on my opinion, having some sort of unique core and then differentiating

the devices on a ram memory / program memory / core peripherals basis would be better.

Bye

drugoimir wrote:

should i wait for these new devices?

If you can stand to wait about two months, there might be a new product that could be more appropriate.

drugoimir wrote:

New devices on the market means that "old" devices will go quickly into obsolescence?

No, definitely not. Most of our products are designed for automotive systems, which means we support the products over a very long automotive life cycle, sometimes exceeding 10 years.

drugoimir wrote:

having some sort of unique core and then differentiating

the devices on a ram memory / program memory / core peripherals basis would be better.

Some of our products do this (the ADAU1701 vs the ADAU1702, for example), and in the future we will have more product differentiation based on memory size.

Hi all,

ADI is better than most companies for supporting older products. I was a young man when designing the AD636 analog RMS-DC converter into a test system, and that IC is still available today.

Bob

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin