That ratio looks exactly right. I suspect that you can slide along that line to optimize the time / frequency tradeoff to taste. ;)


On 09/16/2016 12:04 PM, Giulio Moro wrote:
Yup, I was asking because I found that on the M4 it is difficult to do
proper overlap and add while keeping reasonably small block sizes for
FFTs of useful length, so I was just curious whether you had to
implement threads or just went for block sizes synchronous with the FFT

If I remember correctly I was using 2048 samples per block and 512
samples step, with good results.


    *From:* Eric Brombaugh <>
    *Sent:* Friday, 16 September 2016, 19:50
    *Subject:* Re: [music-dsp] Help with "Sound Retainer"/Sostenuto Effect

    Probably shouldn't reveal too much of the detail, but it likely
    comes as
    no surprise that the tradeoff between time and frequency resolution is
    critical in systems that have limited CPU horsepower. The FFTs in this
    case do run in the audio processing thread which is synchronous to the
    buffer processing rate.

    I'd love to have a go at doing this kind of stuff on something like a
    SHARC where 16kpt FFTs are apparently easy to do at audio rates...


    On 09/16/2016 11:15 AM, Giulio Moro wrote:
     > Nice that it runs on the M4F, what FFT size, overlap and audio
     > processing block size are you using? Are you running the FFT in a
     > separate thread?
     > Giulio
     >    *From:* Eric Brombaugh <
     >    *To:*
     >    *Sent:* Friday, 16 September 2016, 19:12
     >    *Subject:* Re: [music-dsp] Help with "Sound
    Retainer"/Sostenuto Effect
     >    I coded up the spectral freeze core of the Audio Damage "Spectre"
     >    module
     >    in a similar way:
     >    It's a basic phase vocoder with forward and inverse FFTs but
    we added
     >    some fun little tweaks to shift, stretch and randomize the
    spectrum. It
     >    runs nicely on an STM32F405 ARM Cortex M4F processor.

dupswapdrop: music-dsp mailing list

Reply via email to