Package Details: yabridge-git 3.0.1.r0.gd91c8ee-1

Git Clone URL: (read-only, click to copy)
Package Base: yabridge-git
Description: A modern and transparent way to use Windows VST2 and VST3 plugins on Linux
Upstream URL:
Licenses: GPL3
Conflicts: yabridge
Provides: yabridge
Submitter: robbert-vdh
Maintainer: robbert-vdh
Last Packager: robbert-vdh
Votes: 2
Popularity: 0.60
First Submitted: 2020-05-05 13:30
Last Updated: 2021-02-26 15:34

Latest Comments

magillos commented on 2021-01-06 10:39

Your newest pkgbuild (1 job) takes nearly 7 minutes to build and takes a little swap. After removing '--unity=on' and with setting up 'ninja -C build' regardless of RAM available (I hope it's what you wanted me to check) it takes over 13 minutes and uses bit more swap. The problem with previous pkgbuild was not only build time, but also it would make system so unresponsive that sometimes it had to be killed with SysRq and build run again after reboot. If built after reboot it would finish successfully but only after quite long time and occupying literally the whole Ram and swap avaible. So to me the current pkgbuild is the winner. Thanks! (again)

robbert-vdh commented on 2021-01-06 00:21

@magillos Of course! Those unity builds take up quite a bit of RAM, but they do speed up compilation significantly. I've now changed it so it only builds a single target a time at 4 GB RAM, since building a single target can take up to 1.5-2 gigs so with two at a time you're probably already swapping. If you have the time to spare, could you check for me whether building one unity target at a time is still faster than doing a normal build? If you get rid of the --unity=on and replace the memory checks with a plain ninja -C build then it will do a normal non-unity build. And if you really have the time, I'm also curious whether doing two targets at a time (and swapping) is faster than doing only one like I now configured it, because it probably is.

magillos commented on 2021-01-05 23:30

Hey, I noticed your pkgbuild takes into consideration amount of ram available. Could you limit number of current jobs for systems with little ram even further? With 4GB of ram and 4GB of swap on hand the build uses nearly all resources and it takes ages to finish. Thanks for your work!