@MarcoDonnarumma I agree, single-binary external libraries should have
[declare -lib libraryname]in their helpfiles. I would think Iohannes probably assumed people would just load the library through some other method before opening help files, or maybe he just didn't think about it or have the time.
as @ingox said, having zexy in your path is not enough because you have to load the library from a single binary. Therefore you must also put it in the startup list: "Pd libraries to load on startup", or start pd with the flag "-lib zexy"
it should be noted that this info is in the documentation http://msp.ucsd.edu/Pd_documentation/x4.htm#s3.1.2
@MarcoDonnarumma Zexy from deken on my arch linux system includes a zexy.pd_linux file, which is definitely 64-bit (and loads fine). I'm pretty sure this is the file that zexy loads from on linux. Note that zexy and iemlib are now single-object libraries (you need to either load it as a library/set the path to them from the preferences, or use
[declare -lib zexy -path zexy]in a patch.)
I think I just got this on MacOS 10.14.6 on 0.51-2, I did notice a .diag file in the Console in System Reports from pd: (not sure if it's related)
Event: wakeups Action taken: none Wakeups: 45001 wakeups over the last 82 seconds (548 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds Wakeups limit: 45000 Limit duration: 300s Wakeups caused: 45001 Duration: 18.10s Steps: 4
Heaviest stack for the target process: 3 usleep + 53 (libsystem_c.dylib + 501768) [0x7fff76eef808] 2 __semwait_signal + 10 (libsystem_kernel.dylib + 20270) [0x7fff76f63f2e]
3 usleep + 53 (libsystem_c.dylib + 501768) [0x7fff76eef808] 2 __semwait_signal + 10 (libsystem_kernel.dylib + 20270) [0x7fff76f63f2e] 2 <Kernel mode> 1 nanosleep + 29 (libsystem_c.dylib + 501866) [0x7fff76eef86a] 1 pthread_mutex_lock + 42 (libsystem_pthread.dylib + 4449) [0x7fff7701d161]
might be time for a bug report.. gonna try to reproduce/narrow it down somehow..
@svanya I would not do it that way personally, as like @ingox says when someone wants to open your patch to see how it works they will have to mentally substitute "$1", "$2" etc. for the objects, and have to remember what each one is as they look at your patch if they want to understand it.
what this IS useful for imo is if you have a bunch of objects with exactly the same interface and want to use arguments to choose which ones your abstraction will use. for instance, all relational objects have the same interface. Therefore I made an abstraction to pass numbers to the left outlet if they met a certain condition and the right outlet if not by using "$1" inside to be able to choose what relational object to use for the test:
then when you use the object you can use e.g.
[passif == 5]to pass the numbers out of the left outlet if they are equal to 5/the right inlet, and out the right outlet if not equal, or
[passif < 5]to pass out the left outlet if the numbers are less than 5/the right inlet, and out the right outlet if not less.
this could also be useful in a sorting algorithm in order to choose how to sort elements
another example might be if you had multiple objects that interpolate values, all with the same interface but with different interpolation methods. then you could do something like
[myabs~ linear]to select linear interpolation, and
[myabs~ cubic]to select cubic interpolation.
@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.
@ddw_music what do you mean by "Pd/externals" on windows? what is the full path?
Do you mean the new directory that pd prompts the user for when deken is run? Are you sure that you didn't add this path to the search paths when prompted in both Windows and Linux? Because from your description it seems most likely that it was added to the paths on Linux but not Windows. (You can check the "paths" in preferences to see)
The helpbrowser displays everything in the static paths (of which this directory is not a part) and also the user paths (of which it is a part if the user agrees when deken prompts for it)
pd is composed of a gui process (which is a tcl/tk "wish" shell) and the "core" process that does all of the message/dsp processing (and some gui handling logic). The main "app" process is the gui/"wish" one so sometimes when that unexpectedly quits it leaves the "headless" process running.
I don't know why the gui is freezing, but that is why there are phantom pd processes. (Probably safest to force quit them all before attemting to restart pd)
If you look at your logs, are there any crash reports or anything?
(in the "User Reports")
also, are you using or loading any externals when this happens?
@oid that's somewhat fair. Many external libraries have kind of taken the place of "bare-bones" functionality like that though (mainly zexy and iemlib). I guess I just don't see what's wrong with that. Taken in their totality, most libraries used from the extended era don't overlap in functionality, and taken together they are somewhat similar to a "standard library". Since then many libraries have come about to fill in the gaps.
Basically, many libraries have things in it that could be considered "essential" in some regard, and there isn't that much overlap.
Of course, you could grab collections of objects and curate a group that you consider essential. But I'm not sure how much people would use that over whatever library it was pulled from.
when people make external libraries it's generally because those things are needed and doesn't exist in pd vanilla (which is designed to be almost as minimal as possible). So in some ways every external library is essential.
If there are bare-bones things I think those could just be added to vanilla (more list objects, maybe a counter, etc.)
@oid I mean, that's basically what the core objects in pd are.. They aren't abstractions because c is faster. (though there are a few like the reverbs and hilbert~/complex-mod~.)
What kind of functionality would go into a standard library that isn't in pd vanilla?
having said that, it is the case that most bigger external libraries are generally organized by authorship rather than function.