To start: Welcome back to using Pure Data. We as a community can help you make a transition if you are willing to work with our (still) ongoing transition from Pd-extended.
> On Dec 4, 2019, at 9:54 AM, [email protected] wrote: > > I was getting ahead of myself. Plus, my expectations were w-a-y too > high. They are not. > I expected to be able to install the whole thing, a current and > desirable version of pure data with everything I'd need. In general, you can, using deken, as most major libraries that used to be distributed with extended have new maintainers who continue development. As the last version of Pd-extended has libraries built for 32 and 64 bit on macOS and those (now old) versions were uploaded to deken, you can at the very least get those older versions. Admittedly, we probably need a more accessible overview of how to use it as well as a transition guide from Pd-extended and I think *this* is the crux of your issues. One of these is probably related to the difficultly of figuring out *which objects* belong to *which libraries* in patches made in extended. I feel your pain there as I had to go through this while migrating my own projects. > Now that I know that is not, and will never be the case, I'll be pleased > to sift thru those links from 2011 to find the good stuff. I would say this is not true and you seem to conflate your frustration with a *delibrate* attempt to make your life harder. Some backstory: Pd-extended was a successful community-driven "batteries included" version of Pure Data "vanilla" which was bundled with a large number of community-contributed libraries. That was a great thing. On the other hand, Pd-extended was heavily dependent upon the work of 1-2 people who's free time went into trying to maintain and manually merge changes from vanilla Pd. That was a bad thing and when those people had larger life issues to deal with, they could no longer maintain development. This was around 2011-2012. We as a community then asked: Who can take up work on Pd-extended? No one answered. There was a great amount of wailing and gnashing of teeth, but no one answered. In the meantime, some community members developed a simple proof-of-concept package manager for external libraries, either pre-compiled or abstraction-only. The idea behind this was to modularize external development and take away the need for a large, central development version like Pd-extended and it's maintenance overhead. This also allowed the community to focus on bringing improvements to Pd "vanilla" directly. This package manager was informally named "deken" aka Help->Find externals. Since then, we as a community have been figuring out how to handle this whole transition, from increasing community-contributed development to the Pd "vanilla" source code, to collaborative external library development and distribution. The basic idea revolves around: Pd itself comes with the core objects and "core externals" ie. [bonk~], [sigmund~], [bob~], etc. Anything else should be installed either via deken or manually to a folder. You then need to either add that folder to your general Pd path or, better yet, tell Pd about the path or name of the library using the [declare] object. After that, Pd will try to find and load it. Wither newer versions of Pd, you can create a "Pd Documents doctors" in your home documents folder which also creates a default "externals" subdirectory which is where deken will install external libraries by default and this directory is already added to your search path. This allows a simple process for most libraries: find externals, click to download, open patch, create [declare -path some lib], create object from somelib. There are currently caveats for some libs (Gem for instance), but that;'s the basic idea. One pain point is that Pd-extended did all of this automatically, however this made it hard to tell where objects came from and also lead to name clashes where the object from one library shadows that of another. With this new approach, you need to be more explicit as to which libraries you want to use, much akin to a Python import command or include in other languages. The downside, naturally, is that you need to be congnizant of which libraries you were using previously. When I was porting my old projects from Pd-extended, I basically opened the patch and made a list of objects that could not be created. Next, I did a search in the extra folder to find the helpfuls for these objects. Since the helpful would within the library subfolder, I could find the name of the library. After that, you should be able to install the library via deken, then add a [declare] to your main or abstraction patches which need to load the library. Some libraries need only to declare the path while others also need a "-lib" flag if they are pre-compiled in specific way. This is definitely confusing right now and we are working on some ways to make it work more smoothly. > I'm surprised no one has assembled a package of all the things you'd > need, libraries, GEM, everything in one single .zip file. I'd argue we do have that, although it's decentralized as outlined previously. > And instrux on what to do. Exactly. We clearly need improvement here. > The user base is very broad, with thousands of people approaching it for > different reasons, and my tiny niche application is tough to track down. It's not a niche problem, we have been dealing with it for a few years now and it could be communicated better. > Or I haven't dived deep enough to find it. No, you probably have, otherwise you would have found it. This is a very important point to make and clearly needs work. -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
