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?
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.
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?
----------begin_max5_patcher---------- 667.3oc2X90aaBCD.+Ypz9NXwycS3+we1a6ywTUDI3j5ofIJ3rk1p1O6yXCK rURmylI1aufiNNat62cb2Ed5c2DEur4HqMF7QvmAQQOojDok0IIZPPTbc4wU aKa0JFKXeqY4Whus+dR1QoVNW.x9gTwgZtXKSp2BbP55FgTTVyz5+o87xsi2 PyA4q1AuRqq5A9d3oS2no7gcLioGGCta7ynk+n9NPzGRFjuqTt5dtXyh8rUR y1nXp59fhNs.3jtqH00SmUa4WYUKTOb0VVTJk64KOHM7JxfGihO2+i9U0xst .moyJNScMNI4nfFmzYEmTmiSTtFmI9DmaJ4hWllanogCZJ3PNObZ4aDcjtKD IGQpIHBNMUSgThdQiGRdGR7s+gci+YpGEf9GxI9GhlY7urPy+ftw+Pl.WZdn 4eINw+fgZ7qvMt2P3yct2azMhLmcixccyHblo2NLP6simSZ57AOQzBMMIAJM QyIMc9bmvBCMwgHM2vert4LU3vWLOmp3G0lhe8+5O6ceroeVhFvzQ.9ePZQl aZ0OD.LG9e.svyMsfH70J2Z8ZoxIdA.+MiaXMvRl.XmpbdQPvzHHW+2anj4E BpAtNGCt7B73ol17BRZbS5iozOI6rfyb3wa4hW80tzmZ2M9Eb11bX+pA6tuu EXTSkJVqBkkRdiXjRpWX.nSJcOuphI9ojkZd0tF0rn81waEis1zf1ZZIdwzf 1XZvqtokYC0Hga.kDtAThWBn41PMZ3FPoga.k5k.J1FpU3EpgsgZce2EOXaE 1fMjeR1Rr01t9YaDaLMHzKbiXU5lmhov.NeCEt4aTqx27yXaTqx27zDH3.Ne iDt4aPZ31N0NayS8SgoAbmAKMNO85PV.WiyRi6uuHWm.0x2AAv5w0. -----------end_max5_patcher-----------
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.