Anyone?..

Hi there,

Sorry I didn't see this sooner. I'm not sure I fully understand the question, but I'll comment on a few things which maybe might be causing problems. Let me know if this helps.

One thing that I notice is that the delay time is not quantized to the spectral frame size. When using delays within a pfft~, one sample of delay equates to a frequency shift of one bin, two samples is two bins etc, and eventually this wraps around at the framesize to account for a whole spectral frame with no frequency shift. So to avoid unwanted frequency shifts, the delay time should be quantized to the frame size. In the gen~.spectraldelay example patch, this is done by dividing by the frame size, stripping the fractional component, and multiplying back up to the frame size. I've made this change to your SD.gendsp patcher below.

Another possible issue is that, in discrete signal processing, a feedback delay of zero is of course impossible. The absolute minimum delay for feedback is 1 sample. So if a delay of 0 is requested, the [delay] operator will apply 1 sample of delay. In the pfft~ context, this will cause a frequency shift of one bin, which isn't ideal (maybe that's what was causing the additional sound you mentioned?). One way around this is to insert a frame-size worth of delay in the feedback path instead, or more simply by enforcing the minimum delay = framesize. That way each bin gets exactly one frame's worth of delay, which is the minimum. I've also added this to the gendsp below.

When I was working on the gen~.spectraldelay_feedback.maxpat (in the gen examples folder), I found the effect to be slightly cleaner if the framedelta/frameaccum is applied inside the feedback loop, rather than outside (I don't fully understand why...). I've added that change too just in case it helps.

Best,

Graham

PS. There's a separate forum for gen-related topics here: https://cycling74.com/forums/forum.php?id=13

Hi Graham, thank you very much for your exhaustive answer!

As a matter of fact, I didn't include frame quantization for the delays because this was already done, outside gen~, by an external object which directly generates the buffer with a delay time per bin. This way, delay values should be already quantized to the frame size.

I eventually tried to clean the delay buffer, to get rid of uwanted zero values. But, as always, I had the small sound leaking out at the beginning, with a delay of zero, and which it doesn't get captured in the delay loop.

If I do as you said: I quantize the delay times to the spectral frames, and also impose the minimum value of 1 frame of delay, I don't get anymore the leaking sound at the beginning. Anyway I'm asking myself why the simple "max1" isn't enough to solve the problem (I've tested that), so I also need to do the frame quantization.

I would also really like to know what are the differences in detail between the previous gen~ version from Max6.0.5 and the current one, since in that other version I didn't have this problem at all, and above all I had louder sounds at the output, while now it's a little softer.

Can you explain to me? At least what has been really changed in gen~ from 6.05 and 6.07 ?

Thank you very much,

All my best,

Carlo

.. I mean, was the minimum delay time of 1 frame already implemented in Max6.0.5 gen~ ?

This would explain why I didn't have problems with that version.

I also compared the outputted sound from the two versions. It's slightly different. Neither better or worse, just different.

And by the way, it's true, having framedelta/frameaccum inside the feedback loop makes the sound cleaner.

Best,

Carlo

Hi there,

The minimum delay of 1 sample is a theoretical constraint for any discrete feedback system; if there's a change between 6.0.5 and 6.0.7 this isn't it. :-) What a clean sound needed however was a minimum delay at the frame size, which the added quantization in the patcher ensures.

Yes, I'm not sure why putting the delta/accum within the feedback loop helps, but it does.... I'd like to understand why.

G