Recommended Pitch Detection Object?
Hey,
I was wondering if you use [fiddle~] with live instruments or if there are better objects? I remembered @katjav had made the [helmholtz~] object, but when I try to load it, I get the error
C:\\Users\\selli\\Desktop\\PD_patches\\externals\\Katja\\helmholtz~.dll: couldn't load
helmholtz~
... couldn't create
The double slashes are odd... but maybe it's because my OS is Windows 64Bit and the download is for 32Bit?
@s.elliot.perez Try [sigmund~], it might be more accurate than [fiddle~].
@s.elliot.perez I use win7 64-bit...... so maybe not relevant..... but [Helmholtz~] will load in 32-bit vanilla but not Pd 0.49 64-bit.
As far as I am aware windows has not killed off 32-bit processing.... as has osx.
David.
Thanks, @weightless , @whale-av
Is [Helmholtz~] significantly more accurate than [fiddle~] and [sigmund~]? Is it worth changing PD versions over?
@s.elliot.perez It depends on your project. In windows I just run every variant of Pd uninstalled, in folders on my desktop, starting them with shortcuts to the pd.exe executable, with the startup flags included in the shortcut to control how they are run. Some variants share their path preferences in the registry and some don't (not my decision...... just depends on the version).
I only have extended installed, and it remains my first choice most of the time...... but of course vanilla is necessary now for helping on the forum.
It could be that Miller is following @katjav in his [sigmund~] build? "SNAC" is probably out of patent so hard to tell. [Helmholtz~] certainly has fewer control parameters, but is maybe easier to "tune".
[sigmund~] can be used directly with tables (no signal) as well which can be useful.
David.
Here's a related question, @whale-av : What are the disadvantages of using 32-bit PD in 64-bit Windows? Is it slower than the 64-bit release?
@s.elliot.perez As far as I know the advantages of 64-bit is for float precision and greater ram access (not faster)..
I don't think 32-bit will be slower.
Quote....
"Unless you need to access more memory than 32b addressing will allow you, the benefits will be small, if any.
When running on 64b CPU, you get the same memory interface no matter if you are running 32b or 64b code (you are using the same cache and same BUS).
While x64 architecture has a few more registers which allows easier optimizations, this is often counteracted by the fact pointers are now larger and using any structures with pointers results in a higher memory traffic. I would estimate the increase in the overall memory usage for a 64b application compared to a 32b one to be around 15-30 %."
But the 64-bit versions will evolve.... with new objects.... and so 32-bit versions will become "unsupported" as has been the case for "extended".
David.
If I may weigh in (on both the pitch detection & 32/64 topics):
I have tried all three of the aforementioned objects, and personally found [helmholtz~] to work best for my uses. I can't say I was extremely scientific in my comparisons, but I generally got the sense that it performs a bit better than [sigmund~].
When I first began migration from extended to 64-bit vanilla, all of the 32-bit externals I was using needed to be replaced, and [helmholtz~] was the one I missed the most. I replaced it for a while with [sigmund~], but eventually I went & compiled a new [helmholtz~] from source against 64-bit vanilla, which is working fine.
Now, as for comparing performance of 32 vs 64 bit Pd in general (very much FWIW... I'm on MacOS, not Windows, and I have no technical knowledge to back these observations up): a couple years ago I did test my most CPU-intensive patch in both 32 and 64 bit vanilla, and found a modest ~15-20% CPU performance boost (according to the load meter) when using 64-bit. I remember seeing some discussion of this on the Pd-list a while back, it might have been this thread. I did not compare memory usage between versions, so I can't speak to that.
@beep.beep maybe it could help any OSX user it you share your new compiled 64bit object(s). (maybe future me - I'm on OSX but not in the need of pitch detection at the moment). @whale-av as far as I understand the float precision on a 64bit build is still the same as in 32bit on any system. There is the pd-double by @katjav with ->DoublePrecision<- which I really use for some projects where it is needed.
@Johnny-Mauser For sure... (at the risk of veering somewhat off of the original topic) Here's the 64-bit [helmholtz~] I compiled for Mac:
helmholtz~.pd_darwin
(by the way, @katjav included a README with build instructions in the helmholtz download, and it worked right out of the box for me, so I'd imagine you can compile for whichever platform/architecture you like)
The only other two things I ended up recompiling for 64-bit Pd were [pvoc~] from the bsaylor library, and the iem_dp library for double precision operations within normal Pd. (funny that you should mention double precision as well... maybe the latter could be of use to current you, not just future you!) I uploaded both of those in previous forum threads:
@Johnny-Mauser Hmmm... I don't know, and I can't find any definitive info either. But if Pd is compiled for 64-bit and against 64-bit tcl/tk I don't see why floats would be restricted to 32-bit...... except to help Pd run faster...... so maybe they are?. As I understand it the latest OSX will not run anything 32-bit at all.
Maybe that 64-bit is "single precision" but at 64-bit depth has confused any discussion?
If @jancsika has a moment maybe he can explain where things stand.
David.
[helmholtz~] is usually all you need for good, solid monophonic pitch detection. Use [sigmund~] for more spectral finessing.
@whale-av double precision and 64bit processing are two not directly related things. Isnt it like so that Double precision has to be impemented in the code as such? I am apparently not able to share my nowlege better. Getting rusty in theory. And sorry if i sounded smart ass! @beep.beep thanks for the objects!! i never tested these double precision objects within Pd, but i will when i have to play long sound files again. (which will probably not be within the next year)
If @jancsika has a moment maybe he can explain where things stand.
In Purr Data you can do [floatsize(---[pdinfo] to tell whether floats are single or double precision. The current possible outputs from that message would be "32" for single precision or "64" for double precision.
Pd and the externals you use have to be compiled for one or the other-- you can't mix the two floatsizes. Currently Purr Data is able to build itself and most externals with floatsize=64, but some libraries need to be revised so that they work. So atm we're shipping floatsize=64 Purr Data with just the core and a few convenience libraries. I named these builds "purr-double-trouble" since they don't yet ship with all the externals.
That is all a separate issue from the arch for which a piece of software is compiled. "Arch" means chip architecture and uses nicknames like "i32", "x86_64", "arm64". For general purpose computers these generally divide into two broad categories-- the ones which the hardware shuttles data around in groups of 64 bits, and hardware that shuttles data in groups of 32 bits. Some 64-bit platforms even let you run old stuff built for a 32-bit hardware in a special compatibility mode.
So to clarify: you can have:
Oops! Looks like something went wrong!
