[PD] attack/release for spectral gate [was: is this a spectral gate?]

Thu Mar 29 19:56:04 CEST 2007

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 at 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 at 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 at 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 at gmail.com> wrote:
> > > > Hi, Kevin,
> > > >   I liked your idea for a spectral gate.  I can see two possible
> > > > applications for it:
> > > > 1.  removing broadband noise from signals
> > > > 2.  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 at 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 at iem.at mailing list
> > > > > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > >
> > > ++++
> > > http://pocketkm.blogspot.com
> > >
> > >
> >
> >
> > --
> >
> >
> > ++++
> > http://pocketkm.blogspot.com
> >
> >
>

-- 

++++
http://pocketkm.blogspot.com