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. :) Good to know! It'll be in the making then :) I just wonder, if we should establish a new package group for it (as
On 2018-11-21 03:42:50 (+0100), Albert Graef wrote: there might be more), such as "pd-externals" or to be more in line with the other plugin groups "pd-plugins".
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. I would not even bother having it side-by-side then (and just introduce a "conflicts" with pd-l2ork), unless purr-data is about to move to its own locations anyways.
Generally I'd like to note, that it might just be about time to completely discontinue pd-l2ork1 then. Many versions are really only confusing and with even pd-extended still around (sadly), people have a hard time understanding which version is which and why and all that... And they keep on using very outdated and unmaintained software...
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. Sadly, it's not [1]. I'm still waiting for projects to pick up the ball (e.g. csound doesn't seem too eager to do anything about it [2] and might soon have to do without) to adopt, before I can update, because I really don't see any benefit in supporting two versions).
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. You're probably right about that. Personally I much more prefer the modular approach, but I do get why people would want a more integrated solution. However, as a project this gives you many more loose ends to track ;-)
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. ;-) Look, a three-headed monkey! Please consider using wiiuse [3]. That's at least still kinda maintained and has more features! I even got them to make a new release! :) cwiid on the other hand is super dead. Maintaining a separate version with potentially some patches sprinkled on top really doesn't make it any better (supercollider also dropped it this year).
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.) Are you planning on providing tarballs with the submodules included then? Looking at the releases [4], you only provide pre-compiled versions for some OSes. I did something like that for the assets of sc3-plugins [5]. In case this proves to be too annoying, the PKGBUILD needs to be changed to have a proper submodule setup [6].
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. That being said, you can give co-maintainership, if you want. Quoting $srcdir is very important, as it will break builds under certain circumstances.
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. :) That's too bad. Hope he'll get things done though (as the will to release a new version seems to be there..) and it doesn't end up in some bizarre limbo like lmms (in 1.2.0 RC stage for four(!) years).
Best, David [1] http://www.fluidsynth.org/api/index.html#NewIn2_0_0 [2] https://github.com/csound/csound/issues/1036 [3] https://github.com/wiiuse/wiiuse [4] https://github.com/agraef/purr-data/releases [5] https://github.com/supercollider/sc3-plugins/blob/master/package/create_pack... [6] https://wiki.archlinux.org/index.php/VCS_package_guidelines#Git_Submodules P.S.: gmail (or your mail client) breaks your quotes btw (places them below the actually line to be quoted!). -- https://sleepmap.de