Howdy Miller,
the macOS 10.10+ build is working fine and supports both x86_64 & arm64. I think you can remove the link to my previous 0.52-1 arm64-only build on the download page.
On Mar 28, 2022, at 7:18 AM, pd-list-request@lists.iem.at wrote:
Message: 4 Date: Sun, 27 Mar 2022 21:56:46 -0700 From: Miller Puckette via Pd-announce <pd-announce@lists.iem.at mailto:pd-announce@lists.iem.at> To: pd-announce@lists.iem.at mailto:pd-announce@lists.iem.at Cc: Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> Subject: [PD] [PD-announce] Pd 0.52-2 released Message-ID: <YkFADvjORTRhzRCr@ucsd.edu mailto:YkFADvjORTRhzRCr@ucsd.edu> Content-Type: text/plain; charset="us-ascii"
To Pd-announce:
Pd version 0.52-2 is available from http://msp.ucsd.edu/software.htm http://msp.ucsd.edu/software.htm or (source only) via github: https://github.com/pure-data/pure-data https://github.com/pure-data/pure-data .
cheers Miller
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Em seg., 28 de mar. de 2022 às 07:17, Dan Wilcox danomatika@gmail.com escreveu:
Howdy Miller,
the macOS 10.10+ build is working fine and supports both x86_64 & arm64. I think you can remove the link to my previous 0.52-1 arm64-only build on the download page.
Great to know that, so let me see if I get it straight. If you have an apple silicon, it'll run under the hood the arm code and then it will only find and load 'arm64' externals? Or can you load both externals types? How does it work?
Oh, and Miller's site should say it is a universal binary ready for the new macs!
cheers
If you have an apple silicon, it'll run under the hood the arm code and then it will only find and load 'arm64' externals?
From my understanding, yes. For that reason, I guess it's not a good idea to provide universal binaries at this point and we should rather ship seperate binaries. Once most externals are available as universal binaries, we might ship Pd as a universal binary as well.
Of course, you can always force apps to run under Rosetta, but I don't think that's a good user experience.
Christof
On 29.03.2022 16:02, Alexandre Torres Porres wrote:
Em seg., 28 de mar. de 2022 às 07:17, Dan Wilcox danomatika@gmail.com escreveu:
Howdy Miller, the macOS 10.10+ build is working fine and supports both x86_64 & arm64. I think you can remove the link to my previous 0.52-1 arm64-only build on the download page.Great to know that, so let me see if I get it straight. If you have an apple silicon, it'll run under the hood the arm code and then it will only find and load 'arm64' externals? Or can you load both externals types? How does it work?
Oh, and Miller's site should say it is a universal binary ready for the new macs!
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
Em ter., 29 de mar. de 2022 às 11:12, Christof Ressi info@christofressi.com escreveu:
From my understanding, yes. For that reason, I guess it's not a good idea to provide universal binaries at this point and we should rather ship seperate binaries. Once most externals are available as universal binaries, we might ship Pd as a universal binary as well.
Of course, you can always force apps to run under Rosetta, but I don't
think that's a good user experience.
I agree, separate binaries makes more sense these days.
On 3/29/22 16:10, Christof Ressi wrote:
If you have an apple silicon, it'll run under the hood the arm code and then it will only find and load 'arm64' externals?
From my understanding, yes. For that reason, I guess it's not a good idea to provide universal binaries at this point and we should rather ship seperate binaries.
i'm utterly confused.
it was my feeling that the situation for Pd-0.52-1 where we did just that was not ideal. i remember people complaining that there was no M1 binary in the first place.
now people seem to all agree that it was much better way back then.
before anyone starts providing an x86_64-only binary, consider rebuilding the externals for arm64 and upload them. this will be a net-win for the future, rather than trying to keep the past alive.
i did some quick stats of the macOS downloads in the last 10 days. here's the top 10 (which make for 66% of all the macOS downloads):
cyclone zexy else comport Gem iemlib ggee freeverb~ mrpeach pddp
at least zexy and comport already provide m1 binaries. the only library where i would expect any problems for compiling for Darwin-arm64 is Gem (actually building is fine; the problem is more about including all the relevant helper libraries in the deken package - homebrew just sucks when it comes to multi-architecture).
ghdfs IOhannes
Now *I* am utterly confused.
now people seem to all agree that it was much better way back then.
I think everybody agrees that there should be an ARM64 binary for macOS. The question is just whether it should be the default on M1 machines when there are so few ARM64 externals for macOS available on Deken. (I count 9: zexy, comport, xsample, pool, clk, absattr, vasp, zconf, constantq~)
Actually, this issue already came up two months ago and someone called it a "lousy UX":
https://lists.puredata.info/pipermail/pd-list/2022-01/130772.html
So what has changed?
As I said before, we might alternatively add a disclaimer to the download page that people might want to force-run Pd under Rosetta if they don't find all the externals they need.
However, I'm not a Mac user and I don't have a ball in this game. I was just parotting what I thought the consensus was back then...
Christof
On 30.03.2022 09:03, IOhannes m zmoelnig wrote:
On 3/29/22 16:10, Christof Ressi wrote:
If you have an apple silicon, it'll run under the hood the arm code and then it will only find and load 'arm64' externals?
From my understanding, yes. For that reason, I guess it's not a good idea to provide universal binaries at this point and we should rather ship seperate binaries.
i'm utterly confused.
it was my feeling that the situation for Pd-0.52-1 where we did just that was not ideal. i remember people complaining that there was no M1 binary in the first place.
now people seem to all agree that it was much better way back then.
before anyone starts providing an x86_64-only binary, consider rebuilding the externals for arm64 and upload them. this will be a net-win for the future, rather than trying to keep the past alive.
i did some quick stats of the macOS downloads in the last 10 days. here's the top 10 (which make for 66% of all the macOS downloads):
cyclone zexy else comport Gem iemlib ggee freeverb~ mrpeach pddp
at least zexy and comport already provide m1 binaries. the only library where i would expect any problems for compiling for Darwin-arm64 is Gem (actually building is fine; the problem is more about including all the relevant helper libraries in the deken package
- homebrew just sucks when it comes to multi-architecture).
ghdfs IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
it works the same as *any* existing application that is compiled for multiple architectures: it uses the current system architecture but default. If you want, you can force an architecture via using "arch" on the command line:
https://medium.com/swlh/run-x86-terminal-apps-like-homebrew-on-your-new-m1-m... https://medium.com/swlh/run-x86-terminal-apps-like-homebrew-on-your-new-m1-mac-73bdc9b0f343
For Pd, you can't do this by double-clicking to launch the application but by invoking the core internally:
arch -x86_64 /Applications/Pd-0.52-2.app/Contents/Resources/bin/pd
This should force running the core as x86_64 with Rosetta 2.
No, nothing has changed about which externals can be loaded. If the external is compiled for the architecture you are running Pd under, then it should load.
On Mar 29, 2022, at 4:02 PM, Alexandre Torres Porres porres@gmail.com wrote:
Em seg., 28 de mar. de 2022 às 07:17, Dan Wilcox <danomatika@gmail.com mailto:danomatika@gmail.com> escreveu: Howdy Miller,
the macOS 10.10+ build is working fine and supports both x86_64 & arm64. I think you can remove the link to my previous 0.52-1 arm64-only build on the download page.
Great to know that, so let me see if I get it straight. If you have an apple silicon, it'll run under the hood the arm code and then it will only find and load 'arm64' externals? Or can you load both externals types? How does it work?
Oh, and Miller's site should say it is a universal binary ready for the new macs!
cheers
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
Ah right, as Edwin wrote, you can also right-click on the application, choose Get Info, the check Open in Rosetta to force running as x86_64 on M1 macs. However, as Phil notes, this means Pd is running under arch emulation and will be slower, so this is more of a temporary workaround until you can update your externals to universal/native builds.
On Mar 29, 2022, at 9:08 PM, Dan Wilcox danomatika@gmail.com wrote:
it works the same as *any* existing application that is compiled for multiple architectures: it uses the current system architecture but default. If you want, you can force an architecture via using "arch" on the command line:
https://medium.com/swlh/run-x86-terminal-apps-like-homebrew-on-your-new-m1-m... https://medium.com/swlh/run-x86-terminal-apps-like-homebrew-on-your-new-m1-mac-73bdc9b0f343
For Pd, you can't do this by double-clicking to launch the application but by invoking the core internally:
arch -x86_64 /Applications/Pd-0.52-2.app/Contents/Resources/bin/pd
This should force running the core as x86_64 with Rosetta 2.
No, nothing has changed about which externals can be loaded. If the external is compiled for the architecture you are running Pd under, then it should load.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
-
Alexandre Torres Porres -
Christof Ressi -
Dan Wilcox -
IOhannes m zmoelnig