saving plugin presets doesnt work
protectorateindustrial opened this issue · 10 comments
Saving plugin presets isnt working. Presets disappear after rebooting.
There is a quirk in MOD-UI where it's not enough to just save a preset (aka Snapshot), you must also then save the pedalboard. Please try saving the pedalboard after saving a Snapshot to see if that was your issue.
I dont mean snapshots, but presets of individual plugins.
EDIT: I tested saving a preset of a pedal and saved the pedalboard and booted. The saved preset disappeared from the user presets column in webgui.
Thanks for clarifying. Yes, I see that behavior as well.
From my investigation, I see that presets are being saved into ~/data/.lv2 instead of ~/.lv2 Not sure why MOD-UI is doing that, but I'll look into it.
Here is a interim workaround solution:
After a session that included any preset saves (no need to save the pedalboard), then via ssh:
cp -r ~/data/.lv2/* ~/.lv2
sudo systemctl restart jack
Once MOD restarts you should see your preset(s) and they should persist thru reboots. You'll need to repeat the workaround though after any session that includes a preset change.
I'll keep this issue open, for updates and hopefully a real fix eventually
I changed
Environment=HOME=/home/pistomp/data
to
Environment=HOME=/home/pistomp
in the mod-ui.service. Now the presets work and pedalboards are also stored in /home/pistomp/.pedalboards instead of /home/pistomp/data/.pedalboards. I dont know what else this could affect and possibly cause instability, nor have I tested this thoroughtly, but this seems to work initally.
Nice idea. That does seem to work if you move your .pedalboards location. I don't see any issues with that.
Unfortunately, MOD appears to use the HOME env var instead of the LV2_PEDALBOARDS_DIR variable for pedalboards.
I'm not ready to just move the pedalboard dir to home instead the data dir. That creates a non backward compatible change. I'll try to devise a fix that would not create another issue. I'll post back here eventually. For now, you have a workaround.
Thanks for your help. I tested things a bit and other than the pedalboard location, I didn`t find any problems. I did find that couple of the dragonfly reverbs and the ir loaders crash mod instanty @ 96khz and that veja cabinet simulator cant handle more than one instance at time withput crashing. MetalTone also doesnt work at 96khz, but that can be fixed by downloading and building the latest version from brummers git.
Part of the problem with 96khz is that a lot of the plugin devs for Mod are working around 48khz, so quite a few of the plugins are hardwired to 48khz. Is there a particular reason why you’re running at 96khz instead of 48khz? The audio quality gain is very slight and not really worth the extreme overhead. You might be able to only add one simulator plugin and one reverb at 96khz, whereas I’m running 2 amp sims, 2 ir cabs and 2 ir reverbs and only sitting at 72%. Might be worth dropping down and experimenting. Another thing to keep in mind is that most of the convolution based plugins(ir cabs, ir reverb and the amp profiler) all use background processing, so using a higher bit rate is taxing the dsp load and cpu load. Just some thoughts
Yeah, 96khz isnt really feasable for IR stuff it looks like. The older non Ir based plugins ran fine at 96khz and sounded a bit better, but I guess if I wanna use the newer stuff I'll stick to 48khz. :)
Yes, most of the new plugins will resample to 48khz, which adds even more overhead. You’re probably getting some more highs through with 96khz, but it’s negligible for most of the newer plugins due to the resampling. I’ve compared the amp profiler and cab ir to a helix and the only major difference was the noise floor, being slightly better on the helix.
This issue fixed by commit: dc4a2c0
Workaround no longer required. User plugin presets should persist through reboots.