Is there a sense to fork old version of jalv that support gtk2 and use it until there are enough plugins switched to gtk3?
1 Like
These are the dilemas that we face… GTK2 was removed from jalv two years ago. We have already forked jalv to provide some extra Zynthian integration. We want to benefit from recent updates and also contribute upstream. This all gets more complex if you are forked from such an old point. I did compile the two year old version and it ran with the GTK UI but I did not do the extra work of merging it with our fork to integrate with Zynthian.
Today I have been trying to get pipewire working but failing!
3 Likes
lv2.json (30.7 KB)
This is a json file with a dictionary of each type of plugin indexing the plugin URIs that use that type of toolkit. You could use this python script to get some data from it:
import json
with open("lv2.json") as f:
ui_dict = json.load(f)
# Show quantity of plugins providing each UI toolkit type
for ui_type,plugins in ui_dict.items():
print(f"{ui_type}: {len(plugins)}")
# Show plugins providing GTK2 UI
for plugin in ui_dict['http://lv2plug.in/ns/extensions/ui#GtkUI']:
plugin
It is probably more useful to give you the raw data than fill this post with a long list of plugin URIs.
1 Like
I had a play with pipewire and got jalv hosting synthv1 with USB MIDI input and audio output to the speakers. I added a filter-chain module hosting TAL Reverb, i.e. native within pipewire, not with jalv. This all worked but was challenging to make work reliably. pw-cli was used to create the filter-chain (using load-module libpipewire-module-filter-chain... and perform some routing (using the create-link and destroy [object-id] commands). I needed to run wireplumber (session manager) before physical i/o was available and there seems to be the need for some manual config before everything is available in a recognisable way. The unload-module command is not yet implemented so you can’t (easily) remove a module (like a filter chain) nor does it seem you can modify filter chain content.
Some plugins would not load (with no useful explaination), e.g. helm. Sometimes pw-cli crashed although less so as I got used to the required parameters so maybe there is a simple bug that I triggered that could be resolved. Objects created by and instance of pw-cli are destroyed when it closes. Some routes are made automatically. (This may be configurable?) pw-cli only seems to allows listing of all objects which makes it challenging to identify individual entities of interest in the graph. There are several references to each object. It looks like there is an object id that is reused when an object is destroyed, a object.serial that may increment without being reused and module.id. Adding a filter-chain reports a module number that does not tally with any of these references! It can be confusing which of these should be used in commands. (This is likely due to my ignorance having not read all the docs.)
Many object seem to have audio inputs and outputs plus some monitor outputs which appear to mimic the object’s inputs. I am not sure of the monitor purpose but it initially adds to confusion due to sheer quantity of ports.
Links (connections between objects) are objects that can be created and destroyed in the same way as the processing objects themselves. A filter chain can contain several plugins. I have not worked out how they are interconnected within the filter chain. A filter-chain has input and output ports as well as input and output streams.
I had to use pw-jack to launch jalv. I did not find the configuration that enables jack emulation globally. I did not find the configuration to run in “pro” mode.
I did see the plugin parameters within the PipeWire:Interface:Node/3 object (as well as a lot of internal / default pipewire params) I found you could set the value with something like this: s 100 Props { params = [ "Flanger:feedback" 0.6 ] } where the flanger object id is 100 and read it with e 100 Props.
There is an API so these commands could probably be wrapped in a direct interface (rather than rely on the pw-cli app).
So, there is the ability to host LV2 within the pipewire graph and control its parameters. This does not seem to work for all LV2. pw-cli is prone to crashing and getting it all working and configured is challenging. I don’t think it is quite ready for production but it is an interesting option to investigate further.
I know this post is more about pipewire than hosting LV2 but @pau suggested pipewire may offer a solution so this is some initial investigation into that possibility.
[Edit] I just tried hosting AIDA-X in a pipewire filter-chain and its file selection parameters are not exposed… so that doesn’t help us!!!
4 Likes
Thank you @riban for this extensive research.
This is unclear to me:
From man page:
pw-jack - Use PipeWire instead of JACK
does that mean:
- you didn’t manage to start jack,
- or jalv won’t work so long jackd and pipewire are both running
- or …
Pipewire has a jack compatibility layer. It should be possible to enable it globally but I didn’t manage to do that. pw-jack can be used to launch an application (like jalv) and present pipewire as a jack compatible sound server. So I stopped jack throughout my tests, used pipewire as the sound server and used pw-jack to allow jalv to connect to pipewire.
get it 
I think I should have read more carefully the man page of pw-jack:
This results in JACK clients (as jalv) being redirected to PipeWire.
I have pipewire-jack-audio-connection-kit installed. I use Fedora.
This package provides a JACK implementation based on PipeWire.
I have been able to patch a Midas M32 with all its channels, an XAir and use Carla, jalv, calf, qtractor, ardour… As a user I’ve been very happy but I haven dug as @riban trying to solve all our special cases.
I ran all jack applications, even patch applications and I can see the same result in Carla as I do in qpwgraph and helvum (patch apps)
I can use all the plugins from calf, easy effects, etc. I can see the GUI.
I am an advanced user but not a developer, sorry if I can’t help miore, I’d love to 
You don’t use jack any more. If you use Debian it’'s very well explained here.