search

rncbc / qtractor

Qtractor - An Audio/MIDI multi-track sequencer
https://qtractor.org
GNU General Public License v2.0
511 stars 90 forks source link

Helm VST plugin configuration not properly restored after qtractor update #357

Closed tcrass closed 2 years ago

tcrass commented 2 years ago

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:

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

tcrass commented 2 years ago

helm-modulation.zip

rncbc commented 2 years ago

the most recent qtractor release is v0.9.27 have you tried with that?

tcrass commented 2 years ago

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 -- Torsten

rncbc commented 2 years ago

in my tests, with a fresh Helm VST (v0.9.0.21git.abdedd):

rncbc commented 2 years ago

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... helm-modulation-screenshot-1.zip .

tcrass commented 2 years ago

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 -- Torsten

rncbc commented 2 years ago

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?

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.

tcrass commented 2 years ago

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 ;)

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?)

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";

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 -- Torsten ascending.zip

rncbc commented 2 years ago

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

tcrass commented 2 years ago

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.

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 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?

...I'll give that a try! Not tonight, though; I gonna need some quiet moments to gather the required build dependencies...

Cheers -- Torsten

rncbc commented 2 years ago

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: a. ascending-0.9.23-export-1.ogg b. ascending-0.9.27-export-1.ogg hear for yourself, please, cheers ;) ascending-export-1.zip

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.

tcrass commented 2 years ago

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...

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.

...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 -- Torsten

rncbc commented 2 years ago

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).

as said on first reply:

fresh Helm VST (v0.9.0.21git.abdedd):

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)?

tcrass commented 2 years ago

fresh Helm VST (v0.9.0.21git.abdedd):

Where did you get this from? I tried to compile that version from GitHub, but I get an error saying

Compiling border_bounds_constrainer.cpp
In file included from ../../../JUCE/modules/juce_graphics/juce_graphics.h:112,
                 from ../../../JUCE/modules/juce_audio_devices/juce_audio_devices.h:58,
                 from ../../JuceLibraryCode/JuceHeader.h:18,
                 from ../../../src/common/border_bounds_constrainer.h:21,
                 from ../../../src/common/border_bounds_constrainer.cpp:17:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getAlpha()’:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h:116:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<unnamed union>::comps[3]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  116 |     forcedinline uint8& getAlpha() noexcept           { return comps [indexA]; }
      |                                                                ~~~~~~~~~~~~~^
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getRed()’:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h:117:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<unnamed union>::comps[2]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  117 |     forcedinline uint8& getRed() noexcept             { return comps [indexR]; }
      |                                                                ~~~~~~~~~~~~~^
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getGreen()’:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h:118:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<unnamed union>::comps[1]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  118 |     forcedinline uint8& getGreen() noexcept           { return comps [indexG]; }
      |                                                                ~~~~~~~~~~~~~^
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h: In member function ‘juce::uint8& juce::PixelARGB::getBlue()’:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h:119:77: error: cannot bind packed field ‘((juce::PixelARGB*)this)->juce::PixelARGB::<anonymous>.juce::PixelARGB::<unnamed union>::comps[0]’ to ‘juce::uint8&’ {aka ‘unsigned char&’}
  119 |     forcedinline uint8& getBlue() noexcept            { return comps [indexB]; }
      |                                                                ~~~~~~~~~~~~~^
In file included from ../../../JUCE/modules/juce_graphics/juce_graphics.h:134,
                 from ../../../JUCE/modules/juce_audio_devices/juce_audio_devices.h:58,
                 from ../../JuceLibraryCode/JuceHeader.h:18,
                 from ../../../src/common/border_bounds_constrainer.h:21,
                 from ../../../src/common/border_bounds_constrainer.cpp:17:
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h: In instantiation of ‘void juce::RenderingHelpers::EdgeTableFillers::SolidColour<PixelType, replaceExisting>::replaceLine(juce::PixelRGB*, juce::PixelARGB, int) const [with PixelType = juce::PixelRGB; bool replaceExisting = true]’:
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:628:29:   required from ‘void juce::RenderingHelpers::EdgeTableFillers::SolidColour<PixelType, replaceExisting>::handleEdgeTableLine(int, int, int) const [with PixelType = juce::PixelRGB; bool replaceExisting = true]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:2026:79:   required from ‘void juce::RenderingHelpers::ClipRegions<SavedStateType>::RectangleListRegion::SubRectangleIteratorFloat::iterate(Renderer&) const [with Renderer = juce::RenderingHelpers::EdgeTableFillers::SolidColour<juce::PixelRGB, true>; SavedStateType = juce::RenderingHelpers::SoftwareRendererSavedState]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:1592:26:   required from ‘void juce::RenderingHelpers::EdgeTableFillers::renderSolidFill(Iterator&, const juce::Image::BitmapData&, juce::PixelARGB, bool, DestPixelType*) [with Iterator = juce::RenderingHelpers::ClipRegions<juce::RenderingHelpers::SoftwareRendererSavedState>::RectangleListRegion::SubRectangleIteratorFloat; DestPixelType = juce::PixelRGB]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:2645:67:   required from ‘void juce::RenderingHelpers::SoftwareRendererSavedState::fillWithSolidColour(IteratorType&, juce::PixelARGB, bool) const [with IteratorType = juce::RenderingHelpers::ClipRegions<juce::RenderingHelpers::SoftwareRendererSavedState>::RectangleListRegion::SubRectangleIteratorFloat]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:1897:39:   required from ‘void juce::RenderingHelpers::ClipRegions<SavedStateType>::RectangleListRegion::fillRectWithColour(SavedStateType&, juce::Rectangle<float>, juce::PixelARGB) const [with SavedStateType = juce::RenderingHelpers::SoftwareRendererSavedState]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:1894:14:   required from here
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:714:34: warning: converting a packed ‘juce::PixelRGB’ pointer (alignment 1) to a ‘int’ pointer (alignment 4) may result in an unaligned pointer value [-Waddress-of-packed-member]
  714 |                             auto d = reinterpret_cast<int*> (dest);
      |                                  ^
In file included from ../../../JUCE/modules/juce_graphics/juce_graphics.h:112,
                 from ../../../JUCE/modules/juce_audio_devices/juce_audio_devices.h:58,
                 from ../../JuceLibraryCode/JuceHeader.h:18,
                 from ../../../src/common/border_bounds_constrainer.h:21,
                 from ../../../src/common/border_bounds_constrainer.cpp:17:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h:366:17: note: defined here
  366 | class JUCE_API  PixelRGB
      |                 ^~~~~~~~
In file included from ../../../JUCE/modules/juce_graphics/juce_graphics.h:134,
                 from ../../../JUCE/modules/juce_audio_devices/juce_audio_devices.h:58,
                 from ../../JuceLibraryCode/JuceHeader.h:18,
                 from ../../../src/common/border_bounds_constrainer.h:21,
                 from ../../../src/common/border_bounds_constrainer.cpp:17:
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h: In instantiation of ‘void juce::RenderingHelpers::EdgeTableFillers::SolidColour<PixelType, replaceExisting>::replaceLine(juce::PixelRGB*, juce::PixelARGB, int) const [with PixelType = juce::PixelRGB; bool replaceExisting = false]’:
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:628:29:   required from ‘void juce::RenderingHelpers::EdgeTableFillers::SolidColour<PixelType, replaceExisting>::handleEdgeTableLine(int, int, int) const [with PixelType = juce::PixelRGB; bool replaceExisting = false]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:2026:79:   required from ‘void juce::RenderingHelpers::ClipRegions<SavedStateType>::RectangleListRegion::SubRectangleIteratorFloat::iterate(Renderer&) const [with Renderer = juce::RenderingHelpers::EdgeTableFillers::SolidColour<juce::PixelRGB, false>; SavedStateType = juce::RenderingHelpers::SoftwareRendererSavedState]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:1597:26:   required from ‘void juce::RenderingHelpers::EdgeTableFillers::renderSolidFill(Iterator&, const juce::Image::BitmapData&, juce::PixelARGB, bool, DestPixelType*) [with Iterator = juce::RenderingHelpers::ClipRegions<juce::RenderingHelpers::SoftwareRendererSavedState>::RectangleListRegion::SubRectangleIteratorFloat; DestPixelType = juce::PixelRGB]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:2645:67:   required from ‘void juce::RenderingHelpers::SoftwareRendererSavedState::fillWithSolidColour(IteratorType&, juce::PixelARGB, bool) const [with IteratorType = juce::RenderingHelpers::ClipRegions<juce::RenderingHelpers::SoftwareRendererSavedState>::RectangleListRegion::SubRectangleIteratorFloat]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:1897:39:   required from ‘void juce::RenderingHelpers::ClipRegions<SavedStateType>::RectangleListRegion::fillRectWithColour(SavedStateType&, juce::Rectangle<float>, juce::PixelARGB) const [with SavedStateType = juce::RenderingHelpers::SoftwareRendererSavedState]’
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:1894:14:   required from here
../../../JUCE/modules/juce_graphics/native/juce_RenderingHelpers.h:714:34: warning: converting a packed ‘juce::PixelRGB’ pointer (alignment 1) to a ‘int’ pointer (alignment 4) may result in an unaligned pointer value [-Waddress-of-packed-member]
  714 |                             auto d = reinterpret_cast<int*> (dest);
      |                                  ^
In file included from ../../../JUCE/modules/juce_graphics/juce_graphics.h:112,
                 from ../../../JUCE/modules/juce_audio_devices/juce_audio_devices.h:58,
                 from ../../JuceLibraryCode/JuceHeader.h:18,
                 from ../../../src/common/border_bounds_constrainer.h:21,
                 from ../../../src/common/border_bounds_constrainer.cpp:17:
../../../JUCE/modules/juce_graphics/colour/juce_PixelFormats.h:366:17: note: defined here
  366 | class JUCE_API  PixelRGB
      |                 ^~~~~~~~
make[1]: *** [Makefile:400: build/intermediate/Release/border_bounds_constrainer_b5a34af8.o] Error 1
make[1]: Leaving directory '/home/tcrass/src/helm/helm/standalone/builds/linux'
make: *** [Makefile:79: standalone] Error 2

which, according to my research, seems to indicate an incompatibility with my current cpp version (10).

rncbc commented 2 years ago

patch for g++9 attached

helm-gcc91-1.diff.txt

tcrass commented 2 years ago

patch for g++9 attached

Great, thanks! (There's a related issue at https://github.com/mtytel/helm/issues/299 -- have you tried to submit a pull request?)

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)?

Unfortunately, your repos seem to be incompatible with Debian in general and/or Bullseye in particular:

$ sudo add-apt-repository ppa:rncbc/apps-focal
 Applications for xUbuntu 20.04 LTS (focal)
 More info: https://launchpad.net/~rncbc/+archive/ubuntu/apps-focal
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keybox '/tmp/tmp8ng6k3o8/pubring.gpg' created
gpg: /tmp/tmp8ng6k3o8/trustdb.gpg: trustdb created
gpg: key 74407499CD30F338: public key "Launchpad PPA for Rui Nuno Capela" imported
gpg: Total number processed: 1
gpg:               imported: 1
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: no valid OpenPGP data found.

$ sudo apt update
[...]
Ign:23 http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic InRelease                                                     
Err:24 http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic Release                                       
  404  Not Found [IP: 2620:2d:4000:1::3e 80]
[...]
Reading package lists... Done                                                                                                 
E: The repository 'http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

But anyway, thanks to the patch you kindly provided in https://github.com/rncbc/qtractor/issues/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 -- Torsten

rncbc commented 2 years ago

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 /usr/lib/lxvst/helm.so and your former "ascending.qtz" session loads it from /usr/lib/vst/helm.so ...

tcrass commented 2 years ago

dunno much about debian but I believe you may hack the apt source file and substitute "kinetic" for "focal"

I could get rid of the "does not have a Release file" error by marking your repository as trusted:

deb [trusted=yes] http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic main

Doesnt't help much, though:

sudo apt update                                                                                          100
Hit:1 http://security.debian.org/debian-security bullseye-security InRelease
Hit:2 http://ppa.launchpad.net/kxstudio-debian/libs/ubuntu bionic InRelease                                                   
Hit:3 http://ftp.de.debian.org/debian bullseye InRelease                                                                      
[...]
Hit:18 http://ppa.launchpad.net/kxstudio-debian/kxstudio/ubuntu bionic InRelease                                              
Ign:19 http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic InRelease                                                     
Ign:21 http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic Release     
[...]
Ign:32 http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic/main DEP-11 64x64@2 Icons
Ign:33 http://ppa.launchpad.net/rncbc/apps-focal/ubuntu kinetic/main DEP-11 128x128 Icons
Reading package lists... Done
E: Failed to fetch http://ppa.launchpad.net/rncbc/apps-focal/ubuntu/dists/kinetic/main/binary-amd64/Packages  404  Not Found [IP: 2620:2d:4000:1::3e 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.

So loads of rncbc repository files being ignored...

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 /usr/lib/lxvst/helm.so and your former "ascending.qtz" session loads it from /usr/lib/vst/helm.so ...

Now that initially appeared like a really got lead -- alas, I dont' have /usr/lib/vst/helm.so anymore, so qtractor obviously loads helm.so from the other directory (both are listed as VST plugin folders in qtractor's options dialog). Apparently, the exact filename path recorded in the session file doesn't matter -- qtractor even loads Helm if I change the path to something like /usr/foo/bar/helm.so!

So... I guess I'm going to install Ubuntu on a spare partition and try my luck there...

Cheers -- Torsten

tcrass commented 2 years ago

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...

rncbc commented 2 years ago

dunno much about debian but I believe you may hack the apt source file and substitute "kinetic" for "focal"

as suggested above, try:

deb [trusted=yes] http://ppa.launchpad.net/rncbc/apps-focal/ubuntufocalmain

tcrass commented 2 years ago

dunno much about debian but I believe you may hack the apt source file and substitute "kinetic" for "focal"

as suggested above, try:

deb [trusted=yes] http://ppa.launchpad.net/rncbc/apps-focal/ubuntufocalmain

Yeah, [trusted=yes] in conjunction with focal does work, with these settings I could install qtractor 0.9.28 from your repository. Doesn't make any difference, though -- still no modulation.

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 -- Torsten

rncbc commented 2 years ago

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:))

tcrass commented 2 years ago

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 -- Torsten (who is going to sleep much better tonight... :)

tcrass commented 2 years ago

qtractor-helm-interaction

rncbc commented 2 years ago

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.

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! cheers

EDIT: or you may try today's qtractor >= 0.9.28.1git.732b79

tcrass commented 2 years ago

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 -- Torsten

P.S. Would it be possible for you to submit your g++ 9 patch to the Helm repository, perhaps referring to https://github.com/mtytel/helm/issues/299 ? I'd really love to see this pretty little synth with its great UI staying alive...

rncbc commented 2 years ago

P.S. Would it be possible for you to submit your g++ 9 patch to the Helm repository, perhaps referring to https://github.com/mtytel/helm/issues/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;)) cheers

tcrass commented 2 years ago

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

Just submitted a corresponding pull request: https://github.com/mtytel/helm/pull/306

feel free to post it yourself, and to close this issue (you started it anyway;)) cheers

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 -- Torsten