# Spectral "Compensation"?

**URL:** https://discourse.flucoma.org/t/spectral-compensation/299
**Category:** Usage Questions
**Created:** [August 4, 2019, 12:53pm UTC](https://discourse.flucoma.org/t/spectral-compensation/299 "2019-08-04T12:53:30Z")
**Posts on this page:** 1
**Showing post:** 11

<div class="post-metadata">

### Author: ![rodrigo.constanzo](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/rodrigo.constanzo/32/12_2.png) [@rodrigo.constanzo](https://discourse.flucoma.org/u/rodrigo.constanzo)
#### Post date: [August 5, 2019, 4:39pm UTC](https://discourse.flucoma.org/t/spectral-compensation/299/11 "2019-08-05T16:39:37Z")

</div>

Oh nice.

So one intended implementation of this idea would be to include it in C-C-Combine, where for any given analysis frame there would be an input frame (already analyzed) and it’s nearest match from the database (then using `lookup` to get the difference between the two)).

So in that case there would be a known frame for both.

If I understand you right, would that then entail something along the lines of using `irtrimnorm~` (or `fluid.bufcompose~`) to get the audio from the incoming audio buffer (using a JIT approach in C-C-Combine) into its own `buffer~`, and then running `irplapprox~` on it to get an IR which I can then apply to the playback grain?

> [@a.harker](#):
>
> but I’m not sure it is accurate to say that loading an IR into multiconvolve~ “takes time”, except in the sense that all calculations/operations take time. In respect to the max thread you are running in it is immediate.

I meant more in the sense that it may involve `buffer~` operations before/after it, which I guess have the same issues as the threading/overdrive stuff from [this thread](http://discourse.flucoma.org/t/descriptors-comparison-oldschool-vs-newschool/205/97).

> [@a.harker](#):
>
> I’d be up for making a synthetic spectrum from the moments also to try and approximate the shape - that would be a fun task inline with my current interests. The problem here is that we have to decide on the level of complexity/some characteristics of the synthetic filter shape - for centroid and spread that seems fairly doable, but the higher order ones need more thought.

That would be quite cool.

I tried whipping something up using `biquad~` and taking the raw readings and going all wiggle-waggle on `noise~` to see if it works, and I guess I could kind of hear what was happening, but obviously this is not a great way to go about it.

> [@weefuzzy](#):
>
> I’d heartily recommend it – I’ve been loving the per-grain control fun. I might have some code knocking about where I’ve done spectral envelope estimation in FrameLib, so give me a shout when you’re at that point and I’ll dig about.

Unless it’s crazy complicated, I’d be curious to see it either way if it’s handy.

---

_[View the full topic](https://discourse.flucoma.org/t/spectral-compensation/299)._