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
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
--
-
Kevin McCoy