@sheppo yes, everything was reinstalled new. I also have Reaper installed, it is seeing these plugins and they are working. One observation, the Toontrack plugins are identified by Reaper as VSTi. The only plugins that appear to be loading in ACID are identified as VST3i by Reaper.

Is there a setting or checkbox somewhere that may be preventing VSTi from loading?

Sorry if this sounds like a simple answer, but you're trying to use these VSTIs (instruments) as an instrument, and not an audio plugin, right? I assume, as you say these are working on your other computer that you know the difference?

Also, is it the same version of the plugins, and the same version of Acid on both PCs? (Toon plugins have long been reported as having issues over time, so maybe on the new PC you've downloaded the latest version which is incompatible?)

@sheppo I am inserting as a soft synth, then routing the midi channel to it.

ACID literally does not see the plugins at all. I did an experiment on my desktop, having the exact same issues. They are not even showing up in Failed or Ignored folders.

Versions of ACID are identical, versions of Toontrack are identical. I really am dumbfounded why it's working on an older laptop with the same setup, but not loading on two newer systems.

yeah, that's an odd one for sure, and you've definitely tried all the obvious stuff already...

• judging by your list of plugins that ARE detected, would I be right in saying other plugins installed to the same path as toontrack are working just fine? If not, have you tried launching acid as administrator?
• Do you see any reference of the plugins in the VST grovel log? skipped plugins are at the bottom of the log file - which is, by default located somewhere like...
  C:\Users\USERNAME\AppData\Local\MAGIX\ACID Pro\10.0
• other than that I'm stumped and I'd suggest reaching out to support..

Hola amigos, soy nuevo en este post, uso ACID desde la primera version.

Aclaramos, que las versiones de VST ya son varias, aclarare estas dudas para Windows x32 y x64:

Para Wx32 vsti 1 a 2.0 de 16/32bits

Se ubican en la carpeta (C:/Archivos de Programa/vstplugins) o (C:/Archivos de Programa/steinberg/vstplugins)

Para Wx64 vsti2 de 32bits, se ubican en la carpeta

(C:/Archivos de Programa(x86)/vstplugins) o (C:/Archivos de Programa(x86)/steinberg/vstplugins)

Para Wx64 vsti2 de 64bits, se ubican en la carpeta

(C:/Archivos de Programa /vstplugins) o (C:/Archivos de Programa/steinberg/vstplugins)

Para Wx64 vsti3 de 64bits, se ubican en la carpeta

(C:/Archivos de Programa/Common files/vst3)

Se deben saber que tipo de vsti es, al instalar revisar y direccionar la instalación, igual para los vst de efectos.

En Acid10 es automática la carga de los vst, siempre y cuando estén en las carpetas correspondientes,

una vez que arranca se puede revisar en <insertar><Syntetizador Software> se mira un listado de instrumentos listos para trabajar.

Para probar, <ver> activar <Administrador de plugins CTRL+ALT+1> se puede ver los vst cargados

@sheppo the grovel file makes no mention of anything Toontrack related. And you are correct, the other non-Toontrack plugins are tested and working fine. I have reached out to ACID support team a few times over the last 4-5 month with no response about some other stuff too. Really at an impasse regarding what to do other than use different software. :(

@Rober-Estudio5 if Google translate worked correctly... I believe Superior Drummer is only available in 64 bit. I am certain the Plug-In Manager is pointing to where the VSTs are installed because they are working in other programs just fine.

that sounds very odd. If a vst is looked at by Acid it should appear in the grovel file whether it's added, skipped, an effect, or instrument.

a couple more things

1. the file properties of c:\program files\common files\vst3\superior drummer 3.dll in explorer, on both PCs, is exactly the same? both the file size and details tab - maybe the dll is somehow corrupt? (clutching at straws here :)
2. does running Acid as administrator help?
3. This comment... "I have copied all of the ToonTrack dll files to the folder where I can confirm other VSTs are loading from". Doesn't superior drummer 3 do that for you through the product manager? why did you manually copy and not use the installer? (I don't actually have this instrument, but I checked out the installation guide online)
4. there's a couple other log files related to the addition and scanning of plugins in the same folder as the vst grovel log. do you see any mention of the instrument in these?
   • acidpro_bridgeaware_plugincache_x64.xml - this looks like its related to the vst bridge
   • plugin_scan_state_VST*_x** - separate logs for VST2 and 3, and x64 and x32

@sheppo Sorry I missed this reply. Still have not solved the problem sadly. I've sent a couple emails to Torsten, but have received no response.

1) Yes, file was the same. DLL is fine because it is working in other programs.

2) No

3) It was a desperate attempt to move the DLL to a folder that I knew ACID was pulling VSTs from.

4) Neither of those log files mentions Superior Drummer or any ToonTrack plugins for that matter...

Now working fine for me in Acid Pro.

@Rednroll - thanks, marked your response as the solution unless we hear otherwise from @OMEB

I’ve seen a few people complaining about this plugin over the years so probably worth adding to the FAQ

@Rednroll THAT DID IT! I owe you a beer! I had moved it to a couple other folders manually but not like this.

@sheppo any insights why it's being so finicky over what folder it's in?

@sheppo any insights why it's being so finicky over what folder it's in?

I'm going to read the tea leaves somewhat on this since I recall SonyPCH (Peter) a developer from Sonic Foundry/Sony in the past describe in forum discussions when people complained VST2 plugins took so long to scan on startup. He described there is no other way for ACID to know if a .DLL file is a plugin or some other non plugin .DLL file without 1st loading the file upon scan and therefore each DLL would have to go through a loading process for Acid to figure out if it was actually a plugin or not. Thus increased scan and loading times on startup.

Part of the thing VST3 was suppose to solve was to include the ".VST3" file extension instead and also to have them so the installer makes the user install them to a default C:\Program Files\Common Files\VST3 plugin folder location, all so plugins were easier for a host to identify from non plugin files on your system which may be residing in those same folders. So with all that in mind I'm going to take a guess, one of those developers....possibly even Peter from Sony decided, "Now we only need to look for ".VST3" files and they should also only be located in that specific folder and we can speed up the scan time that some are complaining about by not having to load them on start up. So my guess would be the decision was made to recognize that if it was a .DLL file in that VST3 folder to no longer load it and confirm if it was a plugin or not like done in the other VST2 folders from the past, and then therefore just mark the DLL file as a failed plugin because the program never attempted to load it when scanning that folder to be able to know for certain.

Hindsight now being 20/20 and realizing there are some plugin developers who still use the .DLL file extension for VST3 plugins, Acid should have used the older behavior of loading the .DLL files if a .DLL was found under that VST3 folder. I'm certain this is likely the reason Reaper didn't have a problem with it being named a .DLL file in that VST3 folder. With Acid, someone seemed to try to fix one problem of long loading times on startup and unknowingly created another in the process by taking a short-cut method solution.

On a similar situation, I recently installed some Ample Sound VST3 instrument plugins. I noticed some of those plugins got installed under a "Ample Sound" sub folder under the VST3 folder, while others installed under the main VST3 folder. I like to keep my plugins organized by putting them all under a developer name folder, so I moved the ones under the main VST3 folder to the sub Ample Sound Folder. After a rescan, Acid still showed they were all available, but now over half of my Ample Sound plugins failed to load when attempting to add them as a virtual synth, also their names seemed to change as well in Acid and I could not get them to load within Acid no matter how many re-scans of the folder I attempted. I ended up having to try and remember which ones I moved to that sub Ample Sound folder and after moving just a couple of them back to the main VST3 folder, they all started to load correctly and work properly in Acid again. They worked fine in Reaper and the Ample Sound Stand alone host program...just not in Acid...again!

So Acid seems to be very finicky with VST3 plugins in regards to their file extension name and location within that VST3 folder they were originally installed. I had none of these problems with Reaper. I've been tempted multiple times to just give up on using Acid Pro due to these plugin problems and work through my personal challenges in Reaper instead. Reaper just works as you expect, where Acid I feel like I'm having to reverse engineer it whenever I run into a plugin not displaying or not loading within Acid which has been far too often. So far I've been able to resolve most of those problems except for one where my Relab LX480 reverb plugin 64bit version doesn't work in Acid but the 32 bit version does. Again 64bit version works fine in Reaper. I've definitely been on the edge of going back and forth between leaving Acid altogether. These have been some pretty important plugins to my workflow where I would rather have that plugin working than continue using Acid Pro. The "Pro" in the name seems to only be there by marketing virtue, not really in regards to it's robustness.

There just doesn't seem to be a lot of beta testing or Magix testing going on behind the scenes these days to identify these type of problems early on. I used to be on the Acid beta team during the Sonic Foundry and Sony days. I kind of feel like I'm still on the beta testing team today but now with the Acid prime time releases instead.

@Rednroll I've been using ACID more because the Audio side of VEGAS has really gone down hill the last 4-5 years with the broken VST bridge. I've use VEGAS since V1. So ACID has at least been a help to me recording in a familiar platform... but it seems even it has it's problems. Hopefully things get better soon!