Helm VST plugin configuration not properly restored after qtractor update #357
Comments
|
the most recent qtractor release is v0.9.27 have you tried with that? |
Yes, I did -- same result, only the "working" and "original" sessions restore modulation settings. Cheers -- |
|
in my tests, with a fresh Helm VST (v0.9.0.21git.abdedd):
|
|
one worth of a note is that the helm preset/patch name being loaded on dysfunct.qtr (Arp / CM Clear Arp) is quite different from the one seen in both working.qtr and original.qtr (ascending / Vibrations),.. obviously making a huge difference to the sound produced... |
That is kinda wired -- I haven't used Helm patches so far, since (well, at least before 0.9.26 ;) qtractor seemed to be perfectly able to handle saving an restoring patch data. The patch names shown in the "working" and "original" screenshots seem to have been auto-generated (by whom?) from the (original) session's name and track name, respectively, whereas the name displayed in the "dysfunct" screenshot refers to the first patch ("CM Kleer Arp") in the first patch bank ("Arp") that comes pre-installed by default with Helm. In fact, this is what gets displayed when invoking the patch browser by hovering the mouse over the Helm logo in the GUI's upper left corner, so the latter screenshot could be just a coincidential side-effect of your mouse movements. Or is it possible that in some of the recent releases of qtractor some changes were introduced which would cause a VST plugin like Helm to attempt to load a patch (or the first path of the first bank (if no patch has been selected before) on initialization), which in turn might somehow interfere with restoring the saved plugin configuration from the config section? What's in that config section, anyway? Some ASCII-encoded blob, I suppose, in which plugins can store configuration data not accessible through dedicated parameters, I suppose? In Helm's case, this must be the place where things like modulation targets and strengths are stored, since there seem to be no parameters for that. If so, something must have changed between 0.9.23 and 0.9.26 that influences how those blobs get re-applied on initialization. Do you happen to have a clue which qtractor source code files might be involved in that process? Cheers -- |
sorry but qtractor (or any other VST host for that matter) is not involved in that process, but asking the plugin for "the blob", encode and save to xml as a single "chunk", then later load, decode and tell the plugin to set its state from that copy of the "blob"--in no moment does qtractor (or any host) interfere with the said "blob": only the plugin knows how ;) as said on my first reply , I've tested all your supplied sessions on v0.9.23, .26 and latest/current .26git+; no differences have been spotted while loading, playing and saving those sessions, before and after, besides the stark difference between "dysfunct" and the other two, "working" and "original"; ps. note that I'm testing with native system builds, not the AppImage's. |
OK, but somehow the plugin's blob data must be converted to the ascii text found in the session file, right? So qtractor is involved somewhere in the process. If you could give me a hint where to start (blob (de)serialization and plugin communication code), I'd like to examine the changes btw. 0.9.23 and 0.9.26 in an attempt to figure out why the same blob data leads to differen plugin states in different qtractor versions. (I'm not really a C++ expert, but I'll do my best... Last time I was dealing with a language requiring you to explicitly deal with memory allocation was at the end of the last millenium when I was doing some Turbo Pascal... ;) (BTW, which IDE would you recommend for coding qtractor?)
I'll attach an archive file of the original session (renamed from *.qtz to *.zip, 'cause uploading the former is not supported in this forum) -- 17 tracks of Helm glory with some additional Calf sugar added! Track 11 -- "Vibrations" -- is the one I isolated in the previous demo files. You'll find that the patch sounds heavily modulated when loaded into 0.9.23 and that there will be no modulation at all in 0.9.26/27 (apart from the general amp envelope, which is controlled by parameters, not by the config blob). Cheers -- |
|
once again, i can't a hear a difference in loading and playing "ascending.qtz" on v0.9.23 vs. v0.9.27+; even saving to another name and reloading on v0.9.27+ I hear no difference while soloing track 11 - Variations: it just sounds like "working-export-1.ogg" as uploaded before. lest to note, the whole session with no soloed tracks do also sound the same on either v0.9.23 and v0.9.27+. re. the code parts in question:
as you might follow the git blame, the relevant code hasn't changed at all ever since 3 years ago (v0.9.23 is 1year ago). I can only suspect now that you probably have an old AppImage issue; have you tried or can you try with a sane and native build instead? cheers |
Yeah, I understood that you didn't hear any differences between 0.9.23 and 0.9.27 with any of the boiled-down examples, except "dysfunct" being unmodulated; neither did I. But -- in contrast to you -- I do get a difference btw. the two qtractor versions when running the full-fledged original session file. But anyway...
...I'll give that a try! Not tonight, though; I gonna need some quiet moments to gather the required build dependencies... Cheers -- |
|
just for evidence, here attached goes the whole session tracks export to audio as taken from very same pristine "ascending.qtz" loaded on each and respective qtractor version: UPDATE: here know my stance on AppImage's (and Flatpak's or whatever): when in presence of plugins, these containerized packages are mostly intended for first trials... when satisfied and in the long term, you must or are here strongly advised to go with native system builds, meaning something that match and align with your distro system s/w level and nothing else. |
|
OK, this is weird -- just built both 0.9.23 and 0.9.27, and in both versions I do not get the expected modulation! Tomorrow I gonna repeat this experiment on the mentioned laptop which is still capable of running the 0.9.23 AppImage, but I already gut the strong suspicion that...
...you might be right about that. It's a pitty, though -- on Debian, you usually have to wait some years until you get e new version of some application software, so AppImages seemed a good way to go... Talking about plugins -- may I ask which version of Helm you are using? I've installed 5:0.9.0-2kxstudio3 from -- as the name suggests -- the kxstudio repo, but to my knowledge, Helm hasn't been development further for quite some time now (last change on GitHub was 4 years ago). Cheers -- |
as said on first reply:
may I suggest you to try install from my repos ? maybe the PPAs Applications (focal) and Libraries (focal) PPAs are better suitable to your case (Debian 11 bullseye)? |
Where did you get this from? I tried to compile that version from GitHub, but I get an error saying which, according to my research, seems to indicate an incompatibility with my current cpp version (10). |
|
patch for g++9 attached |
Great, thanks! (There's a related issue at mtytel/helm#299 -- have you tried to submit a pull request?)
Unfortunately, your repos seem to be incompatible with Debian in general and/or Bullseye in particular: But anyway, thanks to the patch you kindly provided in #358 ! I now have a self-compiled Helm installation, in conjunction with self-compiled qtractor versions 0.9.23 and 0.9.27. Unfortunately, neither of these combinations give me the modulation I expect from the "ascending" demo session. I'm kind out of ideas. Or maybe you could post
so that I have a chance to verify if it's my build infrastructure that leads to dysfunctional qtractor and/or Helm binaries? Cheers -- |
|
dunno much about debian but I believe you may hack the apt source file and substitute "kinetic" for "focal" ps. just a guess but are you sure you're running the correct helm.so ? last time I've built it from source it it's installed to |
I could get rid of the "does not have a Release file" error by marking your repository as trusted: Doesnt't help much, though: So loads of rncbc repository files being ignored...
Now that initially appeared like a really got lead -- alas, I dont' have So... I guess I'm going to install Ubuntu on a spare partition and try my luck there... Cheers -- |
|
Yet another negative result: I managed to compile both Helm and qtractor (versions 0.9.23 and 0.9.27) on the laptop mentioned previously -- the one which is also capable of running the appimages of 0.9.23 and 0.9.27 with and without modulation, respectively. None of the custom builds, however, does correctly restore modulation settings. I'm slowly running out of ideas... |
as suggested above, try:
|
Yeah, I guess the next thing I gonna try is to unpack the working and non-working AppImage and try to figure out which library versions are used in both cases. Maybe I'll find a hint why Helm state gets correctly restored in one case, but not in the other... Cheers -- |
|
fwiw. it all works on openSUSE Tumbleweed ;) but yes, I can confirm that even the latest v0.9.28 .AppImage doesn't get it right, only the native builds. and you're probably right, Helm (and/or its JUCE base) behaves or decodes differently its own data blobs across different levels of (some) system libraries... that said I guess it would be a PITA to nail this issue further down... I'm out of ideas now too but one last resort: can't you rebuild the said modulation settings that is being missed? AFAICT it's only borked on the Vibrations track#11 (all the others seem OK, but that's probably just me saying:)) |
|
OK, here's the thing: I finally managed to start debugging the whole process of qtractor interacting with Helm using the C++ extension of VS Code by setting breakpoints and printing some debug messages to the console. What I have learned so far is that qtractor indeed initially (while loading the session file) correctly restores the modulation settings for each Helm instance created -- the "chunk" blob contains just some JSON string, defining, among other things, modulation sources, targets and amounts. I can nicely track how these settings get passed down to Helm's "ModulationBank" data structure. However, later on, when qtractor is almost done opening a track, it calls qtracktorTrack::open --> qtractorPluginList::setChannels --> qtractorMidiManager::updateInstruments --> qtractorVstPlugin::getProgram, which, finally, through the VST dispatch mechanism, ends up causing Helm to clear all modulation over and over again for each program loaded, thus destroying the settings so nicely restored while loading the session file. In fact, Helm does have a built-in safeguard against prematurely overwriting its state -- it won't load a program for the first 500 ms after its state has been set set. The corresponding line (helm_plugin.cpp:124) even has a comment saying "Hack for some DAWs that set program on load for VSTs." -- I wonder which DAW this might refer to... ;) Now this might also be the explanation for our different experiences regarding modulation restoration. It appears to me that the time required to load a project increased somewhat between 0.9.23 and 0.9.26. Since I have a pretty old PC, the whole project now takes way longer than 500 ms to load, thus finally allowing qtractor to actually select programs and, as a side effect, to clear Helm's modulation settings. I suppose you have a faster PC than me, preventing the loading process from exceeding Helm's built-in temporary unresponsiveness. I can also confirm that modulation gets correctly restored on my system if I set the delay to a sufficiently high value. This would also explain why the problem seems to affect only larger project with many tracks; I'm not sure, though, why the 0.9.23 AppImage version works fine for me, while a self-compiled 0.9.23 suffers from the issue. Maybe it has to do something with compiler optimization (like release vs. debug configuration). I wonder if it might be prudent to save the "chunk" blob in memory and re-apply it right after updating the instruments in qtractorMidiManager? I could try creating a patch for that myself, but mind, I don't speak C++ fluently, and I might introduce quite some violations against good practices, style guides etc... So what do you think? Cheers -- |
|
|
as a matter of fact, all that seems to worsen when qtractor is compiled to the VeSTige (which is the default) instead of to the official VSTSDK2.x ... and that's why my own local builds, which are all against the later, never exposed the reported loss of modulations, and all other builds, which are of course set to the former, have the symptoms. so please, try to (re)build qtractor on an original vst2sdk (you may probably find it under the helm source tree or else still bundled under the official steinberg's vst3sdk .zip) many thanks for sorting this all out! EDIT: or you may try today's qtractor >= 0.9.28.1git.732b79 |
Great!!! The "loss of modulation" problem really seems to have vanished in that version! Thank you so much! :) I suggest to close this issue now. Cheers -- P.S. Would it be possible for you to submit your g++ 9 patch to the Helm repository, perhaps referring to mtytel/helm#299 ? I'd really love to see this pretty little synth with its great UI staying alive... |
well, the patch wasn't mine in the first place, it was posted once, sometime ago on some LA mailist that I can't remember now whether it was LAD or LAU, sorry feel free to post it yourself, and to close this issue (you started it anyway;)) |
Just submitted a corresponding pull request: mtytel/helm#306
Will do so. Thanks again for caring about my little Helm problem -- and for qtractor in general! :) Just wish it was cross-platform, so that my friends, who still stick to Windows and/or MacOS, could also benefit from your great work... Cheers -- |
Hi there,
being confronted with the "undefined symbol: g_module_open_full" error, which seems to have struck quite some AppImage users recently, I yesterday upgraded from qtractor-0.9.23-66.1.x86_64 to qtractor-0.9.26-69.1.x86_64 (the oldest qtractor AppImage I could find). Unfortunately, after opening some existing qtractor sessions, I found that many Helm VST plugin configuration settings were not properly restored -- in particular, it appeared as though LFO and EG targets and modulation strengths were not re-applied.
On a spare laptop, which hadn't been upgraded for some time, I was still able to launch qtractor 0.9.23, allowing me to confirm that those settings were still there and applicable. I also occasionally managed to create qtractor sessions which would also load properly in 0.9.26 by deleting some tracks in 0.9.23 and saving the session, but I was unable to identify a specific pattern of actions that would reliably convert a session into a state properly loadable by 0.9.26.
I could, however, confirm, that .qtr files, one of which would properly restore modulation settings while the other would not, differed only in the config key="chunk" section of their corresponding plugins.
So it seems that somewhere between 0.9.23 and 0.9.26 some changes have been introduced which prevent config sections written by older qtractor versions to be properly applied by newer versions.
Unfortunately, even after playing around with different qtractor versions on different computers for several hours, I still do not really have a minimum (non-)working example for the problem described above. The attached zip archive, however, does contain three qtractor session which I have created as follows:
helm-modulation.zip
d in the working example. This session does not restore modulation in either qtractor version.
I'd really appreciate if I could still use my old (well, actually not that old) qtractor sessions in more recent application versions... So anything I can do to help clarifying this issue?
Cheers --
Torsten
The text was updated successfully, but these errors were encountered: