[PD-dev] Externals in Pd.52.2(Rosetta Mode) on Mac M1!

Denis Połeć denis.polec at gmail.com
Wed Apr 27 10:43:24 CEST 2022


Hey,

I am on a M1 Max machine, when I am opening pd-0.52-2 in rosetta mode, I don’t face any problems to load 
„old“ - x86 externals.

Old because I load them in the past with deken! It means with an pd intel version… like pd-0.51-4
It seems that deken doesn’t show x86 versions when you run pd in rosetta mode.


> Am 27.04.2022 um 08:25 schrieb IOhannes m zmoelnig <zmoelnig at iem.at>:
> 
> On 4/26/22 21:12, Jakob Skouborg wrote:
> 
>> I checked Dekens platform settings and it is set to Darwin-arm64-32. Does that mean Deken will download "arm specific" externals, even though I am running Pd in Rosetta mode?
> 
> yes.
> 
>> Would it make any difference changing Dekens platform settings to another format? In that case, what should I change it to?
> 
> no.
> 
> 
> it's all much more complicated than we though :-)
> 
> know that I think of it, it seems that Rosetta doesn't really help that much, because Pd is split in two separate processes: Pd-GUI and Pd(-core). The user only ever sees the Pd-GUI, the Pd-core just runs in the background.



> 
> Now, for the Pd-0.52-2 release, both binaries (Pd-GUI and Pd-core) are universal (x86_64/arm64) builds.
> When you start Pd through Rosetta (by right-clicking the app-icon and selectign "Open using Rosetta"), you instruct the OS to launch the Pd-GUI through rosetta.
> The Pd-GUI then starts the Pd-core, and doesn't care a bit about your rosetta-settings, which means that the Pd-core is started in native (arm64) mode.

In my case with rosetta both Pd-Gui and Pd-core are in Intel-Mode.


> 
> So you end up with an x86_64 Pd-GUI process (where the Rosetta doesn't really matter, as speed is not of an essence here), and an arm64 Pd-core process (which is the one that loads externals, and which you tried to force to x86_64 with Rosetta).
> 
> bummer.
> 
> 
> > I’ve tried a few, like zexy and iemlib.
> 
> these are a bit special, as they are part of the small set that provides binaries for both Darwin-x86_64 and Darwin-arm64.
> The arm64 (M1) binary are totally untested though.
> it looks like we are going to get a an M1 based mac in the near future at the iem, so I can at least test our builds locally...
> 
> 
> > Do you guys have any suggestions to what I try out?
> 
> 
> the only quick fix that comes to my mind right now, is to purge the arm64 part of the Pd-core, so it is forced to run through Rosetta.
> 
> something like this should do the trick (in the terminal):
> ```
> cd /Applications/Pd-0.52.2.app/Content/Resources/bin/
> mv pd pd.fat
> lipo pd.fat -thin x86_64 -output pd
> ```
> 
> (this is written from the top-of my head; so the paths might not be correct (and they might be different on your machine anyhow), and the 'lipo' invocation might be wrong as well (check 'man lipo'); but hopefully you'll get the gist of it)
> 
> the long term fix (as has been discussed) is of course to just provide (working) arm64 binaries for "all" the libraries.
> 
> 
> an intermediate-term fix would be to somehow pass the rosetta-settings to the launched sub-process (that is: if Pd-GUI was started via Rosetta, than the Pd-core should also be launched via Rosetta).
> 
> i have no idea how to do this (or whether it is feasible at all).
> 
> fgmadsr
> IOhannes
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev


Best, 
denis

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220427/b92e85b6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto 2022-04-27 um 10.36.11.png
Type: image/png
Size: 19826 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220427/b92e85b6/attachment-0001.png>


More information about the Pd-dev mailing list