Disabled VST's

[LAS100X]

I loaded some VSTs into mulab 2 and they show up in the plugin manager but it says they are disabled. The first one I loaded was ok...but the rest are disabled. I must add these came from the latest computer music magazine. Is this an issue of them being too old and not being compatible or is it something i'm missing?

oh....i'm running a new macbook w/ osx 10.5.4

[MuTools]

Maybe you're trying to open PPC plugins on an Intel machine..?

[pljones]

The issue of hitting a bad plugin and all subsequent ones being flagged as bad still exists in 2testC, depending on the bad plugin.

You have to edit the plugins file, find the first one of the ones marked bad at the end, then delete all the plugins after that one and rerun the scan.

[MuTools]

The issue of hitting a bad plugin and all subsequent ones being flagged as bad still exists in 2testC, depending on the bad plugin.

You have to edit the plugins file, find the first one of the ones marked bad at the end, then delete all the plugins after that one and rerun the scan.

That's a Windows issue.

[pljones]

I realise that Reaper doesn't necessarily take the same approach to scanning VSTs as MULAB but it doesn't end up failing to recognise some VSTs just because of one bad one in its scan. Whilst it may be an unrecoverable situation under Windows when scanning in MULAB, it's not a situation that seems to arise in Reaper.

What's the possibility of running the whole scan in an entirely separate process - its own address space - and halting on the first error, then restarting the process until the scan completed successfully? ("Success" meaning all plugins considered.) Essentially, this is what the user has to do now - run MULAB and scan, hit an error, quit MULAB (and edit the file), then restart MULAB and scan again.

[MuTools]

Whilst it may be an unrecoverable situation under Windows when scanning in MULAB, it's not a situation that seems to arise in Reaper.

Strange indeed.

MU.LAB just uses 'LoadLibrary' to load a plug, nothing more nothing less.

Essentially, this is what the user has to do now - run MULAB and scan, hit an error, quit MULAB (and edit the file), then restart MULAB and scan again.

Not on the system here.

When a plug is not recognized or fails to open, MU.LAB takes note of that in the plug database, and scanning just continues with the next file.

So it seems to be system dependent.

Didn't we already conclude this when we first talked about this some months ago? I'm not sure. Which thread was that, do you remember?

Are there any other users who have this situation on Windows:

When doing a 'big' scan of vst plugins, and 1 vst plugin fails, then all next vst plugins also fail?

[pljones]

It was this thread, which sort of petered out when Cakewalk said they'd fix Rapture -- that not being the point here. I keep the version that crashes as a test of MULAB's scan. (I don't know whether they have indeed issued a fix.)

http://www.drealm.info/mu.lab/Scan1.png - Gets as far a Rapture then gives up
http://www.drealm.info/mu.lab/Scan2.png - The error dialog visible after closing MULAB

I have several other "(disabled)" DLLs as a result of the scan, for example sfArkDLL and a couple of DXi instruments, along with some failing VSTs: Blue Cat Phaser VST(Mono) (the stereo version passed), (and old version of) CM Vocoder, gpuChorusVST and the "ameobe"-skinned version of Triangle I.

When running a scan in Reaper, Rapture causes a Reaper popup saying "Rapture executed an invalid operation" and that if Reaper crashes, just rerun and rescan. CM Vocoder gets the same message. So does the "ameobe"-skinned version of Triangle I. However, the scan completes without skipping any.

[MuTools]

It was this thread, which sort of petered out when Cakewalk said they'd fix Rapture -- that not being the point here. I keep the version that crashes as a test of MULAB's scan. (I don't know whether they have indeed issued a fix.)

http://www.drealm.info/mu.lab/Scan1.png - Gets as far a Rapture then gives up
http://www.drealm.info/mu.lab/Scan2.png - The error dialog visible after closing MULAB

I have several other "(disabled)" DLLs as a result of the scan, for example sfArkDLL and a couple of DXi instruments, along with some failing VSTs: Blue Cat Phaser VST(Mono) (the stereo version passed), (and old version of) CM Vocoder, gpuChorusVST and the "ameobe"-skinned version of Triangle I.

When running a scan in Reaper, Rapture causes a Reaper popup saying "Rapture executed an invalid operation" and that if Reaper crashes, just rerun and rescan. CM Vocoder gets the same message. So does the "ameobe"-skinned version of Triangle I. However, the scan completes without skipping any.

2 questions:

1) Which Windows version do you use?

2) When Test D is there, choose Help menu -> Help Functions -> Start Logging. Then do a fresh scan which includes the problem. Then please email me the latest Log-...txt in your mulab folder. Chance is low that i'll find something new, but it's worth trying it.

[pljones]

1) XP SP3 32bit
2) When Test D is here...

[pljones]

2) When Test D is here...

Test D is here and so is the scan:
http://www.drealm.info/mu.lab/Log-20080830-090555.txt


...
Scanning /I:/Program Files/Vstplugins/BlueCat/Blue Cat Phaser VST(Mono).dll
VstPluginManagerClass[120]:
...
What's that one? It ends up disabled.


...
Scanning /I:/Program Files/Vstplugins/Cakewalk/Rapture/Rapture.dll
VstPluginManagerClass[96]: Exception while creating aeffect for Rapture.dll
Scanning /I:/Program Files/Vstplugins/Camel Audio/Cameleon5000Demo/Cameleon5000.dll
VstPluginManagerClass[120]: Invalid access to memory location.
...
And then same to end of scan.

[MuTools]

2) When Test D is here...

Test D is here and so is the scan:
http://www.drealm.info/mu.lab/Log-20080830-090555.txt

Thanks.

...
Scanning /I:/Program Files/Vstplugins/BlueCat/Blue Cat Phaser VST(Mono).dll
VstPluginManagerClass[120]:
...
What's that one? It ends up disabled.

It means Windows 'LoadLibrary' function failed for that vst plugin.

Normally there is a detailed error description given by Windows, but not here.

It's a failure outside MU.LAB, no idea why.

Scanning /I:/Program Files/Vstplugins/Cakewalk/Rapture/Rapture.dll
VstPluginManagerClass[96]: Exception while creating aeffect for Rapture.dll
Scanning /I:/Program Files/Vstplugins/Camel Audio/Cameleon5000Demo/Cameleon5000.dll
VstPluginManagerClass[120]: Invalid access to memory location.
...
And then same to end of scan.

Mmm, indeed.

As you can see, all next plugins fail at the same point: when doing Windows 'LoadLibrary' for the .dll.

No idea why, but it looks like Rapture corrupts the memory somewhere in one of the dlls it loads. And maybe there isn't a cleanup after Rapture fails, and so the corrupted dlls stay in the mulab process space. That's my wild guess. I don't know of a (relative cheap wrt dev-time) way how to unload all unrefernced dlls from the process space, and even then, i guess if the dlls are not cleaned up properly, their reference count won't be properly decremented as well i assume.

[MuTools]

If this problem only occurs with Rapture, then practical solution is:

-> do the full scan
-> ok, it fails at rapture and all nexts
-> quit mulab
-> edit vstplugins.xml so that the Rapture section contains <Valid>0</Valid>
-> delete all next entries after Rapture so that they will be scanned again
-> eventually delete the VstPluginScanLog.txt
-> relaunch mulab and continue the scan

It's a couple of steps to bypass a difficult/quircky problem.

Would that work for you?

[pljones]

That's what I've been doing. I'm only repeating the problem to see if there's anything new you can throw at it.

[MuTools]

Ok, i see.

Will keep my eye open to find some windows api call that could help here.

Oh, and i always forget to ask: Is Rapture the only vst which is causing this issue, or are there others that fail and then cause all nexts to fail to in the scan? (sorry if i forgot)

[pljones]

For me, it's just Rapture yes. I don't remember seeing any others reported, either.