updated to 0.51-3 https://github.com/sebshader/pdnext/releases/tag/0.51-3
used updated (fixed) tk with no-scrollbar and disabled-help-menu-items fixes on osx, in addition to the font and permissions fixes from pd 0.51-3 (and the new expr functions)
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
[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
[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.
@oid well abstractions are good for understanding the language and often good for quick development. However, c externals are almost always far more efficient/fast if the same general algorithm is used. Just for the simplest example, getting a "float" in pd requires a few function calls: sending a "bang" message to an object that calls its outlet function, which finds the connection and calls the "bang" method for float which then calls the outlet function after accessing the data itself (the actual float value). in c all that would be is 1 memory lookup, and would require the memory of just 1 float instead of an entire pd object. And that isn't even counting all of the extra space and processing it takes to manage the object and class.
You can do a lot in vanilla but there are definitely things that are way easier to do even in c. A good example is any list processing, or any searching or sorting algorithm, or any manipulations of more complex data structures.
Personally I like to use pd for signal-graphs and some message glue, with lua doing the structure and sequencing (with pdlua) and c doing the complex low-level or data structure stuff.
you should be able to make almost anything in vanilla, but for practical use it makes more sense to use compiled externals where possible. I wouldn't necessarily call the gains "purely academic" anyways.
of course you also have to consider how many dependencies you want your patches to rely on..
@jameslo I didn't actually go through the code but just in the simple tests I did if you create the entirety of the graph with the
[receive~]) before the graph with the
[send~]) then it appears to be in the right sort-order.
however when I deleted the
[receive~]afterwards I couldn't get it back in the right order when I recreated them no matter the order.. maybe something to do with
[send~]being at the bottom of a graph and
[receive~]being at the top of one or something.
might have a look through the source later and try to figure it out for real.
I would think that this is dependent on the implementation and not guaranteed to stay the same if the implementation changes significantly tho..
[send~]graphs would be sorted before their corresponding
@jameslo i haven't tested it but it might be the case that if you make sure to create
[send~]that there will be no latency, (unless the
[receive~]is in part of the graph that leads to
[send~]). You might have to create the entire graph the
[recieve~]is part of after creating the entire graph the
[send~]is part of, I'm not sure..
edit: after testing I was not able to get that to work
edit2: after further testing it seems like if I create the graph with the
[receive~]first it gets sorted last, but not if I delete the
[receive~]and recreate it afterwards
so there isn't always latency, it depends on how the dsp graph is sorted. If the
[recieve~]is sorted earlier in the graph before the
[send~], as in the case of feedback, then there will be a block delay since
[recieve~]will process the shared buffer's samples before
[send~]has had a chance to write to the shared buffer. (so
[recieve~]will only get the samples written in the current block by
[send~]in the next block, creating a block delay.)