vectral~ in gen possible?

    Jun 16 2013 | 1:38 am
    Hi there,
    I've been getting into FFT processing again lately and would like to migrate most of the processes to Gen~ for flexibility. The only object that is stopping me from doing this at the moment is vectral~.
    Would it be possible to build something like this in gen~? Has anyone done it before? What would be the best way of going about it?
    I understand how to smooth data in the time domain in gen~ but can't conceptualise how to go about doing this for fft frames.

    • Jun 25 2013 | 6:36 pm
      iam also curious about it…
    • Jun 26 2013 | 4:07 pm
      Here's a basic example. The trick is to use a Data object in place of a history, where the Data dim equals the number of bins; then each index of the Data corresponds to the history of each bin.
      This example just does a lazy low-pass smooth using a mix operator, but obviously fancier processing can be added for whatever slide/deltaclip/rampsmooth etc. effect...
      There's also some code commented out that does the same to phase, which obviously doesn't really make sense, but it sounds interesting in an FFTish way. Probably phase should work on phase deltas (wrapped into -pi,pi), which would need another Data (or Data channel) for the previous frame.
      You could also shift the read or write bin for weird frequency shift effects, but watch out for zero-delay feedback artifacts (again, that would need another frame of history to avoid).
      Save as pfft.vectral:
      Main patch:
    • Jun 27 2013 | 12:06 am
      Thanks so much Graham, great example. Very beautiful sounds too.
      I've tried to recode your example using standard gen objects to better conceptualise it as I'm still in the process of getting to grips with codebox.
      I don't seem to be getting the same effect though.
      Could you give my code a look over?
      Thanks again.
      Here's the gen code:
    • Jun 27 2013 | 12:38 pm
      Probably the inputs to poltocar should come from the mix operators, not the peeks. Also, the second argument to [peek] is not the channel number, but rather the number of channels. To specify the channel you need to send a value to the second inlet.
      Here's a new pfft.vectral.maxpat using patching rather than GenExpr (amplitude only; another one with amp and phase smoothing follows).
      Here's an alternative pfft.vectral.maxpat that does both amplitude and phase:
    • Jun 30 2013 | 11:11 pm
      Graham, mind if I pick this back up for a bit of a detour?
      I'm loving these patches, and I've saved the penultimate pfft.vectral.maxpat to keep working with that. It's saved as pfft.vectral2 here.
      Now, if I do this:
      I get a sort of crude fft-compressor going on. That's what I'm going for, but I'd like to stay in the signal domain for the smoothing input. This is where I run into trouble; if I try to create a [fftin~ 2] object in pfft.vectral2 I get an insta-crash from max - am I abusing the system, or is this a regular ol 'bug? I'm very much a novice in fft-matters.
    • Jul 04 2013 | 10:41 pm
      I can replicate the crash, if audio DSP is on. I've ticketed this as an issue.
      In the meantime, it does work for me to add the [fftin~ 2] if audio DSP is turned off while I do it.
      You might also think about doing all the compression entirely inside the gen~.
    • Jul 06 2013 | 3:14 pm
      haha, duh! Such a simple solution. Thanks, man. Geez, it always helps to talk about patches like this - and it's always nice to have another excuse to do gen~.