And what I don't get at all, why the hell isn't that a background process with no need to interact at all? At the end it could list failed scans with an option to rescan a single plugin. First of all, why is there no time-out implemented? Plugin scans take a huge amount of time and fail regularly, that should be a known fact. This could be the fault of Arturia, but I doubt it, as those plugins get scanned without any hickup in any other host!īut the worst is the behaviour of VEP's scanning. Some Arturia plugins get stuck completely others don't. ![]() This happens on a Macbook Pro M2 running Monterey. Please feel free to also send crash logs from Arturia plugins directly to them.įour years later, and I observe two things. We have sent crash reports to Arturia, and we hope to hear something back from them soon. ![]() Mini V3).Ħ.) For all the VSTs that failed, when I removed them from the VST folder, did a complete rescan, put the vst plugs back, then did a 'rescan for changes' - those plugins did scan successfully, and did instantiate in VEP,Īgain, my configuration is a MacPro (Late 2013, gobs of mem and disk), running High Sierra (10.13.6) On one scan I waited 10 minutes, another scan for 16 minutes afterwards hitting the skip button (which listed the plugin as "Failed Validation").ģ.) Jup-8 V3 causes Pluginscan to crash - I get a dialog box saying "pluinscan quit unexpectedly" (the stack traces seem to indicate vsl code running).Ĥ.) When I remove all 3 of those vst plugs, no other failures were reported (including no failures for Synclaviar, Vox, Wurli).ĥ.) For AUs, some of the same plugs (as the VSTs) fail (ie. ![]() ![]() Subsequently, DX7 V is listed as "Failed Validation".Ģ.) Pluginscan was hanging indefinitely on Farfisa-V. I have ~ 300 plugins in my vst folder, so scans take a fairly significant amount of time.ġ.) DX7 V causes Pluginscan to crash - I get a dialog box saying "pluinscan quit unexpectedly". I did a few more scans, and played with moving plugs around.
0 Comments
Leave a Reply. |