Umenu FFT Size Control


    Dec 24 2008 | 9:32 pm
    Hi,
    is there any way to control/change the FFT Size of a pfft~ using an Umenu or any other stored value instead of typing the new size as an argument?

    • Dec 24 2008 | 9:46 pm
      if you mean changing the fft size dynamically, I don't think you can
    • Dec 24 2008 | 10:08 pm
      The only mean I know is by scripting. (delete pfft~, and reinstantiate a new
      one with the new FFT size). You will interrupt the audio chain, thus get a
      click or even further problems.
      Jean-Francois.
      >
      > is there any way to control/change the FFT Size of a pfft~ using an Umenu or
      > any other stored value instead of typing the new size as an argument?
      >
    • Dec 24 2008 | 11:37 pm
      Thank both of you for your replies!
      Scripting is not a problem for me, but I am a bit concerned if this will work within a plug-in ?
      I want the user to be able to define the FFT Size when the plug-in is loaded.
    • Dec 25 2008 | 12:31 am
      I haven't done much plug-in work, but as long as you don't change the fft size while your audio is running it shouldn't be a problem.
    • Dec 26 2008 | 5:28 am
      Quote: maronid wrote on Wed, 24 December 2008 15:32
      ----------------------------------------------------
      > Hi,
      >
      > is there any way to control/change the FFT Size of a pfft~ using an Umenu or any other stored value instead of typing the new size as an argument?
      >
      ----------------------------------------------------
      I used gate~ 8 with 8 different pfft~ objects and their different sizes hardwired in. With matrix~ you could avoid the clicks too (I was just experimenting so it didn't matter). I don't know if having multiple ones are a problem processor-wise since only one is active at a time, perhaps someone here knows? With the gate~ of course you can have the drop-down, which was nice.
      It was definitely cool to try out the different fft~ sizes on different samples, with wacko values of sig~/speed and gizmo~/pitch shift, it was pretty insane what a basic sample could be mangled into... a snare hit sounded like a totally distorted space-violin, great stuff!
      --CJ
    • Dec 26 2008 | 8:26 am
      [...] yes this is also a good idea...
      all you need to avoid the processor issue is to use the begin~ object in order to shut off the unused signal networks.... i think!
      Dimitris
    • Dec 26 2008 | 4:43 pm
      Sounds like a good idea!
      To gain on CPU usage, you will need to put each of these pfft~ inside a
      poly~, and mute all the unused ones (wihtout poly~, all pfft~ are "active"
      whether you give them an audio signal or a null signal).
      With this technique, you can indeed change the FFT size, overlap, and even
      inside the pfft~ the window shape, all without clicks.
      Jean-Francois.
      > I used gate~ 8 with 8 different pfft~ objects and their different sizes
      > hardwired in. With matrix~ you could avoid the clicks too (I was just
      > experimenting so it didn't matter). I don't know if having multiple ones are a
      > problem processor-wise since only one is active at a time, perhaps someone
      > here knows? With the gate~ of course you can have the drop-down, which was
      > nice.
    • Dec 26 2008 | 10:45 pm
      does putting the pfft into a patcher and using mute~ not work?
    • Dec 26 2008 | 11:22 pm
      > does putting the pfft into a patcher and using mute~ not work?
      Yes, it seems to work great as well.
      Actually, toggle -> [mute~] -> [pfft~ .....] seems to work, too.
      J-F.
    • Dec 27 2008 | 9:53 am
      You can also put the pfft INS poly~ change the arguments of the poly~
      dynamically and reload the patch by resending the patchername. That
      way it does not interrupt the main DSP chain.
      Cheers,
      ej
      On 26 déc. 08, at 23:45, Nick Inhofe wrote:
      >
      > does putting the pfft into a patcher and using mute~ not work?
    • Nov 28 2009 | 7:07 pm
      yea, but wouldn't it be great if pfft just accepted a message to change the fft size. Anyone know why it doesn't? Ill take the click for the simplicity of a message going into pfft to change fft size/overlap, and write a patch using poly (as described above, thanks!) if I don't want the click. Maybe in next version?
    • Apr 02 2013 | 3:24 am
      "yea, but wouldn't it be great if pfft just accepted a message to change the fft size...Maybe in next version?"
      That is for me one of the most annoying things in Max...why can't I simply change the fft size and overlap factor with a message? I want to make a Max for Live device, based on pfft, and i really don't want to have loads of pffts inside, with all the possible permutations of fft size and overlapping factors...
      Maybe in next update?