Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested?
Cheers
FJ
i've seen this the other day https://github.com/solipd/AudioLab/blob/master/pp.doppler~.pd
Em ter, 17 de set de 2019 às 07:25, Frodo Jedi < frodojedi.mailinglist@gmail.com> escreveu:
Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested?
Cheers
FJ _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Hello :)
I’ve got a M1 MacBook(OSX 11.6.5) and I am trying to get externals to work in Pd-0.52.2.
Since there are not a lot of externals that are M1 native yet, I am running PD in Rosetta mode(Intel).
But when I download externals via Deken, they won’t load, even after adding them as a path. I’ve tried a few, like zexy and iemlib.
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? Would it make any difference changing Dekens platform settings to another format? In that case, what should I change it to?
Actually it does not matter if I run Pd in Rosetta mode or not, no externals are seen by Pd.
Do you guys have any suggestions to what I try out?
Best wishes,
Jakob
On 17 Sep 2019, at 12.17, Frodo Jedi frodojedi.mailinglist@gmail.com wrote:
Hi all, I am searching for a Pd implementation of a doppler effect as realistic as possible. Any recommendations? Any patch/external already made and well tested?
Cheers
FJ _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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.
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
On 4/27/22 08:25, IOhannes m zmoelnig wrote:
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
i forgot: this will most likely invalidate any signature of the pd binary. you'll probably have to add an override (or re-sign yourself) in order to launch the resulting Pd...
gmnadsr IOhannes
On 4/27/22 08:27, IOhannes m zmoelnig wrote:
On 4/27/22 08:25, IOhannes m zmoelnig wrote:
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 pdi forgot: this will most likely invalidate any signature of the pd binary. you'll probably have to add an override (or re-sign yourself) in order to launch the resulting Pd...
so here's a better solution (also untested). instead if *everything* i wrote above do this:
1. find the file Pd.app/Content/Resources/tcl/pd-gui.tcl 2. open it in an editor 3. locate the line (somewhere around line:846) that says: "[exec -- $pd_exec -guiport $::port {*}$::pd_startup_args &]" 4. in this line put an "arch -x86_64" before the $pd_exec, so it now reads: "[exec -- arch -x86_64 $pd_exec -guiport $::port {*}$::pd_startup_args &]"
this will (well: should) force the Pd-core to run as x86_64.
it would be great if you could report back any success (or failure)...
gfmadsr IOhannes
On Wed, 2022-04-27 at 08:42 +0200, IOhannes m zmoelnig wrote:
so here's a better solution (also untested). instead if *everything* i wrote above do this:
- find the file Pd.app/Content/Resources/tcl/pd-gui.tcl
- open it in an editor
- locate the line (somewhere around line:846) that says:
"[exec -- $pd_exec -guiport $::port {*}$::pd_startup_args &]" 4. in this line put an "arch -x86_64" before the $pd_exec, so it now reads: "[exec -- arch -x86_64 $pd_exec -guiport $::port {*}$::pd_startup_args &]"
That's valuable to know. Thanks, IOHannes. I still have two questions regarding this matter:
1. How does Deken detect current platform/arch? Does it something like `uname -m` or does it check what arch Pd has, or something else?
2. Does the code-signing take into account only the compiled binaries or the whole app? Do I have to re-code-sign after having modified pd- gui.tcl?
BTW: I have access to an M1 with macOS Monterey and hopefully will soon be able to build a few externals and test stuff.
Roman
On 4/27/22 09:01, Roman Haefeli wrote:
That's valuable to know. Thanks, IOHannes. I still have two questions regarding this matter:
- How does Deken detect current platform/arch? Does it something like
`uname -m` or does it check what arch Pd has, or something else?
at compile time, Pd "knows" which architecture it is build for. e.g. when the compiler produces x86_64 binaries for macOS, it sets some macro(s) that Pd then uses to calculate the "Deken specifier". when building universal (fat) binaries, the compiler really runs two times, once with the macro for x86_64 and once with the macro for arm64. when you run the binary, only one of the compiled files (with the proper macro defined) is actually used.
- Does the code-signing take into account only the compiled binaries
or the whole app? Do I have to re-code-sign after having modified pd- gui.tcl?
i really don't know.
i would have expected it to only sign the binaries (so you wouldn't have to re-sign after modifying pd-gui.tcl). but then i just checked the Pd-0.52-2.app/Contents/_CodeSignature/CodeResources (which afaiu contains the signatures), and it seems that the data-files are signed as well...
i guess you just have to try :-)
BTW: I have access to an M1 with macOS Monterey and hopefully will soon be able to build a few externals and test stuff.
that would be great.
gfmdasr IOhannes
I finally had the chance run Pd [1] on an M1-Mac with Monterey. Here's what I found:
When starting Pd normally, two processes (Pd and pd) are running in native mode. Deken shows only arm64 externals. When installing an external, it can be loaded afterwards.
When 'Open with Rosetta' is checked in the information dialog and Pd is started, both processes (Pd and pd) are running in Rosetta mode (the intel binary is executed). Trying to load the previously downloaded arm64 external fails with an error message indicating wront architecture. Now, Deken only shows amd64 externals. When downloading and installing an external now, it can be loaded successfully afterwards.
tl;dr: Pd and Deken seem to do everything correctly on M1 Macs.
Child processed are launched with the same arch as their parent. I observed this also with QjackCtl and jackd. Normally, both run in native mode. When 'Open with Rosetta' is checked in QjackCtl, jackd runs under Rosetta too.
Roman
[1] http://msp.ucsd.edu/Software/pd-0.52-2.macos.zip
On Wed, 2022-04-27 at 09:01 +0200, Roman Haefeli wrote:
On Wed, 2022-04-27 at 08:42 +0200, IOhannes m zmoelnig wrote:
so here's a better solution (also untested). instead if *everything* i wrote above do this:
- find the file Pd.app/Content/Resources/tcl/pd-gui.tcl
- open it in an editor
- locate the line (somewhere around line:846) that says:
"[exec -- $pd_exec -guiport $::port {*}$::pd_startup_args &]" 4. in this line put an "arch -x86_64" before the $pd_exec, so it now reads: "[exec -- arch -x86_64 $pd_exec -guiport $::port {*}$::pd_startup_args &]"
That's valuable to know. Thanks, IOHannes. I still have two questions regarding this matter:
- How does Deken detect current platform/arch? Does it something
like `uname -m` or does it check what arch Pd has, or something else?
- Does the code-signing take into account only the compiled binaries
or the whole app? Do I have to re-code-sign after having modified pd- gui.tcl?
BTW: I have access to an M1 with macOS Monterey and hopefully will soon be able to build a few externals and test stuff.
Roman
Am 30. April 2022 20:33:48 MESZ schrieb Roman Haefeli reduzent@gmail.com:
tl;dr: Pd and Deken seem to do everything correctly on M1 Macs.
thanks a lot for checking so thoroughly
mfg.sfg.jfd IOhannes
Hey 😊
I am off to work atm, but I will just make a short comment and get back to it this afternoon.
When I open Pd in Rosetta mode, it does show up as an Intel app in activity monitor, it says Intel next to it, where native arm apps just say Apple. Dunno if it means anything, if some of Pd is still running arm while Rosetta mode, as you mentioned.
Anyway I will try your suggestion this afternoon, I’ll gladly help out any way I can 😊
My M1 MacBook is the basic model 8gb memory, 8 core, 256gb hd, if it is of any relevance.
Jakob
Den 27. apr. 2022 kl. 08.42 skrev IOhannes m zmoelnig zmoelnig@iem.at:
On 4/27/22 08:27, IOhannes m zmoelnig wrote:
On 4/27/22 08:25, IOhannes m zmoelnig wrote: 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 pdi forgot: this will most likely invalidate any signature of the pd binary. you'll probably have to add an override (or re-sign yourself) in order to launch the resulting Pd...
so here's a better solution (also untested). instead if *everything* i wrote above do this:
- find the file Pd.app/Content/Resources/tcl/pd-gui.tcl
- open it in an editor
- locate the line (somewhere around line:846) that says:
"[exec -- $pd_exec -guiport $::port {*}$::pd_startup_args &]" 4. in this line put an "arch -x86_64" before the $pd_exec, so it now reads: "[exec -- arch -x86_64 $pd_exec -guiport $::port {*}$::pd_startup_args &]"
this will (well: should) force the Pd-core to run as x86_64.
it would be great if you could report back any success (or failure)...
gfmadsr IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
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@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@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Best, denis
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.
Are you sure? I thought that when a universal binary is executed as a child process, it will "inherit" the architecture of the parent process by default.
Christof
On 4/27/22 14:15, Christof Ressi wrote:
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.
Are you sure? I thought that when a universal binary is executed as a child process, it will "inherit" the architecture of the parent process by default.
no, i'm not sure.
it's what i concluded from jakob's problem description.
denis' answer proves that you might be right.
fdmsa IOhannes
Hey again :)
I tried adding the arch -x86_64 to line 846 and I am running PD in Rosetta mode and most seems to be working now.
I have installed these externals, via Deken, with the arch -x86_64 and my experience is: Cyclone - Works with arch -x86_64 but not without. Else - Works with and without arch -x86_64 Zexy - Works with and without arch -x86_64 Tof - Works with arch -x86_64 but not without. Freeverb - Works with arch -x86_64 but not without. Iemlib: - Seems like objects does not work. Like init, filter~, vcf_filter~, aspeedlim, etc. neither with or without
I double checked the above a few times, I made a copy of PD before I changed line 846, so I had a version with the arch -x86_64 and one without. Then I opened and tested the different externals with and without arch -x86_64 and the result is the above.
I have to admit I forgot to add the startup flag for zexy (-lib zexy). Sorry, it has been years since I set up PD last time.
About Christofs comment, I tried to explain as well as I could. I might have missed something.
If you have any further questions or anything else you’d like me to try, I’d be happy to help out.
THANKS!
Jakob
On 27 Apr 2022, at 18.54, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 4/27/22 14:15, Christof Ressi wrote:
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.
Are you sure? I thought that when a universal binary is executed as a child process, it will "inherit" the architecture of the parent process by default.
no, i'm not sure.
it's what i concluded from jakob's problem description.
denis' answer proves that you might be right.
fdmsa IOhannes _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
Am 27. April 2022 19:34:01 MESZ schrieb Jakob Skouborg syntaxerror60@hotmail.com:
Iemlib: - Seems like objects does not work. Like init, filter~, vcf_filter~, aspeedlim, etc. neither with or without
You have to both *load* iemlib, and add it's *path*.
Typically you would add this to your patches depending on this library: [declare -path iemlib -lib iemlib]
mfg.sfg.jfd IOhannes
-
Alexandre Torres Porres -
Christof Ressi -
Denis Połeć -
Frodo Jedi -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Jakob -
Jakob Skouborg
-
Roman Haefeli