Finding a .dylib required by externals
I'm running Pd-0.52-2 on MacOS Monterey (12.6) and having trouble with externals that I created. When developing/debugging, everything is fine. I have 4 externals with extensions .pd_darwin, each dependent upon a DLL named libo2pd.dylib. With everything in ~/Documents/Pd/externals/, I can start my locally compiled pd-0.52-2.app, and everything works. But if I run a downloaded /Applications/Pd-052-2.app and try to create one of these external objects, I get the message:
/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin: dlopen(/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin, 0x000A): Library not loaded: 'libo2pd.dylib'
Referenced from: '/Users/rbd/Documents/Pd/externals/o2ensemble.pd_darwin'
Reason: tried: 'libo2pd.dylib' (relative path not allowed in hardened program), '/usr/lib/libo2pd.dylib' (no such file)
o2ensemble o2global
... couldn't create
I get the same results running from the command line, and running from the directory with the .dylib and externals does not make any difference. Note that /usr/lib is protected even using sudo, so even if I could install libo2pd.dylib there, I don't think it's an acceptable solution.
I suspect this problem stems from Apple security policies, but I don't know how Pd searches for .dylibs and there's a lot of ambiguity in documentation and discussions since "libraries" and "paths" are used in multiple ways. I also tried setting LD_LIBRARY_PATH and running from the command line, but that didn't work.
Does anyone know to set up Pd for an external that depends on a DLL?
posted in extra~
Can't install purr-data on Manjaro
Hey, I'm trying to get purr-data to work on my fresh Manjaro XFCE install, but it does not work. Any help is greatly appreciated!
$ yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00)
Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00)
Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00)
LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00)
Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00)
A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
1) gconf 2) gconf-gtk2
Enter a number (default=1): ==>
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2] gconf-3.2.6+11+g07808097-10 purr-data-git-2.12.0.r4366.6d94e10b-1
2 gconf (Build Files Exist)
1 purr-data-git
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/1): /home/olav/.cache/yay/gconf
:: (1/2) Downloaded PKGBUILD: gconf
:: (2/2) Downloaded PKGBUILD: purr-data-git
2 gconf (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: (1/2) Parsing SRCINFO: gconf
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning gconf git repo...
Cloning into bare repository '/home/olav/.cache/yay/gconf/gconf'...
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
remote: Enumerating objects: 21531, done.
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 21531 (delta 0), reused 0 (delta 0), pack-reused 21531
Receiving objects: 100% (21531/21531), 10.88 MiB | 9.46 MiB/s, done.
Resolving deltas: 100% (17681/17681), done.1 KiB | 704.00 KiB/s
-> Found 01_xml-gettext-domain.patch388.01 KiB | 704.00 KiB/s
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
-> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86.7M 100 86.7M 0 0 3966k 0 0:00:22 0:00:22 --:--:-- 8404k
==> Validating source files with md5sums...
purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:24:19 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating gconf git repo...
Fetching origin
-> Found 01_xml-gettext-domain.patch
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Creating working copy of gconf git repo...
Cloning into 'gconf'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
/home/olav/.cache/yay/gconf/PKGBUILD: line 30: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: gconf
And
yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00)
Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00)
Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00)
LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00)
Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00)
A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
1) gconf 2) gconf-gtk2
Enter a number (default=1): ==>
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2] gconf-3.2.6+11+g07808097-10 purr-data-git-2.12.0.r4366.6d94e10b-1
2 gconf (Build Files Exist)
1 purr-data-git
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/1): /home/olav/.cache/yay/gconf
:: (1/2) Downloaded PKGBUILD: gconf
:: (2/2) Downloaded PKGBUILD: purr-data-git
2 gconf (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: (1/2) Parsing SRCINFO: gconf
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning gconf git repo...
Cloning into bare repository '/home/olav/.cache/yay/gconf/gconf'...
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:23:23 PM CET)
==> Retrieving sources...
-> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
remote: Enumerating objects: 21531, done.
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 21531 (delta 0), reused 0 (delta 0), pack-reused 21531
Receiving objects: 100% (21531/21531), 10.88 MiB | 9.46 MiB/s, done.
Resolving deltas: 100% (17681/17681), done.1 KiB | 704.00 KiB/s
-> Found 01_xml-gettext-domain.patch388.01 KiB | 704.00 KiB/s
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 5.71 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
-> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86.7M 100 86.7M 0 0 3966k 0 0:00:22 0:00:22 --:--:-- 8404k
==> Validating source files with md5sums...
purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf 3.2.6+11+g07808097-10 (Wed 09 Feb 2022 10:24:19 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Updating gconf git repo...
Fetching origin
-> Found 01_xml-gettext-domain.patch
-> Found gconf-reload.patch
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-install.hook
-> Found gconf-remove.hook
==> Validating source files with sha256sums...
gconf ... Skipped
01_xml-gettext-domain.patch ... Passed
gconf-reload.patch ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Creating working copy of gconf git repo...
Cloning into 'gconf'...
done.
Switched to a new branch 'makepkg'
==> Starting prepare()...
/home/olav/.cache/yay/gconf/PKGBUILD: line 30: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: gconf
[olav@AMD-Computer ~]$ yay purr-data
7 aur/purrdata-faust 0.18-1 (+0 0.00)
Run Faust signal processors in Pd, Purr-Data version
6 aur/purrdata-pure 0.26-1 (+0 0.00)
Loader plugin for the Pure programming language, Purr-Data version
5 aur/purrdata-lv2plugin-git 25.e00f302-1 (+0 0.00)
LV2 plugin host for Pd, Purr-Data version
4 aur/purrdata-mdnsbrowser-git 8.88d2b0c-1 (+0 0.00)
Zeroconf service advertising and discovery for Pd, Purr-Data version
3 aur/purrdata-touchosc-git 44.443c793-1 (+0 0.00)
A TouchOSC MIDI bridge for Pd, Purr-Data version
2 aur/purr-data-git 2.12.0.r4366.6d94e10b-1 (+2 0.00)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
1 aur/purr-data 2.12.0.r4346.aeb24d89-1 (+6 0.03) (Out-of-date: 2021-06-17)
Jonathan Wilkes' nw.js variant of Pd-L2Ork (git version)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)
==> 2
:: There are 2 providers available for gconf:
:: Repository AUR
1) gconf 2) gconf-gtk2
Enter a number (default=1): ==> 2
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur:2] gconf-gtk2-3.2.6-5 purr-data-git-2.12.0.r4366.6d94e10b-1
2 gconf-gtk2 (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> a
:: Deleting (1/2): /home/olav/.cache/yay/gconf-gtk2
:: Deleting (2/2): /home/olav/.cache/yay/purr-data-git
:: (1/2) Downloaded PKGBUILD: purr-data-git
:: (2/2) Downloaded PKGBUILD: gconf-gtk2
2 gconf-gtk2 (Build Files Exist)
1 purr-data-git (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==>
:: (1/2) Parsing SRCINFO: gconf-gtk2
:: (2/2) Parsing SRCINFO: purr-data-git
==> Making package: purr-data-git 2.12.0.r4366.6d94e10b-1 (Wed 09 Feb 2022 10:40:58 PM CET)
==> Retrieving sources...
==> Making package: gconf-gtk2 3.2.6-5 (Wed 09 Feb 2022 10:40:58 PM CET)
==> Retrieving sources...
-> Cloning purr-data-git git repo...
Cloning into bare repository '/home/olav/.cache/yay/purr-data-git/purr-data-git'...
-> Downloading GConf-3.2.6.tar.xz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 1523k 100 1523k 0 0 1610k 0 --:--:-- --:--:-- --:--:-- 1610k
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-reload.patch
-> Found gconf-install.hook
-> Found gconf-remove.hook
-> Found 01_xml-gettext-domain.patch
-> Found dbus-dontspew.patch
-> Found gsettings-data-convert-fix-invalid-schema-path.patch
==> Validating source files with sha256sums...
GConf-3.2.6.tar.xz ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-reload.patch ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
01_xml-gettext-domain.patch ... Passed
dbus-dontspew.patch ... Passed
gsettings-data-convert-fix-invalid-schema-path.patch ... Passed
remote: Enumerating objects: 63399, done.
remote: Counting objects: 100% (1852/1852), done.
remote: Compressing objects: 100% (641/641), done.
remote: Total 63399 (delta 1106), reused 1786 (delta 1052), pack-reused 61547
Receiving objects: 100% (63399/63399), 177.19 MiB | 9.76 MiB/s, done.
Resolving deltas: 100% (33721/33721), done.
-> Downloading nwjs-sdk-v0.24.4-linux-x64.tar.gz...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 86.7M 100 86.7M 0 0 11.7M 0 0:00:07 0:00:07 --:--:-- 14.4M
==> Validating source files with md5sums...
purr-data-git ... Skipped
==> Validating source_x86_64 files with md5sums...
nwjs-sdk-v0.24.4-linux-x64.tar.gz ... Passed
==> Making package: gconf-gtk2 3.2.6-5 (Wed 09 Feb 2022 10:41:26 PM CET)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
-> Found GConf-3.2.6.tar.xz
-> Found gconf-merge-schema
-> Found gconfpkg
-> Found gconf-reload.patch
-> Found gconf-install.hook
-> Found gconf-remove.hook
-> Found 01_xml-gettext-domain.patch
-> Found dbus-dontspew.patch
-> Found gsettings-data-convert-fix-invalid-schema-path.patch
==> Validating source files with sha256sums...
GConf-3.2.6.tar.xz ... Passed
gconf-merge-schema ... Passed
gconfpkg ... Passed
gconf-reload.patch ... Passed
gconf-install.hook ... Passed
gconf-remove.hook ... Passed
01_xml-gettext-domain.patch ... Passed
dbus-dontspew.patch ... Passed
gsettings-data-convert-fix-invalid-schema-path.patch ... Passed
==> Removing existing $srcdir/ directory...
==> Extracting sources...
-> Extracting GConf-3.2.6.tar.xz with bsdtar
==> Starting prepare()...
/home/olav/.cache/yay/gconf-gtk2/PKGBUILD: line 39: patch: command not found
==> ERROR: A failure occurred in prepare().
Aborting...
-> error making: gconf-gtk2
posted in technical issues
Why does Pd look so much worse on linux/windows than in macOS?
Howdy all,
I just found this and want to respond from my perspective as someone who has spent by now a good amount of time (paid & unpaid) working on the Pure Data source code itself.
I'm just writing for myself and don't speak for Miller or anyone else.
Mac looks good
The antialiasing on macOS is provided by the system and utilized by Tk. It's essentially "free" and you can enable or disable it on the canvas. This is by design as I believe Apple pushed antialiasing at the system level starting with Mac OS X 1.
There are even some platform-specific settings to control the underlying CoreGraphics settings which I think Hans tried but had issues with: https://github.com/pure-data/pure-data/blob/master/tcl/apple_events.tcl#L16. As I recall, I actually disabled the font antialiasing as people complained that the canvas fonts on mac were "too fuzzy" while Linux was "nice and crisp."
In addition, the last few versions of Pd have had support for "Retina" high resolution displays enabled and the macOS compositor does a nice job of handling the point to pixel scaling for you, for free, in the background. Again, Tk simply uses the system for this and you can enable/disable via various app bundle plist settings and/or app defaults keys.
This is why the macOS screenshots look so good: antialiasing is on and it's likely the rendering is at double the resolution of the Linux screenshot.
IMO a fair comparison is: normal screen size in Linux vs normal screen size in Mac.
Nope. See above. 
It could also just be Apple holding back a bit of the driver code from the open source community to make certain linux/BSD never gets quite as nice as OSX on their hardware, they seem to like to play such games, that one key bit of code that is not free and you must license from them if you want it and they only license it out in high volume and at high cost.
Nah. Apple simply invested in antialiasing via its accelerated compositor when OS X was released. I doubt there are patents or licensing on common antialiasing algorithms which go back to the 60s or even earlier.
tkpath exists, why not use it?
Last I checked, tkpath is long dead. Sure, it has a website and screenshots (uhh Mac OS X 10.2 anyone?) but the latest (and only?) Sourceforge download is dated 2005. I do see a mirror repo on Github but it is archived and the last commit was 5 years ago.
And I did check on this, in fact I spent about a day (unpaid) seeing if I could update the tkpath mac implementation to move away from the ATSU (Apple Type Support) APIs which were not available in 64 bit. In the end, I ran out of energy and stopped as it would be too much work, too many details, and likely to not be maintained reliably by probably anyone.
It makes sense to help out a thriving project but much harder to justify propping something up that is barely active beyond "it still works" on a couple of platforms.
Why aren't the fonts all the same yet?!
I also despise how linux/windows has 'bold' for default
I honestly don't really care about this... but I resisted because I know so many people do and are used to it already. We could clearly and easily make the change but then we have to deal with all the pushback. If you went to the Pd list and got an overwhelming consensus and Miller was fine with it, then ok, that would make sense. As it was, "I think it should be this way because it doesn't make sense to me" was not enough of a carrot for me to personally make and support the change.
Maybe my problem is that I feel a responsibility for making what seems like a quick and easy change to others?
And this view is after having put an in ordinate amount of time just getting (almost) the same font on all platforms, including writing and debugging a custom C Tcl extension just to load arbitrary TTF files on Windows.
Why don't we add abz, 123 to Pd? xyzzy already has it?!
What I've learned is that it's much easier to write new code than it is to maintain it. This is especially true for cross platform projects where you have to figure out platform intricacies and edge cases even when mediated by a common interface like Tk. It's true for any non-native wrapper like QT, WXWidgets, web browsers, etc.
Actually, I am pretty happy that Pd's only core dependencies a Tcl/Tk, PortAudio, and PortMidi as it greatly lowers the amount of vectors for bitrot. That being said, I just spent about 2 hours fixing the help browser for mac after trying Miller's latest 0.52-0test2 build. The end result is 4 lines of code.
For a software community to thrive over the long haul, it needs to attract new users. If new users get turned off by an outdated surface presentation, then it's harder to retain new users.
Yes, this is correct, but first we have to keep the damn thing working at all. 
I think most people agree with you, including me when I was teaching with Pd.
I've observed, at times, when someone points out a deficiency in Pd, the Pd community's response often downplays, or denies, or gets defensive about the deficiency. (Not always, but often enough for me to mention it.) I'm seeing that trend again here. Pd is all about lines, and the lines don't look good -- and some of the responses are "this is not important" or (oid) "I like the fact that it never changed." That's... thoroughly baffling to me.
I read this as "community" = "active developers." It's true, some people tend to poo poo the same reoccurring ideas but this is largely out of years of hearing discussions and decisions and treatises on the list or the forum or facebook or whatever but nothing more. In the end, code talks, even better, a working technical implementation that is honed with input from people who will most likely end up maintaining it, without probably understanding it completely at first.
This was very hard back on Sourceforge as people had to submit patches(!) to the bug tracker. Thanks to moving development to Github and the improvement of tools and community, I'm happy to see the new engagement over the last 5-10 years. This was one of the pushes for me to help overhaul the build system to make it possible and easy for people to build Pd itself, then they are much more likely to help contribute as opposed to waiting for binary builds and unleashing an unmanageable flood of bug reports and feature requests on the mailing list.
I know it's not going to change anytime soon, because the current options are a/ wait for Tcl/Tk to catch up with modern rendering or b/ burn Pd developer cycles implementing something that Tcl/Tk will(?) eventually implement or c/ rip the guts out of the GUI and rewrite the whole thing using a modern graphics framework like Qt. None of those is good (well, c might be a viable investment in the future -- SuperCollider, around 2010-2011, ripped out the Cocoa GUIs and went to Qt, and the benefits have been massive -- but I know the developer resources aren't there for Pd to dump Tcl/Tk).
A couple of points:
-
Your point (c) already happened... you can use Purr Data (or the new Pd-L2ork etc). The GUI is implemented in Node/Electron/JS (I'm not sure of the details). Is it tracking Pd vanilla releases?... well that's a different issue.
-
As for updating Tk, it's probably not likely to happen as advanced graphics are not their focus. I could be wrong about this.
I agree that updating the GUI itself is the better solution for the long run. I also agree that it's a big undertaking when the current implementation is essentially still working fine after over 20 years, especially since Miller's stated goal was for 50 year project support, ie. pieces composed in the late 90s should work in 2040. This is one reason why we don't just "switch over to QT or Juce so the lines can look like Max." At this point, Pd is aesthetically more Max than Max, at least judging by looking at the original Ircam Max documentation in an archive closet at work.
A way forward: libpd?
I my view, the best way forward is to build upon Jonathan Wilke's work in Purr Data for abstracting the GUI communication. He essentially replaced the raw Tcl commands with abstracted drawing commands such as "draw rectangle here of this color and thickness" or "open this window and put it here."
For those that don't know, "Pd" is actually two processes, similar to SuperCollider, where the "core" manages the audio, patch dsp/msg graph, and most of the canvas interaction event handling (mouse, key). The GUI is a separate process which communicates with the core over a localhost loopback networking connection. The GUI is basically just opening windows, showing settings, and forwarding interaction events to the core. When you open the audio preferences dialog, the core sends the current settings to the GUI, the GUI then sends everything back to the core after you make your changes and close the dialog. The same for working on a patch canvas: your mouse and key events are forwarded to the core, then drawing commands are sent back like "draw object outline here, draw osc~ text here inside. etc."
So basically, the core has almost all of the GUI's logic while the GUI just does the chrome like scroll bars and windows. This means it could be trivial to port the GUI to other toolkits or frameworks as compared to rewriting an overly interconnected monolithic application (trust me, I know...).
Basically, if we take Jonathan's approach, I feel adding a GUI communication abstraction layer to libpd would allow for making custom GUIs much easier. You basically just have to respond to the drawing and windowing commands and forward the input events.
Ideally, then each fork could use the same Pd core internally and implement their own GUIs or platform specific versions such as a pure Cocoa macOS Pd. There is some other re-organization that would be needed in the C core, but we've already ported a number of improvements from extended and Pd-L2ork, so it is indeed possible.
Also note: the libpd C sources are now part of the pure-data repo as of a couple months ago...
Discouraging Initiative?!
But there's a big difference between "we know it's a problem but can't do much about it" vs "it's not a serious problem." The former may invite new developers to take some initiative. The latter discourages initiative. A healthy open source software community should really be careful about the latter.
IMO Pd is healthier now than it has been as long as I've know it (2006). We have so many updates and improvements over every release the last few years, with many contributions by people in this thread. Thank you! THAT is how we make the project sustainable and work toward finding solutions for deep issues and aesthetic issues and usage issues and all of that.
We've managed to integrate a great many changes from Pd-Extended into vanilla and open up/decentralize the externals and in a collaborative manner. For this I am also grateful when I install an external for a project.
At this point, I encourage more people to pitch in. If you work at a university or institution, consider sponsoring some student work on specific issues which volunteering developers could help supervise, organize a Pd conference or developer meetup (this are super useful!), or consider some sort of paid residency or focused project for artists using Pd. A good amount of my own work on Pd and libpd has been sponsored in many of these ways and has helped encourage me to continue.
This is likely to be more positive toward the community as a whole than banging back and forth on the list or the forum. Besides, I'd rather see cool projects made with Pd than keep talking about working on Pd.
That being said, I know everyone here wants to see the project continue and improve and it will. We are still largely opening up the development and figuring how to support/maintain it. As with any such project, this is an ongoing process.
Out
Ok, that was long and rambly and it's way past my bed time.
Good night all.
posted in technical issues
GEM / Catalina
Hello. I can't get GEM to work on MacOS Catalina (10.15.4). I installed using Help > Find Externals. Here're the errors I get. . . .
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/Gem.pd_darwin, 10): Library not loaded: libfreetype.6.dylib
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/stuff/lib/libftgl.2.dylib
Reason: image not found
GEM: Graphics Environment for Multimedia
GEM: ver: 0.94.git v0.94_pre1
GEM: compiled on Dec 21 2018
GEM: maintained by IOhannes m zmoelnig
GEM: Authors : Mark Danks (original version)
GEM: Chris Clepper
GEM: Cyrille Henry
GEM: IOhannes m zmoelnig
GEM: with help by Guenter Geiger, Daniel Heckenberg, James Tittle, Hans-Christoph Steiner, et al.
GEM: found a bug? miss a feature? please report it:
GEM: homepage https://gem.iem.at/
GEM: bug-tracker https://bugs.gem.iem.at/
GEM: mailing-list https://lists.puredata.info/listinfo/gem-dev/
GEM: binary/abstractions version mismatch!
GEM: continue at your own risk...
GEM: compiled for MMX/SSE2 architecture
GEM: using SSE2 optimization
GEM: detected 8 CPUs
GEM: image loading support: magick SGI imageIO jpeg tiff
GEM: image saving support: SGI imageIO jpeg magick tiff
/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin, 10): Symbol not found: __ZN9GemWindow3keyEiNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEii
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
Expected in: flat namespace
in /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin: dlopen(/Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin, 10): Symbol not found: __ZN9GemWindow3keyEiNSt3__112basic_stringIcNS0_11char_traitsIcEENS0_9allocatorIcEEEEii
Referenced from: /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
Expected in: flat namespace
in /Users/jbohn/Documents/Pd/externals/Gem/gemcocoawindow.pd_darwin
gemcocoawindow
... couldn't create
posted in technical issues
Building on Windows - works from Git source, not from tarball
I wanted to build PD on Windows 10 to get ASIO support. I failed when I used the "Source" files from the PD website. I succeeded when I used source that I cloned from Github. I followed the same instructions from the wiki both when I failed and when I succeeded. (They are the same as in the manual, just a little more concise.)
I am sharing below my terminal output from the failed build attempts from the downloaded source code (the tar.gz file). Some of these messages suggest that there might be errors in the makefiles. I don't know anything about makefiles, so I can't really interpret the errors. But I did want to pass them along, in case a developer might find them useful. Here you go:
bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ./autogen.sh
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'm4/config'.
libtoolize: linking file 'm4/config/config.guess'
libtoolize: linking file 'm4/config/config.sub'
libtoolize: linking file 'm4/config/install-sh'
libtoolize: linking file 'm4/config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4/generated'.
libtoolize: linking file 'm4/generated/libtool.m4'
libtoolize: linking file 'm4/generated/ltoptions.m4'
libtoolize: linking file 'm4/generated/ltsugar.m4'
libtoolize: linking file 'm4/generated/ltversion.m4'
libtoolize: linking file 'm4/generated/lt~obsolete.m4'
configure.ac:166: warning: The macro `AC_LIBTOOL_DLOPEN' is obsolete.
configure.ac:166: You should run autoupdate.
aclocal.m4:8488: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:166: the top level
configure.ac:166: warning: AC_LIBTOOL_DLOPEN: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:166: put the 'dlopen' option into LT_INIT's first parameter.
../autoconf-2.71/lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8488: AC_LIBTOOL_DLOPEN is expanded from...
configure.ac:166: the top level
configure.ac:167: warning: The macro `AC_LIBTOOL_WIN32_DLL' is obsolete.
configure.ac:167: You should run autoupdate.
aclocal.m4:8523: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:167: the top level
configure.ac:167: warning: AC_LIBTOOL_WIN32_DLL: Remove this warning and the call to _LT_SET_OPTION when you
configure.ac:167: put the 'win32-dll' option into LT_INIT's first parameter.
../autoconf-2.71/lib/autoconf/general.m4:2434: AC_DIAGNOSE is expanded from...
aclocal.m4:8523: AC_LIBTOOL_WIN32_DLL is expanded from...
configure.ac:167: the top level
configure.ac:168: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:168: You should run autoupdate.
aclocal.m4:121: AC_PROG_LIBTOOL is expanded from...
configure.ac:168: the top level
configure.ac:182: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:182: You should run autoupdate.
../autoconf-2.71/lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:182: the top level
configure.ac:213: warning: The macro `AC_TYPE_SIGNAL' is obsolete.
configure.ac:213: You should run autoupdate.
../autoconf-2.71/lib/autoconf/types.m4:776: AC_TYPE_SIGNAL is expanded from...
configure.ac:213: the top level
configure.ac:235: warning: The macro `AC_CHECK_LIBM' is obsolete.
configure.ac:235: You should run autoupdate.
aclocal.m4:3879: AC_CHECK_LIBM is expanded from...
configure.ac:235: the top level
configure.ac:276: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:276: You should run autoupdate.
../autoconf-2.71/lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
m4/universal.m4:14: PD_CHECK_UNIVERSAL is expanded from...
configure.ac:276: the top level
configure.ac:168: installing 'm4/config/compile'
configure.ac:9: installing 'm4/config/missing'
asio/Makefile.am: installing 'm4/config/depcomp'
bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ autoupdate
configure.ac:182: warning: The preprocessor macro `STDC_HEADERS' is obsolete.
Except in unusual embedded environments, you can safely include all
ISO C90 headers unconditionally.
configure.ac:213: warning: your code may safely assume C89 semantics that RETSIGTYPE is void.
Remove this warning and the `AC_CACHE_CHECK' when you adjust the code.
bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ^C
bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ ./configure
configure: loading site script /etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-w64-mingw32
checking host system type... x86_64-w64-mingw32
configure: iPhone SDK only available for arm-apple-darwin hosts, skipping tests
configure: Android SDK only available for arm-linux hosts, skipping tests
checking for as... as
checking for dlltool... dlltool
checking for objdump... objdump
checking how to print strings... printf
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /mingw64/bin/nm -B
checking the name lister (/mingw64/bin/nm -B) interface... BSD nm
checking whether ln -s works... no, using cp -pR
checking the maximum length of command line arguments... 8192
checking how to convert x86_64-w64-mingw32 file names to x86_64-w64-mingw32 format... func_convert_file_msys_to_w32
checking how to convert x86_64-w64-mingw32 file names to toolchain format... func_convert_file_msys_to_w32
checking for C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe option to reload object files... -r
checking for objdump... (cached) objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for dlltool... (cached) dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /mingw64/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for vfork.h... no
checking for dlfcn.h... no
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking for g++... g++
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe
checking if the linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT -DPIC
checking if g++ PIC flag -DDLL_EXPORT -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (C:/msys64/mingw64/x86_64-w64-mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether make sets $(MAKE)... (cached) yes
checking whether ln -s works... no, using cp -pR
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for windres... windres
checking for egrep... (cached) /usr/bin/grep -E
checking for fcntl.h... yes
checking for limits.h... yes
checking for malloc.h... yes
checking for netdb.h... no
checking for netinet/in.h... no
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for sys/ioctl.h... no
checking for sys/param.h... yes
checking for sys/socket.h... no
checking for sys/soundcard.h... no
checking for sys/time.h... yes
checking for sys/timeb.h... yes
checking for unistd.h... (cached) yes
checking for int16_t... yes
checking for int32_t... yes
checking for off_t... yes
checking for pid_t... yes
checking for size_t... yes
checking for working alloca.h... no
checking for alloca... yes
checking for error_at_line... no
checking for fork... no
checking for vfork... no
checking for GNU libc compatible malloc... (cached) yes
checking for GNU libc compatible realloc... (cached) yes
checking return type of signal handlers... void
checking for dup2... yes
checking for floor... yes
checking for getcwd... yes
checking for gethostbyname... no
checking for gettimeofday... yes
checking for memmove... yes
checking for memset... yes
checking for pow... yes
checking for regcomp... no
checking for select... no
checking for socket... no
checking for sqrt... yes
checking for strchr... yes
checking for strerror... yes
checking for strrchr... yes
checking for strstr... yes
checking for strtol... yes
checking for dlopen in -ldl... no
checking for cos in -lm... yes
checking for CoreAudio/CoreAudio.h... no
checking for pthread_create in -lpthread... yes
checking for msgfmt... yes
checking for sys/soundcard.h... (cached) no
checking for snd_pcm_info in -lasound... no
configure: Using included PortAudio
configure: Using included PortMidi
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating asio/Makefile
config.status: creating doc/Makefile
config.status: creating font/Makefile
config.status: creating mac/Makefile
config.status: creating man/Makefile
config.status: creating msw/Makefile
config.status: creating portaudio/Makefile
config.status: creating portmidi/Makefile
config.status: creating tcl/Makefile
config.status: creating tcl/pd-gui
config.status: creating po/Makefile
config.status: creating src/Makefile
config.status: creating extra/Makefile
config.status: creating extra/bob~/GNUmakefile
config.status: creating extra/bonk~/GNUmakefile
config.status: creating extra/choice/GNUmakefile
config.status: creating extra/fiddle~/GNUmakefile
config.status: creating extra/loop~/GNUmakefile
config.status: creating extra/lrshift~/GNUmakefile
config.status: creating extra/pd~/GNUmakefile
config.status: creating extra/pique/GNUmakefile
config.status: creating extra/sigmund~/GNUmakefile
config.status: creating extra/stdout/GNUmakefile
config.status: creating pd.pc
config.status: executing depfiles commands
config.status: executing libtool commands
configure:
pd 0.51.4 is now configured
Platform: MinGW
Debug build: no
Universal build: no
Localizations: yes
Source directory: .
Installation prefix: /mingw64
Compiler: gcc
CPPFLAGS:
CFLAGS: -g -O2 -ffast-math -funroll-loops -fomit-frame-pointer -O3
LDFLAGS:
INCLUDES:
LIBS: -lpthread
External extension: dll
External CFLAGS: -mms-bitfields
External LDFLAGS: -s -Wl,--enable-auto-import -no-undefined -lpd
fftw: no
wish(tcl/tk): wish85.exe
audio APIs: PortAudio ASIO MMIO
midi APIs: PortMidi
bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/c/Useras/bhage/Downloads/pd-0.51-4/m4/config/missing' aclocal-1.16 -I m4/generated -I m4
configure.ac:170: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro
configure.ac:170: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: autom4te failed with exit status: 1
make: *** [Makefile:451: aclocal.m4] Error 1
bhage@LAPTOP-F1TU0LRH MINGW64 /c/Users/bhage/Downloads/pd-0.51-4
$ make app
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh '/c/Users/bhage/Downloads/pd-0.51-4/m4/config/missing' aclocal-1.16 -I m4/generated -I m4
configure.ac:170: error: AC_REQUIRE(): cannot be used outside of an AC_DEFUN'd macro
configure.ac:170: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: autom4te failed with exit status: 1
make: *** [Makefile:451: aclocal.m4] Error 1
posted in technical issues
Pd FLOSS Manual, what to do with it?
@60hz said:
So what I see is that pd-vanilla and his minimal gui with computer scientists oriented documentation is not suited for newcomers and artist but purr-data is. So that should make sense that flossmanuals should have a documentation about it.
It makes sense and we're saying Purr Data can have its own Floss manuals, but what are you talking about, a new entry or turning the current Floss Manuals into a Purr Data Manual?
By the way, the point of updating this Floss manuals to Vanilla is to make its documentation and itself more suited for newcomers, the solution to the exact problem you're raising it won't change if we don't do anything about it and if efforts to change it are rejected.
Folks, when I started this thread, I made no mention to Purr Data. Purr Data is something else. I get the confusion, I get the relation, it's not out of purpose to bring this up here, but I want to make things clear.
See, we're talking about a Manual, a so called "Pure Data" manual, which actually mixed the notion of Pd itself and Pd Extended (now dead) and sits around still as a "Pure Data" manual. While Pd itself has also its 'official' manual. That's all very confusing already, right? The point is then to fix this, work on the Pure Data documentation itself (it's all in the original post). Purr Data relates to Pd and Extended but it's a whole different animal. It has different configurations, interface, features and whatnot. More over, it has quite strong incompatibilities that people don't seem to bring up. When you have a so called Pure Data manual talking now about 'Purr Data' actually, things get even more confusing, we're adding more noise.
What's also confusing is the mixed notion of a 'Software Manual' and a 'Tutorial'. These are supposed to be distinct things. And tutorials are free to focus on different things. Floss seems to be a tutorial on how to do some stuff in Pd, not a 'real software manual' at all. Floss also seems to be good to talk about some externals for Pd. Cool... we could update it then and keep it mostly the same. The changes would be minimal. We'd have a good section on how to manage externals in Pd Vanilla theses days. That'd be great, right? How to configure, etc...
If you're saying, "but hey, I think most of the tutorial examples would work on Purr Data, as they already ship the externals we're talking about, cause they were originally based in Extended", fine! Cool! Great, we can see if what we have in the end perfectly suits being just implemented, opened, and used in Purr Data as well. I'm not talking about the configuration part and things like that, just running the patches...
If it's all fine we can just say "hey, the things you see here are also suited if you want to run Purr Data"
How about it?
Note: On the other side, I prefer using pd-ceammc libraries which are organized AND replace all pd-extended and more, so the best would be having Purr Data + ceammc lib and the peace would come back on earth...
They do not, by far, replace "all pd-extended", nope, sorry, not a fact. Where's ceammc's GEM replacement for instance?
And what are you suggesting with "Purr Data + ceammc lib"? A Floss manuals for both?
And are you talking about the ceammc library that you can install directly from vanilla and use it as part of vanilla or the 'Pd-ceammc' fork of Pd, that comes with the ceammc library and some more stuff?
Well... everything I said about "hey what about Purr Data?" applies here. And the fact is that Pd-ceammc, unlike Purr Data, is not a "whole different animal", it's pretty much just another 'race' of Pd. It is 100% compatible to Pd-Vanilla (unlike Purr Data). the changes are minimal. You can, for example, run Deken and install externals in Pd-ceammc.
If you don't want to bother using something else than Vanilla, you can install the ceammc library in Vanilla and just use most of what ceammc offers anyway. It's all compatible.
So any Pure Data Manual, Floss manual, tutorial, will work great for Pd-ceammc. And if we consider the fact that a Manual for Purr is needed (not a tutorial, a 'manual', a 'software manual') since it's just too different. That doesn't hold for Pd-ceammc.
And yeah, when I say Purr Data is highly incompatible, you can't run any of the GUI objects from Pd-ceammc in Purr Data. You can't run other GUIs from other libraries.
In fact, Purr Data doesn't even have all of the GUI externals from extended ported and running. Also, Purr Data misses updates from cyclone. Purr is also not doing a great job keeping up to the latest vanilla changes and has some changes of their own to vanilla things. So, unlike Extended and Vanilla, it's really hard tying them with a knot. Unfortunately, at least to me, the community is divided. There are independent developments. And it's hard to manage this, hence the talk about creating a whole new FLOSS for them if needed.
If Purr Data were in fact a reincarnation of Extended, fine. But that's not quite it. And here's something people don't really seem to be aware is that the best shot to have an updated external library that runs all extended patches is going to be "Vanilla + install externals yourself"
And there's also the fact that there are more libraries than just the extended libraries out there, and you can also get them into Vanilla. Like ceammc, like timbreid, like soundhack, like ELSE, like many many others that are just missing, not compatible or hard to get into Purr.
So, there's a way to have both Pd-ceamm + Purr Data when it comes to the externals - get them all for vanilla!
Sure, you'll miss the interface differences from Purr and maybe I don't know what. But that's it, and it needs to be clear what the choice is, there's also a sacrifice in giving up Vanilla.
posted in tutorials
Fresh Pd 0.50.2 install comes with broken libs and deken installs broken libs
@ddw_music said:
One way that this could be improved:
- Pd could recommend externals be placed under a specific location. (Actually, here, you could follow SuperCollider's lead and have a system-wide location and a user-specific location.)
well, pd does now prompt/recommend a directory for installing externals (e.g. ~/Documents/Pd). It just so happens that the path isn't in the static paths. It was better when there were just 2 standard library locations: 1 for system-wide libraries and 1 for user-specific libraries (e.g. /Library/Pd and ~/Library/Pd on osx). This is still technically the case, they're just not the directories that pd prompts the user to install externals to. (though they are installed there by default) http://msp.ucsd.edu/Pd_documentation/x4.htm#s2.1
imo prompting the user to create ~/Documents/Pd and install externals there is a mistake
- Per patch file, keep a list of which locations have provided externals or abstractions.
the declare help file does say "WARNING: as of version 0.47, "declare -path" and "declare -stdpath" inside abstractions take effect only within those abstractions. If Pd's compatibility version is set to 0.46 or earlier the old (buggy) behavior takes effect."
perhaps this could be extended to libraries too
- If there is a binary library in the access path, load it automatically. Do not make the user distinguish between lib and path.
I agree that if someone specifies "-lib" it should work for multi-object, abstraction, and single-object libraries. However there should be cases for adding to a path without it being a library imo.
maybe the solution is a general "import" object for libraries like extended used to have, since [declare] seems to be designed to refer to specific binaries and paths without any further method of abstraction.
- If it's the first time this subdirectory provided an object to this patch file, print a message in the console (help the user not overlook the dependency).
I don't think this is a good idea. It would clog up the console. maybe there could be some kind of helper object or something in [pdcontrol] or [declare] that gets a list of all of the library or external dependencies of a patch when the user needs them. (or maybe some external would be better).
- Have a menu option to print a list of dependencies. (If the list of external subdirectories is saved in the patch, this is easy.)
The whole idea of using [declare] is to be able to understand a patch's dependencies just by opening it. Of course when people develop with libraries loaded into their startup path instead of using [declare] or [libraryname/objectname], that doesn't work. But if people actually used [import] or something instead this would be unnecessary
For me, the sticking points are that the search is non-recursive (this design decision, frankly, baffles me, I could not disagree with it more strongly) and that the user is expected to know which external packs provide a single-binary library.
I think it's good that libraries aren't searched recursively. This allows the maintainer/developer full control of loading resources, and doesn't waste time searching potentially large non-object resource directories in a library every time an object is loaded.
posted in technical issues
[declare] vs help browser
@ddw_music well I for one have never been on board with the whole ~/Documents/Pd/externals thing.. especially if it is not in staticpaths (also why would you install externals into Documents of all places??). I do think that ~/pd-externals is supposed to be different from ~/Documents/Pd/externals though (that was your main hangup I think). To me it makes sense that windows has appreciably different standard paths than linux.
This isn't so much an inconsistency between the gui prompt and the helpbrowser as it is an inconsistency between the gui prompt and the static paths themselves (which the helpbrowser then references when it populates its listboxes)
if it were up to me externals would still be installed in an "old" standard location by default - e.g. ~/Library/Pd on osx - and the gui wouldn't recommend anything different, maybe just tell the user what directory externals will be installed to and ask if they want to change it.
I assume you can navigate to the externals directory in the help browser in windows and Gem and Zexy show up there though..
just fyi you can safely delete your /home/dlm/pd-externals entry from the search paths as it is already in the static path. (then it won't show up in the helpbrowser anymore, which is redundant since the helpbrowser is populated with its contents anyhow)
on the other hand, I suppose one could use ~/Documents/Pd/externals as a way to disclude items from the root helpbrowser listbox. 
posted in technical issues
[declare] vs help browser
As a further test -- I hacked ./tcl/helpbrowser.tcl to print to stdout some progress messages while building the help browser directory list. (Doing this in Linux -- I haven't set up the Windows machine to build Pd from source.)
To my surprise, I found that the Externals Install Directory is part of $::sys_staticpath (in Linux).
Each entry in $::sys_staticpath is globbed for any subdirectories -- so this is how it's finding Gem, cyclone, zexy etc.
staticpath add search /home/dlm/pd-externals/Gem
staticpath add search /home/dlm/pd-externals/freeverb~
staticpath add search /home/dlm/pd-externals/zexy
... etc.
A little bit later, it checks $::sys_searchpath -- this comes from preferences. These entries are not globbed for subdirectories.
searchpath add search /home/dlm/pd-externals
(Above is the only entry coming from Preferences > Path.)
So one possible difference is that the "static path" includes my external location in Linux (that isn't speculation -- the stdout listing proves it), while it probably doesn't in Windows.
OK, then, let's grep staticpath... this leads to s_path.c, which says (in an ifdef for Linux):
sys_expandpath("~/pd-externals", pathbuf, MAXPDSTRING);
STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, pathbuf, 0);
So user-home/pd-externals is a special, hardcoded location for Linux, which I happen to be using for my externals.
Looking a bit further down, hardcoded locations in Windows are AppData/Pd and something about common-program-files/Pd -- but the Pd GUI recommends Documents/Pd/externals as the installation directory. (And Mac will have a similar problem, because the hardcoded locations include ~/Library/Pd but again not Documents/Pd/externals.)
I'm satisfied that this explains the difference in behavior between the two environments. But it leaves a bit of an impression that this hasn't been completely thought through. If there are magic locations for help browser search, ideally this would be coordinated with recommended installation directories, but they aren't.
hjh
posted in technical issues
Help with installing external, Gem addon: pix_motion_sector
Hi,
I can not get this to work, I am still trying to get comfortable with externals. Thankful for help, sorry for my ignorance. :/
pix_motion_sector (scroll down)
link text
README:
"Throw the pix_motion_sector folder in Pd's Contents/Resources/extra directory. The provided macintosh binary should work as-is. To build, cd to the pix_motion_sector directory and type "make". "
I put it first in Contents/Resources/extra and did build.
Something about installing xcode, I though I had it so I just went along.
Could not create [pix_motion_sector] in pd.
Tried to move the folder to my other externals user...documents/pd/externals. No luck.
Tried to remove and all files and rebuild.
Terminal:
make: Nothing to be done for `all'
Dowloaded Command_Line_Tools_for_Xcode_11.3.1 (I am on Mojave).
Pd says:
/Users/Nicklas/Documents/Pd/externals/pix_motion_sector/pix_motion_sector.pd_darwin: dlopen(/Users/Nicklas/Documents/Pd/externals/pix_motion_sector/pix_motion_sector.pd_darwin, 10): Symbol not found: __ZN7GemBase10isRunnableEv
Referenced from: /Users/Nicklas/Documents/Pd/externals/pix_motion_sector/pix_motion_sector.pd_darwin
Expected in: dynamic lookup
pix_motion_sector
... couldn't create
posted in technical issues