On 2018-11-21 03:42:50 (+0100), Albert Graef wrote: > 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 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_package.sh [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
Attachment:
signature.asc
Description: PGP signature
