Carve ATK & REL anyone ever using those params?

[jappe]

I don't understand the use of the attack and release parameters on Carve.
I use Carve to immediately duck signal in dominant frequency regions when they occur in ref in.

I mean, I'd say it's the first milliseconds that is the most important region to duck because that defines the instrument characteristics (wavetable synths are built on this audio principle) and rhythm. I interpret the word "muddiness" in music context as follows: Two or more instruments whose rhythm gets lost because of spectral masking.

Why would I ever want to delay the ducking? If it's for some creative effect then personally I don't think It's useful for me.
A feature I miss is to have a trigger counter on the ref in so I can set a maximum timespan for each ducking event (given that I'm only interested to duck the first part of the sound). I'm thinking that could be utilized if the user selects "beat detection mode" so that each beat triggers a timer for how long the ducking will persist.


EDIT: removed stupid statements that could very well be invalidated if I get to understand why Attack and Release are necessary features with the current time range they have.

[lowpryo]

doesn't it depend on the source material? sure, if you have a kick ducking a bass, you might want it to be instant. but if you have soft vocals carving out a piano, a longer attack would probably be more subtle and pleasant, which is appropriate. same with the release. also, the pumping effect from a longer release is desired for a lot of genres.

basically the same reason you'd use an attack and release while using sidechain compression. maybe it's not useful for the music you make, but it's hardly a "waste of space"!

[selig]

I was curious what the attack response was for Carve, so I decided to test it. Here's what I found…

I first created a steady 1 kHz tone (from Pulsar), and recorded it to an audio track which I then fed to the main input of Carve. Then I duplicated that track and cut out every other half note, creating a hard "on/off" signal, which I then fed to the reference input of Carve. The expected results should be that the output of Carve will follow the "on/off" signal, ducking the steady tone when the Ref tone is "on" (since both tones are at the same frequency).

There are a few issues this test reveals - if anyone can show if I've done anything incorrectly here I would really appreciate it, as I don't want to mis-represent a developer's product in any way!

Here's the results I measured.
The first issue I see is that the attack response time (the time between the ref input and the BEGINNING of the attack phase) is inconsistent, taking anywhere from 13-83 ms to start the attack phase (and it appears to be different every time).


The second issue is that once the attack phase does start, the default attack time (2%) is around 80 ms to full "duck". With the Attack time set to the fastest setting, you get an attack time around 60 ms.


The third issue the response is inconsistent over time - sometimes it ducked the main signal, sometimes not; sometimes it ducks the signal by a large amount, sometimes by not very much at all as shown here:


The fourth issue this test appears to reveal is that I see is that the ducking isn't "holding" while the input is present, which is totally unexpected IMO. If you send a steady tone into the reference input, and the same tone into the main input, you would expect the output to duck for the duration of the ref tone - but it doesn't. It ducks at first, then the level returns to almost the full original level. Not sure if this is by design, but if you are using Carve to duck a bass line from the kick you probably wouldn't notice it (other than the slow response time).


Finally, oddly there is ducking when the ref input goes from "on" to "off", which is definitely not expected. This can be seen on all of the above pics.

I found the ducking issues (#3 and #4) to be odd, and so I repeated the test with a lower frequency of around 100 Hz. The response was now 100% as expected, though the initial delays (issue #1) still occur for both the attack and release phases. This test reveals the fastest Release time is around 60ms, and the initial delay before the Release kicks in falls between 100 and 160ms. In this pic the Attack and Release times are set to their fastest:

[friday]

Any feedback from OchenK here? Would really be nice to here the idea behind. Or maybe the "aha" so he can correct the issue, that's for what feedbacks are not to make the product bad, to make it better!!!! Nice Work Selig!

[jappe]

doesn't it depend on the source material? sure, if you have a kick ducking a bass, you might want it to be instant. but if you have soft vocals carving out a piano, a longer attack would probably be more subtle and pleasant, which is appropriate. same with the release. also, the pumping effect from a longer release is desired for a lot of genres.

basically the same reason you'd use an attack and release while using sidechain compression. maybe it's not useful for the music you make, but it's hardly a "waste of space"!

I guess Attack could be for preventing unwanted overtones for quick attack Ref In? I would expect the Attack knob to have very short attack range (few milliseconds, not seconds) if it was for that reason.
What's a little bit unclear to me is also what distortion impact even a quick attack ref in would have: it would not suddenly drop for example 200Hz in Sig In to zero amplitude, but rather morph the 200 Hz Sig In amplitude envelop with the 200 Hz Ref In amplitude envelop - I think?

Now lets dive into the interesting findings Selig got...

[jappe]

The first issue I see is that the attack response time (the time between the ref input and the BEGINNING of the attack phase) is inconsistent, taking anywhere from 13-83 ms to start the attack phase (and it appears to be different every time).

Interesting...could this be related to the FFT frame size Carve uses? (i e the time until it detects a ref in signal will vary from zero up to the time it takes to play one frame?).

[ochenk]

Hey Selig,

Based on your analysis and questions, my guess is that you don’t understand how FFT analysis works. If you did, you’d know what’s going on. My understanding is that you don’t program your own plugins, so you may not have immediate need to understand FFT, but it’s pretty fundamental to DSP, so it might behoove you to look into it, at least to get a basic understanding.

For others following along, here’s a bit about FFT and how Carve works under the hood:

When looking at digital audio, you can’t analyze or extract any frequency information in real time. The way the math works out, you can only get frequency info by analyzing a batch of samples. It’s the difference between sequential samples that illustrates frequency. The larger the batch, the more detailed the frequency information you get. Looking at a batch of 64 samples will give you a little info. A batch of 4096 samples will give you a whole lot more info. The more info you need, the larger a batch you need.

In Reason, we can’t look ahead to see the upcoming samples, so we can only gather those batches as they come in real time. If we want a batch of 256 samples, we have to build up a batch of 256 samples as they come in, then analyze them, then start outputting them. Since we’re still in real time, we can only output 1 sample at a time.

So that means that to do any frequency analysis on 256 samples, we have a delay, or latency, of the time it takes the 256 to build up, then the time it takes to output those 256 samples. That’s why most plugins that deal with frequency have some latency. The larger the FFT batches (i.e. the more info needed in the frequency analysis) the larger the latency.

Often that latency isn’t a problem. But Carve is intended to do a lot of quick changing frequency analysis and application, often as an inline effect, so latency wasn’t going to work so well. So Carve works in a slightly different way. Carve doesn’t introduce any audio latency. The samples that come in are filtered and sent right out. I’m using zero-delay filters to alter the audio. But the parameters for those filters (i.e. how much gain and cut for each) require info that comes from an FFT analysis, so that information has a delay. It doesn’t delay the audio, but it does delay when the filter gains and cuts are applied, because they have to wait for the FFT analysis to come back.

Now, remember back to filling that batch. The samples that were loaded into the beginning of that batch sit in the batch longer than the samples that are loaded into the end of the batch, since as soon as the batch is filled, it’s analyzed and applied. When you take a random one of those samples, sometimes it’ll be at the beginning of the batch, sometimes it’ll be at the end. That means that if you designate any random sample as special (e.g. the beginning of a note), there will be some variability as to when the frequency info comes back about that sample since that special sample can be anywhere in the batch.

So Selig, you’re demonstrating that variance. It’s working as designed. I could eliminate that variance, but there would have to be a standard audio latency. This way, there’s no audio latency, and even the variance at its largest is still faster than what the standard latency would have to be.

[lowpryo]

nice Ochen, thanks for the quick lesson! very easy to understand. also makes me realize why more devices don't use this kind of frequency ducking technique!

do you know the reasoning behind what he called "issue #4", where the filtering doesn't hold steady for the duration of the note?

[jappe]

Thank's Ochen for a good explanation.
In case anyone is interested there is also a great FFT tutorial which explains things in an extremely good way:

http://betterexplained.com/articles/an- ... transform/

I don't mind at all if we go a bit OT with this, I find the subject highly interesting.

But could you also comment on the questions I asked in this thread please Ochen. Let me know if something is unclear, I am aware that I sometimes fail to express myself in an understandable way.

[selig]

nice Ochen, thanks for the quick lesson! very easy to understand. also makes me realize why more devices don't use this kind of frequency ducking technique!

do you know the reasoning behind what he called "issue #4", where the filtering doesn't hold steady for the duration of the note?

That issue was affecting the 1 kHz tone, but was working perfectly on the 100 Hz tone.

[selig]

Hey Selig,

Based on your analysis and questions, my guess is that you don’t understand how FFT analysis works. If you did, you’d know what’s going on. My understanding is that you don’t program your own plugins, so you may not have immediate need to understand FFT, but it’s pretty fundamental to DSP, so it might behoove you to look into it, at least to get a basic understanding.

For others following along, here’s a bit about FFT and how Carve works under the hood:

When looking at digital audio, you can’t analyze or extract any frequency information in real time. The way the math works out, you can only get frequency info by analyzing a batch of samples. It’s the difference between sequential samples that illustrates frequency. The larger the batch, the more detailed the frequency information you get. Looking at a batch of 64 samples will give you a little info. A batch of 4096 samples will give you a whole lot more info. The more info you need, the larger a batch you need.

In Reason, we can’t look ahead to see the upcoming samples, so we can only gather those batches as they come in real time. If we want a batch of 256 samples, we have to build up a batch of 256 samples as they come in, then analyze them, then start outputting them. Since we’re still in real time, we can only output 1 sample at a time.

So that means that to do any frequency analysis on 256 samples, we have a delay, or latency, of the time it takes the 256 to build up, then the time it takes to output those 256 samples. That’s why most plugins that deal with frequency have some latency. The larger the FFT batches (i.e. the more info needed in the frequency analysis) the larger the latency.

Often that latency isn’t a problem. But Carve is intended to do a lot of quick changing frequency analysis and application, often as an inline effect, so latency wasn’t going to work so well. So Carve works in a slightly different way. Carve doesn’t introduce any audio latency. The samples that come in are filtered and sent right out. I’m using zero-delay filters to alter the audio. But the parameters for those filters (i.e. how much gain and cut for each) require info that comes from an FFT analysis, so that information has a delay. It doesn’t delay the audio, but it does delay when the filter gains and cuts are applied, because they have to wait for the FFT analysis to come back.

Now, remember back to filling that batch. The samples that were loaded into the beginning of that batch sit in the batch longer than the samples that are loaded into the end of the batch, since as soon as the batch is filled, it’s analyzed and applied. When you take a random one of those samples, sometimes it’ll be at the beginning of the batch, sometimes it’ll be at the end. That means that if you designate any random sample as special (e.g. the beginning of a note), there will be some variability as to when the frequency info comes back about that sample since that special sample can be anywhere in the batch.

So Selig, you’re demonstrating that variance. It’s working as designed. I could eliminate that variance, but there would have to be a standard audio latency. This way, there’s no audio latency, and even the variance at its largest is still faster than what the standard latency would have to be.

That would be awesome if you would add that as an option! Consistency would trump delay for some implementations IMO, and having the option would allow the ability to have a more precise mode available to those who want it. It would seem that since there is always a delay in the response of Carve, you'll have to "pre delay" your audio tracks in order to get the desired response anyway, and as such a consistent delay would seem to be more useful than a random delay. Meaning, a consistent delay can be worked around, but a random delay cannot.

Also, a faster attack could be quite handy as well if that's possible to implement without audio artifacts.

Bottom line: There's no free lunch!
It was not my intention to explain FFT to the masses, and you've done a good job here. It is my intention to simply measure and report!

In the end, it's good to know my testing was accurate and that these issues are "by design". I feel that users need to know exactly what devices are actually doing, something I've been doing for many years now. For example, if they expect the device to duck the first few milliseconds and wonder why it's taking up to a 16th note (at 120 BPM) to fully duck the signal, now they know why!

Thanks for your quick reply here - IMO it's helpful for users to have access to the information that allows them to understand the technology behind the products they use!

[TheGodOfRainbows]

nice Ochen, thanks for the quick lesson! very easy to understand.

Yeah! Very easy to understand! I TOTALLY understood all that stuff!

[jappe]

nice Ochen, thanks for the quick lesson! very easy to understand.

Yeah! Very easy to understand! I TOTALLY understood all that stuff!

The topic discussed isn't for all audiences I assume. Check out the link I posted in this thread for a "FFT for dummies" introduction instead. I find it really good, and there's links to follow for supplemental tutorials when things like "Eulers formula" are mentioned.


OnT: How are you Carve users using the Carve Attack and Release? Do you always keep it at minimum settings like I do?
Anyone has a practical (tried out) example where it didn't work to keep them on minimal settings? (an example where you don't overdrive Carve so it basically becomes an ordinary side chain compressor - I use compressors for that)

[Puckboy2000]

Great test Selig and great explanation Ochen. Really cool to understand what's going on under the hood.

[ochenk]

OnT: How are you Carve users using the Carve Attack and Release? Do you always keep it at minimum settings like I do?

Hey Jappe. No, I don't usually leave everything at the minimum. For me, it's usually a "turn the knobs until it sounds right" thing, but I can give a few examples of when I don't want the attack and/or release at the minimums.

Release is the easy one. I usually don't use the minimum setting. Let's say I have a kick drum carving out frequencies in a bass line. If the kick drum is very active, you'll get a somewhat chaotic pumping of the bass line. So I increase the release to smooth that out. That way, if there's bit of room between kicks, the bass has time to come back in, but if the kicks are right on each other, I don't have the bass trying to come in between them.

That attack is a little more nuanced. One example that I regularly see is when I have more than two sounds that I'm dealing with. Let's take the kick and bass example, but also add a pad. I'll sometimes route it so that the kick is ducking the bass and the transient of the bass notes duck the pad. If attack is on minimum and the kick and bass play at the same time (which they often do), both the bass and the pad will get cut and the kick with cut through. But if I'm okay with hearing the kick and pad at the same time, I'll increase the attack on the bass Carve. That way, when a kick and bass note hit at the same time, the kick and pad will play, and as the bass note comes back in, the pad starts to get cut. It creates a nice depth where the frequency clashes are addressed, but still allows the different textures to intermingle.

Make sense?

[jappe]

Thank's a lot for your explanation, I appreciate it very much! But I must admit I don't understand it. Perhaps I misunderstand exactly how your example Carves are routed. Or perhaps I just need my fourth cup of coffe.

My questions in red below:

OnT: How are you Carve users using the Carve Attack and Release? Do you always keep it at minimum settings like I do?

That attack is a little more nuanced. One example that I regularly see is when I have more than two sounds that I'm dealing with. Let's take the kick and bass example, but also add a pad.

I'll sometimes route it so that the kick is ducking the bass and the transient of the bass notes duck the pad.
Is it the transient of the ducked bass that ducks the pad, or the unprocessed transient of the bass that ducks the pad?


If attack is on minimum and the kick and bass play at the same time (which they often do), both the bass and the pad will get cut and the kick with cut through.
This seems to imply that it is the unprocessed transient of the original bass that ducks the pad - because a ducked bass into pad Ref In won't duck the pad right? (other than the varying time period until Carve detects the ref in as you explained in your previous post)

But if I'm okay with hearing the kick and pad at the same time, I'll increase the attack on the bass Carve. That way, when a kick and bass note hit at the same time, the kick and pad will play, and as the bass note comes back in, the pad starts to get cut.
This is where I get lost. If it is the original Bass that's connected to Pad Ref in, then changing the attack on the bass Carve would have zero effect on the pad?

Make sense?