[PD-dev] Pd-extended EOL?
hans at at.or.at
Mon Nov 9 20:44:04 CET 2015
On Nov 9, 2015, at 2:56 PM, IOhannes m zmoelnig wrote:
> hi hans,
> great to hear from you!
> On 2015-11-09 14:49, Hans-Christoph Steiner wrote:
>> FYI, for anyone interested, it would not be hard to do a Pd-extended update if it is just a matter of updating the libraries.
> what i would find more interesting: how hard would it be to update the
> PdX-core to Pd-0.47? that is, the patcheset against Pd-vanilla.
> i once had a look at the PdX repository (which is based on miller's
> vanilla Pd), but even for PdX-0.43 the two repositories had diverged by
> (iirc) a few hundred commits, which makes it highly impractical to
> is there any meta-description available of the diffs between PdX and Pd?
For a long time, I used a git workflow that kept the Pd-extended changes as a set of patches on top of vanilla, you can see that in the 'patch_series' branch. You can see that in the history. I ultimately abandoned that because there were too many commits from vanilla that I had to remove in order to keep things working. So I switched to treating vanilla as a source of patches which I included into the pd-extended master. I regularly submitted patches that didn't rely on the Pd-extended stuff to the patch tracker. Many of those were ignored for years. I have no idea the current state of them.
That workflow is documented here under "Pd-extended":
As for syncing up Pd-extended with the latest vanilla commits, that is a manual process of reviewing them and including them. If I remember correctly, basically anything that touches an object, e.g. src/x_list.c, src/d_soundfile.c is directly accepted. The objects in extra/ actually removed from pd-extended.git, so those changes can all be ignored. I generally automatically accepted changes to the DSP core too. Stuff related to the GUI definitely needs to be carefully reviewed.
More information about the Pd-dev