[pfft~] question(s)
Here goes two hopeless questions:
[gizmo~]s placed in a [pfft~] harmonize OK, but I'm using them as "melody parts", so sometimes some parts need to be silenced. Is it possible to mute [gizmo~]s placed in only one [pfft~] individually? In other words, does sending them "1"s do that? I'm scared of causing much overhead by putting them into separate [pfft~]s, in which case they would obviously be mutable.
What can I do to minimize the latency of the transposed audio (passing through the [pfft~])? I see that it must be inevitable to some degree, related with FFT window's hop size and total size and sampling freq.; is there a known adjustment to give the best result without losing low freq. resolution?
Thanks.
yes, you can control individually every gizmo~ inside your pfft~. but you will not silence them by sending them "1", they just will output an untransposed signal. to silence a gizmo~, put a gain control after it (connect it to both outputs!). then, if your gizmo~s are many you can choose to put them inside a poly~ and selectively mute the poly~ instances in order to save some CPU %.
the pfft~ latency is only related to your window size. overlap (window size / hop size) doesn't affect it. Sampling rate of course does, but the actual relationship between frequency and time resolutions is not affected by sampling rate either: so, by changing the sr you will have no improvement in your latency without losing frequency resolution.
aa
Thanks very much for your answers.
About your answer to the 2nd one:
About the resolutions; I know that the product of deltatime and deltafrequency cannot be smaller than a constant, I wondered if values for an "optimum" trade-off was experimented before to be written as pfft~arguments. But it would differ anyway as how fast the audio changes / how low freq. it includes... Guess that was a silly question, sorry.
I'm surprised with your answer about the window, because when I increase the overlap from 4 to 8, I hear more "synchrony". I had thought it was because the hop size was reduced (by 0.5) outputting two times faster (?)
About your answer to the 1st one:
I'm using only three transposed parts in addition to the source audio.
Do you mean controlling gain like below or with [*~ ]s?
you can control the gains as you did, or with *~ - conceptually it's the same.
Just, if you use *~ remember to smooth the gain factor with line~ or similar if you don't want clicks and other artifacts.
increasing the overlap improves the time resolution of the processing you do in pfft~, and this explains the better "readyness" you hear. it doesn't change the inherent pfft~ latency, though - test it with a dummy pfft patch, with fftin~ connected to fftout~, and you'll see...
Thanks again. I can see better now.