Expand obxd window 
So this has fixed it for you? You now have the naitive GUI for each engine?
Ok. I have seen the light now. I was looking for a distinct application that acted as a general jalv UI for all currently running jalv instances, not in the drop down menus of the individual engines …
Yep, it’s there, can save lv2 patches the appropriate directory just as @jofemodo said.
This also explains what I though was a memory lapse; I seemed to remember a while ago for instance obxd having a save menu but it was set to save in a different place, and I was assuming it was some internal format that could only be loaded by the engine itself. I didn’t realize that was actually jalv providing that function.
Great stuff at any rate - this goes a very long way to saving individual patches, in fact it accomplishes it, even if it does require VNC access.
I’m guessing the secret is having the right version of jalv, coupled with the setting up of the appropriate directory? EDIT: Yes, just like for zynaddsubfx it’s a question of setting the CWD properly before starting it. Sweet.
I wonder if jalv could be coerced into producing an .lv2 file by telling it somehow, without actually accessing the dropdown menu. Then the Zynthian UI could do that.
Yes. It’s in my list from a long time ago. You can be sure it will be done sooner than later …
Regards!
Jalv does not support saving presets from the console so we may need to modify it. Jalv is really only a technology demonstration tool and isn’t designed to be used for production but it works nicely and has provided a good and stable host for LV2 to Zynthian. It would be great to write our won LV2 host, maybe derived from jalv codebase and maybe the changes we need to apply to implement preset management might support such activity. Of course that is time consuming so we need to identify the right cost / benefit ratio.
1 Like
That would be a great addition. LV2 preset management is so limited.
It does seem though that at least jalv.gtk supports saving presets from a dropdown menu, so the function is there, it “just” needs to be accessed in another manner. Sure, forking a project and maintaining it incurs a cost itself in terms of resources so I fully understand the concern. I get the impression @jofemodo is on to something though.
BTW, and slightly off topic, when switching to the testing branch, I noticed that when loading one of my snapshots that some of the layers made it through to the new Audio Mixer UI. Has some of the work on migrating pre-audio-mixer snapshots been started then?
This functionality is implemented in jalv.gtk source code but not in jalv so isn’t available when running without GUI or via console access to jalv gtk (IIRC). Of course the code is there if we want to fork and refactor it into both applications.
Yes, better preset management is on the roadmap. Watch this space…
2 Likes
Synthpod is a client/server lv2 host.
ORRRRRRR
mod-host which has an obvious preset-save option right there on the page.
1 Like
He may have a good point here! IF mod-host is sufficiently stable with sufficiently low overhead it may be a suitable host. Many users already run it as part of mod-ui so it is already there but I’m not sure how much work there would be to present plugins’ naitive UI. I will take a look at both these options. (Synthpod is currently not compiling due to a dependancy issue.)
[Edit] The reason that synthpod won’t compile on zynthian is because it depends on a later verson of vterm (and possibly others - synthbox is heavy on dependancies). I am compiling it on a RPi 400 running 64-but Bullseye to see what it offers. It may be a contender for the next stable which may be based on Bullseye. I think there may be too much work to do to add naitive UI to mod-host but let’s see what the best solution is. I would like to be able to launch the naitive UI separate from the core LV2 which allows more granular control over things. There are many options which I continue to investigate…
Why not extend jalv?
Jalv with gui can only save at the moment, and only in one bank.
As a user, I would like to be able to save, load, delete and rename individual sounds,
if possible in different banks, okay sorting presets would not be bad either.
1 Like
Yep! Looking at it now. It shouldn’t be too tricky. Can implement in each jalv variant for now and consider deriving a common version later.
1 Like
I totally agree with extending Jalv. It has been done in the past and most of the changes are now merged upstream. @drobilla is a friendly guy!
@riban , please, fork from our jalv repo:
I think there is some minor fix that is now merged upstream. After implementing this, we could PR upstream again.
Ahhh! And try to figure a mechanism for getting feedback when a parameter is modified from the native gui 
Regards!
1 Like
Sorry, this may not be relevant, I didn’t read the whole topic.
at the beginning of the vnc server implementation, I remember (maybe I dreamed) that we could tweak with all the lv2s, the gui-less lv2 was just replaced by generic guis with the different parameters. this way we could save presets for all lv2 synths or effects. can we just put this functionality back? could this be a temporary solution?
Give me a few days. It might be more satisfying to implement what we want than to spend time reverting to a suboptimal implementation. We can have that in our back pocket in case we find it takes too long to implement the right solution.
2 Likes
Just to really trip you up should Zynseq sequences store at layer level rather than one singleton…?
Is that related to this topic? We are discussing saving synth patches, specifically LV2 presets.
I was surprised to not find a feature request in GitHub for this feature. I think it has been discussed many times and certainly desired by many. I have added feature request #614. Please take a look and comment. I have suggested how it might be implemented in the Zynthian UI - basically add a context menu to the preset list by bold press of SELECT button.
3 Likes
Terrific.! This could also be a valuable addition for linux in general.
I was surprised to not find a feature request in GitHub for this feature. I think it has been discussed many times and certainly desired by many.
I’m pretty sure you already opened a issue for this some time ago
Regards,