I made a post asking for pitch shifting in the form of a plugin I could adjust in real time, and was pointed towards the LV2 version of Rubber Band. I installed it through Mint’s Synaptic Package Manager and four LV2 plugins installed and appeared in Ardour: Rubber Band Stereo Pitch Shifter, Rubber Band R3 Stereo Pitch Shifter, and the mono equivalents of each.
I didn’t know what the R3 variants were, but apparently they’re more advanced versions of the algorithm that use more CPU but produce a better result. I assume this is what Ardour uses for it’s native implementation of Rubber Band, because comparing the same region pitch shifted by it vs the LV2 plugin, it’s obvious the former is better.
Thing is, trying to add the R3 variant to my session fails, and “[ERROR]: LV2: Failed to instantiate plugin http://breakfastquay.com/rdf/lv2-rubberband#r3stereo” is printed in the log. The popup window just says that the plugin could not be loaded.
I don’t know why a URL would be the issue here? I assume I’m missing something, but why’s it there to begin with? Any advice is appreciated. Thanks!
That is just part of how LV2 packages get unique identities, it identifies that particular plugin.
My first guess is that the plugin is not statically compiled, and is attempting to load a rubberband library which is different than the library used by Ardour. Just a guess, but that is a somewhat common problem with plugins.
I see…that’s weird because I installed the plugin separately and I assume it’s meant to be standalone. It’s like it’s reporting there’s a version of itself installed that actually isn’t.
If you go to where the plugin LV2 directory is located, you can find that path in the ttl file. Like I wrote earlier, it is just part of how LV2 plugins are identified to make sure they are unique.
Plugins should be compiled statically and not rely on dynamically loaded libraries. That may not be the cause of the problem, but even on my Fedora system, which generally tries to get the audio software right, it looks like the plugin is not compiled statically:
You can see from the ldd output that it relies on system libraries for libfftw3 and libsamplerate.
I think maybe libstdc++, libm, and libgcc are OK, but I don’t remember for sure, I always have to have @x42 explain to me again which system libraries are actually OK to link. Maybe just libc and libX11.
For sure the dynamically linked libfftw3 and libsamplerate look wrong to me. It would be interesting to compare the output of ldd from the mint build of the plugin which you installed.
At least you understand some of what this means lol. I assume this is a problem with some dependencies, but not sure what to do with this information, myself.
As Robin pointed out above, the indication that the plugin uses libsamplerate and libfftw3 from the system installation (what ldd indicates with the arrow => pointing to the location of the system version) likely conflicts with the versions in use by Ardour (from ardour.org).
If you were using the version of Ardour compiled by Mint, then it would presumably be using those same system versions and so would not have a conflict with the plugin.
The short of it is that the plugin is not compiled properly, and since both the Mint and Fedora versions are essentially the same in that regard it is probably how the upstream project is configured.
I took a quick look at the upstream and it uses meson for building, which I am not familiar with.
Ideally someone could figure out how to modify the meson settings to build a personal statically linked version of the plugin, and also submit the changes upstream so that everyone would get the benefit.
I’m not sure where that leaves you in the short term, since the plugin is just not usable with the ardour.org build as it currently stands.
The version I have installed turned out to be 4.0.0 (from the Fedora repository).
Even though it has dynamically linked libfftw3 and libsamplerate as noted above, it was able to be loaded and operate properly in Ardour 8.12 from ardour.org.
However I still don’t like having the dynamically linked libraries, so this is how you can recompile to have a fully static plugin:
(I would recommend first removing your distribution version to make sure there is no confusion about which plugin is being loaded by Ardour)
Get the source code from this link: https://breakfastquay.com/files/releases/rubberband-4.0.0.tar.bz2
Untar the source (tar -xjf rubberband-4.0.0.tar.bz2) which will unpack the files into a new directory named rubberband-4.0.0.
Change to that new directory and run the meson command with these options (side note: I assume that you can use your distribution package manager to make sure meson, gcc, etc. development tools are installed). meson setup build -Dfft=builtin -Dresampler=builtin -Djni=disabled -Dladspa=disabled -Dvamp=disabled -Dcmdline=disabled -Dtests=disabled ninja -C build
Assuming the build completes with no errors, run these commands to copy the lv2 files to your local lv2 folder (still from within the rubberband-4.0.0 directory): cp -r ./ladspa-lv2/rubberband.lv2/ ~/.lv2/ cp build/lv2-rubberband.so ~/.lv2/rubberband.lv2/
This is what I ended up with, I don’t think any of these libraries are particularly problematic to have linked:
$ ldd ./.lv2/rubberband.lv2/lv2-rubberband.so
linux-vdso.so.1 (0x00007fc192452000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fc192000000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc1922aa000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc19227e000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc191e0e000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc192454000)