Do you have access to an ARM
machine? If not, I could probably get one online with ssh access, if that's useful.
I've mailed Joe White with the question if he can patch the code for libpd and check performance on ARM. He has done some extremely popular RjDj apps and needed to optimize for them as well. Think it would be good anyway to keep in touch with libpd users and app programmers about this topic, even though we're in an early stage with it.
Yes definitely, we should let everyone who wants to be get involved. I am just saying with need a development platform to start with. Once that's nailed down, we can deal with more issues, like porting to libpd, dealing with externals that could be either 32-bit or 64-bit, etc.
I setup a nightly build on the macosx106-x86_64 and called it pd-double. Andras and r33p, if you are listening, could you run this build on your 64-bit boxes also? All you need to do is:
~pd/auto-build cp -a pd-extended pd-double
Listening now. I did: $ cd ~pd/auto-build $ sudo cp -a pd-extended pd-double What's next? Shall I try patching or rather pull IOhannes's sources?
If you have the run-automated-builder script in a cron job, that is all you have to do.
.hc
Ah, so tomorrow a single and double precision build will automatically be made? Cool.
Also, as I was busy with my life (buying a flat) these days, and I couldn't follow the list as precisely as I wished, could you advise me what's the current best way to roll my own double precision pd? Because I would like to benchmark a fully optimised one.
That would great to have those numbers. [...]
Aaargh. I've arrived to the point where I have almost no functional pd on my box (with the exception of l2ork). vanilla says: "bash: /usr/bin/pd: No such file or directory" (i remember this is a known issue... for 64bit? can it be fixed by any chance?) extended (latest autobuild), and the fresh-built double keep on saying "watchdog: signaling pd..." What did I mess up? Will complete removals/reinstalls help?
Andras