Hey all,
I'd like to give information on the work being done so far: Since my last mail regarding the "new packages in [community] topic", I've added a few more:
* dpf-plugins * fabla * luppp * non-daw (non-{mixer,session-manager,timeline}) * sorcer * sonic-pi (but that's seriously on its way out again...) * infamousplugins * zam-plugins * rt-tests * giada * artyfx * freewheeling * avldrums.lv2 * blop.lv2 * eteroj.lv2 * fomp.lv2 * mda.lv2 * midi_matrix.lv2 * moony.lv2 * sherlock.lv2 * vm.lv2 * cmt * convolv2 * din * patchmatrix * spectmorph * lmms (updated to latest RC) * sweep * qmidictl * qxgedit * alsa-tools * python-jack-client * python-pyalsa * python-zita-audiotools * python-zita-jacktools * zita-jclient * zita-jclient * aliki * jaaa * jconvolver * jnoisemeter * njconnect * paulstretch * realtime-privileges * japa * lv2file * noise-repellent * setbfree * ams-lv2 * beatslash-lv2 * gmsynth.lv2 * lsp-plugins * libmusicxml * dragonfly-reverb * wolf-shaper * ssr
@Albert: pd-lua is still on the list, let's get in touch! @Chris: dexed can also go to [community], I'll look into it!
Most of them are in (at least) one of the audio related groups: "pro-audio", "lv2-plugins", "dssi-plugins", "vst-plugins", "ladspa-plugins" or "realtime"
You can have a look with:
pacman -Sg <group_name>
And install the whole group with:
pacman -S <group_name>
I have done some (minor) revamps of the relevant Arch wiki pages ([1], [2], [3]), but would love to see many more changes (to remove irrelevant data and add actual good and concise examples).
Enjoy!
David
P.S.: If you have suggestions for more additions, let me know!
[1] https://wiki.archlinux.org/index.php/Professional_audio [2] https://wiki.archlinux.org/index.php/Realtime_kernel_patchset [3] https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit
Hi David,
again many thanks for undertaking this effort which benefits all Arch users!
On Tue, Nov 20, 2018 at 12:47 PM David Runge dave@sleepmap.de wrote:
@Albert: pd-lua is still on the list, let's get in touch!
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/
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.
Best, Albert
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!
Besides: How stable is the purring data by now? :)
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 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
On Tue, Nov 20, 2018 at 3:29 PM David Runge dave@sleepmap.de wrote:
Okay, I'll have a look. What is it used for specifically, tho?
Scripting. Pd-Lua allows you to write your own Pd externals, so you can quickly create your own objects which can do more than what you can do with just Pd (using the full power of a real programming language). You can also do that with C, of course, but Lua is much easier.
Is there the possibility to make it compatible with newer lua versions
upstream
Not sure, you'll have to ask IOhannes. He maintains the earlier version in Debian, and we all know how fast that moves. :)
to have it integrated as a working external depending on LUA version?
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.
Besides: How stable is the purring data by now? :)
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. ;-)
Also, I recently noticed that Gem (Pd's graphics environment,
[...]
I agree on the importance, but: no releases have been made in the last 7(!) years [1].
True. But it's still being used, as it's the recommended way to do both 2D/3D graphics and video with Pd. I'm currently testing a build of Purr Data with Gem based on the latest git, and so far it works fine on Arch for me.
I wouldn't want to build 0.93.3 and would only even consider packaging
this, if proper releases are being made again.
We could politely ask IOhannes (he's the current maintainer) to put out a new release. I'll mail him right away.
Apart from that, we don't really have a naming scheme for pd externals.
Maybe just pd-gem then?
Yep.
Has there ever been a PKGBUILD for it?
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.
Albert
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
On Tue, Nov 20, 2018 at 10:34 PM David Runge dave@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 pastures.
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. :)
Albert
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.
Many many thanks!!
*Dancehall Echo*
Web Site Promoting Reggae, Dancehall And Soca Music.
Sur Le Net: www.dancehallecho.net
Réseaux sociaux: Facebook http://+www.facebook.com/DancehallEcho Twitter http://www.twitter.com/DancehallEcho Google + https://www.google.com/+DancehallechoNet
Le mer. 21 nov. 2018 à 04:11, Albert Graef aggraef@gmail.com a écrit :
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
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_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!).
On 2018-11-21 11:56:44 (+0100), David Runge wrote:
Good to know! It'll be in the making then :)
And in [community] now! I the layout is a little different though, as the "default" path /usr/lib/pd-externals is not a default search path for pd (was this added because of Debian?). However, /usr/lib/pd/extra is! Please test! It seemed to work when I tried it :)
I'll have to wait with purr-data though, until the dust settles a bit :D
However, I might have a look at how pd-gem is built and if that actually now makes sense or not.
Best, David
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
On Mon, Jun 24, 2019 at 10:29 AM David Runge dave@sleepmap.de wrote:
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?
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?
Greetings, Albert
On 2019-06-24 11:31:34 (+0200), Albert Graef wrote:
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 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...
On 11/20/18 3:47 AM, David Runge wrote:
Hey all,
I'd like to give information on the work being done so far: Since my last mail regarding the "new packages in [community] topic", I've added a few more:
- dpf-plugins
- fabla
- luppp
- non-daw (non-{mixer,session-manager,timeline})
- sorcer
- sonic-pi (but that's seriously on its way out again...)
- infamousplugins
- zam-plugins
- rt-tests
- giada
- artyfx
- freewheeling
- avldrums.lv2
- blop.lv2
- eteroj.lv2
- fomp.lv2
- mda.lv2
- midi_matrix.lv2
- moony.lv2
- sherlock.lv2
- vm.lv2
- cmt
- convolv2
- din
- patchmatrix
- spectmorph
- lmms (updated to latest RC)
- sweep
- qmidictl
- qxgedit
- alsa-tools
- python-jack-client
- python-pyalsa
- python-zita-audiotools
- python-zita-jacktools
- zita-jclient
- zita-jclient
- aliki
- jaaa
- jconvolver
- jnoisemeter
- njconnect
- paulstretch
- realtime-privileges
- japa
- lv2file
- noise-repellent
- setbfree
- ams-lv2
- beatslash-lv2
- gmsynth.lv2
- lsp-plugins
- libmusicxml
- dragonfly-reverb
- wolf-shaper
- ssr
@Albert: pd-lua is still on the list, let's get in touch! @Chris: dexed can also go to [community], I'll look into it!
Most of them are in (at least) one of the audio related groups: "pro-audio", "lv2-plugins", "dssi-plugins", "vst-plugins", "ladspa-plugins" or "realtime"
You can have a look with:
pacman -Sg <group_name>
And install the whole group with:
pacman -S <group_name>
I have done some (minor) revamps of the relevant Arch wiki pages ([1], [2], [3]), but would love to see many more changes (to remove irrelevant data and add actual good and concise examples).
Enjoy!
David
P.S.: If you have suggestions for more additions, let me know!
[1] https://wiki.archlinux.org/index.php/Professional_audio [2] https://wiki.archlinux.org/index.php/Realtime_kernel_patchset [3] https://wiki.archlinux.org/index.php/JACK_Audio_Connection_Kit
Wow, there are like a dozen really amazing things in here that I've never even heard of (and I'm someone who already had a ton of repo/AUR plugins installed)! This is like an an early Christmas present. Thank you!
Am 20.11.18 um 12:47 schrieb David Runge:
@Chris: dexed can also go to [community], I'll look into it!
In case you're wondering, why in the AUR PKGBUILD the plug-in and the stand-alone version are build separately, there is in error in JUCE, where it tries to initialize the ALSA output in the plug-in version, which leads to crash, so the plug-in is build without (unnecessary) ALSA or JACK support.
Chris
On 2018-11-21 13:53:54 (+0100), SpotlightKid wrote:
Am 20.11.18 um 12:47 schrieb David Runge:
@Chris: dexed can also go to [community], I'll look into it!
In case you're wondering, why in the AUR PKGBUILD the plug-in and the stand-alone version are build separately, there is in error in JUCE, where it tries to initialize the ALSA output in the plug-in version, which leads to crash, so the plug-in is build without (unnecessary) ALSA or JACK support.
I'm not allowed to package the steinberg-sdk stuff, so the -vst build will have to remain in the AUR. However, the standalone can be moved!
Best, David
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
On 2018-11-25 13:25:40 (+0100), SpotlightKid wrote:
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)?
I'm not allowed to redistribute the Steinberg SDK (as a package), because of licensing issues [1]. 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. This would create a factory of problems.
If a project wants to build vst2 on Linux, the less painful way seems to be to use one of the alternatives mentioned in the wiki article. Developers might also want to have a look into DPF [2].
I tried to get in touch with Steinberg finding a way to get an exception, agreement, or whatever, but never got past 1st level support (aka Tier 1) and them wanting me to sign some useless blah (from their point of view they don't support Linux and don't care).
AFAIK, VST2 support in their SDK is also supposed to be dropped soonish (I don't really follow any of their business movements, so if anyone can present some real data on that, that would be great - else take it as hearsay).
Just uploading anything Steinberg related to the repos is asking for trouble (when keeping in mind this year's DMCAs on github against Robin Gareus and the Csound project [3], amongst others).
That being said: Steinberg is hard at work deprecating VST2 using any means possible and I certainly don't plan on standing in the way (they probably have a closet full of attorneys).
Best, David
[1] https://wiki.archlinux.org/index.php/Professional_audio#Restricted_software [2] https://github.com/DISTRHO/DPF [3] https://github.com/csound/csound/issues/989
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
arch-proaudio@lists.archlinux.org