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.

Hi,

not sure if this is a bug. Don't wanna noobishly spam to the devs' bug reports pile but this needs to be clarified. Is it a deken issue or on the repository or what?

Some searches for externals in the 64-bit version of PD vanilla for windows (I'm on windows 10) the deken search (in the menu: Help -> Find externals) don't return results while the same externals (in some cases) can found on the 32-bit version. Some externals are neither found in the 32- nor 64-bit version. Additionally - as a marker that something is wrong here - PD does not output the line

[deken]: No matching externals found. Try using the full name e.g. 'freeverb'.

which is the case for truly non-existing names (like searching "sdfsdfsdf").

Example of external found as expected on 32- and 64-version:
cyclone

Example of external found as expected on 32- but NOT on 64-bit version:
moonlib

Example of external found neither on 32- or 64-bit version:
apple

What I'm most eager to find out is whether, say, the moonlib external is just not compiled for 64-bit windows and therefore is not found or whether it should be found and just isn't (which hints more towards a bug).

Does anyone have an idea? I'm not completely new to PD but not up to date at all with its development. It seems the current version 0.49 vanilla is the first to have a 64-bit windows version.

kind regards

Have you given Pd root priority (chmod 4755)?

why should I do that? this would make pd run as root always right?
pd already runs with realtime priority, as far as I can see:

$ pd -rt &
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackLinuxFutex::Connect name = jack_sem.1000_default_pure_data
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = pure_data refnum = 4
Jack: JackClient::PortRegister ref = 4 name = pure_data:input0 type = 32 bit float mono audio port_index = 7
Jack: JackClient::PortRegister ref = 4 name = pure_data:input1 type = 32 bit float mono audio port_index = 8
Jack: JackClient::PortRegister ref = 4 name = pure_data:output0 type = 32 bit float mono audio port_index = 9
Jack: JackClient::PortRegister ref = 4 name = pure_data:output1 type = 32 bit float mono audio port_index = 10
Jack: JackClient::Activate
Jack: JackPosixThread::StartImp : create non RT thread
Jack: JackPosixThread::ThreadHandler : start
Jack: JackClient::kBufferSizeCallback buffer_size = 256
Jack: JackClient::Init : period = 5804 computation = 100 constraint = 5804
Jack: JackPosixThread::AcquireRealTimeImp priority = 5
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 2
Jack: JackClient::kActivateClient name = pure_data ref = 4 
Jack: JackClient::Connect src = system:capture_1 dst = pure_data:input0
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::Connect src = system:capture_2 dst = pure_data:input1
Jack: JackClient::Connect src = pure_data:output0 dst = system:playback_1
Jack: JackClient::Connect src = pure_data:output1 dst = system:playback_2
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18
Jack: JackClient::ClientNotify ref = 4 name = pure_data notify = 18

$ ps al | grep pd
F   UID   PID  PPID PRI  NI    VSZ   RSS WCHAN  STAT TTY        TIME COMMAND
0  1000  1212   746  -7   - 259980 183892 -     SLl  pts/0      0:19 pd -rt
0  1000  1214  1212  20   0  58984 24812 -      Sl   pts/0      0:02 wish /usr/lib/pd/tcl//pd-gui.tcl 5401
0  1000  1216  1212  -9   -   2308   796 -      S    pts/0      0:00 /usr/lib/pd/bin/pd-watchdog
0  1000  1311   746  20   0  15064  3088 -      R+   pts/0      0:00 ps al
...

Anyone else having this problem?
I recently installed 64-bit Pd to try it out and some cyclone objects where no longer creating so I updated it with deken

(version is: cyclone v0.3rc1.dek
Upoaded by lucarda @ 2018-09-28 00:09:15)

I cannot get any of these objects to create on 64-bit pd

so then I tried the same thing in my 32-bit version of pd that I have installed separately this time the cyclone version was:
cyclone-v0.3rc1-(Windows-i386-32)-externals.zip
Uploaded by porres @2018-06-28 04:10:47

with the same sad but curious result.

Perhaps @Porres has an idea of what is going on?
(by the way great work getting all those Max 7 objects cloned over!)

Any suggestions appreciated
I would really like to be able to get my patches to work and also would be great to test these new objects..

currently what I have done is merge the Pd-extended cyclone
(version v0.0.extended-(Windowsi386-32)-externals.zip
uploaded by chr15m @ 2015-07-30 15:42:43
with the new one from Porres in order to run my older patches. Of course none of the new objects work in this situation, but this works ok
on my 32-bit Pd (which is version 0.48.1).

@weightless In theory, there is no 32/64-bit limitation. I didn't published the 32-bit version because I think most of people use (or will use) Pd 64-bit and it requires more dev, more testing and so on. Anyway, I managed to compile 32-bit versions on Mac and Linux but I didn't achieved to do it on Windows. The system's libraries of the 32-bit version of LLVM that I compiled was not compatible with Pd (perhaps it's my computer or perhapsI did a stupid mistake). Anyway, compiling LLVM last more than 1 hour so, after a couple of tests, I gave up. But if you're familiar with build systems, you can try yourself. All the instruction are on the README.

Hi everyone,

I am comming to you today because i want to make a project live !.
This project work with pureData and some external pd object :
fluid~ , freeverb~..

My objectiv is to install a 32 bits version of pureData to make external pd work.

I tried these solutions :
Multi arch ubuntu 64 bits host

• On a 64 bits ubuntu
  - add i386 arch
  - update , dist-upgrade..

Then when installing : $> apt-get install puredata:i386
This package is no more available :
These packet a replacing it :

puredata-utils puredata-utils:i386 puredata-extra:i386 puredata-core:i386
puredata-core puredata-dev puredata-doc puredata-extra puredata-gui

So i installed

$> apt-get install puredata-utils:i386 puredata-extra:i386 puredata-core:i386 puredata-gui

pureData is now installed. But when i run it i have this message :

ALSA lib conf.c:3357:(snd_config_hooks_call) Cannot open shared library libasound_module_conf_pulse.so
ALSA lib control.c:954:(snd_ctl_open_noupdate) Invalid CTL hw:0
ALSA card scan error

Still i can use the debugger and hear sound..

When running my stido project using some object like :
udpReceive or udpSend...

i got this on the initialisation (you can see also all the pd objects used) :

import mrpeach/routeOSC
... couldn't create
 import mrpeach/udpreceive
... couldn't create
 import mrpeach/udpsend
... couldn't create
 import mrpeach/packOSC
... couldn't create
 import mrpeach/unpackOSC
... couldn't create
 import flatspace/prepend
... couldn't create
 import flatspace/prepend
... couldn't create
 import moocow/sprinkler
... couldn't create
 import cyclone/speedlim
... couldn't create
./libs/fluid~.pd_linux: libreadline.so.5: cannot open shared object file: No such file or directory
 fluid~
... couldn't create
 freeverb~
... couldn't create
beware! this is xeq 0.1, 3rd beta build... it may bite!
./

So its not working ^^

Solution 2 - Docker

I was thinking : maybe i can just make a puredata container with all the 32 bits libs, So i tried to find some puredata 32 bits image. But nothing.. And Docker is a little tricky with 32 bits container as he didn't provide any support yet.

Still its possible to run 32 bits linux on it .. i found some 32 bits images on the net, but no way how to create one..

If someone has a solution please..

I am working as a volunteer on this project because i believe on it. I have no time yet to update the pd engine for 64 bits..
This project is helping disabled people and your respons will help me so much to provide them a long term support for this software

If you wanna take a look at the project http://orguesensoriel.com

Thank you a lot,

Damien

@alfonso.santimone Oh wow, a Windows 10 VM can't even run on my build machine! It's eating the entire system's memory-- I couldn't even ssh into it and had to reboot.

I could probably cross-compile on the Windows 7 VM. But I wouldn't be able to run tests so that isn't ideal.

Anyway, if you want to try compiling yourself, you can use the instructions from the 32-bit build as a guide:

https://git.purrdata.net/jwilkes/purr-data#windows-32-bit-using-msys2

You'll have to change some of the instructions and download the corresponding msys2 64-bit packages. You'll also certainly run into crashers because the Makefile for windows currently installs some 32-bit dependencies manually into the Purr Data installer package. But if you get that far I can guide you through the solutions to most of those problems.

The good news is that you don't need Lucas' preprocessor flag because we already have an ifdef for Windows 64 big in our build system.

If you can get through all that it would help the project: I could add instructions for a 64-bit Windows build and fix up the windows Makefile so it works for 64-bit. (The GUI we ship on Windows is already 64-bit so that's ready to go.)

I've just opened this tar.gz file downloaded via deken

motex-v0-0extended-(Darwin-i386-32)(Darwin-PowerPC-32)(Darwin-x86_64-32)-externals.tar.gz

and it contains system.pd_darwin, So when you get Deken sorted [motex/system] may also be an option for macs

@ilpoj It could be a widows10 update.
tcl ........ pd_guiprefs.tcl performs the read/writes through the "registry" object.
On a 64-bit system 32-bit apps write to the "VirtualStore" in the registry.
What is 64-bit and what is 32-bit in Pd and Tcl/Tk?
Maybe it's writing to one and reading from the other?
Tcl........ Tcl 8.6 recommended........
https://stackoverflow.com/questions/31432958/tcl-unable-to-read-variables-of-32-bit-registry-hierarchy-on-a-64-bit-machine
Widows........ Microsoft intend to bin VirtualStore and force app compatibility.....
...... have they just started this process?
https://msdn.microsoft.com/en-us/library/windows/desktop/aa965884(v=vs.85).aspx
Other software identical problem.......
http://knowledgebase.progress.com/articles/Article/UACvirtualisation
Pd_guiprefs.tcl on-going work....... 16 days ago.... maybe time to post a bug?
https://github.com/pure-data/pure-data/tree/master/tcl

Again..... Tcl 8.6 recommended.......
https://community.activestate.com/node/11350
and....
http://www.tcl.tk/cgi-bin/tct/tip/362.html
David.

Hi everybody.
Recently I've been watching some videos of pure data for my classes and I've come up with an special "obect" (I'm putting the "" because I don't have a clue of what it is)

Can someone please tell me what the hell is this thing and where to find it to put in pd, because I'm lost and really interested in finding what it is and its purpose. In the video it "works" like if you were putting a number object, but again, I'm just throwing ideas hahaha, This thing appeared in a video using Gem.

Thank you very very much for the time.