Package Details: zynaddsubfx-git 3.0.1.r33.g1b465614-1

Git Clone URL: (read-only, click to copy)
Package Base: zynaddsubfx-git
Description: A powerful realtime, multi-timbral software synthesizer.
Upstream URL:
Licenses: GPL
Conflicts: zynaddsubfx
Provides: zynaddsubfx
Submitter: speps
Maintainer: WoefulDerelict
Last Packager: WoefulDerelict
Votes: 14
Popularity: 0.000000
First Submitted: 2011-07-09 23:54 (UTC)
Last Updated: 2017-05-15 23:03 (UTC)

Latest Comments

okxa commented on 2021-07-18 21:52 (UTC) (edited on 2021-07-18 21:52 (UTC) by okxa)

I cannot seem to be able to compile this:

fatal: git upload-pack: not our ref 39e17e1c5c3db56fe9d0308af28be90f172e455e
fatal: remote error: upload-pack: not our ref 39e17e1c5c3db56fe9d0308af28be90f172e455e
Fetched in submodule path 'instruments', but it did not contain 39e17e1c5c3db56fe9d0308af28be90f172e455e. Direct fetching of that commit failed.

sediment commented on 2020-04-25 13:47 (UTC)

I believe that lash and fltk are optional dependencies, and should probably be marked up as such in the PKGBUILD. (Neither of them are dependencies for the regular, non-git zyn package.)

I was able to get it to compile without lash just by taking it out of the deps list in PKGBUILD. I seemed to get some trouble compiling without fltk, so that one may be more complicated. It seems that it should be possible, but I have to admit that at this point I'm out of my depth.

dvzrv commented on 2018-06-15 06:22 (UTC)

I've removed lash from [community]:

WoefulDerelict commented on 2016-08-10 01:37 (UTC)

habys: I get a similar output using makepkg when attempting to build 2.5.4.r119.g9a097e6 I am unsure why; however, I suspect this is due to upstream changes.

habys commented on 2016-08-10 01:27 (UTC)

Anyone see this error: -- Installing: /tmp/yaourt-tmp-luke/aur-zynaddsubfx-git/pkg/zynaddsubfx-git/usr/lib/lv2/ZynReverb.lv2/ZynReverb.ttl CMake Error at src/Plugin/ZynAddSubFX/cmake_install.cmake:36 (file): file INSTALL cannot find "/tmp/yaourt-tmp-luke/aur-zynaddsubfx-git/src/zynaddsubfx-git/build/src/Plugin/ZynAddSubFX/lv2/manifest.ttl". Call Stack (most recent call first): src/Plugin/cmake_install.cmake:44 (include) src/cmake_install.cmake:80 (include) cmake_install.cmake:70 (include) make: *** [Makefile:72: install] Error 1

Moxon commented on 2016-08-02 18:09 (UTC) (edited on 2016-08-02 18:10 (UTC) by Moxon)

WoefulDerelict: I am humbled by your efforts to recreate the bug. I checked my makepkg.conf and BUILDDIR is the only variable which has been changed by me. Even worse and probably embarassing for me: I cannot reproduce the error any more. I can only guess that it was some glitch in my system which went away either by rebooting or by updating the system - zynaddsubfx-git was just successfully compiled and installed on my machine. Thank you for taking care of this piece of software in arch, it enables me to make music (which probably only I like) with a fine soft synthesizer.

WoefulDerelict commented on 2016-07-21 01:30 (UTC) (edited on 2016-07-21 01:38 (UTC) by WoefulDerelict)

Moxon: That is, of course, your prerogative. Unfortunately I have been completely unable to reproduce the reported behaviour on a multitude of systems. The package builds fine in a clean test environment ( as well as on test boxes with nothing more than a pacstrap of base and base-devel: even when building in /tmp on machines with as little as 1GB of RAM. Not even yaourt misbehaves and it also builds in /tmp. If I parse the output you shared correctly your build isn't even managing to properly retrieve the sources. The fetch data is all off and it appears to be looking for the git repository is a very, very strange place '/var/cache/pacman/pkg/zynaddsubfx-git27501/zynaddsubfx-git/zynaddsubfx-git' This is definitely not the default location for package sources. If makepkg has a BUILDDIR of /tmp/makepkg the primary location it should be working with is '/tmp/makepkg/zynaddsubfx-git' along with the source, which by default is downloaded to the same directory the PKGBUILD resides in. If you have modified other variables in makepkg.conf like SRCDEST they could be responsible for altering the default behaviour and the root of your current issue. If there is not enough space to download the sources it could result in the errors you're experiencing. If you compare the output you provided with the following output from a healthy build you should notice that the git repo has more data than is being reported/retrieved on your system which would explain why it does not appear to be a valid repository when git attempts to work with it: it's incomplete. ==> Retrieving sources... -> Cloning zynaddsubfx-git git repo... Cloning into bare repository '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/zynaddsubfx-git'... remote: Counting objects: 20923, done. remote: Compressing objects: 100% (6615/6615), done. remote: Total 20923 (delta 17027), reused 18030 (delta 14292) Receiving objects: 100% (20923/20923), 6.33 MiB | 82.00 KiB/s, done. Resolving deltas: 100% (17027/17027), done. Checking connectivity... done. -> Downloading % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 1134k 100 1134k 0 0 616k 0 0:00:01 0:00:01 --:--:-- 616k ==> Validating source files with sha512sums... zynaddsubfx-git ... Skipped ... Passed ==> Extracting sources... -> Creating working copy of git repo... Cloning into 'zynaddsubfx-git'... done. ==> Starting prepare()... Already on 'master' Your branch is up-to-date with 'origin/master'. Submodule 'DPF' (git:// registered for path 'DPF' Submodule 'instruments' (git:// registered for path 'instruments' Submodule 'rtosc' ( registered for path 'rtosc' Cloning into '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/src/zynaddsubfx-git/DPF'... Cloning into '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/src/zynaddsubfx-git/instruments'... Cloning into '/home/llewelyn/ArchPackageSources/Workspace/zynaddsubfx-git/src/zynaddsubfx-git/rtosc'... Submodule path 'DPF': checked out '79dfcc97e4e153daec564774c418d68ca1130e59' Submodule path 'instruments': checked out 'fc0624067d980a36a3826ccdf6694c993c7d3862' Submodule path 'rtosc': checked out '0771cb1f29a68d13bb8ec00abaaafcb54cb1366e' One thing of which I am certain at this point, having conducted thorough build testing on multiple machines, is that the issue is specific to your system, likely the result of deviating from the standard distribution configuration, not this package.

Moxon commented on 2016-07-20 18:43 (UTC) (edited on 2016-07-20 18:45 (UTC) by Moxon)

Hm. I beg to differ. With 4.9GB on /tmp even zynaddsubfx should be able to compile. It is the only package which fails, all others from AUR work. Also the error occurs even before the compilation starts and does not hint towards a out of space error.

WoefulDerelict commented on 2016-07-18 18:41 (UTC)

Moxon: Unfortunately this problem exists not with any package or even in opting to use /tmp/makepkg as your BUILDDIR but between the keyboard and chair. If you had bothered to consult the documentation you would know that the default behaviour on Arch is that /tmp exists on tmpfs which is limited to half of the system memory ( The build is failing because your system does not have enough space in tmpfs to house the build. This limitation is one of the key reasons /tmp/makepkg is not used by default and why yaourt attracts the most negative feedback of any AUR helper as it attempts to build in tmpfs by default. You can solve this problem by either building outside of tmpfs or by adjusting the maximum size of your tmpfs by following the procedure on the tmpfs page of the Arch Wiki.

Moxon commented on 2016-07-18 14:12 (UTC)

This might be a problem with not just this package, but: If you set BUILDDIR in /etc/makepkg.conf to e.g. /tmp/makepkg, the build fails early with this error message: $ makepkg -sir ==> Making package: zynaddsubfx-git 2.5.4.r40.gd920f8b-1 (Sun Jul 17 14:17:38 CEST 2016) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Updating zynaddsubfx-git git repo... Fetching origin remote: Counting objects: 538, done. remote: Compressing objects: 100% (120/120), done. remote: Total 389 (delta 318), reused 329 (delta 269) Receiving objects: 100% (389/389), 77.59 KiB | 0 bytes/s, done. Resolving deltas: 100% (318/318), completed with 88 local objects. From git:// 731722e..5f420f5 master -> master * [new branch] unique_version -> unique_version -> Found ==> Validating source files with sha512sums... zynaddsubfx-git ... Skipped ... Passed ==> Extracting sources... -> Creating working copy of git repo... fatal: '/var/cache/pacman/pkg/zynaddsubfx-git27501/zynaddsubfx-git/zynaddsubfx-git' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ==> ERROR: Failure while updating working copy of git repo Aborting...

commented on 2015-04-08 01:58 (UTC)

I also hit the X11 linking error. Here's the ugly workaround I used to get it built: In zynaddsubfx-git/src/CMakeLists.txt add ${X11_LIBRARIES} beneath ${GUI_LIBRARIES} on line 371. Good luck!

cocreature commented on 2015-03-25 08:54 (UTC)

I'm getting the same error haby is getting.

habys commented on 2015-03-24 18:56 (UTC)

Some kinda linking errors with X11 trying to build today: libzynaddsubfx_core.a(Master.cpp.o): In function `memset': /usr/include/bits/string3.h:86: warning: memset used with constant zero length parameter; this could be due to transposed parameters /usr/bin/ld: UI/libzynaddsubfx_gui.a(MasterUI.cxx.o): undefined reference to symbol 'XCreateBitmapFromData' /usr/lib/ error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status src/CMakeFiles/zynaddsubfx.dir/build.make:95: recipe for target 'src/zynaddsubfx' failed make[2]: *** [src/zynaddsubfx] Error 1 CMakeFiles/Makefile2:1760: recipe for target 'src/CMakeFiles/zynaddsubfx.dir/all' failed make[1]: *** [src/CMakeFiles/zynaddsubfx.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... libzynaddsubfx_core.a(Master.cpp.o): In function `memset': /usr/include/bits/string3.h:86: warning: memset used with constant zero length parameter; this could be due to transposed parameters [100%] Built target zynaddsubfx_dssi Makefile:126: recipe for target 'all' failed make: *** [all] Error 2 ==> ERROR: A failure occurred in build(). Aborting...

Potomac commented on 2015-03-14 09:35 (UTC)

there is a problem with this package : the PKGBUILD needs to be rewritten, because the /usr/lib64 directory is used, and pacman doesn't want to install this package because there is a conflict directory with /usr/lib64 and the symbolic link "/usr/lib64", the solution is to add these lines in package() section in the PKGBUILD : # move files from /usr/lib64 to /usr/lib mkdir $pkgdir/usr/lib mv $pkgdir/usr/lib64/* $pkgdir/usr/lib rm -rf $pkgdir/usr/lib64

cocreature commented on 2014-09-06 20:07 (UTC)

Awesome, you finally did update the package thx. /usr/bin/ontroller and /usr/bin/splitter don't have the executable bit set, you should add that.

cocreature commented on 2014-09-04 08:13 (UTC)

@hollunder it hasn't been updated for 9 months, if you want to maintain it just file an orphan request.

hollunder commented on 2014-09-04 07:38 (UTC)

Speps, maintain or disown ffs.

seym commented on 2014-04-25 10:05 (UTC)

The file on sourceforge has change from to I tried to change in in PKGBUILD build (first time I do it, I suppose something is missing), but I got the followind error : /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/ référence indéfinie vers « pthread_key_create » /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/ référence indéfinie vers « pthread_once » /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/ référence indéfinie vers « pthread_getspecific » /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/ référence indéfinie vers « pthread_key_delete » /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/ référence indéfinie vers « pthread_setspecific » collect2: erreur: ld a retourné 1 code d'état d'exécution src/Tests/CMakeFiles/ADnoteTest.dir/build.make:95: recipe for target 'src/Tests/ADnoteTest' failed make[2]: *** [src/Tests/ADnoteTest] Error 1 CMakeFiles/Makefile2:1318: recipe for target 'src/Tests/CMakeFiles/ADnoteTest.dir/all' failed make[1]: *** [src/Tests/CMakeFiles/ADnoteTest.dir/all] Error 2 Makefile:126: recipe for target 'all' failed make: *** [all] Error 2

cocreature commented on 2013-12-14 10:38 (UTC)

So I created a pkgbuild using the new pkgver function which should work fine. Also the new gui is enabled during build. You can check it out here

svictor commented on 2013-11-28 14:37 (UTC)

Eventually managed to install it. - Change 1st source for "" md5sum is f282369eebc5cc7a7b242424177b9369 - at line 95 replace zynaddsubfxParameters by unsortedzynaddsubfxParameters_20131122 - mkdir src/zynaddsubfx-build/instruments/banks Strangely, I don't get the dark gui, although I have ntk installed and detected by the configure script. Following this thread, the new GUI should be default in git if ntk detected: But well, that's a different story I guess!

svictor commented on 2013-11-28 14:13 (UTC)

The first source file is now Once this is changed zafx builds fine, but then I get the following error: CMake Error at cmake_install.cmake:57 (FILE): file INSTALL cannot find "/home/victor/bin/yaourt-tmp-victor/aur-zynaddsubfx-git/src/zynaddsubfx-build/instruments/banks". Makefile:65: recipe for target 'install' failed make: *** [install] Error 1 ==> ERROR: A failure occurred in package(). Aborting...

GuestOne commented on 2012-07-09 08:27 (UTC)

This package is not updated anymore?

speps commented on 2011-11-30 17:10 (UTC)

Bug closed, now mxml builds shared libs too. Package updated to depend on mxml.

speps commented on 2011-11-28 02:32 (UTC)

@bjonnh Thanks for reporting, package updated. Btw the issue seems to come out from the mxml build. I have opened a bug report here > You can build your own mxml with the attached PKGBUILD >

bjonnh commented on 2011-11-27 11:15 (UTC)

Got another error about a missing -fPIC at the linking stage

bjonnh commented on 2011-11-27 11:00 (UTC)

The Parameters zip changed. You have to edit PKGBUILD with these parameters: source=("" "" "" "$_p-jack.desktop" "$_p-alsa.desktop" "$_p.svg") md5sums=('7d960c52c31320135a2d2a95f37f369e' '7d7974e877b818fb562cc870d5886fc5' '271ca88e262d3d3378f8d695a7151d1b' '137baa3407ca0a9ce3d7f4644723978f' '9825fcb4efc641ce1806d58cf1389aa9' '6f7e9c3ce3947088a10c99c46a65431f')

ottoshmidt commented on 2011-07-11 23:52 (UTC)

this appears to work.. will stick to it.

speps commented on 2011-07-10 22:14 (UTC)

@ottoshmidt You have to select input and output backend in File > Nio Settings to choose between alsa and jack Or you can start with the -I {jack,alsa} -O {jack,alsa} flags to choose at startup (-I midi for input && -O audio for output) Btw I've just included a desktop file for each backend: zynaddsubfx-alsa.desktop > zynaddsubfx -I alsa -O alsa zynaddsubfx-jack.desktop > zynaddsubfx -I jack -O jack Remember you can combine inputs and outputs (-I alsa -I jack | -I jack -O alsa) Also now the old stable release ( 2.4.1 ) builds again. Just choose ;)

ottoshmidt commented on 2011-07-10 10:43 (UTC)

installed ok but when I run it doesn't appear in the Jack connections :( neither output nor input pane.