Is there any reason pd lacks a standard library of commonly used abstractions? I did a search of both the mailing list and forum and it seems the idea has never even been brought up. It would make patches easier to share and understand since everything in the library could have a help file and be common in the community, reduce the number of abstractions/subpatches one needs to open and figure out to understand a patch, reduce the number of abstractions needed to be shared with a patch, and most importantly make getting started with pd easier since it would remove some of the drudgery. Is this just something no one has ever bothered to do? Everyone that sticks with pd likely has a counter abstraction, why not just standardize it finally?

If there is interest and people are willing to contribute abstractions, ideas, recommendations, I am willing to put in the time on packaging, giving everything a uniform format, help files, etc, even some abstractions, but would need the community to actually accomplish this.

@oid There are several libraries that could be considered basic, like cyclone or list-abs. There is also else by @porres that tries to provide a comprehensive collection of common abstractions.

The reason that no library is standard is the open modular approach, the vanilla ideology and the philosophy of the core developers that they only include in the main distribution what they are willing to maintain.

There has been an approach to make a comprehensive distribution that contained many basic libraries for most use cases. This was Pd extended. With the result that this distribution is abandoned since a long time. Purr data is another approach, but it didn't really catch on within the community.

@ingox By standard library i do not mean the all inclusive pd-extended approach, i mean standard in the sense which every other programming language uses the phrase, a library of functions which are so commonly used that everyone should have and know them. This does not go against the vanilla ideology, just builds on it, and would be vanilla by deffinition, a standard library does not build upon other libraries. Porres, like extended go far beyond what a standard library does, list-abs is closer, but more specialized than a standard library.

@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.

@seb-harmonik-ar all of those basic bread and butter things like various counters, adders, dividers, missing array functions like insert, some of the list-abs stuff updated to take advantage of [list store], anything commonly used. It will make things simpler to read and troubleshoot, especially when dealing with other people patches. That really is a big part of the whole purpose, we see the [declare] for stdlib and we know what is inside all those abstractions instantly, know they work and they reduce what needs to be read so that massive patch that someone needs help on is not as massive and less time needed to dive into subpatches and abstractions.

@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.)

@seb-harmonik.ar Nothing is wrong with that. I am only suggesting to extend what there is to offer the community, not replace it. There are many objects which do not really benefit from being an external and will likely never become a vanilla object, like a counter. A counter can be simple, but there are many ways to count, by one, by two, exponentially, backwards, by scale degree and on and on, these are the exact sorts of objects a standard library is perfect for. A few basic counters can be included and cover 90% of use cases and a good chunk of the remainder just need to copy the abstraction and make a minor change like adding an outlet. While externals and the interpreter are all about speed and efficiency in execution, a standard library (really any proper library made from a language extending itself through its own faculties) is all about speed and efficiency in coding, trouble shooting and reading.

While I could just do it myself, it would not result in a well rounded standard library, it would just be a library for dealing with hardware synths since that is almost everything I do with pd. Most standard libraries are evolved by the community, even when the language specs the standard lib, real world use and the needs of the community ultimately dictate what is in there, the spec is just a starting point or guideline. For this to work it needs to be more than one person, people need to dig into the abstraction folders and find some potential candidates and offer improvements/ideas on abstractions, I can't do it all myself.

So far it does not look like there is community support for such a project, but who knows, only been 12 hours so far.

Edit: Fixed 4AM syntax and sentence structure.

Probably one reason why this type of project is hard to start is "scope creep" -- you start with a counter and a couple of list ops, and then somebody wants more list ops, and string conversions, and... that's how you end up with a pile of bloat that's hard to maintain (the pd-extended problem that's been alluded to).

While I understand the reasons for the minimal-core philosophy, it does have an impact on the end user. If I want a bandlimited sawtooth in SuperCollider, I write Saw.ar(frequency). In pd, I need to find the mmb abstractions, or create my own oversampling oscillator abstraction. I often wonder what is the middle ground between the kitchen-sink unmaintainable pd-extended and the ultra-minimal pd vanilla. (It's not my business to say how pd should be maintained. But I think it is fair to mention the user's perspective, that there are a lot fewer obstacles to getting off the ground when the set of core operations is richer. It also matters because boxes and wires can be more cumbersome than text -- a counter could be i = i + 1 or it could be a float box into a [t f f] where one branch goes [+ 1] and into the float's cold inlet and the other branch is your result. The time spent building these little structures is time not spent making music.)

hjh

@ddw_music I don't really see scope creep being an issue, but that is mostly because I am fairly skeptical that there will be enough support to even get a viable library together let alone one that is bloated and even if it did get fairly large, maintenance is not nearly as much of an issue with abstractions as it is with externals, worst case is they end up like list=abs, perfectly functional but outdated and inefficient by current standards. Either way, I am not going to worry too much about that until it becomes at least a vaguely dim possibility, the whole project is somewhat self limiting by way of my freetime and the community, I have no expectations of anyone else contributing beyond sharing abstractions, if I get it great, but I expect it will be mainly me going through them to give them a consistent style, commenting code, and writing help files and I really can't see bloat as likely. Ideally someone will step up and deal with the audio abstractions, I do not do much audio in pd and others can probably do it better, but I can muddle through for the cause if I must.

I agree that pd could have basic abstractions in order to make it more easy like random list etc...

The CEAMMC lib is certainly one of the best exemple of what a good standard lib could be (many basic object with good naming convention etc). But the functions are growing a bit too much and the complexity added by the extending pd with new data types are maybe the limit of such project.

Everyone that sticks with pd likely has a counter abstraction, why not just standardize it finally?

If you want to create an abstraction-based library of utility objects which you think are common to a large number of use cases, you should do it. I believe there are at least a handful of such abstraction-based utility libraries in Pd-extended, but they probably include a different set of abstractions than what you want. If you use a consistent interface for everything and include full documentation in the help-patches, your library will probably be a welcome addition to the available externals. I'd be willing to include such a library in Purr Data for example.

If you want your library to somehow have precedence over other libraries-- e.g., shipping with Pd Vanilla-- I'd suggest to first gauge interest in your idea on the pd dev mailing list.

@jancsika "If you want your library to somehow have precedence over other libraries-- e.g., shipping with Pd Vanilla-- I'd suggest to first gauge interest in your idea on the pd dev mailing list."

Do you believe they would be receptive to this idea? Or, "thanks but no thanks"?

It might not be necessary to ship the library with vanilla -- it would have helped me if the "new user" documentation had listed a few external packs with common features. IMO at least cyclone is indispensable, and I tell students to install pddp for [ezoutput~].

hjh

Do you believe they would be receptive to this idea?

Depends on how the precedence is actually implemented.

Where is this "new user documentation?"

In Purr Data we load these libraries by default and have improved the search functionality recently. So it's less of an issue.

@jancsika Where is this "new user documentation?"

I don't know -- I was hoping someone here would.

What I mean is: If we agree that using Pd without cyclone and zexy is tying one hand behind your back... someone downloads Pd, never used it before. How do they find out that they should install cyclone and zexy?

hjh

@jancsika I am not too concerned about it being accepted as THE standard library or anything, just using that as a guideline as to what should and should not being included. If I do go ahead with this I intend to get input from the dev-list, if nothing else they likely will be able to offer some valuable advice regarding the sorts of things which should and should not be included, or perhaps they will point out the reason such a thing does not exist for pd.

@ddw_music said:

What I mean is: If we agree that using Pd without cyclone and zexy is tying one hand behind your back... someone downloads Pd, never used it before. How do they find out that they should install cyclone and zexy?

That's part of the reason we have default startup paths in Purr Data for all the libraries that were shipped with Pd-extended. The other reason is that this means that any patches that were developed during the Pd-extended days will work by default in Purr Data.

This means there are probably object names taken by some of these libraries that you'd rather have for yourself. On the other hand if you don't load or ship anything as a default then you end up with this discoverability problem you describe.