Is it expected that in the fluid.pitch~ max helpfile with default settings the result is very poor (5.5kHz rather than 220Hz) - result is fine with an fft size of 4096, but poor for 1024.
Note that if the maxfftsize is set the same as the fft size the results are much better, so this does appear to be a bug.
Is it expected that in the fluid.pitch~ max helpfile with default settings the result is very poor (5.5kHz rather than 220Hz) - result is fine with an fft size of 4096, but poor for 1024.
No, and I’m not seeing that here (the first tab, I assume), but will check against a released build.
Note that if the maxfftsize is set the same as the fft size the results are much better, so this does appear to be a bug.
I’m not observing this either, but could be some bug in argument / attribute processing w/r/t to max<X> stuff that since has been fixed on the dev branch.
What’s your current version? (send version) to any fluid.* object
My version could be not meaningful as I may have made my own build, but if not I’ll be on the package manager version, and the issue was reported to me by someone who would be on that version.
First tab indeed.
I’m on intel in case that is relevant. I expect that James is not.
According to the package manager I have 1.0.4 and there is no conflict showing, so I think it is the PM version.
Here is my install with fft size set to 4096.
Here is my install with fft size set to 1024.
The incorrect value is consistent every time.
wow this is surreal - I have the package manager version, on the exact same machine as yours @a.harker and I get the expected results… less precision at 1024 but still good. I would try to remove my install and re-download, in case what cycling uploads get corrupted but that is quite very unlikely, agreed?
also, what are you svs settings?
SVS settings don’t change things for me (or SIAI etc.). It is possible I have a custom build, but the person who alerted me to the issue was Matt Jackson and I don’t see how he could have anything other than an official release.
so strange… eventually we might find the cultprit…
If I can return to my plea for the version string it might still help, because it has commit hashes in it. If the reporter is on an older package manager build and you haven’t built for a while then it’s possible that some badness coincides. At least having your commit hashes will improve our odds of reproducing it, no?
fluid.pitch~: Fluid Corpus Manipulation Toolkit, version 1.0.0-TB2.beta6+sha.0a46dc9.core.sha.646b677a
That doesn’t look quite right, but I’m confused as to how Matt would be on a version with this issue also, unless he had a beta version previously.
The current package manager version (1.0.4) isn’t the first, IIRC. So if Matt got in early and hasn’t updated then perhaps you and he are both being afflicted by something we’ve already fixed.
Sure - I just mailed him to see if an update at his end fixes it but he mailed me a screenshot showing that he is on 1.0.4…
If I blast my install and redownload I get expected results:
fluid.pitch~: Fluid Corpus Manipulation Toolkit, version 1.0.4+sha.ffc30a0.core.sha.60e1a77
I’m the reporter.
In fluid.pitch~ helpful basic tab, with FluCoMa 1.0.4 I and Cycle get a stable pitch of 224.00… and confidence of .784… And at 4096 frame size 220.26
My issue was and is a complete user error. I was on the Select tab and listening to the results. I was completely careless and thought that the sounds I heard were being pitch tracked. I heard the queasy part of the modular and the high pitched part and thought that the high pitched part was bad pitch tracking. I’m an idiot. Please excuse the fuss.
@Matt_Jackson, not to worry! Much rather hear about possible problems than not 
Glad it’s working now
Ah - looks like some helpful combo of my misunderstanding of Matt’s report, me not being on the official release version and the package manager not identifying when I was “off piste” that led to this noise. Sorry…
