Got it - do be sure to check out I04.noisegate.pd, they may have beaten you to it. Even so we should add attack/release with vectral~ (which is maybe a standard object now?) and offer the patch as an improvement to the documentation.
k
On 3/29/07, Charles Henry czhenry@gmail.com wrote:
Cool! I will try this once I get done with work today.
The difference between this spectral gate and a noise gate, as I tried to describe it, is that it will separate the noise from narrow-band signals. A noise gate just turns the audio on/off as a function of amplitude.
Later, Chuck
On 3/29/07, Kevin McCoy km.takewithyou@gmail.com wrote:
GOT IT!
It needs to use [vectral~] from cyclone (curiously included in pd 0.40-1 vanilla?!), which generates ramps across bins with the "rampsmooth" message. I found this out by poking around on some max/msp archives. Patch is attached, and sounds much much better now!
There's no documentation but you can download the MSP documentation from cycling 74's website. It takes a sync signal for its leftmost two inlets (basically a phasor that ramps from 0 to n-1 (in this case 511) or whatever block/vector size you're using). I followed Miller's advice from a previous thread and just made a table like the hann window.
Chuck I think this might help you with your idea too!
Now to make a GOP abstraction... I might even make a tilt control so that the cutoff doesn't have to be the same for all freqs. BTW, the [expr~] object in the fft-analysis subpatch should be replaced with [q8_sqrt~] - sqrt~ objs just happen to be broken in 39-2 extended test7 right now so I had to use expr~.
Kevin
On 3/29/07, Kevin McCoy km.takewithyou@gmail.com wrote:
Hi Chuck!
Actually I was working on it tonight. The problem with it is that it is too harsh and leaves too many artifacts on the signal right now because the binary [>~] from zexy needs to be smoothed out with attack/release that persists across different blocks in time. What I tried tonight was successive delay lines where the block starts out at 0.25 of its original amplitude, then passes to another delay and is amplified to 0.5, then to 1, held at 1, down to 0.5, and then to 0.25 and back off. Successive delay lines that increase and then decrease were the only way I could think to do this job of smoothing it out over time and preserve information from past blocks of audio. I've attached the patch as I was working on it tonight.
However, this has some problems of its own and I was getting a lot of high frequencies that I didn't want there, so I think this approach will need to be windowed as well - the delay lines may need to be smoothed too, something along the lines of the pitch shifting example in the documentation, except in the frequency domain?? I dunno and I'm in a little bit over my head at this point. It's hard to measure and assess what you do right and wrong in the frequency domain! Sometimes a brother just needs a scope. I am also open to fact that I am completely wrong about this :)
What you're describing, if I read you correctly, is I think implemented in the noisegate example in Pd's doc... if they are different, could you clarify? but all of these just sound bad to me and of poor quality, they really need attack and release to sound convincing/interesting and less "artifact-y" when you really push them. I'm all for destruction/mangling of audio, and FFT seems truly powerful in that regard, but I just don't like these results yet. Of course, Tom Erbe's soundhack filters already do this, but he hasn't responded to this on how he got attack/release to work for him - it may need to be handled differently in Pd as opposed to whatever he used to code those VSTs.
That said, I would *love* to hear/try what you come up with. Let's be in touch about this!
Kevin
On 3/28/07, Charles Henry czhenry@gmail.com wrote:
Hi, Kevin, I liked your idea for a spectral gate. I can see two possible applications for it:
- removing broadband noise from signals
- masking out one sound from a collection of sounds
And the first option is especially cool. It would be like a noise gate on steroids, because it would remove the noise, even when there's a signal present. If it's alright... I'd like to give it a try, and send it to you. I'll re-format it so that one signal (noise or whatever) can be recorded and then used to mask the same signals out of a continuous signal input. In fact this can be reformatted as a kind of weiner filter, which will optimally reconstruct signals in the presence of noise. Have you gotten this working the way you want yet?
Chuck
On 3/23/07, Kevin McCoy km.takewithyou@gmail.com wrote:
Hello all,
A while ago I was working on a spectral gate patch and now I've come back to it. Here's a quote from Tom Erbe's earlier email:
"For a spectral gate, just calculate the amplitude from real and imag, make your gate decision based on the amplitude and threshold, and then apply the same gain reduction to both real and imag. Add attack and release to the gate-gain for smoother results."
I want to add the attack and release so it sounds smoother and less bubbly/harsh (know what I mean?) I am racking my brain trying to figure out how to do this to each of the frequencies. The soundhack vst does this really nicely and even has a visual representation of the gate where you can see it rise and fall with attack/release for the whole spectrum.
The problem for me is persistence across different blocks. I suspect [line~] doesn't work for this as it does for amplitude attack/release implementations. For example, if there is a spike around 3000 Hz, how can I carry that attack and release across several blocks of audio? I used delay objects with what I thought was some success, but I don't think I had it right. I have attached the patch which is basically what Frank posted earlier - it does not have any of this yet and is just a hard on/off.
Much confusion, I would be grateful for any help! Kevin --
++++ http://pocketkm.blogspot.com
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
--
--
sorry for the delayed reply - i'm a bit behind on the pd-list...
in my plug, i keep a table of gain factors for each fft band. before
each fft, i update the gain factors by multiplying by an attack
multiplier if we are below the threshold or by a release multiplier
if above the threshold. after that, each gain factor is limited, so
it doesn't go past the gate gain setting after attack, or past 1.0
after release.
this recalcing of the gain table only happens once per fft...
the attack multiplier and release multiplier are recalculated based
on both time and the gate gain setting.
On Mar 29, 2007, at 10:56 AM, Kevin McCoy wrote:
Of course, Tom Erbe's soundhack filters already do this, but he hasn't responded to this on how he got attack/release to work for him - it may need to be handled differently in Pd as opposed to whatever he used to code those VSTs.
tom erbe ~ tre@ucsd.edu ~ studio director - computer music ~ ucsd
department of music
Tom,
Your approach is really sensible and what I was originally seeking to do, but it's difficult in Pd without the help of a few externals I imagine. [vectral~] has ended up working just fine and may open some doors into other strange manipulations :)
Thanks for being willing to share your info - it is much appreciated! Really I was just trying to sort of emulate some of the functionality of your plug so I could use something like it in Pd; on OS X there's no VST support at the moment. If I release an abstraction I will most certainly give you credit for ideas and inspiration (and Frank Barknecht too since he turned me on to FFT with his excellent tutorial and started this patch).
Also, your plugins are visually just fantastic - maybe when Pd's gui advances a little bit more we will be able to enjoy the hypnotic dancing lines too.
Kevin
On 3/29/07, Tom Erbe tre@music.ucsd.edu wrote:
sorry for the delayed reply - i'm a bit behind on the pd-list...
in my plug, i keep a table of gain factors for each fft band. before each fft, i update the gain factors by multiplying by an attack multiplier if we are below the threshold or by a release multiplier if above the threshold. after that, each gain factor is limited, so it doesn't go past the gate gain setting after attack, or past 1.0 after release.
this recalcing of the gain table only happens once per fft...
the attack multiplier and release multiplier are recalculated based on both time and the gate gain setting.
On Mar 29, 2007, at 10:56 AM, Kevin McCoy wrote:
Of course, Tom Erbe's soundhack filters already do this, but he hasn't responded to this on how he got attack/release to work for him - it may need to be handled differently in Pd as opposed to whatever he used to code those VSTs.
tom erbe ~ tre@ucsd.edu ~ studio director - computer music ~ ucsd department of music
-
Kevin McCoy -
Tom Erbe