Of course.
I mean, you could show all available ALSA devices in the audio in/out view and when a device gets checked (routed from any chain) , the alsa-jack bridge for it is started. In the other side, when the alsa-jack bridge device has no connections, stop the alsa-jack bridge for the device.
I know the idea is slowly penetrating your mind and probably you will wake-up in the middle of the night, sweating and anxious … it’s just what you, as a user, would expect 
Good night!
My friend, I was in your head yesterday when I implemented that but had to undo the change because we need to avoid scanning for new devices (to show all alsa devices available) if the user wants to avoid the extra overhead. So, I reinstated the enable hotplug option and, when this is checked, any detected devices are available to disable.
We could limit the scan for new devices to when the audio in/out view is shown but I would like it to be more dynamic than that.
It gets better if I put/append into Webconf Display (advanced) Config
dtoverlay=vc4-kms-v3d-pi5,noaudio
dtparam=audio=off
force_pwm_open=0
If i delete the dtparam=audio=on from config.txt, it will be restored as soon as any Save in Webconf is asserted.
With adding dtparam=audio=off in Display Config, ths will be the one of the last lines of config txt, and so it will probably have priority.
Edit: force_pwm_open=-1 has no adverse effect. In case any kind of software-pwm is meant, this would release additional resources.
Ed2: force_pwm_open=0 is the same, but makes the value not show in vcgencmd get_config int, maybe lesser is more. Documentation is lacking on RPi side.
Hi @riban ,
In MOD-UI only the capture 1 and 2 and hardware playback 1 and 2 are accessible. Is this intended? Would be nice if also here all inputs and outputs are accessible. With the virtual cords, in/ouputs can then be selected so no Zynthian GUI impact… 
Cheers and thanks again,
Maarten
And we’re quite sure this is easier than pipewire?
I think the relevant question is whether Pipewire can achieve the same or better latency than JACK. I don’t know the answer to that question.
Well my friend @Baggypants, I have delivered hot-plug jack whilst we await your pipewire offering. 
Regarding mod-ui, we expose it as a stereo in/out processor. I’m not sure how tricky it would be to dynamically change this and we want to ideally move away from it. Zynthian can do almost all of its functions natively.
@riban ,
I am curious, because perhaps MOD-UI is not existing in the future anymore…
and I love this this “plugin”, because it reduces the processor load of a plugin chain:
Is this possible in Zynthian alone?
And what about parallel effects in a chain? (Perhaps possible with several chains on zynthian?)
Cheers from a very happy using but now worried inhabitant of the zynthian universe.
Dear worried of zynthiverse,
Your concerns may be reduced by this info…
Any LV2 hosted in mod-ui on zynthian should already be available to add in a normal chain.
You can have as many LV2 plugins in a chain as you want. You can move them up/down the chain to position them in series or parallel. See the chain options menu.
Hahaha @riban
Oh… luckily… no more tranquilizers then…
I wonder how this works, I have to dive into this. Now I cannot envision how to have for instance 4 plugins parallel in series with a serial plugin chain before and after… But I wil find out
Thanks again,
Enjoy your evening,
Maarten
It builds up from the submenus of the chain in the Chain options…
It’s not a particular slick operation in itself but as with so much that has been refined, the mixer audio sub system has undergone much work to make this sort of context efficient.
Pretty will come later…
The GUI on MOD UI was a work of beauty but all really just broke down into a similar structure of connections within the jack universe, so there shouldn’t be anything in the MOD file that can’t be done, and if there is I’m sure people would like to hear about it.
I don’t know if there is any kind of tooling available to transfer patches. It should only be a one way, one time operation.
Hi @wyleu
Thanks! … Serial connections are clear… but the parallel part I have to try …
Enjoy your evening (England I suppose…)
Cheers,
Maarten
YEp that’s what I’m looking for now . .
Be nice if after adding a chain it didn’t return to the mixer page. You have to navigate back in to build something semi involved.
The chain is represented in a kind of tree like structure. In the example @wyleu showed, there is a synth processor (Helm), followed by 4 audio processors in parallel (GxEcho-Stereo, MDA Delay, Modulay, Regrader) followed by an audio processor in series (GxTubeDelay) followed by an audio processor in series (the infamous beng delay) then the chain reaches the mixer strip indicated by the FADER and then it goes to an audio processor (Regrader) and then another audio process in series (MDA Delay).
The indentation shows whether processors are in parallel or series. All in parallel have the same indetation. The thick lines show audio path and thin lines show the MIDI path.
As @wyleu says, this isn’t very pretty and we have ideas to improve this. (Someone was going to look at that…) But it is functional.
When you move a processor it moves to the next slot in the chain, adding a slot if it is moving from a parallel position so that you can change the processor’s postion from parallel to series to parallel…
It would be nice to have a more graphical represenation of this and I would love for someone to design that. I don’t have the time.
Thanks a lot!
Unfortunately I am just a user not a skilled programmer… (Only did some modeling with matlab)
Cheers and still… eh do enjoy the evening guys!
Maarten
No problem. There are those that are around here…
Probably watching their code used is as close to pleasure and real life as they ever get. . .
@riban and I talked about developing a dedicated screen for fx management that is more similar to fractal, helix, and other similar devices where all fxs are presented as blocks with links and where you can enable/disable, move around and when selected have their parameters displayed instead of using existing screen where all parameters of all fxs are listed inside a single screen and where you can’t disable fx if it does not have parameter to do so.
I planned to do that but never found a time.
That screen would fully make mod-ui obsolete.
Hi @stojos
GREAT!!
i am (again) looking forward to this interface!!
I am very willing to be a tester!
Cheers!
Maarten
Probably will never happen as I like my zynth working, but I’m pretty sure the test I did had less cpu overhead than what you’re doing. And also has better controls regarding filtering devices.
