Go Back   Cockos Incorporated Forums > REAPER Forums > REAPER Bug Reports

Reply
 
Thread Tools Display Modes
Old 05-07-2022, 06:30 PM   #1
sensapaz
Human being with feelings
 
Join Date: Mar 2021
Posts: 70
Default Ignores 64-bit VSTs in saved chain, loads & auto-bridges 32-bit versions (FIXED)

I had originally posted this in a thread about missing the VST bridging / firewalling dropdown in preferences. After learning that dropdown went away in an earlier version, I'm moving the rest here.

I have different portable installs I'm using for testing updates/upgrades:

* An older v6.23 I am very happy with (my goto)
* 2 temporary new portables of v6.56

All three installs are on the same machine (Win 10) and have the same VST paths in their respective preferences for scanning plugins. The system has a mix of 64- and 32 bit VST2 and VST3 plugins.



==== ISSUE 1 ====

From v6.23 I saved an FX chain with several 64-bit VST3 and VST plugins (and only one which is 32-bit only)

v6.23 loads the 64-bit plugins I was using, and the single 32-bit plugin, as intended.

But both installs of v6.56 ignore them and load/bridge the 32-bit versions instead. All of them. Big pain.

What's going on?



==== ISSUE 2 ====
It gets even weirder:

After the fx chain initially loads the bridged 32-bit instances, I've had some of the plugins in the chain SILENTLY CHANGE BACK to 64-bit.

That's right: one minute I'm looking at the bridged versions; a few minutes later I check and it's 64 bit. A plugin that Reaper was reporting as being 32-bit and bridged with a non-dockable UI, changed itself to the 64-bit version (which was referenced in the saved chain to begin with).

I had to replicate this multiple times before I was sure what I just saw.


==== ISSUE 3 =====

Some VSTs on this machine will have 4 different file versions in their respective paths: vst2-32, vst2-64, vst3-32, vst3-64 (remember I use other apps here, not just Reaper).

In v6.23, this has not been a problem. It seemed to follow the duplicate rules from the vst preferences page (the same-named plugins later in the path list or higher in the directory structure win)

In v6.56 (same vst paths as v6.23), the fx browser shows duplicates.

For example, I will see two same-named versions of the VST3 version of the plugin. I know that one is 32 bit and comes from one path, and one is 64 bit from another path (which should have been prioritized in the scan list).

What's going here?


Thanks for any clues to resolving all this weirdness.
sensapaz is offline   Reply With Quote
Old 05-08-2022, 10:10 PM   #2
sensapaz
Human being with feelings
 
Join Date: Mar 2021
Posts: 70
Default

==== UPDATE ====

I think I figured this out.

6.56 allows duplicate plugins in a way 6.23 did not. This had a chain reaction of other dependencies, like the plugin IDs in fx chain files, and how those IDs are assigned based on the scan order of vst folders.

Hope you can bear with me. Here are the steps of how I got there, and my conclusion.

================================================== =====
The fx chain was originally saved from v6.23.

I verified in notepad that the file specified 64-bit plugins.

Then I loaded the chain in v6.56. Same machine, same installed plugins, same scanned vst paths as 6.23.

In 6.56, the plugins loaded the bridged 32-bit versions, seeming to ignore what the file called for.

I then re-saved the fx chain from 6.56 to a new file.

Then I compared the two files (6.23 and 6.56) side by side in notepad.

Sure enough, resaved v6.56 file lists the 32 bit bridged plugins, not the 64 bit versions that were called for in the 6.23 file.

BUT THERE'S A PROBLEM: 6.56 uses the same numerical ID for that plugin instance. That is: 6.23 64 bit plugin, and 6.56 32 bit plugin, use same ID.

This provided the clue to what I think is the real problem:

An apparent change in how 6.23 and 6.56 deduplicate vst plugins.

6.23 appears to de-duplicate via the PLUGIN NAME (what it reports in the fx UI), and not the FILE NAME.

So, if one file is named coolplugin32.vst3, and another is named coolplugin64.vst3, and both files report to Reaper as "VST3: Cool Plugin," 6.23 would only keep one (from whichever vst directory in was scanned last).

In my case, this is the 64 bit version.

Perfect: no duplicates in the fx browser in 6.23. Only one plugin called "VST3: Cool Plugin."

6.56 is different. It appears to dedupe instead via the FILE NAME, and not the plugin name.

So, if there are two uniquely-named files for the same plugin, coolplugin32.vst3 and coolplugin64.vst3, 6.56 loads both.

The problem is: they both show up in Reaper as "VST3: Cool Plugin," with no way to tell them apart.

On the same machine, where 6.23 lists one plugin, 6.56 lists two.

This causes another problem:

Back to the plugin numerical ID in the saved fx chain file.

That ID appears tied to the plugin's position on a list, not its file name.

6.56 kept a second version of the same plugin -- from an earlier-scanned folder that 6.23 would exclude by deduplication rule.

So, in 6.56, the ID number is transposed: the first plugin gets the same ID.

In other words: the ID that 6.23 assigned to a 64 bit plugin, is now assigned to a 32 bit plugin in 6.56.

(because 6.56 scanned it earlier and did not discard it)

So that's why 6.56 is loading the 32 bit version of a plugin in an fx chain.

Because of a scanning / deduplication change, the extra 32 bit plugin has usurped an ID that belonged to the 64 bit version in the saved fx chain.


================================================== =====

As for the mystery of the silently changing plugins in 6.56: ones which load as 32 bit bridged (due to above issues) and later self-correct to 64 bit.

This seems to happen with vendors like Waves that use shells to call individual plugins.

Why this happens is beyond me, but that's what happens.

================================================== =====

This has been a big pain.

Personally I think 6.23 used a better logic for deduplicating. If the plugin name reports the same, even if the file names are different, keep the last one scanned (which is given priority).

That's what it all seems to point to.

Thanks for reading if you made it to the end.

I've attached a sample notepad entry that shows a 32 bit VST in 6.56 getting the same plugin ID as its 64 bit counterpart in 6.23.
Attached Images
File Type: png 3- fx chain plugin ID transpose 6.23-6.56.png (44.0 KB, 196 views)
sensapaz is offline   Reply With Quote
Old 05-09-2022, 05:11 AM   #3
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,754
Default

Can you share what your VST paths are set to, and where the 32-bit and 64-bit versions of the respective plug-in is located? It's likely that the 32-bit version is listed last (which indicates it gets priority), and while at one point REAPER used the filename as the highest-level disambiguation, it now uses the VST ID (which is recommended practice for VSTs), which could cause the change in behavior.

So: make sure the 32-bit path is listed _before_ the 64-bit path in the path list in the preferences. And once you make that change, clear the cache and re-scan.

Last edited by Justin; 05-09-2022 at 05:28 AM.
Justin is offline   Reply With Quote
Old 05-09-2022, 07:47 AM   #4
sensapaz
Human being with feelings
 
Join Date: Mar 2021
Posts: 70
Default

Quote:
Originally Posted by Justin View Post
Can you share what your VST paths are set to, and where the 32-bit and 64-bit versions of the respective plug-in is located? It's likely that the 32-bit version is listed last (which indicates it gets priority), and while at one point REAPER used the filename as the highest-level disambiguation, it now uses the VST ID (which is recommended practice for VSTs), which could cause the change in behavior.

So: make sure the 32-bit path is listed _before_ the 64-bit path in the path list in the preferences. And once you make that change, clear the cache and re-scan.
Hi Justin. For highest priority, 64-bit paths are already listed last. These are the VST paths, as entered in preferences, in this order:

C:\Program Files (x86)\VSTPlugIns
C:\Program Files (x86)\Common Files\VST3
C:\Program Files\VSTPlugIns
C:\Program Files\Common Files\VST3

Let's take this HOFA plugin as an example, "HOFA 4U Meter Fader & MS-Pan."

It has 4 versions, one in each path, with unique file names:

HOFA 4U Meter Fader & MS-Pan.dll
HOFA 4U Meter Fader & MS-Pan.vst3
HOFA 4U Meter Fader & MS-Pan x64.dll
HOFA 4U Meter Fader & MS-Pan x64.vst3


In 6.56, all 4 appear in the FX browser, in this order (note this is not the same order as the paths themselves; relative to paths, the display order is 3, 1, 2, 4):

VST: 4U Meter, Fader & MS-Pan (HOFA)
VST: 4U Meter, Fader & MS-Pan (x86) (HOFA)
VST3: 4U Meter, Fader & MS-Pan (HOFA)
VST3: 4U Meter, Fader & MS-Pan (HOFA)

Note also that position 3 and 4 are dupes. Through manual sleuthing, 3 is the x86 VST3, 4 is the x64 VST3.

In 6.23 (different deduping logic), they appear in the same order, but there are only 3:

VST: 4U Meter, Fader & MS-Pan (HOFA)
VST: 4U Meter, Fader & MS-Pan (x86) (HOFA)
VST3: 4U Meter, Fader & MS-Pan (HOFA)

Position 3 is the x64 VST3. Presumably the x86 VST3 has been 'deduped out' by a higher priority to the last scanned x64 VST3 (that is, if 6.23 dedupes by plugin name as I proposed, not file name).

The wires then get crossed in the saved fx chains.

The 6.23 fx chain file calls for the 64-bit VST3 plugin (6.23 fx browser position 3), with ID 1549429998{565345686666313455204D657465722C.

Open that fx chain in 6.56 and the same ID, 1549429998{565345686666313455204D657465722C, instead calls the 32-bit VST3 (6.56 fx browser position 3). We know this by re-saving the same chain from 6.56.


There is another big problem with this chain in 6.56:

I opened the chain in the monitor FX.
As discussed, because of an ID transposition, the 32-bit VST3 gets loaded, bridged.
Even if I manually replace the fx to the 64-bit VST3, every time I restart Reaper, it reverts to the 32-bit VST3 bridged.

That's not good.

The same behavior happens regardless of which track I use to load the fx chain.

If I load in track 1, for example, same issue. If I drag the FX in track 1 to another rack, same issue.
sensapaz is offline   Reply With Quote
Old 05-09-2022, 09:37 AM   #5
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,754
Default

Ahh I think I see what's going on. Fixing!

Last edited by Justin; 05-09-2022 at 11:10 AM.
Justin is offline   Reply With Quote
Old 05-09-2022, 02:42 PM   #6
sensapaz
Human being with feelings
 
Join Date: Mar 2021
Posts: 70
Default

Quote:
Originally Posted by Justin View Post
Ahh I think I see what's going on. Fixing!
Excellent Justin. Was just preparing to post ini files for you. Let me know if you still want them.

What did you find was going on?
sensapaz is offline   Reply With Quote
Old 05-09-2022, 06:34 PM   #7
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,754
Default

Quote:
Originally Posted by sensapaz View Post
Excellent Justin. Was just preparing to post ini files for you. Let me know if you still want them.

What did you find was going on?
In older REAPER versions the DLL filename would be used first, and if the file wasn't found, it would fallback to the VST3 ID. We changed it to use the VST ID first, but if multiple plug-ins use the same VST3 ID, in 6.43+ (or so) it will use one of them (predictably but not with any useful logic).

So to fix -- if multiple plug-ins exist with the same VST3 ID, we'll only display/use the one that occurs in the later path. Coming in 6.58... (and it's in the current +dev build if you want to check out the pre-release forum).
Justin is offline   Reply With Quote
Old 05-09-2022, 11:08 PM   #8
sensapaz
Human being with feelings
 
Join Date: Mar 2021
Posts: 70
Default

Quote:
Originally Posted by Justin View Post
In older REAPER versions the DLL filename would be used first, and if the file wasn't found, it would fallback to the VST3 ID. We changed it to use the VST ID first, but if multiple plug-ins use the same VST3 ID, in 6.43+ (or so) it will use one of them (predictably but not with any useful logic).

So to fix -- if multiple plug-ins exist with the same VST3 ID, we'll only display/use the one that occurs in the later path. Coming in 6.58... (and it's in the current +dev build if you want to check out the pre-release forum).
Thanks Justin.

If possible, I think it would be helpful if the user guide reflected those dedupe rules a little more clearly (end of section 1.16, p. 24).
sensapaz is offline   Reply With Quote
Old 05-21-2022, 11:55 AM   #9
fieldswn
Human being with feelings
 
fieldswn's Avatar
 
Join Date: Oct 2006
Location: Wilmington, DE
Posts: 179
Default Breaking change

Oh no! Could you please make this optional?

My REAPER-based live performance system (10 years in the making) uses 7 instances of Surge VSTi. One for snares, one for kicks, etc. Each instance requires its own set of presets. To facilitate that, I create copies of the VST with different names, like this:

surge-snr.vst3
surge-bass.vst3
surge-bd.vst3
...

So they each show up as a separate plugin in REAPER with their own set of presets.

With the new version 6.58, this is no longer working. Only one instance of Surge appears.

Could you please make this optional?
__________________
williamfields.com
fieldswn is offline   Reply With Quote
Old 05-23-2022, 06:09 AM   #10
Justin
Administrator
 
Justin's Avatar
 
Join Date: Jan 2005
Location: NYC
Posts: 15,754
Default

Quote:
Originally Posted by fieldswn View Post
Oh no! Could you please make this optional?

My REAPER-based live performance system (10 years in the making) uses 7 instances of Surge VSTi. One for snares, one for kicks, etc. Each instance requires its own set of presets. To facilitate that, I create copies of the VST with different names, like this:

surge-snr.vst3
surge-bass.vst3
surge-bd.vst3
...

So they each show up as a separate plugin in REAPER with their own set of presets.

With the new version 6.58, this is no longer working. Only one instance of Surge appears.

Could you please make this optional?
The cleanest way would be to hex-edit these VST3 copies to have different UID16s ... or recompile Surge with those edits.


The next +dev build will have an option, if you could test it. It might break other things, though probably not things that would affect a live performance.
Justin is offline   Reply With Quote
Old 05-23-2022, 06:27 AM   #11
fieldswn
Human being with feelings
 
fieldswn's Avatar
 
Join Date: Oct 2006
Location: Wilmington, DE
Posts: 179
Default

Thank you Justin! 🙏

I will keep an eye out for the dev build and test the new option.
__________________
williamfields.com
fieldswn is offline   Reply With Quote
Old 05-23-2022, 10:31 AM   #12
EvilDragon
Human being with feelings
 
EvilDragon's Avatar
 
Join Date: Jun 2009
Location: Croatia
Posts: 24,800
Default

I want to ask - why complicate things like that with Surge?

What you could do is simply save presets you want as Reaper plugin presets, then you can program change between them just fine (proper Program Change support with per-instance program lists is eventually be implemented in Surge XT, but not this year).
EvilDragon is offline   Reply With Quote
Old 05-23-2022, 10:47 AM   #13
fieldswn
Human being with feelings
 
fieldswn's Avatar
 
Join Date: Oct 2006
Location: Wilmington, DE
Posts: 179
Default

Quote:
Originally Posted by Justin View Post
The next +dev build will have an option, if you could test it. It might break other things, though probably not things that would affect a live performance.
The new option in v6.58+dev0523 seems to be working. Thank you Justin!
__________________
williamfields.com
fieldswn is offline   Reply With Quote
Old 05-23-2022, 10:53 AM   #14
fieldswn
Human being with feelings
 
fieldswn's Avatar
 
Join Date: Oct 2006
Location: Wilmington, DE
Posts: 179
Default

Quote:
Originally Posted by EvilDragon View Post
I want to ask - why complicate things like that with Surge?

What you could do is simply save presets you want as Reaper plugin presets, then you can program change between them just fine (proper Program Change support with per-instance program lists is eventually be implemented in Surge XT, but not this year).
I am using REAPER plugin presets. But I need multiple different collections of presets. For example: one collection of presets for snares, one collection of presets for bass, etc.

The reason is that, for each one, I have a MIDI controller mapped to an instance of ReaControlMIDI, which in turn, is sending a Program Change message to Surge to select from the presets.

So, I guess my real requirement is to be able to have different sets of REAPER plugin presets for the same plugin. Is there is a better way to achieve that?


Thanks,
-Bill
__________________
williamfields.com
fieldswn is offline   Reply With Quote
Old 05-23-2022, 12:49 PM   #15
sensapaz
Human being with feelings
 
Join Date: Mar 2021
Posts: 70
Default

Quote:
Originally Posted by Justin View Post
The cleanest way would be to hex-edit these VST3 copies to have different UID16s ... or recompile Surge with those edits.


The next +dev build will have an option, if you could test it. It might break other things, though probably not things that would affect a live performance.
Hi Justin. Thinking more about my original issue and fieldswn's, I'm wondering if a couple of other enhancements would make sense. To put the handling of duplicate VSTs more in the hands of the user:

1. In Preferences > Plug-ins > VST
Add two check boxes. One for "allow duplicates by plug-in name" and another for "allow duplicates by plug-in source file name"

2. In the FX Browser > Options > Show in FX list > Duplicate plug-ins of different types...
Add options for "Show only 64-bit if present" and "Show only 32-bit if present"

3. In the FX Browser's FX list
Add a right-click option to "View plug-in file info," which could display plug-in name, file name, and path, to help tell the duplicates apart.

I think this combination of features could be really useful, both for diagnosing problems, or for having more flexibility for creative uses like what fieldswn is doing.

Regardless, thanks for listening.
sensapaz is offline   Reply With Quote
Old 06-04-2023, 03:43 AM   #16
PMdL
Human being with feelings
 
PMdL's Avatar
 
Join Date: Dec 2016
Posts: 17
Default VST3 x86 Bridged

Quote:
Originally Posted by sensapaz View Post
Hi Justin. Thinking more about my original issue and fieldswn's, I'm wondering if a couple of other enhancements would make sense. To put the handling of duplicate VSTs more in the hands of the user:

1. In Preferences > Plug-ins > VST
Add two check boxes. One for "allow duplicates by plug-in name" and another for "allow duplicates by plug-in source file name"
Hi, if I install 6.23, Reaper can load VST3 PlugIns (For example Wave VST3), while with 6.80 Reaper loads x86 Bridged.
I've tried to check "allow duplicates by plug-in name" and "allow duplicates by plug-in source file name" in Reaper 6.8, but I couldn't find it.
Now I've installed again 6.23.

Thank you
Attached Images
File Type: gif Cattura2.GIF (102.9 KB, 84 views)
PMdL is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 01:27 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.