the main issue is that L2Ork which Purr Data is based on, is a breaking variant of PD-vanilla. it may look cool visually, and has a few modules not available, but PurrData has exactly one maintainer and contributor - Jonathan Wilkes. since you’re using Linux on the Pi you could just build/run L2Ork actually, but i would have to say, if PurrData isn’t 100% compatble with L2Ork then you’re two branches away from PD proper and entirely beholden to Jonathan to update and support it.
the ‘extended’ reference that @jofemodo mentioned is a version of PD compiled by Hans Christoph-Steiner called PD-extended. it contained vanilla PD plus a lot of other objects and libraries making it more usable and friendly than vanilla PD was at the time. for a while (5 years or so) it was the preferred distribution with those just getting started in PD. but at least some of the objects/libraries introduced breaking changes compared to vanilla, and more importantly Hans got a full time job and had no more time to maintain the project and nobody else took up the challenge. so this left users wanting updates to PD-extended out on a limb with a dead and unsupported fork.
however there’s been some good news - the death of PD-extended spurred a lot of development in PD-vanilla and especially how it handles external objects and libraries, and they now have a pretty robust system for handling how to extend functionality in PD-vanilla called Deken - you can search for libraries and externals and easily install them and configure object search paths. additionally later versions of PD-vanilla have introduced a lot of useful objects, and last, even libraries of external objects that were falling into disuse like Cyclone (which brings in many MaxMSP objects and functionality to PD) now have new updates to bring them in line with the newest PD-vanilla versions.
L2ork is a pretty well known fork for PD but it’s wholly incompatible with PD-vanilla. Ivica the main developer of L2ork made a decisive break with PD-vanilla specifically for the students at Virginia tech for the laptop orchestra. Jonathan was a developer of PD getting dissatisfied with PD vanilla’s limitations at the time (in the dead time after PD-extended stopped being maintained) and so switched to L2ork as the base for a new, better looking version of PD called PurrData, that would run on Mac and Windows (L2ork only runs on Linux). so now you know the story, at least as much as i’ve pieced together over mailing list posts over the years.
so, the practical upshot is that if L2ork or PurrData was supported on Zynthian it would have to be as a completely separate library/path as PD-Vanilla and it are incompatible with each other. maybe not 100% but say 30%. furthermore if PurrData introduces objects or functionality NOT in L2ork, then you’re really branching out in a potentially dead area. one maintainer == risky bet. if it’s still 100% compatible with L2ork it may be useful to pursue it as a separate layer availble, but regardless it will not work with the existing PD layer, or to be more accurate it’s risky to do so because you’ll eventually get conflicts.
@weichselbaumj i would recommend seeing if you can get your patch to run in PD-vanilla. i might suggest you add the CEAMMC object library which has many externals that are useful. additionally you can try the ELSE library, although the maintainer of that likes the newest PD versions (not betas, i mean new releases) and these updates can break compatibility with older PD versions for certain objects. but i am nearly certain that externals are out there that can do what [triangle~] and [limiter~] can do. also PD-Vanilla is maintained by a few individuals and is updated fairly frequently - it’s not going anywhere unlike PD-extended which is dead. again having one maintainer and especially no contributors is not healthy.
anyway, that’s my rather long reply but as a user of PD who watched the saga unfold over the last decade i can see pitfalls in using forks, although as i said L2ork could be worth supporting.
best,
scott
nor am I a professional audio-processing expert. So I would be happy about your feedback or recommendations if you have any input for improvement. 
