You are here

Home › Forums › Projects › qtractor

I have a problem with a particular VST3 plugin

21 July, 2024 - 17:04 — windowsrefund

Hi

OK so I've been using these strange MONSTER plugins from agushardiman.tv. I say strange because I get the sense the developer uses some kind of abstract framework to create them which means there's no source code. Anyway, they're quite "good" from a "get up and running" perspective and I like working with them despite the fact they're shipped as windoze VST3s, In the past, I have always hosted my plugins through Carla and triggered them over MIDI busses with the audio being sent back to their corresponding audio busses. I'm done with that approach and have leaned to several work-flow changes for the purpose of doing everything through Qtractor itself.

So part of that is to get access to all the plugins I need. For the non-naitive VST and VST3s, I use yabridge which works nicely. Qtractor ends up using the .so files created by yabridge. The resulting plugin can be loaded and everything works as expected. That is, until I just tried to open a .qtr file using this particular MONSTER BASS plugin. Qtractor crashed (oh nos!). If I run it from a console, I can see the following immediately following the crash:

[1]    22420 IOT instruction  qtractor InsertMix1.qtr

Fortunately, I do know how to recover with a work-around. I know I can open the .qtr file and change...

    <plugin type="VST3">
     <filename>/home/windowsrefund/.vst3/yabridge/MONSTER Bass v2-2022.08.vst3/Contents/x86_64-linux/MONSTER Bass v2-2022.08.so</filename>
     <index>0</index>
     <label>MONSTER_Bass_v2_2022_08</label>
     <preset></preset>
     <direct-access-param>-1</direct-access-param>
     <activated>1</activated>

to

    <plugin type="VST3">
     <filename>/home/windowsrefund/.vst3/yabridge/MONSTER Bass v2-2022.08.vst3/Contents/x86_64-linux/MONSTER Bass v2-2022.08.so</filename>
     <index>0</index>
     <label>MONSTER_Bass_v2_2022_08</label>
     <preset></preset>
     <direct-access-param>-1</direct-access-param>
     <activated>0</activated>

That will allow me to open and start working with the material again.

The .qtr file itself does have another yabridge-managed VST3 file enabled which is not causing a problem. That said, I can't imagine this is a problem with Qtractor itself and more likely these MONSTER plugins have some kind of bug. I figured it was worth a shot to explain what I'm seeing, share the error, and maybe get lucky?

I'll continue troubleshooting and looking for some answers on my end. I'll report anything of interest.

Forums: 
qtractor
22 July, 2024 - 03:18 — windowsrefund

A small update to mention I can reproduce the scenario with the Monster Drums plugin from the same developer. This would have me think these plugins share some trait exposing them to this scenario.

OK, so can I reproduce it with Carla? In order to find out, I loaded the same 2 plugins into Carla 2.5.8. Carla sees each of these VST3s as "native" since yabridge is workingi its magic. Both plugins loaded fine, were usable, and I was able to save the Carla session to /tmp/carla-test.carxp and use that file to reload both plugins after restarting Carla.

I did see something of interest in Carla's log though....

======= Starting engine =======
======= Engine started ========
Carla engine started, details:
  Driver name:  JACK
  Sample rate:  44100
  Process mode: Multi client
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] Initializing yabridge version 5.1.0
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] library:       '/home/windowsrefund/.local/share/yabridge/libyabridge-vst3.so'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] host:          '/home/windowsrefund/.local/share/yabridge/yabridge-host.exe'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] plugin:        '/home/windowsrefund/.vst3/win/MONSTER Drum v3-2022.07.vst3'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] plugin type:   'VST3'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] realtime:      'yes'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] sockets:       '/run/user/1000/yabridge-MONSTER Drum v3-2022.07-0LWhkmvw'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] wine prefix:   '<default>'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] wine version:  '9.13 (Staging)'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] 
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] config from:   '<defaults>'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] hosting mode:  'individually, 64-bit'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] other options: '<none>'
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] 
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] Enabled features:
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] - bitbridge support
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] - CLAP support
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] - VST3 support
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] 
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] 002c:fixme:winediag:loader_init wine-staging 9.13 is a testing version containing experimental patches.
23:08:16 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org.
23:08:18 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] Initializing yabridge host version 5.1.0
23:08:18 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] Preparing to load VST3 plugin at '/home/windowsrefund/.vst3/win/MONSTER Drum v3-2022.07.vst3'
23:08:18 [MONSTER Drum v3-2022.07-0LWhkmvw] [Wine STDERR] Finished initializing '/home/windowsrefund/.vst3/win/MONSTER Drum v3-2022.07.vst3'
JUCE Assertion failure in juce_VST3PluginFormat.cpp:3636

Honestly, I don't grok why Carla is reporting the file as being loaded from ~/.vst/win given the fact it is reported as "Native" so I'll chalk that down as some type of symlinkish thing I'm not going to worry about. So maybe Carla is handling JUCE raising some sort of exception where Qtractor isn't? I don't know.

Again, given what I think I know about these MONSTER plugins, I'd be willing to bet they're not entirely compliant with these vst standards? As such, I'm certainly not expecting much but I'm hoping to be pleasantly surprised if the underlying issue is something simple.

All the best

2 August, 2024 - 03:19 — windowsrefund

Going to recompile with this update and will report back.

2 August, 2024 - 03:29 — windowsrefund

No change.

That said, I've also noticed another odd behavior with these plugins where the correct patch isn't being loaded despite the appropriate config node existing in the .qtr fiile. Is anyone interested in trying to reproduce any of this on their end? If so, I'd be more than happy to share the exact steps taken to get yabridge working with Qtractor.

4 August, 2024 - 03:45 — windowsrefund

I am really happy to report I've discovered something in the sense of a root cause :)

On a hunch, I checked out and recompiled this commit. Now, this particular VST3 plugin's patch is persisted as I'd expect. Interestingly enough, some parameters do not persist (global volume) but others do. That curiosity aside, being able to persist patch selection is obviously fundamental so this is a win.

It does not solve the other IOT instruction crash I reported but I work around that by ensuring I disable the plugin before I save and exit Qtractor. I use automation to activate it before the part plays so this is fine.

So basically, 55c7d1335c34d10ebd76733c679d248af567e860 is the commit that introduced the inability to persist patches from this author. The odd thing is, other VST3 plugins I have do not appear to be impacted in this fashion which is why I mentioned what I knew about these MONSTER plugins and how the author seems to develop them in what I deems as "a very strange way". In other words, they are clearly not "standard" in as much as that word actually means anything. I also have a suspicion the "developer" would have no idea as he says there is no source code.............. uhm, yea.

6 August, 2024 - 03:08 — windowsrefund

Never mind. I thought I had made some progress but it does look like the previously mentioned commit is in play in terms of a root cause.

6 August, 2024 - 14:18 — windowsrefund

Rui,

Any chance 55c7d1335c34d10ebd76733c679d248af567e860 can be reverted?

All the best

6 August, 2024 - 16:28 — rncbc
rncbc's picture

not so simple

commit 55c7d1335c34d10ebd76733c679d248af567e860 is not reversible anymore, it has been superseded since then.

sorry

6 August, 2024 - 17:03 — windowsrefund

Couldn't you cherry pick the newer commits into a new release? Unless I'm wrong, VST3s are unable to persist their state now? Actually, that's not a fair statement as I've only been talking about these particular MONSTER plugins. That said, the commit in question may be impacting other plugins that I wouldn't know about.

6 August, 2024 - 20:19 — rncbc
rncbc's picture

nope

because the newer commits were indeed to fix some other native VST3 plugins--Dexed and Surge XT, to name a few popular ones--to save and restore their state properly (which weren't before).

byee

6 August, 2024 - 20:43 — windowsrefund

Let me try a different angle then. Would you mind seeing if you could reproduce what I've reported against this plugin? It's the smallest of all the plugins by that developer and I'd be able to share any information about how to setup yabridge and/or wine if needed. (though I suspect you already know).

6 August, 2024 - 22:18 — rncbc
rncbc's picture

sure you'll understand I don't have the time nor the will to deal with--let alone debugging--these non-linux-nor-free-open-source stuff...

moreover, it looks and are actually presented like toys: it baffles me why do you have this so special interest on them.

no hard feelings though

cheers

7 August, 2024 - 03:31 — windowsrefund

OK, I'm going to make a few points here.

  1. This has nothing to do with any interest in toy sounds. Out of all these MONSTER plugins, this is the smallest plugin in terms of size. I didn't even know about the particular plugin (because I actually have no need for it in my music) but for good reason, the main yabridge developer has been looking into a related issue here when I asked for help looking at this from the perspective of yabridge. In other words, it's the most practical of all the plugins to use for troubleshooting. IMHO, you, as a developer, shouldn't have needed me to explain all this and choosing to attack the "legitimacy" of the plugin's musical purpose, rather than focus on the real issue is childish and lazy. One could easily argue the 2 plugins you say your commit fixed are unpopular, dated, and equally not important. I would never make that argument because I know it's all subjective. The point is, you have NO IDEA what other VST/3 plugins are now broken as a result of that commit.

  2. You pushed an "EXPERIMENTAL" commit (I'd actually go further and say you introduced a bug) to master. I reported an unintended consequence of that commit and have been troubleshooting, sharing my findings, and have been asking for help. The commit actually BROKE something and you're basically saying you don't give a shit. OK, do me a favor then, when you push to master, stop marking your commits as "EXPERIMENTAL", close the issues section, and let it be known your pushes to the master branch are "take it or leave it". In fact, just get rid of the develop branch all together? Now, I know what I just suggested is utter nonsense and in all my time watching you grow this project would never expect you to actually go through with any of that. I'm simply making a point that you know your commit broke something and this is not a decent way to move forward. You actually introduced a bug which a long-time supporter has provided valuable feedback on. I actually did all of the work related to identifying the root cause and make a logical request to revert that commit. Under normal development best practices that commit wouldn't even be in master as it would have been kept in the develop branch for some reasonable amount of time in order to sollcit feedback like what I've contributed here.

Just out of curiosity, I went ahead and installed both dexed and surge on my system. Here's what I noticed:

  • Both of these plugins have lv2 variants. I suspect this is why the persistence bug as it relates to the vst3 variant existed for so long. In other words, I'd be willing to bet nobody is using the vst3 variant since they'd have a preference for the lv2.

surge vst3

  • As the screenshot shows, I wasn't able to reproduce the original bug your commit allegedly fixed. We can see the non-default "Attacky" patch was loaded after I changed the default patch, saved my session, restarted qtractor, and loaded my .qtr. I'd do the same with Dexed but that's a VST2 plugin (see the dexed-vst debian package) so I don't know why that would even be in scope.

So from what I've seen, the commit I've asked to be reverted doesn't fix anything but DOES break something.

So please revert it?

File attachments: 
Image icon surge-vst3.png
7 August, 2024 - 08:31 — rncbc
rncbc's picture

did you check whether surge, dexed or any other native vst3 plugins for that matter, actually saved and reloaded their state exactly before and after the so called broken commit ?

have you really checked if they actually sound as intended upon save and reload? and I'm talking about native GNU/Linux-VST3, not any of those wine-bridged stuff out there; and you're right in judging my stance about them, I don't care much about that sh*t; sorry again.

so please, do us a favor and focus on free/open-source VST3 plugins and only; and more importantly, grab the latest versions of both (the plugins and qtractor) always or forget about it.

cheers

ps. those commits are not going to be reverted anytime, the only way now is forward!

7 August, 2024 - 14:17 — windowsrefund

What an absolutely childish attitude. That's fine Rui. I've already forked the project and fixed it by removing your broken commit.

7 August, 2024 - 17:33 — rncbc
rncbc's picture

good luck then

be reminded your fork won't get any support from yours truly

cheers

7 August, 2024 - 18:17 — windowsrefund

You mean I won't be impacted by experimental changes being shoved in with no regard for user impact? Sold!

windowsrefund/qtractor-not-broken

Add new comment

Copyright (C) 2006-2024 rncbc aka Rui Nuno Capela. All rights reserved.
Powered by Drupal