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

[David Runge]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-proaudio/attachments/20181121/7022f415/attachment.asc>