Any better plugin/waves compatibly w/DP11 on w10?

[CharlzS]

If DP or your plugins update, plugins can disappear again, and you're back to square one. The recent DP 11.03 update has completely broken it for me, to the point that I've uninstalled and just won't bother with it. It's far too much work. There aren't enough hours in the day for me to mess with this anymore.

I can't speak on Waves, specifically, as I don't use their plug-ins.

Sorry to hear your troubles, but this has not been my experience. I have never had a plug disappear. As far as validation across different machines, I have three VST2 plugs that do not validate on two different machines. One machine is an i7 laptop and the other is Xeon workststion. UVI DrumReplacer and the Korg MonoPoly and Korg ARP Odyssey fail on both architectures and all the other VST2 validate with no issues - Izotope, Softube, Korg, Flux, Arturia, McDSP, NI, VSL and Toontrack. I run all the Korg VSTis in VEP anyway, so no issue. There are some issues with VST3 - a few single plugs from multiple vendors (McDSP 6030 Comp, Massive X, a couple of IZ Neutron plugs) do not validate, but that's pretty much it. The plugs are consistent across both PCs. Stuff not validating is not unique to DP. None of my Softube VST3 plugs validated in Studio One (that may have been remedied by an update, but I have not revisited it). The Waves (PSP, etc.) issue was something completely different and unique to how DP was handling the video. Since you're not using those then no issue. You might want to give one last look at how/where the plugs are installed.

[pencilina]

iT, I too am sorry to hear about your travails. I’m basically in the same boat as Charlesz. Despite how terrible DP’s VST validation process is, I’m usually able to rescan and get plug ins working and haven’t had any issues with windows asio drivers- MOTU, KMI and RME are as good as they can be. That said I’ve pretty much given up on ‘doze as a viable platform for creative work and VST validation in Mojave doesn’t seem to be any better.

[iTrensharo]

iT, I too am sorry to hear about your travails. I’m basically in the same boat as Charlesz. Despite how terrible DP’s VST validation process is, I’m usually able to rescan and get plug ins working and haven’t had any issues with windows asio drivers- MOTU, KMI and RME are as good as they can be. That said I’ve pretty much given up on ‘doze as a viable platform for creative work and VST validation in Mojave doesn’t seem to be any better.

Windows has been fine for creative work. Honestly, it has been as smooth as a Mac, for me. I was on macOS up until Mojave, or maybe Catalina. One of those. I prefer having a machine that I can easily upgrade myself, though. The iMac became regrettable from that standpoint. I can easily spread costs across a long time span on Windows, and benefit from decreasing component costs.

I really like DP as a DAW. I just can't reliably use my stuff with it. I didn't mind replacing the audio interface. I was kind of desperate for it to work out. I like it that much. Hard to explain. Wasn't really a matter of "OMG, so much better than DAW_01" but more a matter of "I really just... like using this software." Same reason many would buy a Mac over a PC, I guess.

I think they are just running into troubles with the VST Validation because they have historically used a system more similar to what Avid does with Pro Tools and AVX plug-ins. The lack of MAS support from 3rd parties (generally speaking) has basically forced them into VST on Windows. I think going through MAS is what is causing all of the issues.

They are issuing me a refund.

[pencilina]

They are issuing me a refund.

!!! Impressive !!! Seriously, well done. MOTU works slowly in fixing stuff but they usually do. Im glad they did the right thing instead of insisting the problem was solely on your end (or maybe you were able to relentlessly convince them it wasn’t). As far as windows goes I use a win laptop for bigwig and pre-production in DP but I adore my Mojave hackintosh. I can just fly through work with different media types, software and hardware and the OS sort of disappears, Im able to focus on creative choices and I get stuff done. That said the next upgrade will be hell but I’ll probably wait a few years and then grab an M1 machine once everything is fully native and working. Good luck to you and if you come back to DP when the kinks are worked out we’ll see you.

[Michael Canavan]

If DP or your plugins update, plugins can disappear again, and you're back to square one. The recent DP 11.03 update has completely broken it for me, to the point that I've uninstalled and just won't bother with it. It's far too much work. There aren't enough hours in the day for me to mess with this anymore.

I can't speak on Waves, specifically, as I don't use their plug-ins.

Sorry to hear your troubles, but this has not been my experience. I have never had a plug disappear. As far as validation across different machines, I have three VST2 plugs that do not validate on two different machines. One machine is an i7 laptop and the other is Xeon workststion. UVI DrumReplacer and the Korg MonoPoly and Korg ARP Odyssey fail on both architectures and all the other VST2 validate with no issues - Izotope, Softube, Korg, Flux, Arturia, McDSP, NI, VSL and Toontrack. I run all the Korg VSTis in VEP anyway, so no issue. There are some issues with VST3 - a few single plugs from multiple vendors (McDSP 6030 Comp, Massive X, a couple of IZ Neutron plugs) do not validate, but that's pretty much it. The plugs are consistent across both PCs. Stuff not validating is not unique to DP. None of my Softube VST3 plugs validated in Studio One (that may have been remedied by an update, but I have not revisited it). The Waves (PSP, etc.) issue was something completely different and unique to how DP was handling the video. Since you're not using those then no issue. You might want to give one last look at how/where the plugs are installed.

It's definitely a configuration issue IMO. The fact you're not experiencing the issue points towards some problem other than a global issue, i.e. it's a rare bug that he caught with his particular software configuration, or VST folder location. It's too late to get iTrensharo to do this but the culprit if it isn't a folder location permission type issue, is likely an errant VST. It's definitely possible to have a VST hose the validation process.

[iTrensharo]

If DP or your plugins update, plugins can disappear again, and you're back to square one. The recent DP 11.03 update has completely broken it for me, to the point that I've uninstalled and just won't bother with it. It's far too much work. There aren't enough hours in the day for me to mess with this anymore.

I can't speak on Waves, specifically, as I don't use their plug-ins.

Sorry to hear your troubles, but this has not been my experience. I have never had a plug disappear. As far as validation across different machines, I have three VST2 plugs that do not validate on two different machines. One machine is an i7 laptop and the other is Xeon workststion. UVI DrumReplacer and the Korg MonoPoly and Korg ARP Odyssey fail on both architectures and all the other VST2 validate with no issues - Izotope, Softube, Korg, Flux, Arturia, McDSP, NI, VSL and Toontrack. I run all the Korg VSTis in VEP anyway, so no issue. There are some issues with VST3 - a few single plugs from multiple vendors (McDSP 6030 Comp, Massive X, a couple of IZ Neutron plugs) do not validate, but that's pretty much it. The plugs are consistent across both PCs. Stuff not validating is not unique to DP. None of my Softube VST3 plugs validated in Studio One (that may have been remedied by an update, but I have not revisited it). The Waves (PSP, etc.) issue was something completely different and unique to how DP was handling the video. Since you're not using those then no issue. You might want to give one last look at how/where the plugs are installed.

It's definitely a configuration issue IMO. The fact you're not experiencing the issue points towards some problem other than a global issue, i.e. it's a rare bug that he caught with his particular software configuration, or VST folder location. It's too late to get iTrensharo to do this but the culprit if it isn't a folder location permission type issue, is likely an errant VST. It's definitely possible to have a VST hose the validation process.

Lol. No. This is a funny read. Excuse me.

1. Contacted support. They [told me they] have gotten other reports of users having the same issue.

2. Not a configuration issue. Has nothing to do with any of that. These plugins do not fail to show up or work in any other Audio/Video application on either of my machines - and I have replicated the issue on two separate machines.

3. All of my plugins are installed in the system directories.

4. It's an issue MOTU is aware of, and I am not the only person who has reported it to them. I'm guessing the M-Audio ASIO Driver working with literally everything on my system EXCEPT DP11 is also a configuration issue, too?

C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 are both default system folders for VST2 and VST3 plug-ins. If an application cannot reliably function with plug-ins installed in those locations, then that application is broken, AFAIC.

%ProgramFiles% is a protected directory on Windows. Only Administrators have Write Access by default, but anyone can Read from %ProgramFiles%.

Therefore, it's easy to check for permissions issues, considering:

A. Any subdirectory of %ProgramFiles% inherits its permissions de facto, and
B. Any Files within %ProgramFiles% or its subdirectories inheret its permissions de facto.

So, %ProgramFiles%\Steinberg\VstPlugins has the same permissions by virtue of inhereting from Steinberg, which inherits from %ProgramFiles%

DAWs only need Read Access to this directory, which the system grants to any user or application by default, unless the administrator of the system changes this himself (which is likely to break more than just ONE DAW on the system). As a result, the easy check for permission errors is simply to do File -> Open in Digital Performer and navigate to C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 within that dialog. The File Open Dialog will be running with the permissions level of the Digital Performer DAW (the application that opened the dialog).

If the Open Dialog can navigate to those directories without a UAC Prompt or Permission Denied error, then ... the permissions issue does not exist.

Again, the DAW only needs READ access to access those locations. You'd have to be running DP on a very limited account, probably with additional - group policy-imposed limitations to have issue with that. I am not.

Lastly, and most unremarkably, it should be known that user applications run by default under the permissions of your user account - so really, checking this in DP isn't REALLY necessary. If you can go to those locations in File Explorer, then any application you launch should be able to read from them without issue.

An errant VST is likely to cause issue in at least one other host. I have tried several to see if I could get any of those that trip up the validator to choke...

Cubase
Studio One
Cakewalk by BandLab
Sound Forge Pro
WaveLab
Samplitude Pro X4 (Known for flaky VST3 Support, so a nice stress test for them)
DaVinci Resolve Studio (Newly added VST3 Support, not even that robust... but works as expected)

This does not happen. They "just work." The issue is certainly not the VST Plug-ins.

In any case, the issue has been reported by other users, as I have been told this directly. So, they are aware of it. It's probably just a hard issue to fix, given the manner in which they support VST (by going through their MAS system, while many other DAWs support them directly) and how inconsistent it can be in terms of presentation.

1. What plug-ins Pass and Fail the validator is completely inconsistent across different machines, and even across VST Cache Clears on the same machine.

2. Updating a plug-in can push it from Pass -> Fail and vice versa, due to automatic Re-Validation when DP sees the change.

3. The Re-Validation can cause the plug-in to disappear from all plug-in choosers (again).

This means that someone at MOTU can look at a Windows system there and see something that appears to be working properly, while the end user is seeing different behavior. Whatever validation process they are using for VST is not reliably consistent, and this will make it a royal PITA to troubleshoot and find/target/fix any issues therein.

[Michael Canavan]

Sorry to hear your troubles, but this has not been my experience. I have never had a plug disappear. As far as validation across different machines, I have three VST2 plugs that do not validate on two different machines. One machine is an i7 laptop and the other is Xeon workststion. UVI DrumReplacer and the Korg MonoPoly and Korg ARP Odyssey fail on both architectures and all the other VST2 validate with no issues - Izotope, Softube, Korg, Flux, Arturia, McDSP, NI, VSL and Toontrack. I run all the Korg VSTis in VEP anyway, so no issue. There are some issues with VST3 - a few single plugs from multiple vendors (McDSP 6030 Comp, Massive X, a couple of IZ Neutron plugs) do not validate, but that's pretty much it. The plugs are consistent across both PCs. Stuff not validating is not unique to DP. None of my Softube VST3 plugs validated in Studio One (that may have been remedied by an update, but I have not revisited it). The Waves (PSP, etc.) issue was something completely different and unique to how DP was handling the video. Since you're not using those then no issue. You might want to give one last look at how/where the plugs are installed.

It's definitely a configuration issue IMO. The fact you're not experiencing the issue points towards some problem other than a global issue, i.e. it's a rare bug that he caught with his particular software configuration, or VST folder location. It's too late to get iTrensharo to do this but the culprit if it isn't a folder location permission type issue, is likely an errant VST. It's definitely possible to have a VST hose the validation process.

Lol. No. This is a funny read. Excuse me.

1. Contacted support. They [told me they] have gotten other reports of users having the same issue.

2. Not a configuration issue. Has nothing to do with any of that. These plugins do not fail to show up or work in any other Audio/Video application on either of my machines - and I have replicated the issue on two separate machines.

3. All of my plugins are installed in the system directories.

4. It's an issue MOTU is aware of, and I am not the only person who has reported it to them. I'm guessing the M-Audio ASIO Driver working with literally everything on my system EXCEPT DP11 is also a configuration issue, too?

C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 are both default system folders for VST2 and VST3 plug-ins. If an application cannot reliably function with plug-ins installed in those locations, then that application is broken, AFAIC.

%ProgramFiles% is a protected directory on Windows. Only Administrators have Write Access by default, but anyone can Read from %ProgramFiles%.

Therefore, it's easy to check for permissions issues, considering:

A. Any subdirectory of %ProgramFiles% inherits its permissions de facto, and
B. Any Files within %ProgramFiles% or its subdirectories inheret its permissions de facto.

So, %ProgramFiles%\Steinberg\VstPlugins has the same permissions by virtue of inhereting from Steinberg, which inherits from %ProgramFiles%

DAWs only need Read Access to this directory, which the system grants to any user or application by default, unless the administrator of the system changes this himself (which is likely to break more than just ONE DAW on the system). As a result, the easy check for permission errors is simply to do File -> Open in Digital Performer and navigate to C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 within that dialog. The File Open Dialog will be running with the permissions level of the Digital Performer DAW (the application that opened the dialog).

If the Open Dialog can navigate to those directories without a UAC Prompt or Permission Denied error, then ... the permissions issue does not exist.

Again, the DAW only needs READ access to access those locations. You'd have to be running DP on a very limited account, probably with additional - group policy-imposed limitations to have issue with that. I am not.

Lastly, and most unremarkably, it should be known that user applications run by default under the permissions of your user account - so really, checking this in DP isn't REALLY necessary. If you can go to those locations in File Explorer, then any application you launch should be able to read from them without issue.

An errant VST is likely to cause issue in at least one other host. I have tried several to see if I could get any of those that trip up the validator to choke...

Cubase
Studio One
Cakewalk by BandLab
Sound Forge Pro
WaveLab
Samplitude Pro X4 (Known for flaky VST3 Support, so a nice stress test for them)
DaVinci Resolve Studio (Newly added VST3 Support, not even that robust... but works as expected)

This does not happen. They "just work." The issue is certainly not the VST Plug-ins.

In any case, the issue has been reported by other users, as I have been told this directly. So, they are aware of it. It's probably just a hard issue to fix, given the manner in which they support VST (by going through their MAS system, while many other DAWs support them directly) and how inconsistent it can be in terms of presentation.

1. What plug-ins Pass and Fail the validator is completely inconsistent across different machines, and even across VST Cache Clears on the same machine.

2. Updating a plug-in can push it from Pass -> Fail and vice versa, due to automatic Re-Validation when DP sees the change.

3. The Re-Validation can cause the plug-in to disappear from all plug-in choosers (again).

This means that someone at MOTU can look at a Windows system there and see something that appears to be working properly, while the end user is seeing different behavior. Whatever validation process they are using for VST is not reliably consistent, and this will make it a royal PITA to troubleshoot and find/target/fix any issues therein.

You’re conflating things a bit here. I never said it wasn’t a critical bug, just that it’s rare enough configuration wise that it passed through their beta phase. Do you think their beta testers ignored it, or is it more likely they simply don’t have the same set up as you and hundreds possibly of other people? No company wants to release bugs, it’s just that the beta testers either don’t own enough plug ins, haves enough variations of configurations, and or don’t attempt enough things to catch the bugs.

You’re ticked off about this and I don’t blame you but this isn’t a rare thing, and I’m certain this VST disappearing bug you experienced hasn’t been a part of the Windows DP ecosystem forever, probably an 11 issue. I found a bug where hitting retrospective record for a third time will mess it up, and the fourth time will crash DP. It’s not anywhere near the crippling bug you have, but the point is this sort of thing isn’t some unusual event and you’re jumping to a lot of weird conclusions, most DAWs have a way off plugging various protocols into their internal audio system, it’s not the MAS plug in per say that’s the issue, it’s a bug period.

I mean if you want to play non coder, end user detective on why DP is having issues with VSTs, and specifically on Windows it’s probably due to their obviously buggy implementation of the Windows VST examination process, which is likely a batch of code that you can nab from Steinberg or at least get an idea of how to implement. It’s likely having issues with all the changes in 11, so at some point it will get addressed. Of course none of this means you and others need to wait around for them to fix it.

I’ve just done exactly what you’re doing now, about Logic, Live and DP. I found a crippling bug and declared the DAW garbage, which is very obviously not true for everyone, but I would rant on forums each time, declaring all kinds of things that were either patently wrong or proven to be a temporary problem fixed in an update. Anyway I’m glad you got through to tech support, that’s great for people on Windows who will continue to use DP, and good luck with whatever DAW you do use.

[CharlzS]

C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 are both default system folders for VST2 and VST3 plug-ins. If an application cannot reliably function with plug-ins installed in those locations, then that application is broken, AFAIC.

%ProgramFiles% is a protected directory on Windows. Only Administrators have Write Access by default, but anyone can Read from %ProgramFiles%.

Therefore, it's easy to check for permissions issues, considering:

A. Any subdirectory of %ProgramFiles% inherits its permissions de facto, and
B. Any Files within %ProgramFiles% or its subdirectories inheret its permissions de facto.

So, %ProgramFiles%\Steinberg\VstPlugins has the same permissions by virtue of inhereting from Steinberg, which inherits from %ProgramFiles%

On the VST2 install folders, I have never seen C:\Program Files\Steinberg\VstPlugins. If that wasn't a typo, then could be an issue. The old Steinberg install folder was C:\Program Files\Common Files\Steimberg\VST2, but I believe the current consensus is C:\Program Files\VSTPlugins. That's where I have everything installed an DP assumes the latter as the installation folder if nothing is specified in the additional folders preference. Even Steinberg defaulted to this for plugin support files when I installed Cubase and HALion a while back. McDSP and Waves used to use the old convention but have since changed. I know you're done with DP, but I would recommend anyone coming to PC to install all their VST2 plugs in C:\Program Files\vstplugins.

[iTrensharo]

C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 are both default system folders for VST2 and VST3 plug-ins. If an application cannot reliably function with plug-ins installed in those locations, then that application is broken, AFAIC.

%ProgramFiles% is a protected directory on Windows. Only Administrators have Write Access by default, but anyone can Read from %ProgramFiles%.

Therefore, it's easy to check for permissions issues, considering:

A. Any subdirectory of %ProgramFiles% inherits its permissions de facto, and
B. Any Files within %ProgramFiles% or its subdirectories inheret its permissions de facto.

So, %ProgramFiles%\Steinberg\VstPlugins has the same permissions by virtue of inhereting from Steinberg, which inherits from %ProgramFiles%

On the VST2 install folders, I have never seen C:\Program Files\Steinberg\VstPlugins. If that wasn't a typo, then could be an issue. The old Steinberg install folder was C:\Program Files\Common Files\Steimberg\VST2, but I believe the current consensus is C:\Program Files\VSTPlugins. That's where I have everything installed an DP assumes the latter as the installation folder if nothing is specified in the additional folders preference. Even Steinberg defaulted to this for plugin support files when I installed Cubase and HALion a while back. McDSP and Waves used to use the old convention but have since changed. I know you're done with DP, but I would recommend anyone coming to PC to install all their VST2 plugs in C:\Program Files\vstplugins.

The generic standard is C:\Program Files\Steinberg\VstPlugins- for VST3, this has been moved to a vendor neutral base directory under Common Files - similar to the OpenFX component directory for Video Plug-ins.

The only time the default ends up being something else, is when you install a plug-in package on a fresh machine and it defaults to a different location. In that case, it writes that location into the Windows Registry. The location in the registry is what well-written installers will reference when offering the installation location on your machine...

Steinberg defaults to installing their plug-ins in the aforementioned location, as do countless others on Windows.

It's impossible for C:\Program Files\Common Files\VST2 to have been the default as VST Pre-Dates Windows XP and "Common Files" did not exist on Windows 9x. No one was generating this directory on Windows 98 maschines for VST Plug-ins... The generic default has been the Steinberg directory because, when the VST SDK was released, Steinberg was the only vendor that had developed VST Plug-ins or Virtual instruments.

I have seen installers suggest everything from:

C:\Program Files\Common Files\VST2 - ironically, only recent installers like MAGIX coreFX/wizardFX Suite I've seen do this.

C:\VstPlugins - Often Older Plug-in installers, or those from vendors that used this path earlier on due to file path limitations.

C:\Program Files\VstPlugins - far more common than the other two, and was useful for shaving characters off the file path if you had nested directory structures in there, due to NTFS 256 character limitation for file paths. This is generally why vendors have erred towards suggesting this directory.

But well written installers will reference the Windows Registry and suggest the base path provided there, which is often the first one a user accepts (or writes in) when installing plug-ins.

Vendors usually used an application subdirectory for their own bundled plug-ins (Steinberg does this for Cubase's stuff, for example, as did SONAR, Samplitude Pro X and countless others).

[iTrensharo]

It's definitely a configuration issue IMO. The fact you're not experiencing the issue points towards some problem other than a global issue, i.e. it's a rare bug that he caught with his particular software configuration, or VST folder location. It's too late to get iTrensharo to do this but the culprit if it isn't a folder location permission type issue, is likely an errant VST. It's definitely possible to have a VST hose the validation process.

Lol. No. This is a funny read. Excuse me.

1. Contacted support. They [told me they] have gotten other reports of users having the same issue.

2. Not a configuration issue. Has nothing to do with any of that. These plugins do not fail to show up or work in any other Audio/Video application on either of my machines - and I have replicated the issue on two separate machines.

3. All of my plugins are installed in the system directories.

4. It's an issue MOTU is aware of, and I am not the only person who has reported it to them. I'm guessing the M-Audio ASIO Driver working with literally everything on my system EXCEPT DP11 is also a configuration issue, too?

C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 are both default system folders for VST2 and VST3 plug-ins. If an application cannot reliably function with plug-ins installed in those locations, then that application is broken, AFAIC.

%ProgramFiles% is a protected directory on Windows. Only Administrators have Write Access by default, but anyone can Read from %ProgramFiles%.

Therefore, it's easy to check for permissions issues, considering:

A. Any subdirectory of %ProgramFiles% inherits its permissions de facto, and
B. Any Files within %ProgramFiles% or its subdirectories inheret its permissions de facto.

So, %ProgramFiles%\Steinberg\VstPlugins has the same permissions by virtue of inhereting from Steinberg, which inherits from %ProgramFiles%

DAWs only need Read Access to this directory, which the system grants to any user or application by default, unless the administrator of the system changes this himself (which is likely to break more than just ONE DAW on the system). As a result, the easy check for permission errors is simply to do File -> Open in Digital Performer and navigate to C:\Program Files\Steinberg\VstPlugins and C:\Program Files\Common Files\VST3 within that dialog. The File Open Dialog will be running with the permissions level of the Digital Performer DAW (the application that opened the dialog).

If the Open Dialog can navigate to those directories without a UAC Prompt or Permission Denied error, then ... the permissions issue does not exist.

Again, the DAW only needs READ access to access those locations. You'd have to be running DP on a very limited account, probably with additional - group policy-imposed limitations to have issue with that. I am not.

Lastly, and most unremarkably, it should be known that user applications run by default under the permissions of your user account - so really, checking this in DP isn't REALLY necessary. If you can go to those locations in File Explorer, then any application you launch should be able to read from them without issue.

An errant VST is likely to cause issue in at least one other host. I have tried several to see if I could get any of those that trip up the validator to choke...

Cubase
Studio One
Cakewalk by BandLab
Sound Forge Pro
WaveLab
Samplitude Pro X4 (Known for flaky VST3 Support, so a nice stress test for them)
DaVinci Resolve Studio (Newly added VST3 Support, not even that robust... but works as expected)

This does not happen. They "just work." The issue is certainly not the VST Plug-ins.

In any case, the issue has been reported by other users, as I have been told this directly. So, they are aware of it. It's probably just a hard issue to fix, given the manner in which they support VST (by going through their MAS system, while many other DAWs support them directly) and how inconsistent it can be in terms of presentation.

1. What plug-ins Pass and Fail the validator is completely inconsistent across different machines, and even across VST Cache Clears on the same machine.

2. Updating a plug-in can push it from Pass -> Fail and vice versa, due to automatic Re-Validation when DP sees the change.

3. The Re-Validation can cause the plug-in to disappear from all plug-in choosers (again).

This means that someone at MOTU can look at a Windows system there and see something that appears to be working properly, while the end user is seeing different behavior. Whatever validation process they are using for VST is not reliably consistent, and this will make it a royal PITA to troubleshoot and find/target/fix any issues therein.

You’re conflating things a bit here. I never said it wasn’t a critical bug, just that it’s rare enough configuration wise that it passed through their beta phase. Do you think their beta testers ignored it, or is it more likely they simply don’t have the same set up as you and hundreds possibly of other people? No company wants to release bugs, it’s just that the beta testers either don’t own enough plug ins, haves enough variations of configurations, and or don’t attempt enough things to catch the bugs.

You’re ticked off about this and I don’t blame you but this isn’t a rare thing, and I’m certain this VST disappearing bug you experienced hasn’t been a part of the Windows DP ecosystem forever, probably an 11 issue. I found a bug where hitting retrospective record for a third time will mess it up, and the fourth time will crash DP. It’s not anywhere near the crippling bug you have, but the point is this sort of thing isn’t some unusual event and you’re jumping to a lot of weird conclusions, most DAWs have a way off plugging various protocols into their internal audio system, it’s not the MAS plug in per say that’s the issue, it’s a bug period.

I mean if you want to play non coder, end user detective on why DP is having issues with VSTs, and specifically on Windows it’s probably due to their obviously buggy implementation of the Windows VST examination process, which is likely a batch of code that you can nab from Steinberg or at least get an idea of how to implement. It’s likely having issues with all the changes in 11, so at some point it will get addressed. Of course none of this means you and others need to wait around for them to fix it.

I’ve just done exactly what you’re doing now, about Logic, Live and DP. I found a crippling bug and declared the DAW garbage, which is very obviously not true for everyone, but I would rant on forums each time, declaring all kinds of things that were either patently wrong or proven to be a temporary problem fixed in an update. Anyway I’m glad you got through to tech support, that’s great for people on Windows who will continue to use DP, and good luck with whatever DAW you do use.

It's no rare.

I've reproduced it on two separate machines here, and they've gotten reports from other people reporting the same issues. They've stated this to me directly.

In any case, I am not mad, because I was always going to ask for a refund if it weren't rectified. It wasn't, and I did, and I got what I asked for. Nothing to be ticked off about, really.

But to state that this is "rare" is ... well... a blatant untruth. I'll just leave it at that.

And I've never seen a DAW bug out over what I told it to search for VST Plug-ins, particularly when that DAW gives you [practically] infinite fields to enter in different locations.

The issue wasn't the location. The plug-ins were scanning, and in some cases they were passing the validator but still not being made available for access in DP. If I reinstalled some of them, withi the same exact revision of the software, they would sometimes show up. If I reinstalled DP on the same machine, different plugins can be bugged out. Reinstalling some may get them to show up. Revalidating some may get them to show up.

But never have I been able to get it to make all of my plug-ins (that passed validation) available for use... and often it wasn't even a forgettable plug-in that was missing. It was something like Kontakt and Komplete Kontrol, or a bunch of iZotope, etc.

If it were just ValhallaFreqEcho that was missing, I'd have just installed that plug-in, kept the DAW, and went on with my life

[Michael Canavan]

But to state that this is "rare" is ... well... a blatant untruth. I'll just leave it at that.

You should take the whole quote into consideration.

I never said it wasn’t a critical bug, just that it’s rare enough configuration wise that it passed through their beta phase. Do you think their beta testers ignored it, or is it more likely they simply don’t have the same set up as you and hundreds possibly of other people?

You skip a word or two there. I mean do you think their beta testers caught this and MOTU released it anyway? You have to admit that's unlikely, or maybe you do think that's what happened, I don't know?

MOTU beta test their software, your particular configuration somehow wasn't tested, that's obvious.
IMO this means they need to expand their Windows beta pool, if issues like this pass.