[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.
[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
How to compile/install externals in vanilla Pd?
@4zz4 here is a video that explain how to use the externals folder:
there you also have to put your compiled externals.
You can download most of the externals from Deken.
But if you want to compile them by yourself: In my own experience it is easier with Linux than with Windows. Mostly you have a makefile for Linux and a .sln file for Windows/Visual Studio.
It is different from external to external, most of the time there is helpful information in the readme/install file of the external.
If you have problems with compiling a certain library it would be good to know which library and where (which error), then it is easier to help.
How to compile/install externals in vanilla Pd?
I know Pd wants me to use viual studio (i'm on windows, i will switch to linux when i havue time for it) to compile externals. It also wants me to use a shell, but idk how to do that. i opened a powershell window in the external that i wanted to compile, but when i entered in "nmake" and "pd_nt" there nothing happended. The external was downloaded on SourceForge and i unzipped it twice to get out the contents.
Can somebody explain how to compile an external as much as practically possible?
Also, where should i put my externals? is it in "lib", "extra", something else or should i make a new folder for externals? I currently made a new folder to externals called "externals" because i saw a youtuber having a folder named that for his externals.
External Loading Problem – "Image not found"
Hi all,
I downloaded FFTease from Git (https://github.com/umlaeute/pd-fftease) placed it my externals folder.
However, when I try to load any of the objects. I the following error:
/Users/myname/Documents/Pd/externals/fftease32-externals/burrow~.pd_darwin: dlopen(/Users/myname/Documents/Pd/externals/fftease32-externals/burrow~.pd_darwin, 10): Library not loaded: @loader_path/libfftease.dylib
Referenced from: /Users/myname/Documents/Pd/externals/fftease32-externals/burrow~.pd_darwin
Reason: image not found
burrow~
Has anyone got any ideas what the problem would be? I've been searching for about an hour now. I tried updating x11 to see if that was the problem (it wasn't), based on other forum posts with similar errors. I've also tried forcing PureData to run in 32 bit to see if that would work.
Pd seems to be able to navigate to the right subfolder in my externals directory but none of the objects (in this instance [burrow~]) seem to load.
Any suggestions would be appreciated.
... couldn't create
Purr Data 2.10.0 released
Purr Data 2.10.0 is now available:
https://github.com/jonwwilkes/purr-data/releases/tag/2.10.0
Changes:
- iem_spec2/spec2_tabreceive_enable~: fix array error handler and set sane default array name value
- fix partconv crashers in bsaylor lib and add perfroutine for array errors
- adaptive/nlms3~: fix typo that caused a double free
- fix lyonpotpourri crashers in dsp, perform and constructor routines
- at least keep the inoperable streamout13~ and streamin13~ from crashing when instantiating
- use some sane default values in ekext/lpreson~ to prevent segfault
- quick fixes to keep cxc/mean~ from crashing when dsp is turned on
- greatly reduce undefined behavior in all dsp objects
- fix hex2dec so that it actually does something useful
- fix #523: crash with manual width adjustment on subpatch
- add ability to change makefile flags for Gem from toplevel makefile
- fix stray bugs detected by obs
- unauthorized/cooled~: increase string buffer size to accommodate the terminating nul character
- unauthorized/cooled~: fix memory access bug trying to concatenate into a string constant
- iemmatrix/mtx_dispersive_dline: add missing void return type
- allow make options like -j8 to be passed to the Gem compilation, which takes awfully long on a single cpu.
- cxc/cxc_split: fix use of un-initialized pointer
- ggee/serial_bird: fix undefined behavior with the ++ operator
- ext13/scramble~: fix header for scramble~
- jasch_lib/detox/detox: reformat for sanity's sake, fix array overflow, undefined behavior
- linux desktop: remove the -rt -audiobuf options from the desktop files.
- linux desktop: change DEFAULTADVANCE to 20 ms for Linux.
- linux desktop: remove leftover TargetEnvironment=Unity lines in menu entries for Purr Data
- linux desktop: add some comments and a few more useful desktop action examples to the main desktop file, so that the user understands how to adjust these if needed.
- linux desktop: replace pd-gui -> nw in the ForceQuit actions, which is the proper name of the GUI program on Linux
- linux desktop: remove useless %U arguments from desktop actions.
- linux desktop: invoke desktop actions via /bin/sh.
- linux desktop: migrate the desktop actions from the ancient Unity syntax to the current freedesktop.org standard
- linux desktop: remove sticky options from the desktop files. For now, keep -rt -audiobuf 20.
- Gem: sync with https://github.com/umlaeute/Gem, QT4L and startup issues have been fixed
- linux: fix the Debian control files once again, since the dependency auto-detection needs a Depends line in there.
- debuild: Support for ARM (e.g., Raspbian)
- update nw-update to nw.js 0.24.4 to fix font issues under Linux
- backport 'add-to-path' from vanilla rev. c917dd19, to make Gem happy.
- usability improvements in the documentation browser.
- switch Gem to the latest from upstream.
- add missing dlls for fluid~ on Windows. Fixes #540.
- Debian packaging: Demote python and fluid-soundfont dependencies, as suggested in #540.
- polish the externals/Makefile clean targets, and delete redundant files in repo
- fix compile options for Xcode 10 - fftease and lyonpotpourri externals.
- update pd-lua to latest upstream.
- fix compile options for Xcode 10 - externals and abstractions.
- fix compile options for Xcode 10.
- ios header needs to be included before base64.h, to avoid compile errors on macOS 10.14.
- fix improper string access in pd_getdirname on Mac.
- fix list cat crasher, update help patch, add missing test abstractions
- get rid of obsolete and unneeded unicap and sndobj dependencies on Linux.
- mark some globals as extern to fix compilation if g_canvas.h is included more than once
Please report bugs here:
The miniwoog
@whale-av Tried to copy all the externals from ye 'olde source code from Pd-extended to my own installation dir of Pd. That got rid of some errors. But some errors about " | " stayed. That's strange because that's a Vanilla logical operator.
Then I tried to compile ye 'olde source code from Pd-extended from source code. Got some error about pthread_create@@GLIBC
Maybe because pthread does not work anymore in modern C compilers? The current source code compiled without problems on my PC.
Anyway, I was about to give up and then I tried to install an old Linux Mint package (i.e. pre-compiled software). This luckily installed just fine. And guess what? The Moog patch works excellent.
There is a downside to all this, however. It's a shame that de kind developers of Pd make a version that does not work w/ our beloved patches anymore. Not even when you use the 'Find Externals' utility. And not even when you copy all the old Pd-extended externals to your current externals directory. A shame that ll that work on great patches from a few years ago go to waste.
Does anybody know how to compile the old Pd-extended on a mdern Linux system?
Now for that Pd-extended on a Raspberry Pi....
possible deken bug + general question on dependencies
@oystersauce You are looking for freeverb~ ...... which has been compiled for 64-bit windows and is available on Deken.
I am pretty certain that your recent posts are all about the same problem.
If nobody has recompiled an external for 64-bit for the OS that you are running (and added a link to Deken) then Deken will not find it.
Some externals might have been compiled but not added, some have not been compiled, and maybe some cannot be compiled.
You might find repositories for the C code on github that will allow you to compile for your system.
Please share them afterwards as it will help others with the same problem.
64-bit Vanilla is starting to have some useful tools, but if you don't need them or the higher precision of 64-bit then Extended or Deken for 32-bit Vanilla are still a better bet at the moment.
Of course on a 64-bit OSX that is not an option.
If you are willing to try a fork like Purr Data then the developers are often more active and willing to help rebuild old (or even new) externals for their version.
A lot of people have been looking for [knob] and @yoichi_tbbb recently made a great one here........ https://forum.pdpatchrepo.info/topic/10938/new-knob-gui-object which I am surprised no-one has compiled for 64-bit.
David.
possible deken bug + general question on dependencies
Hi,
not sure if this is a bug. Don't wanna noobishly spam to the devs' bug reports pile but this needs to be clarified. Is it a deken issue or on the repository or what?
Some searches for externals in the 64-bit version of PD vanilla for windows (I'm on windows 10) the deken search (in the menu: Help -> Find externals) don't return results while the same externals (in some cases) can found on the 32-bit version. Some externals are neither found in the 32- nor 64-bit version. Additionally - as a marker that something is wrong here - PD does not output the line
[deken]: No matching externals found. Try using the full name e.g. 'freeverb'.
which is the case for truly non-existing names (like searching "sdfsdfsdf").
Example of external found as expected on 32- and 64-version:
cyclone
Example of external found as expected on 32- but NOT on 64-bit version:
moonlib
Example of external found neither on 32- or 64-bit version:
apple
What I'm most eager to find out is whether, say, the moonlib external is just not compiled for 64-bit windows and therefore is not found or whether it should be found and just isn't (which hints more towards a bug).
Does anyone have an idea? I'm not completely new to PD but not up to date at all with its development. It seems the current version 0.49 vanilla is the first to have a 64-bit windows version.
kind regards
It's been a long time
@joesh Hi, the object names are always the same but perhaps you used to use Pd extended back in the days and now that you have installed Pd "vanilla" you are missing some externals, which came pre-installed in Pd extended.
In Pd 0.48-1 you can install external libraries quite easily. First you have to find out which externals you need, and for that you can search google for the names of the objects that don't load. Those in the screenshot you have posted are from cyclone. Then you go to Pd > help menu > find externals and type the name of the external, for example cyclone. Then you click on the correct version for your operating system, and when prompted you have to click "no" and chose a path of your preference where to install the external. Then click yes when prompted again.
This should do it, under "find externals" you'll find most of the most used externals, but just in case you need something that is not there you can download the external manually, put it in the path you have specified earlier and then add that path in Pd > preferences > Path..