every time when i launch my MPT, it will verify my plugin. and i have the plugin like FL Studio VSTi, it will takes a lot of time. how can i bypass that? (sorry for my Chinese style English ;D)
I can confirm it also happens on of my my computer.
This should not happen under normal circumstances - OpenMPT should only check if the plugin exists, but not load it. It may have to load the plugin if there are two copies of an identically-named plugin registered in different paths, e.g. if you have a a plugin C:\foo\bar.dll and another plugin C:\bar.dll - this is about the only situation in which plugins should be scanned during startup. So please verify that there is only one copy of the plugin in OpenMPT's plugin list. If you are not sure if there are identically-named plugins in that list, you can also go to Help -> Show Settings Folder, open mptrack.ini and copy the [VST Plugins] section from that file.
On particular circumstances I use same filename, e.g. Synth1 VSTi has 32-bit and 64-bit, and for platform portability plugins are placed as ".\Daichi\Synth1 VSTi\x86\Synth1 VSTi.dll" and ".\Daichi\Synth1 VSTi\x64\Synth1 VSTi.dll" when exist for x86 and x64. The majority of songs need to use this path pattern instead its original filename, so can be loaded on OpenMPT 32/64-bit natively when possible.
In OpenMPT 1.27.00.15 (r7259), the plugin manager should no longer be confused about several plugins sharing the same filename. Note that the plugin cache file had to be restructured for this purpose, so a full rescan of all registered plugins will happen on first start.
So did anyone try this using the latest buildbot versions (https://buildbot.openmpt.org/builds/)?
Quote from: Saga Musix on November 21, 2016, 23:53:26
So did anyone try this using the latest buildbot versions (https://buildbot.openmpt.org/builds/)?
yes. but it's still love to scan my computer... haha...
maybe it will work on my OS X...
That's strange. Can you please go to Help -> Show Settings Folder in OpenMPT and then upload the mptrack.ini and plugin.cache files from that directory here (put them in a zip file)? Also, please paste the location of these files (the folder path in Explorer) here.
Quote from: Saga Musix on November 25, 2016, 13:15:41
That's strange. Can you please go to Help -> Show Settings Folder in OpenMPT and then upload the mptrack.ini and plugin.cache files from that directory here (put them in a zip file)? Also, please paste the location of these files (the folder path in Explorer) here.
plugin location:
32bit: D:/VSTplugin
64bit: D:/VSTplugin/Program Files
software: D:/OpenMPTh
Please also provide the plugin.cache file that should be found next to mptrack.ini.
D:\OpenMPT is just the path where the OpenMPT executable is located I guess, but the INI file suggests that it is not run in portable mode, so the mptrack.ini location should not be D:\OpenMPT but more something like C:\Users\<your user name>\AppData\Roaming\OpenMPT. Can you give the full path for that?
EDIT: The mptrack.ini file suggests that you were using OpenMPT 1.26.03.00, which is neither the latest stable version, nor is it the test version I asked you to test. In case you did use the latest test version, then it's the wrong mptrack.ini for some reason.
I had the idea that the extended plugin verification time can also be caused by antivirus software.
To verify that, please check:
1) If you run OpenMPT a second time instantly after closing it, does it still take as long to scan the plugins, or is it quicker?
2) If that is not the case (or alternatively, after a reboot), check if disabling your antivirus speeds up the scan process.
Quote from: Saga Musix on December 01, 2016, 18:36:11
I had the idea that the extended plugin verification time can also be caused by antivirus software.
To verify that, please check:
1) If you run OpenMPT a second time instantly after closing it, does it still take as long to scan the plugins, or is it quicker?
2) If that is not the case (or alternatively, after a reboot), check if disabling your antivirus speeds up the scan process.
Sorry to you for waiting a long time for my reply.
I tried it on my new computer (Windows10 Simplified Chinese 64bit) and the time has shorten to about 3 sec!
Thanks for your help!
Sounds to me like antivirus might indeed have been involved then. If Rakib and jmkz could give some input on that as well, that would be even more reassuring.
Which version to test?
Im using version: 1.26.07.00 32 bit
Source Code: clean
For the case you have plugins sharing the same filename: r7259 or later from buildbot.
For the general checks to test if antivirus affects the loading time (as explained above): Current stable is okay.
I got plugin verify first time after updating to a test-build, but now its gone.
Okay, as mentioned before, the new version will have to rescan all plugins once since the cache format has changed. If it starts being slow again (e.g. after the next system restart), it's most likely going to be an antivirus issue (they often lock files that are being accessed until they have fully scanned the file).
No its very fast now. No problems with the update. Thanks alot.
Edit: Whats up with the vu-meter colors now?
Quote from: Rakib on December 07, 2016, 21:38:39
Edit: Whats up with the vu-meter colors now?
We now have VU meters for VSTis (https://forum.openmpt.org/index.php?topic=2006.0), and by default they have a different colour than sample-based channels.
Whenever I have 2 versions of modplug and open them after eachother (I dont normally open them at the same time) the vst plugins check the cache and sometimes throw up information dialogues etc, I've just come to accept this is how modplug behaves when you have different versions of it. but if I stick to 1 modplug it goes through them quick, which is awesome :)
You can run as many OpenMPT instances in parallel as you like. There should be no dialogs. What does this dialog tell you?
Quote from: Saga Musix on January 28, 2017, 19:30:19What does this dialog tell you?
Loads of them I'll write them down, but they are mostly specific to the plugin it is loading, so let me just check so I can get you some of them... it's not a big deal because as I said it works fine most of the time, and I do think some of it has something to do with the sheer number of free plugins I have installed everywhere I have a modplug :P
bit overkill maybe...
So maybe the first three:
1: cannot execute modplug vsti, (I should just get it out, but I'll check if it works, not everything is ideally set up on this laptop modplug, what I did know about was clone vsts if I have two of the exact same vst in different places and modplug has them both it slows things down sometimes) press ok
[edit] checked and yeah the openmodplugvsti I have isnt working at all... will maybe grab another or not use it
2: dumbass donationware message - press ok
3: serial number for dahornet, I keep meaning to get to that :P
those are just the first three, and I did try to make it clear that this only happens if I swap from one modplug to the other (by closing one down and going to the other) I dont generally have them both open at the same time, but I will check if it does that too, but it might also be because the other modplug I have is the one you are busy working on at the moment, the one you pointed me to for the midi.
[edit] yeah it's taking its time and giving messages for the load
another message that comes up and seems quite worrying at first is that the whole thing has crashed, send a report... I click cancel and it continues loading. o_O anyways... figured that one out a while back
Anyways what I have been trying to say is I consider modplug an incredible piece of software so I put up with a few foibles here and there, this extra loading time going through each vst is one of those things I have encountered plenty of times in the past and is not something I hold against modplug in any way, if it hits I normally just try and do something else until the software is open. I generally blame myself and my vsts, for any problem :)
Okay uhm... just to be sure, do you try to use the same OpenMPT version side-by-side or is it an instance of OpenMPT 1.26 and an instance of OpenMPT 1.27? Because as stated above, OpenMPT 1.27 has a different plugin cache format so if you keep switching between those two versions the plugin cache will get regenerated each time. But if you keep using OpenMPT 1.27, there is no reason why it should show those boxes on each startup.
Quote from: Saga Musix on January 29, 2017, 00:39:36
Okay uhm... just to be sure, do you try to use the same OpenMPT version side-by-side or is it an instance of OpenMPT 1.26 and an instance of OpenMPT 1.27? Because as stated above, OpenMPT 1.27 has a different plugin cache format so if you keep switching between those two versions the plugin cache will get regenerated each time. But if you keep using OpenMPT 1.27, there is no reason why it should show those boxes on each startup.
You are spot on there, see I knew it was simple architecture thanks for explaining it though, that is precisely what is happening the two different versions and plugin cache regenerating. Well now I know what to call it at least :P
from my first post : "Whenever I have 2 versions of modplug and open them after eachother" if they had been the same version but different instances I would have said so, or maybe used the word copy (two instances of modplug open, two copies of modplug open)
Quotefrom my first post : "Whenever I have 2 versions of modplug and open them after eachother" if they had been the same version but different instances I would have said so, or maybe used the word copy (two instances of modplug open, two copies of modplug open)
Sure it could have been an indicator, but:
1) People use all kind of wrong terminolgy so I filter it away automatically
2) This issue is specific to the transition to OpenMPT 1.27. For example, unless something weird happens, upgrading to OpenMPT 1.28 from OpenMPT 1.27 will not have the same issue. ;)
Quote from: Saga Musix on January 29, 2017, 00:58:36
Sure it could have been an indicator, but:
1) People use all kind of wrong terminolgy so I filter it away automatically
Oh I can understand that, my grammar hasn't always been perfect but I listened to the grammar nazis and tried to improve, but the internet is still mostly people who cannot spell or formulate a coherent sentence.
Quote from: Saga Musix on January 29, 2017, 00:58:36
2) This issue is specific to the transition to OpenMPT 1.27. For example, unless something weird happens, upgrading to OpenMPT 1.28 from OpenMPT 1.27 will not have the same issue. ;)
Ok cool :) yeah I think the times I had it in the past were for other reasons, as I said before I figured out one of them was multiple copies of the same plug in at different locations, so it's good to know it wont happen after this in this present way... I am generally sticking with the 1.28 at the moment, the midi import is too useful and as I have been saying changing from one to the other is a pain. I have about 700 plugins on this laptop so it does take some time.