On Tue, Nov 20, 2018 at 10:34 PM David Runge <dave@sleepmap.de> wrote:
[lua] Wow, that external has quite a turbulent history. I hope you can keep it alive as new upstream!
I'm using it a lot for my own programming and in my more advanced Pd courses, so I have a vested interest to keep it working. :) [purr] These two AUR dependencies [1] [2] seem odd though (and quite dated).
Yeah, we tend to have that a lot in the Linux audio world, don't we. ;-) Often these are research or side projects which become orphaned once the original author becomes a professor or leaves the university for greener pastures. Anyway, we can probably do without libunicap, AFAICT it just exposes the same video capture devices as v4l2 does, and the latter is preferable since it's actively maintained. libsndobj is used for flext, I'm not sure whether we even build that anymore, I'm just going to try and remove libsndobj and see what happens. Wow, lots going on in that PKGBUILD!
Yeah, there's a lot of shuffling of the staging area going on there. That is to make it possible to have parallel installations of "classic" Pd-l2ork (Pd-l2ork 1, Ico's version) and Purr Data (Pd-l2ork 2, Jonathan's version). As Pd-l2ork1 slowly starts falling victim to bitrot, I'm thinking about getting rid of all this, but it's not high up on my priority list right now. Does purr-data compile with fluidsynth > 2.0.0?
Not sure, I haven't tried. As long as its API is backward-compatible, it should. If it isn't, then qsynth probably is in trouble, too. Are the submodules [3] special versions of the externals? These are specific snapshots of some of the bigger external libraries (most notably Gem) that are known to work in Purr. Some of these are also mirrored in Jonathan's Gitlab, so that they don't disappear and we can make minor adjustments as needed. Ideally one would like to be able to build those separetely I guess (if
possible).
I have to disagree there. The whole idea behind Purr (like Pd-l2ork and Pd-extended before it) is that you get everything and the kitchen sink in one big package, so that all the stuff is well integrated and ready to go. It's actually possible to build a "light" version of Purr, which is pretty much like Vanilla (with just a few essential externals included), but it's much less useful since we don't have support for Deken. Most people will want to use full package anyway. Having yet another slightly modified version [4] of cwiid is just not
very pretty...
That's included in the source for those who still might want to use it (mostly Ico Bukvic and the L2ork at this point AFAICT), but otherwise you're not even going to see it. So just look the other direction. ;-) As you can see we're still carrying around some cruft, but that's because we also support Mac, Windows and some older Linux systems such as Ubuntu Trusty that Purr users still have in use, and we don't want to maintain different variants across different Linux distros. (The only thing that I'm going to adjust for Arch is to switch to the latest upstream revision of Gem. I already have a branch set up for that, I'm currently testing it "on the job", and it seems to work fine so far. But the latest Gem from git still has some regressions on Mac and Windows, that's why our official Purr source is currently stuck with an older Gem snapshot.) btw: You have to quote $srcdir, as it potentially contains spaces! I count on you to rectify all those glitches once you adopt Purr. :) It's a complicated package, and I admit that I just don't have the time to properly look into all these minutiae.
We could politely ask IOhannes (he's the current maintainer) to put
out a new release. I'll mail him right away. Thanks!
He already replied. No chance for a new Gem release right now, as he's still fighting with a some Mac and Windows regressions. So that leaves it up in the air. Maybe just procrastinate on it some more and we'll see a new release some day. In the meantime people will have to use Deken. Or switch to Purr. :) Albert -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef@gmail.com WWW: https://plus.google.com/+AlbertGraef