On 10/5/21 21:02, Alexandre Torres Porres wrote:

I don't really know, but I bet that just installs iem externals on Vanilla and is not really a fork.

so what's you definition of a "fork"?

gmfdsf IOhannes

On 10/6/21 2:33 AM, Alexandre Torres Porres wrote:

Em ter., 5 de out. de 2021 às 19:12, IOhannes m zmölnig zmoelnig@iem.at escreveu:

...

so what's you definition of a "fork"?

A modification of the source code to reflect different features. If I

but the "pd-iem" has all kinds of different features, e.g. you do do image processing and matrix processing and what not. it doesn't change the source code of the implementation of osc~ though (but iirc, neither did DesireData, Pd-Devel or PurrData).

so where does "modification of the source code" start? how is modifying a line of code in a git-repository different from monkey-patching interpreted functions at runtime? what's the role of dynamic extensions ("externals") in this context?

mgfdrs IOhannes

On 10/6/21 10:16 AM, Christof Ressi wrote:

FWIW, I wouldn't consider pd-iem a fork, either. IMO, adding a bunch of plugins doesn't qualify as a fork. I think a better word would be "distro". Actually, that's how the project describes itself:

"is a Pure Data libraries distribution for plain Pure Data (Pd-vanilla), focussed on (but not limited to) IEM libraries."

sure. i wouldn't consider pd-iem a fork myself.

Of course, there is no universal definition of "fork" and lots of grey areas with great potential for infinite bike shedding.

which is what i am famous for :-P

in any case, *because* there is no universal definition of "fork", there should at least be a common understanding of the term if we want to answer a question like "how many forks of Pd are there?"

alex listed "pd-extended" as one of the well-known forks. but what constitutes the forkiness in this case? apparently not the large number of externals shipped (as this would make it as "distro"), but something else. from the top of my head (as I never was a Pd-extended user myself), two things come to my mind: tooltips and white object-backgrounds (going along with those red signal connections).

otoh, I consider the "puredata" package as shipped with Debian/Ubuntu/... to be *Pd-vanilla*, thus not a fork. nevertheless, it contains some (minor) source-code modifications with respect to what you get when installing Pd from scratch:

• some bugfixes, that are already present in the 'master' branch of Pd,

but did not make it into the last release

• some enhancements (like jack port numbering starting from 1 rather

than 0), that are already present in the 'master' branch of Pd, but did not make it into the last release

• some debian specific modification (e.g. showing the time when the

package was released rather than the time when Pd was compiled; enhanced privacy in HTML-code; search some additional paths for externals and/or gui-plugins,...)

some of the "bugfixes" and "enhancements" have been added to the Debian packages *before* they were merged into Pd's 'master' branch (although *I* might have pushed them into the 'develop' branch with a high confidence that they will end up in 'master' once miller goes into merge-mode).

does this make it a "fork" then?

mgfdasr IOhannes

hmmm, I thought there was a pretty simple and straightforward and "universal" definition of a fork, which would be basically a parallel (independent) development. Maybe there's just no "official scientific definition"? Wikipedia https://en.wikipedia.org/wiki/Fork_(software_development) says "*a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software*", one of the referred sources on wikipedia https://flosshub.org/sites/flosshub.org/files/paper_0.pdf says "*In general it is assumed that a software product evolves within the authoring company or group of developers that develop the project. However, in some cases different groups of developers make the software evolve in different directions, a situation which is commonly known as a fork.*"

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. Some of the changes were listed here and I assume the first ones were in favor of better managing the build system and library loading. 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?) but these are now also possible in Vanilla. Eventually other changs like in the documentation and User Interface modifications aimed at a friendlier user experience. Other than that, Pd Extended had a very close evolution line with Vanilla. Its versioning did follow Vanilla's after all, so the core functions were there and some changes also eventually were brought into Vanilla.

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 thre, but it seems it started in the Vanilla development but never made into it? 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).

As for "github forks", some of these so called forks are just development branches with modifications that may eventually be merged (I have one of those). Others are just people that once copied the source code and never really worked on it. There might be some that made relatively small modifications for personal reasons, like Christoff's, 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.

I started this thread just to make sure I wasn't missing anything, and I guess the discussion shows us that I haven't, I believe. Since I'm writing now about the history of Pd and its forks, the bike shedding discussion is actually welcome so I can get everything right.

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.

We often say and hear Pd has "many" flavours and forks that come and go, but there aren't that many really.

And, well, I can't consider MAX as a fork of Pd or the other way around. I heard that MSP objects were first based on Pd signal objects, but that's not really a fork of the software, more like appropriation - or stealing :)

cheers

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

Em qua., 6 de out. de 2021 às 12:41, IOhannes m zmoelnig zmoelnig@iem.at escreveu:

...

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.

Yes, it is the most prominent/important fork these days, but I don't consider it as providing "minor changes", they seem pretty drastic to me and result in a number of incompatibilities. It's like "a true fork" I guess, though yeah, it's not like it isn't "close". But we're now just being quite subjective, there's no concrete/absolute measure here so it's a matter of opinion. It's also a matter of perspective though, and when you compare to Extended and Pd Ceammc, they're on a much more independent route and codebase.

...

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)

Nothing too detailed, just what it offered. I remember it had many UI improvements, which seems to be a golden rule for any Pd fork :) and that maybe it did include gridflow pre installed? So, yeah, another golden standard: pre installed externals. Finally, if it was for linux only. That should do it, but anything else is welcome.

...

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.

Ok, I'm now convinced MSP was a fork of Pd ;) nice catch folks!

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.

yeah, I was being ironic and I know I shouldn't say that, it's not correct. Though I also say I do that, ironically. For instance, I say some objects from ELSE are "stolen" from cyclone, which also has a BSD license. But then, I've also worked a lot on fixing and taking care of those objects, so I'm also "stealing" from myself. And, well, cyclone also "steals" from MAX, but that process is actually reverse engineering and not stealing :) maybe we're stealing ideas? Well, I've stolen a lot of ideas from SuperCollider into ELSE as well...

cheers

Em qua., 6 de out. de 2021 às 17:14, Sebastian Shader sebfumaster@aol.com escreveu:

by these definitions it is also a very "minor" fork

as "minor" as it can be :) not that I don't think this is ain't nice

as all of the changes are basically contained in a few open PRs for vanilla (except for the logo).

But what's your plan with it? Keep it going and add more stuff even if most of the PRs get into Vanilla? I think the one that allows us to write color themes plugins has a good chance to get in, and it's one of the main selling points of your fork.

cheers

Only thing i can say is to confirm that Spaghettis IS a fork.

----- Mail d'origine ----- De: IOhannes m zmoelnig zmoelnig@iem.at À: pd-list@lists.iem.at Envoyé: Wed, 06 Oct 2021 10:56:07 +0200 (CEST) Objet: Re: [PD] list of Pd forks?

On 10/5/21 4:12 AM, Alexandre Torres Porres wrote:

That's it, right? Did I miss something?

github lists 172 "forks" (in the github-meaning of the word). it seems that none of them have bothered to change the name, so the repos are still called "pure-data" "many" (but it's hard to give actual numbers) have somehow or other diverged from the original codebase (that is: they have branches that contain commits that have not (yet?) been merged into the canonical repository.

gmsr IOhannes

On 06.10.21 11:03, cyrille henry wrote:

electronic art forked pd to became the audio engine of a game (spore). I don't know the name of the fork since it was not public. Other company have probably done the same without advertising it.

Small correction: they used the control rate part of Pd to write the procedural sound, but the audio was generated not by Pd but their own audio engine.

Here is the paper form Pdcon~: https://www.uni-weimar.de/kunst-und-gestaltung/wiki/PDCON:Conference/Using_P...