Are others able to work with user patches/presets? In my experience, they work well until reboot. After reboot, the user area does show patches you’ve created but it’s impossible to load them (tried on macOS and iOS). Something purple shows in the background, but the currently-loaded patch stays the same.
At the same time, modified patches do show up in a pedalboard. So a cumbersome workaround would be to save each patch to its own pedalboard.
The patches show up as their own .lv2 folders with a simplified structure (only manifest.ttl and presets.ttl; no <plugin_name>.so or <plugin_name>.ttl ). The folder name might be slightly different (for instance, JX10-<patch_name>.lv2 instead of mod-mda-JX10.lv2). Adding and deleting these folders does seem to have the expected effect but doesn’t solve (or create) the problem on its own.
Tried with a plain vanilla install, using JX-10. Also tried expanding the filesystem using raspi-config.
The problem first manifested itself for me (and became more prominent) with TAL-NoiseMaker. Several cool presets with that plugin, with quite a few possible tweaks. Saving those patches to the user area and selecting them can be very helpful, especially while making selections or tweaks. For instance, some of them sound really nice but cause xruns upon loading. Other presets require a few tweaks to work with my setup (say, enabling pitchbend). With a proper set of tweaked patches, that TAL NoiseMaker plugin can really make the pisound into a valuable piece of gear for live use. (And thanks again to @tomerb for leading us to the Zynthian Collection.)
For JX-10 and other plugins, it’s less of an issue for me because fewer patches really suit my needs.
Still, it’s a problem which can likely be fixed easily.
It might be useful to check if there’s any errors or warnings logged to the system logs during the critical times like saving or loading presets, using commands like:
Here goes. Saved “Stately” (a tweaked version of “Rubber Bass ZF” in JX-10) during one session. Rebooted. Now, can’t select it in the user presets and the mod-ui journal does show that there’s a difference. Saved some others during the same session and they’re fine. (Meaning, they’re fine during the session, but the same problem happens with them at reboot.) Journal.zip (1.9 KB)
Hmm, can’t tell what’s going wrong from the information logged… Next steps could be trying to add custom print statements around the relevant places in the mod’s python scripts, or inspecting the /usr/local/modep/.lv2/JX10-Rubber_Bass_ZF_stately_.lv2/Rubber_Bass_ZF_stately_.ttl file.
Others aren’t encountering the problem? Fully reproducible on my setup which is very close to plain vanilla. Might try again with the original modep.zipimage.
Oh, and speaking of plain vanilla… Had never used the modep command to set things up. Maybe that’ll solve things!
Interesting that the image worked from the start. We’ll find out if the install script makes a difference. Does sound like it’s updating a few things (after plugging my Pi into Ethernet).
…
Same issue after doing modep. Was worth a try.
…
Confirmed that the problem persists after a clean install and using the modep command (at least, after installing everything).
So, to reiterate…
Clean MODEP install from the card image.
The “Piano” pedalboard is loaded, so click on the gear icon to change patches.
Save a patch under a new name (just added ‘1’ to the default name).
Reboot.
Can’t load that new user patch.
Dunno how difficult it’d be to solve this bug but it does make it more difficult to use MODEP.
The reason it’s more than inconvenient is that there are likely occasions when loading different patches from different plugins makes a whole lot of sense. Saving things in a new pedalboard is ok but it’s really not flexible. Some of these tweaks are very quick, at least in a desktop browser. But they don’t work very well on iOS.
Might work around some of these things by sending MIDI to everything, or maybe OSC (haven’t tried anything OSC-related on the pisound, yet, but did do so in the past).
Sorry for necroing this topic, but yeah I reproduced this issue just now.
I was trying to convert some DX7 sysex into lv2 preset files so that I can load them from Dexed, and I was wondering why they weren’t getting listed in the UI. As @Enkerli describes, you can save your own patch, and it is visible/available to select from the plugin options, but once mod-ui is restarted they aren’t available to use anymore.
The UI is clearly able to write the files out, are owned by modep:modep with chmod 644… if we can squash this bug, man we can potentially enable MODEP users to load patches from the entire Blackwinny collection. A huge payoff!
I’ll take some time tomorrow to investigate this bug. @Giedrius if you know where in the src user patches are being loaded, that would be useful.
Update:
If you copy your preset data into the main lv2 directory (in this case, /usr/modep/lv2), and then restart mod-ui, you can then access the preset successfully.
That reveals a workaround, but ideally you wouldn’t want to clog up the main lv2 directory with your presets… and that doesn’t solve saving and reloading presets in the UI between restarts without manual intervention. I’ll keep looking at this.
I’ll document the workaround. @Giedrius I warn it’s a little dirty, but it gives us something to think about.
Steps
Add modep to the patch UNIX group. usermod -a -G patch modep
Grant group write permissions to the lv2 directory. chmod 775 /usr/modep/lv2
Modify method preset_save_new() in mod/host.py, replacing all instances of ~/.lv2 with /usr/modep/lv2.
Result
You can now save and recall user presets.
/usr/modep/lv2 contains both plugins and presets.
Again, you’re adding a lot of clutter to /usr/modep/lv2, but ¯\_(ツ)_/¯ this bug is 3.5yrs old and at least we now have a workaround while the root cause is found and addressed!
(final thought: I imagine this isn’t broken for Mod devices… I wonder if they fixed this upstream?)
