[arch-proaudio] New additions since some time this year

Albert Graef aggraef at gmail.com
Wed Nov 21 02:42:50 UTC 2018

On Tue, Nov 20, 2018 at 10:34 PM David Runge <dave at 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

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. :)


Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email:  aggraef at gmail.com
WWW:    https://plus.google.com/+AlbertGraef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/arch-proaudio/attachments/20181121/eae7c64a/attachment-0001.html>

More information about the arch-proaudio mailing list