[PD] list of Pd forks?

[IOhannes m zmoelnig]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20211006/ef733187/attachment-0001.sig>