Could you make a simple example patch that demonstrates the rhythmicized/pulsed result that you don't like? Without knowing exactly what's going on in your patch, my first question would be whether or not you're smoothing the frequencies and amplitudes with a [line~] or something else. Maybe sudden changes due to fleeting tracking errors cause glitches that pulse in sync with the analysis period?
With a violin as input you should get a reasonable enough spectrum to get stable harmonic tracking with a window much smaller than 65536. The low G on a violin is 196Hz, so the bin spacing you'd get with -npts 4096 would give plenty of resolution for catching multiples of that fundamental and higher ones, and only 92ms of extra delay. The hop setting you choose will just affect how often the information is updated (and CPU usage too). You should expect to deal with some temporary tracking errors during moments like attacks, where components of the spectrum won't be in a perfectly harmonic relationship.
Going beyond 131072 points using Pd's built-in mayer_fft() has given me garbage as output in the past. Maybe someone else knows something about this limitation?
On Wed, Feb 9, 2011 at 11:41 AM, J bz jbeezez@gmail.com wrote:
Hi all,
I'm doing a piece with a viola d'amore (7 string viol) where [sigmund~] is analysing the live input and feeding 48 tracks/partials to a bank of 48 [osc~] for resynthesis and a bit of jiggery-pokery, mainly reversing the amplitudes so the quietest partials are the loudest and vice versa.
The viola is playing long(ish) single notes between 1-3 seconds and the problem I am having is that when sigmund processes the partials they come out rhythmicised/pulses which seems to be a combination of the 'hop' and 'npts' settings. As the values for hop and npts get higher the pulses get longer up until my current huge setting: [sigmund~ -npts 65536 -hop 65536 -npeak 48 tracks] when the partial frequencies balance out into steady lines. I have also tried -hop 131072 which works too but trying that with the -npts completely locks pd.
The problem I have now is that there is a significant delay between the beginning of the processing in comparison to the viola and worse still is the overlap after the viola has stopped playing. Also the viola notes are indeterminate so I can't just set a cutoff to sync the two together. I could use the input of the viola to gate the tail of the processing but I am currently using a combination of [env~] and [lop~] so that as the performer plays his amplitude controls the processing in reverse, so when he's loud the processing is quiet etc. I suppose I can add another layer on top of the end
I am aware that the gap between the two sounding events is caused by the huge window sizes I am using and that there may well be no way around this to get the kind of sound from the processing I'm looking for, i.e. without the pulses, but I am wondering if anyone has any tips and tricks I can apply to try and bring the two sounds, viola and processing, closer together. Or ideally some way of achieving the smoother processing with lower npts and hop settings. This is for a live performance btw.
All good wishes,
Julian
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list