Change:
sha256 = "sha256-39pvfcg4fvf7DAbAPzEHA1ja1LFL6r88nEwNYwaDC8w="; }; }; <del> in stdenv.mkDerivation rec { </del> <ins> in multiStdenv.mkDerivation rec { </ins> pname = "yabridge"; <del> version = "3.3.1"; </del> <ins> version = "3.5.2"; </ins> # NOTE: Also update yabridgectl's cargoHash when this is updated src = fetchFromGitHub { owner = "robbert-vdh"; repo = pname; rev = version; <del> hash = "sha256-3B+6YuCWVJljqdyGpePjPf5JDwLSWFNgOCeLt8e4mO8="; </del> <ins> hash = "sha256-SLiksc8lQo2A5sefKbcaJyhi8vPdp2p2Jbc7bvM0sDw="; </ins> }; # Unpack subproject sources

Discussion:
The current version of doesn't build support for the bitbridge that allows for running 32 bit VST plugins. Information on building that is on the . Basically, what's necessary is to make sure that the 32 bit versions of and are installed, and adding a meson flag. It didn't end up being that simple when I tried adding it myself by just adding the 32 bit dependencies to buildInputs and the meson flag; I got a vague error about meson being unable to find boost_filesystem. paging the maintainer of the package:
Attached are my modifications to the current yabridge definition. It is very hacky, but it seems to build... all up until it gets to the part where it links stuff. There, ld fails (see attached error log).
I spent a lot of time trying to get this to work, but I couldn't find any way to specify both the 32bit and 64bit version of boost in a build because of There probably is a hacky way to work around it, but I couldn't find how. I decided to give up on it until is fixed, but I would be happy to accept a workaround if you find one.
It looks like that linking error is the same problem I was running into. The build would only ever pick up either the 32bit boost or the 64bit one, but not both. I couldn't find a way to specify the right one per-architecture. I also thought of trying to combine the 32bit & 64bit builds after building them separately, but the project fails to compile as 32bit, because it makes the assumption that the default build will be 64bit.
Hmm. An idea i haven't tried yet is trying to patch one of the release binaries. Might be a little easier than trying to wrangle meson, at least until that issue gets fixed.
Complete crackpot idea; since the 32 bit stuff that gets built are just binaries that yabridgectl looks for in $PATH (i think), maybe it's possible to just take them from the prebuilt binaries and patch them? I'll try this when i get the chance.

EDIT: this idea was as terrible as it sounds, and the prebuilt binaries only worked through steam-run (presumably because they were compiled with hardcoded FHS paths)
Sorry to leave so many comments in a row, but I got it working and pretty much no ugly hacks too. I'll just paste my definition verbatim. Pretty much all i did was replace with (unsure if necessary, probably is), add the bitbridge flag, and replace all references to with (this was the reason for the linking issues at the end). Then i just a wildcard to the installPhase to get the 32 bit stuff in $out/bin. There are a few lines where I don't know if they're actually necessary; once it worked i stopped testing. I'm also unsure of how to handle referring to pkgsi686Linux, or if there's even a better/more specific way rather than just including pkgsi686Linux as an input. EDIT: I can also open a PR tomorrow if these changes look fine.