Vectral~ use as a fft noisegate release time?

    Apr 21 2010 | 7:26 pm
    I'm trying to build a FFT noisegate / expander similar to the tutorial#26, but I'd like to try to get rid of the watery sound by having some kind of attack/release control in the expander*. For example, if a bin amplitude drops below the threshold, I'd like it to take for instance 4 windows before its amplitude drops to the set value (eg. zero).
    As I've understood it, vectral~ would be the object to use. However, I can't quite wrap my head around how to use it. I've made an attempt, where I've tried to do something like that with vectral~, and it does seem to be doing something, but I'm not sure what it's doing and whether it's doing the right thing. At least its behaviour seems a little strange when changing the parameters in the main patch.
    The 3 attached patchers should be placed in the same folder, noisegate-example is the main patch.
    Any help is much appreciated.
    * There is an older thread about the same topic, but it didn't really solve the issue.

    • Apr 22 2010 | 8:20 am
      If I understand correctly what you're looking for, this is what you need to put inside your pfft~.
      now in3 does nothing (I didn't really understand what it was for), in4 is the
      gate's attack and in5 the release.
      Then, it would be cool to have the times and threshold expressed in some more intuitive measurement units...
    • Apr 22 2010 | 8:38 am
      ... just swap attack and release...
    • Apr 22 2010 | 9:26 am
      A couple of quick things:
      @andrea - your [vectral~] is in the wrong place - you are smoothing the amplitudes of the input after gating (which will result in a kind of time smearing of the input - what you want to do is smooth the gate control signal (which could simply be the output of the [>~], although if you want control over the level when ducked you'll need to do something a bit cleverer than that.
      @ visa tapani and @ andrea. The spectral frame size (or vector size within a [pfft~]) is HALF of the FFT size - you want the second output to [fftinfo~] - not sure hpw that affects things (if at all) - but just to be clear that the patch doesn't seem to work the way you think it does...
      Here's a corrected version of andrea's patch - untested, but it should be right:
      Also, here's a more efficient way implementation in which we don't calculate the phases, and do the amplitude modification in cartesian form, so we also lose the [poltocar~]. That should save on CPU:
    • Apr 22 2010 | 10:05 am
      of course you're right, thank you - I definitely made it up too quickly!
      I liked the reverb-like sound of the thing, though... I could use it someday ;)
      for the record, I think it could get even more efficient if we remove also the cartopol~:
    • Apr 22 2010 | 11:42 am
      Yes - if you only calculate the square amplitudes (and then square the threshold you can lose the sqrt from the [cartopol~] calculation, which should be cheaper also!
    • Apr 22 2010 | 12:05 pm
      Thanks a lot for your help Andrea and Alex! These solutions seem to work indeed. The only important thing I'm missing is control for the level of the bins that fall under the threshold (what 'in 3' did in the original patch). I'd like to also be able to invert the action of the effect and boost the quieter bins. In the original design this was simple to do, but I'm not quite sure how to implement it in this design.
      I'm still having some trouble wrapping my head around how vectral~works... Since the inputs to vectral~ are now either 0 or 1 from the >~ comparison, is the output then a value between 0 and 1 smoothed according to the rampsmooth time? In what kind of units is the attack/release time actually given? If the attack is set to 2, does it mean that it takes 2 (or 3) window sizes for it to reach the target value? Ie. if the >~ goes from 0 to 1 for a certain bin, on that window for that bin vectral will output 0.3333, for that bin in the next window it will be 0.666 and in the next 1?
      Also, the input index of vectral puzzles me slightly. In all the implementations I've seen, FFT bin index is connected to both. In what kind of cases would you have a different signal for input and output index?
      Sorry for the dumb questions!
    • Apr 22 2010 | 1:45 pm
      Hi Visa.
      You can view it this way:
      The output of >~ is the gain. So, it will be 1 if the amplitude of the bin is above the threshold, or 0 if it's below. This gain is smoothed by vectral~ and applied to the amplitude of the bin. Knowing this, it's not difficult to change these levels (you can use e.g. a selector~ and two sig~).
      About vectral~, you can imagine it as a sort of a bank of rampsmooth~s taking turns. The 1st rampsmooth~ operates on the 1st sample of the vector, the 2nd rampsmooth~ on the 2nd sample and so on. The smoothing time is expressed in frames - it makes sense because for each bin every step of the smoothing happens once per vector. Keep in mind that to convert frames ms you have to take overlap into account.
      Let i and j be the indexes at a given moment: then the j-th sample of the incoming bin gets smoothed and sent out as the i-th one. Most of the times you don't want this, so usually the two indexes are the same.
      Hope this helps!