"Reset VST plug-in information" not working

rrichard63 wrote on 11/3/2019, 9:15 PM

Has anybody encountered this situation? I'm in Music Maker 2019 Premium 27.0.2.28. After a clean reinstall, the program is still listing one subfolder of 32 bit VST plugins (all my Izotope plugins) as available in the track and master FX windows. Clicking on "Reset VST plug-in information" does not remove these plugins. I don't know why it picks the Izotope subfolder out of the several dozen subfolders in my VST plugins folder. And I don't know how to remove them from Music Maker's list.

Updating to Music Maker 2020 causes "Reset VST plug-in information" to crash Music Maker. This happens every time, not just once. That's why I uninstalled the 2020 version and reinstalled the 2019 version.

 

Comments

ralftaro wrote on 11/6/2019, 6:49 AM

Hi there,

First things first: In order to get any meaningful effect out of the button in the program settings to reset the VST plug-in information, you will *need* to have version 2020 (28.x) installed. This function was buggy/incomplete before, and did get fixed only now in generation 28.x to actually perform a proper and complete reset of the VST plug-ins. In version 2019 (27.x) it actually wouldn't have the full, desired effect, which is exactly what you're experiencing.

You can always achieve the desired effect of properly resetting the VST plug-in information stored by the program by simply manually finding and deleting the appropriate INI file, which is "VstPlugins.ini" found in the following location (using default installation settings):

C:\Users\<UserName>\AppData\Roaming\MAGIX\mm27\

(For an older or newer Music Maker version the last bit of the file path would have to be changed accordingly.)

 

As far as your problem in version 2020 goes (in which you could also apply the workaround solution above), are you positive the reset function is really *crashing* the program? Does the program actually terminate and give you a crash guard message? This doesn't happen for me. Maybe it's just a misinterpretation of what's going on, partly caused by some current shortcomings in Music Maker when it comes to scanning the VST plug-ins. Essentially, here's what happens when you trigger the VST reset function: First of all, the program dumps the VST INI and related information completely. However, it doesn't stop there. It triggers a scanning process of some VST default locations and starts rebuilding the INI again. Just like any VST scanning process you can trigger manually from Music Maker, this potentially takes a bit of time, and doesn't currently feature any kind of useful progress indication, which is a bit of a problem. This might easily give you the impression that the program is frozen. (If you start messing around with the system too much at that point, you might possibly even get it to fault or crash.) However, what's really needed is a bit of patience.

In my test setup, the reset just took what felt like several minutes (with not too many VST plug-ins installed on the system), due to the lengthy scanning of plug-ins. At that stage, while the program seemed to be frozen, I could open the location of the "VstPlugins.ini" in Windows file browser and watch its size grow, as it was being rebuild.

So, equipped with this information, maybe you want to give version 2020 another shot. I strongly recommend it, as it did fix many problems with the MIDI engine, MIDI device handlings etc. compared to version 2019, which might be relevant to your use case. If it comes down to it, you can always perform the VST plug-in reset as described above.

ralftaro wrote on 11/6/2019, 6:58 AM

Also, here's another idea as to what might be going on: If you're really experiencing an actual crash following the use of the VST reset button, the crash may not actually be part of the reset an inherent to this function, but it might be part of the VST plug-in rescan I described above. A specific, problematic 3rd-party plug-in somewhere in your VST folder paths may be causing the issue. You should be able to deny or confirm this hypothesis by e.g. manually throwing out the "VstPlugins.ini" as described above, and then triggering the rescan manually adding the VST path(s) again via the appropriate button. This would even enable you to add the relevant paths one by one, in order to narrow down which plug-in is causing (compatibility?) problems with Music Maker.

Well, I hope any of this input helps to steer you into the right direction. 🙂

Cheers!

 

rrichard63 wrote on 11/7/2019, 9:20 AM

Thanks for your help. I will try MMM 2020 again. Then I'll report back here.

(1) The first time, as you suspect "Reset VST plugin information" didn't completely crash the program. MMM just hangs indefinitely (longer than 10 minutes) -- it doesn't respond to any keystrokes or mouse clicks and can only be stopped in Windows Task Manager. And there's no information on the screen about what -- if anything --- "Reset VST plugin information" is doing, and no way to cancel the operation.

Feature request: when doing something like a plugin scan, the program needs to provide a little dialog with a progress bar and a "Cancel" command.

(2) Also, your responses suggest that "Reset VST plugin information" doesn't just forget the user-defined paths added with the command button to it's left ("Add VST plugin folder" or words to that effect). Apparently, it also rescans everything in a default path defined in the Windows registry. That's not what I thought, and not what I need. I need to be able to get MMM to ignore the path in the registry entirely.

Feature request: provide an option to ignore the default VST path in the Windows registry.

(3) I didn't mention this in my first post, but I found VSTplugins.ini and tried deleting everything that is not an MMM stock plugin. In MMM 2019, the result is that the program restores everything I deleted on startup -- it doesn't wait for the user to choose "Reset VST plugin information".

(4) Finally, MMM thinks that my default VST path is C:\VST32\Common\Izotope -- only one developer's products. If your description is correct, it should be scanning all of C:\VST32\Common, which is the path in the registry. I can't figure out why.

I will install MMM 2020 and let the scan run for several hours. I see that there's a new update since my previous post. Maybe this problem will go away.

Thanks again.

 

rrichard63 wrote on 11/7/2019, 11:49 AM

Updated again, this time to 28.0.2.43. (I believe that the previous experiment was with 20.0.0.12.) After reinstalling add-ons, clicked "Reset VST plugin information". Almost immediately, MMM showed up in Windows Task Manager as not responding. After about three minutes, got a new dialog box (new to me, never seen it before) headed "Music Maker doesn't work any more". Choose "Send error report" and linked to this thread in the field for additional information.

Either (1) the plugin scanner crashes when it reaches some undocumented limit on the number of plugins, or (2) I have a plugin that the scanner can't handle. If (2), the program provides no information at all on what the defective plugin might be, and therefore it is impossible for the user to correct the problem.

UPDATE WITH ADDITIONAL INFORMATION. I looked at VSTPlugins.ini as it was left after this most recent crash. First, the scanner stopped on the 73rd plugin (approximately, it's hard to count lines in a text file). This line reads:

"C:\VST32\Common\Akai\VIP.dll",512

In all the previous lines, the number in the the position where 512 is here is either 0 or 1. I suspect the 512 is some kind of error code.

Second, the plugins in the Izotope folder were gone (finally).

Please note, I have never told MMM to scan C:\VST32\Common. It can only have gotten that path from the Windows registry.

 

browj2 wrote on 11/7/2019, 12:49 PM

@rrichard63

Hi,

I presume that you're using Windows 10.

I don't know how you are getting these VST folders. I have no C:\VST32\Common folder on my computer

I have:

C:\Program Files (x86)\VSTPlugins

and I believe that this is what MusicMaker scans by default. This is where I have most of my VST/VSTi plugins.

I suggest that you at least temporarily remove/rename C:\VST32\Common so that Music Maker won't scan it.

Then check what you have under the correct location above and move anything out of there that Music Maker could possibly have trouble with. Make sure that you have no 64bit VST's that Music Maker could scan; they won't work.

Delete both the MusicMaker.ini and the VstPlugins.ini files and start again.

John CB

 

John C.B.

VideoPro X(16); Movie Studio 2024 Platinum; MM2025 Premium Edition; Samplitude Pro X8 Suite; see About me for more.

Desktop System - Windows 10 Pro 22H2; MB ROG STRIX B560-A Gaming WiFi; Graphics Card Zotac Gaming NVIDIA GeForce RTX-3060, PS; Power supply EVGA 750W; Intel Core i7-10700K @ 3.80GHz (UHD Graphics 630); RAM 32 GB; OS on Kingston SSD 1TB; secondary WD 2TB; others 1.5TB, 3TB, 500GB, 4TB, 5TB, 6TB, 8TB; three monitors - HP 25" main, LG 4K 27" second, HP 27" third; Casio WK-225 piano keyboard; M-Audio M-Track USB mixer.

Notebook - Microsoft Surface Pro 4, i5-6300U, 8 GB RAM, 256 SSD, W10 Pro 20H2.

YouTube Channel: @JCBrownVideos

rrichard63 wrote on 11/7/2019, 1:17 PM

(1) Windows 7 SP1. When the day comes that Windows 7 simply won't run any more, I will stop doing music on computers. Or, if I am very wealthy then, switch to Macintosh. I have Windows 10 on a separate laptop, unfortunately, and despise it with an unholy passion.

(2) There are reasons why I put all plugins in C:\VST32 (and C:\VST64 for 64-bit plugins). On my computer, C:\Program Files (x86)\VSTPlugins and C:\Program Files (x86)\Steinberg\VSTPlugins both exist but are always empty.

(3) I know from the above history that what Music Maker scans by default is not necessarily C:\Program Files (x86)\VSTPlugins. It is whatever path it finds in the Windows registry.

I will temporarily move everything from C:\VST32\Common and see what happens. But after that experiment I will have to move everything back for all of my other programs that host VST plugins.

 

rrichard63 wrote on 11/7/2019, 2:04 PM

Here is the resultsof my next experiment. Moving everything out of C:\VST32\Common (or C:\Program Files (x86)\VSTPlugins or whatever your default is) does make MMM remove all third-party plugins on startup, so you can start from scratch. But putting plugins back in the default location causes MMM to rescan them again on startup.

In other words, in order to make a plugin unavailable to MMM, I have to also make it unavailable to every other VST host on my system. I can use the "Add VST plugin folders" command to add more folders in addition to the default path. But I cannot remove the default path. For many of my other applications -- the ones that make it possible to ignore the Windows registry default -- there is a workaround that would allow me to use selected plugins in MMM. But that will probably not apply to every other VST host on my system, and would take a lot of work to implement.

I'm going to find out whether it's feasible to remove the feature pack that includes VST support. That depends on what other features it includes. If I'm not able to do that, I will have to abandon Music Maker, including my investment in soundpools, instruments, etc.

 

ralftaro wrote on 11/8/2019, 9:25 AM

Richard,

Just a few comments regarding your various observations and problems above:

Yes, the VST scanning process definitely does require a proper progress indicator again. This is on the agenda. In the long run, Music Maker will get a much improved VST plug-in handling and bridge, which it will probably inherit from the work that was done in ACID.

The program does indeed perform a plug-in scan on being started, which explains why you weren't able to simply take out a single plug-in from the INI file without that line in the file being repopulated later on.

I'm currently in touch with development to figure out whether there's any more elegant way to eliminate a problematic plug-in, other than manually isolating it into a different folder on your system, and adding that folder only in host programs that can handle that plug-in. However, for the time being, with the current VST engine in Music Maker, the answer might be "no". I'll keep you posted.

Cheers!