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 <[email protected]>:
> 
> 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
> [email protected]
> https://lists.puredata.info/listinfo/pd-dev


Best, 
denis

_______________________________________________
Pd-dev mailing list
[email protected]
https://lists.puredata.info/listinfo/pd-dev

Reply via email to