On 10/6/21 4:46 PM, Alexandre Torres Porres wrote:
Now, correct me if I'm wrong, but as I see it, Pd-Extended started as a "distro", then it evolved to a proper fork with parallel/independent development.
not really. Pd-extended was *always* closely related to the development of Pd-vanilla, adding some patches on top of it. hans was eager to bring back improvements to the vanilla development, but with some things it was obvious that miller won't accept them.
this is different from e.g. PurrData, which is basically its own thing by now, and there's little exchange between the two projects (i think jonathan pulls the latest and greatest features of Pd-vanilla into PurrData whenever there's demand. and Pd's undo-system was a backport of ico's system for Pd-l2ork; but i think that is as far as it goes).
Some of the changes were listed here and I assume the first ones were in favor of better managing the build system
i don't recall Pd-extended changing anything of the build system with regard to the core. hans did provide a build system for externals to ease building of the entire affair in a single run, but that was equally usable for people who did not embrace Pd-extended (neither as a "fork" nor as a "distro").
and library loading.
i don't recall any changes with regard to libraries. Pd-extended had [import], but that was just an external that was automatically loaded at start up (or at least, it could have been an external. in Debian there's still a "puredata-import" package that provides this very object.)
Other changes were necessary so loading externals like [initbang] were possible (IOhannes, if you never used Pd Extended, how were you using [initbang] back in the day?)
for the projects that needed it, i maintained my own "fork" of Pd.
As I see it, the only actual incompatibility that I know is that in the last version of Extended we have the "$@" syntax. I don't know the story there, but it seems it started in the Vanilla development but never made into it?
like all the things in Pd-extended: somebody implemented a feature for Pd-vanilla, and if it didn't make it (but was considered interesting enough) it went into Pd-extended.
as such, Pd-extended was (also) a testbed for Pd-vanilla development, with the idea to field test some feature and see how actually useful they are.
Anyway, other than that and generally speaking, Pd Extended was kinda of a "minor" fork. Another similar example of such a "minor fork" is Pd Ceammc. It has similar characteristics like offering a different UI and providing pre installed libraries and objects (most of which can be loaded in Vanilla).
afaict, the same is true of PurrData, which i would consider the most prominent/important fork of Pd (that is still very close to the original software) these days.
but I'm only counting Pd forks those projects that are being relevantly adopted by and distributed to users. Hence, with this criteria, I can't really consider "Spaghettis" and "Pd-next" relevant forks yet.
the same would probably be true for DesireData. i don't think anybody apart from matju (and his mtl gang), chun and claude used it (and i'm not sure about claude).
now about the history of Pd and its forks, the bike shedding discussion is actually welcome so I can get everything right.
glad to hear that.
For those that have a good recollection or ever used it, please tell me a bit more about "Desire Data", although I think I can reach Mathieu for that.
what do you want to hear? (although my recollection probably *is* rusty on that)
And, well, I can't consider MAX as a fork of Pd or the other way around. I
Pd could probably be considered a fork of Max/FTS (though not of Max/Opcode which evolved into what we now know as Max/MSP).
but then also decidedly not.
a fork typically means that actual code is taken from the parent project, and then evolved into a different direction. Pd was a complete re-write (no IRCAM code!).
heard that MSP objects were first based on Pd signal objects, but that's
to my knowledge, MSP (not just the objects, the entire engine!) was indeed "based on Pd", if not "Pd itself".
but others surely know better.
not really a fork of the software, more like appropriation - or stealing :)
how so?
it's definitely not "stealing". it's very hard to "steal" something that is free for *all* to take. miller could have chosen to license Pd under the GPL, which would have prevented its use in a closed source project. but Pd is not GPL. instead it is released under the 3-clause BSD license, which is one of the licenses that allow for use in a closed source, proprietary project.
and i think if my recollection is correct (see above), then this is a text-book example of your wikipedia-definition of a fork: « developers ["Cycling'74"] take ["appropriate" or "steal" as you term it; but also consider "are given"] a copy of source code from one software package ["Pd"] and start independent development on it, creating a distinct and separate piece of software ["Max/MSP"]. »
gfmsdt IOhannes