I don’t know if this should be reported at a bug, so I think I’ll ask the experts first.
I’ve been working on a project for some days now and have exported the project about 10 times during that time. Now, I suddenly can’t export.
The Export window opens and 704 bytes are written to the wave file and then nothing else happens.
The Export window stays open, but the file size does not increase and the progress bar does not move.
A separate issue is that I have 2 midi tracks with Helm (one is a copy of the other) and every time I start Ardour, I have to get the sound I want to use again.
This could of course be Helm-related and not Ardour.
That used to be an issue with JACK on some Linux distributions (Ubuntu 14.xx and 16.xx were affected) – jack won’t enter ‘freewheeling’ (faster than realtime) processing for Ardour to export.
In some cases restarting jack helped, another option is to not use JACK but ardour’s built-in ALSA backend.
Hi Robin,
Huh… That’s really weird, today it will export. I guess a reboot did the trick.
I’m on version 5.12 on Ubuntu Studio with KX repos.
My Helm is the latest version, I think 3.0.0.
It sounds a little like that issue, but he uses much older versions and I don’t lose modulation, but the sound preset.
I was just testing Helm a little for the first time, and I’m also seeing issues when re-opening files. Seemed like a lot of the settings were just getting garbled. I played around some, tried switching to the VST version (which didn’t appear to help), back to LV2 again, and at some point it apparently started loading correctly again… I have no idea how to reproduce the bug, since right now it seems to be working correctly and I don’t know when/how it started in the first place…
EDIT: oh yeah, I’m on Debian testing, downloaded the latest (0.9.0) .deb installer for Helm from its website.
EDIT 2: Also definitely seemed like there was more going on than just the modulation connections being lost, as described in the linked bug report (which supposedly should have been fixed a long time ago anyway). Seemed more like the modulation (and possibly other) settings just being garbled…
OK, I was doing some more testing with Helm, just messing around with presets and parameters, and it happened again. After re-opening the project, some of the parameters were messed up. (Almost like it was loading the parameters of an earlier state, belonging to a different preset, and not the most recently saved? I dunno, that’s speculation.) After deleting the plugin and inserting it again, it once again seems to function correctly. (But of course I’ve lost the previous state of the plugin when I delete it.)
I still don’t know how to reproduce this bug, nor do I know if it’s a) related to the problem zenseidk was describing in the original post, or b) if the bug is with Helm or Ardour… The fact that this has happened to me twice now in a relatively short period of trying out the plugin is somewhat worrying, though…
This very error made me go mad today. I use a project with three instances of Helm, so three MIDI tracks that use Helm. When I restart Ardour, Helm loads whatever… so I saved the plugin preset (not Helm sound preset) and restartet: Same mess. However, I can load my saved preset for each track and then I’m fine. This is annoying, since one of course forgets about it when tweaking the sound.
My system us Kubuntu 16.04 with kxStudio PPAs. Ardour is 5.12.0, Helm is 0.9.0, installed via kxStudios packages. 0.9.0 is the latest stable version available from the Helm website.
It is unlikely that this is an Ardour issue. I’m fine with several instances of the GM synth. Also SF2 synth, setBfree and PianoTeq6 work well. However, one should test for issues with several instances of the same software synthesizer in general.
I would be glade if I had a fully working Helm. (This is so funny altogether, Helm in German means “Helmet” in English.) I’ve been using synthesizers for years, such as Roland JD-XA, Korg Monologue, Roland Juno 106, and others… Helm to my ears and knowledge is the only Linux soft synth that has a reasonable filter section.
Need to add to this: Also happens to me with Dexed in the Linux VST version. (The Helm issue is with LV2). So perhaps more of an issue in Ardour 5.12.0?
This unfortunately is quite a bit of an annoyance since Helm and Dexed are among the best synths available for Linux.
Me again. This wouldn’t let me sleep so I did some experiments. In a new project, things worked fine. What the Helm?
Perphaps there is something going on with the patch selector? I got no idea.
In short: things go amiss if plugin-internal presets compete with plugin-state. Ardour 5.12 restores them in the wrong order. – As long as you don’t use VST-programs, things should be fine.
Robin, thanks for your reply. Well, I now went back to dexed LV2. However, Helm and Dexed (LV2) still have the issue that they load weird presets after restarting Ardour.
For Helm and this very project of mine it seems to be what you describe as conflict between plugin-internal presets and plugin-state / external plugin presets. I edited the sound and saved it in Helm, but then I edited again and saved it as plugin preset. It turns out that the Synth sound preset of Helm overrides the plugin preset (so to say, it is loaded later probably).
However, Dexed (LV2) behaves weirdly. I figured out, why: Dexed reacts to the Patch Selector (which probably just sends MIDI program change?). The “Cartridge” in Dexed stays put, but the patch inside the cartridge adjusts to the Patch Selector of Ardour on loading the project. Again, this overrides plugin state.
The behavior of the Patch Selector also affects Helm. Now that I selected a patch once on my channel using Helm, I got the same trouble there. But once I’ve used the patch selector, I can’t get back to “please don’t send any program change to the plugin”.
So, to sum up, there’s a couple of issues here:
Probably, Dexed VST has trouble saving things (needs testing, perhaps I’m wrong).
Helm loads the last stored (user) preset, overriding plugin state
The Patch Selector overrides everything via program change and cannot be disabled once used.
So this is what I believe to have found out.
Best
Niels
