On 2018-11-20 14:02:15 (+0100), Albert Graef wrote:

again many thanks for undertaking this effort which benefits all Arch users! I'm happy to do some improvements and make things a little easier to actually use!

We've since integrated this into purr-data, but in any case it would be nice to have it with vanilla Pd as well. (The version available in Pd's package manager Deken is rather old and doesn't work with Lua 5.3.) My PKGBUILD is in the AUR: https://aur.archlinux.org/packages/pd-lua/ Okay, I'll have a look. What is it used for specifically, tho? Is there the possibility to make it compatible with newer lua versions upstream to have it integrated as a working external depending on LUA version? If they pre-build all things, they could pre-build this as well!

Also, I recently noticed that Gem (Pd's graphics environment, https://github.com/umlaeute/Gem) seems to have disappeared. We should really dig out the old PKGBUILD and make it available again. Gem is rather important, one of Pd's flagship extensions, and it's used by many media artists doing graphics and video stuff with Pd. It's a big package, has lots of dependencies and takes a while to build, so it would be nice to have it in the official repositories. I can help with that if needed. I agree on the importance, but: no releases have been made in the last 7(!) years [1]. That's pretty bizarre given the fact, that since then there have been over 2200(!) commits [2] to the codebase! I wouldn't want to build 0.93.3 and would only even consider packaging

Besides: How stable is the purring data by now? :) this, if proper releases are being made again. If you're up for debating with upstream about that, please feel free to do so! I'm already spending enough time on other people's bug trackers as is ;-) Apart from that, we don't really have a naming scheme for pd externals. Maybe just pd-gem then? Searching my aur-requests backlog, there haven't been any repos for gem in the AUR (and certainly not in [community]) for this since early 2016. Has there ever been a PKGBUILD for it? Best, David [1] https://github.com/umlaeute/Gem/releases [2] https://github.com/umlaeute/Gem/compare/0.93.3...master -- https://sleepmap.de

On 2018-11-20 18:47:34 (+0100), Albert Graef wrote:

Not sure, you'll have to ask IOhannes. He maintains the earlier version in Debian, and we all know how fast that moves. :) Hm, well, forget about that then. I was more hoping for an integration in the whole deken ecosystem.

My fork should still work with Lua 5.2 as well, Lua 5.1 isn't supported in either version AFAICT (there have been some incompatible changes in the language). I wouldn't want to use anything earlier than Lua 5.2 anyway. Yeah, we don't want to go there. :) Wow, that external has quite a turbulent history. I hope you can keep it alive as new upstream!

Only few dependencies it seems, this should be really straight forward.

Quite. You might want to package 2.6.0 which has been out for a while, see https://agraef.github.io/purr-data/. I have a PKGBUILD for the git version in the AUR, it should be easy to adjust this for a stable release. Dependencies galore, though. ;-) omg... indeed. These two AUR dependencies [1] [2] seem odd though (and quite dated).

Does purr-data compile with fluidsynth > 2.0.0? I will have to update it eventually. Wow, lots going on in that PKGBUILD! Are the submodules [3] special versions of the externals? Ideally one would like to be able to build those separetely I guess (if possible). It just looks like this is pulling in a lot of (legacy - such as cwiid... ewwww... I just deprecated that!! ;-) ) stuff. Having yet another slightly modified version [4] of cwiid is just not very pretty... All these weird half-dead Nintendo libs... :> btw: You have to quote $srcdir, as it potentially contains spaces! Most of the time you can just drop its use though, as all PKGBUILD functions always start with $(pwd)==$srcdir by default.

We could politely ask IOhannes (he's the current maintainer) to put out a new release. I'll mail him right away. Thanks!

I thought so, might be quite some time away, but maybe I'm mistaken. Or maybe it went away after the big AUR4 house-cleaning. The big purge... hehe. Hm, should be pretty straight forward to do though... I hope.

[1] https://aur.archlinux.org/packages/libunicap/ [2] https://aur.archlinux.org/packages/libsndobj-git/ [3] https://github.com/agraef/purr-data/blob/master/.gitmodules [4] https://github.com/pd-l2ork/cwiid -- https://sleepmap.de

On Wed, Nov 21, 2018 at 3:42 AM Albert Graef <aggraef@gmail.com> wrote:

Anyway, we can probably do without libunicap, [...] I'm just going to try and remove libsndobj and see what happens.

Looking good. I still need to test with a real HDMI cam and capture device before I commit that to the AUR. But it looks like we can get rid of both. -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggraef@gmail.com WWW: https://plus.google.com/+AlbertGraef

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

On 2018-11-21 11:56:44 (+0100), David Runge wrote:

On 2018-11-21 03:42:50 (+0100), Albert Graef wrote:

...

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). It seems the release of 0.94 [1] went by relatively unnoticed.

I have build pd-gem, but I think it might lack some optional libraries for video input/output, which we don't have in the repos and also not in the AUR (mainly because they're super ancient or part of cinelerra's hackery). Would you be up for testing this? Best, David [1] https://github.com/umlaeute/Gem/releases -- https://sleepmap.de

I can give it a whirl some time, as soon as the semester is over (in a few weeks). Do you have a PKGBUILD for that, or at least a list of the dependencies you used (or missed), so that I can have a look and figure out what's really needed? That would be very much appreciated. You can grab it from [community] [1] now. During configure, the build process still can't find something to work with mpeg/mpeg3 (which would probably be provided by the unpackaged

On 2019-06-24 11:31:34 (+0200), Albert Graef wrote: libmpeg3), gmerlin (in AUR) or glewmx (also AUR). All are rather antiquated, but could be moved to community probably, although I'm not so sure about conflicts with existing glew versions in the repos right now, when looking at the latter. Closing, the examples worked for me and I didn't have any stability issues. Nonetheless, maybe some features are missing. Best, David [1] https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... -- https://sleepmap.de

Am 21.11.18 um 15:17 schrieb David Runge:

I'm not allowed to package the steinberg-sdk stuff,

Can you post a link to the reason so I can point people to it (e.g. just had a question on the giada-vst AUR page, why VST support isn't included in the community package)? Chris

Am 25.11.18 um 14:54 schrieb David Runge:

I'm not allowed to redistribute the Steinberg SDK (as a package), because of licensing issues [1].

Thanks for the explanation and the link. It's really shame, though, since some (mostly cross-platform) audio software only comes in VST format as a plug-in.

Downloading it every time for every package is an option, but the SDK is a moving target, tarball/versioning sucks and their folder structure is a mess, too.

Wouldn't it be theoretically possible to build a package, which downloads the SDK on the user's system on installation? Sort of like the flashplugin-installer package on debian does (did?)? Then this could be included in community and packages in community could be build with VST support. I can understand, though, that this would probably not be very robust and cause a maintenance burden. Incidentally, many cross-platform audio projects are plagued by the same issues regarding release archive naming and versioning (I'm looking at you, Polyphone!), but giada, for example, got this sorted out eventually. Chris