Vst~ slow to initialize....
Jul 16 2007 | 9:12 am
I searched the forums trying to find a solution. I just thought I'd mention that first before you read any further. I am running WMAX 4.6.3 .
For the past month I've experienced a strange problem with the vst~ object. I noticed it when a patch Ive been working on started taking forever to load one morning. I initially attributed it to some loadbang funkiness or maybe some java junk. However, later i found the culprit was the vst~ object. To test this, I put a sole vst~ object in a patch without any arguments or initialize messages. Opening this patch as soon as I start max causes the program to hang for about 5 seconds. After that I can open the patch at usual speed.... almost instantaneously.
The normal behavior I'm used to is my patch opening in less than a second. When it hangs like this, its a mystery. Here is what Ive tried so far.
- deleting the preference folder. - setting enablepathcache to 0 - rebooting the computer - formatting the computer
Formatting actually fixed the problem... but it came back today [I formatted about 2 weeks ago]. I am unable to connect any sort of event in or outside of Max that would recreate this happening. I have added no new peripherals or software.
- Jul 16 2007 | 9:51 am**UPDATE**I just finished reformatting my computer using Acronis True Image to revert back to an earlier image. Now, when I open up any patch containing vst~ it loads instantly first time, no waiting. I quoted 5 seconds before when things where f'ed up. I tried it again a few times and the real number was almost 10 seconds to load nothing but a vst~ object.My question to the programmer of VST~. Are there any windows services that vst~ needs in order to function correctly?
- Jul 16 2007 | 9:54 amDo you provide full search path for the vst, or the name only? Are there any difference in load time? If your search path is excessive, it might take longer for Max to find files that it is searching for.Apart from that, also keep in mind that vst plugs need to allocate a fair amount of ram, etc. when loading, and this might take a while. I wouldn't be surprised if this caused some plug-ins to take longer than others.Best, Trondjamez wrote: > I searched the forums trying to find a solution. I just thought I'd mention that first before you read any further. I am running WMAX 4.6.3 . > > For the past month I've experienced a strange problem with the vst~ object. I noticed it when a patch Ive been working on started taking forever to load one morning. I initially attributed it to some loadbang funkiness or maybe some java junk. However, later i found the culprit was the vst~ object. To test this, I put a sole vst~ object in a patch without any arguments or initialize messages. Opening this patch as soon as I start max causes the program to hang for about 5 seconds. After that I can open the patch at usual speed.... almost instantaneously. > > The normal behavior I'm used to is my patch opening in less than a second. When it hangs like this, its a mystery. Here is what Ive tried so far. > > - deleting the preference folder. > - setting enablepathcache to 0 > - rebooting the computer > - formatting the computer > > Formatting actually fixed the problem... but it came back today [I formatted about 2 weeks ago]. I am unable to connect any sort of event in or outside of Max that would recreate this happening. I have added no new peripherals or software.
- Jul 16 2007 | 10:05 amhi trond.The vst~ object had no arguments or messages passed to it at load time. There were also no search paths other than the default externals folder [which doesn't need to be added to search paths, it is automatically searched]. So, both of what you are saying wouldn't be applicable.Besides, I reformatted, added my extended search paths and all that and now it works fine. This is the second time this is happened in the month so I am a bit concerned. The only thing I can think of is that I disable some XP services that vst~ may rely on somehow.At a loss. I should have probably tried to fix it while the problem was still active instead of taking the easy way out and formatting the computer.
- Jul 18 2007 | 2:06 pmbump ;( anyone experience anything similar? symptom: vst~ object in windows suddenly requires >5 seconds to load without arguments or load messages IE, empty vst~.
- Aug 10 2007 | 3:15 pmOkay, so I reformatted my computer on July 18th in an attempt to remedy this problem. For 3 weeks vst~ has been performing as expected. a blank vst~ object [IE, one without any arguments or plugin loaded] will not require any significant load times when opening the patch that contains the object.] I can put a vst~ object in an empty patch, save it, then open it and it loads up lightning fast.As of yesterday, if I take that same patch; JUST A VST~ OBJECT, it'll take over 10 seconds to load. The same behavior has returned to ruin my life. The only solution I have so far is to format my computer.A NOTE TO VST~'s DEVELOPER:Can you please tell me if vst~ requires any shared .dll files that may have been overwritten by some greedy application? In all fairness, I haven't installed any new software since July 18th so the bug pretty much appeared out of nowhere.Any help regarding this matter would be appreciated. I don't feel I'm being melodramatic when I say that this is really causing me a lot of lost time and is ruining what little free time I do have to work on Max related things.James
- Aug 18 2007 | 2:38 am*bump*this issue is making my max experience a nightmare.
- Aug 18 2007 | 3:34 pmHey James,This report and the other one about processor spin after waking up from sleep could go into support.I can tell you now that nothing will happen straight away about either of these problems, but we will be able to look at them as part of the testing for the next release of MaxMSP.-A
- Aug 20 2007 | 3:35 amwell, that's cool. I mean, I don't know what to say. Ive stopped using max almost entirely because of these two bugs. Not being able to use vst~ effectively or suspend my computer and come back later is just beyond annoying. I'm saying I've grown to hate Max, in the way that many have grown to hate most music apps, heh. [pick yer poison]...
- Aug 20 2007 | 4:37 pmHi, I've found this pb too, just with Max MSP V 4,6,3. I prefer to use older Version like 4,6,2 and it workds for me I'm in Win Xp RegardsNicolas
- Aug 31 2007 | 11:47 pmToday, the 31st... vst~ failed to initialize in any sort of reasonable time. Task manager shows the CPU stuck at 50% for about 15 seconds before a simple patch containing ONLY one vst~ object and nothing else. [vst~ is left withOUT arguments for anyone thinking the loading delay might be related to searching for a plugin.]Considering how difficult it is to diagnose and reproduce this bug, I have serious doubts as to whether or not it can be addressed and serviced. I have kept a casual log of dates when the bug appears and things I've tried doing to remove the bug before resorting to reformatting my computer.**I personally feel that there is more I can do to locate the bug on XP but I need information from Cycling. I need to know if vst~ relies on any dll libraries in the system32 folder or the Windows folder. Something may be getting overwritten at some point which is causing this to happen.**I'm not sure if this problem occurred in the past. Then, I may have mistaken excessive loading time to overly complex patches. I have built quite a few environments around the vst~ object and can't really remember if, over the years, this was ever a bug. It's only been apart of my awareness for 3 months.I will try emailing Cycling as well, with a copy of my "log" in about 30 minutes. Thank you to anyone that has read this.Thank you.
- Sep 01 2007 | 12:10 amFWIW, the vst~ object only requires vst plug-in dlls. That is to say, we don't install any support libs to make it work.Your system VST folder, if you have one defined in your registry, is added to the maxmsp search path by vst~. Have you tried cleaning this out? What happens if there is only one vst in your vst folder etc. etc. or none?Also, vst~ will add some pluggo folders to the search path if pluggo is installed. Try ditching this too....-A" You want this, don't you? The hate isswelling in you now. Take your Jedi weapon.Use it. I am unarmed. Strike me down with it.Give in to your anger. With each passingmoment, you make yourself more my servant."
- Sep 01 2007 | 12:50 amGod damn it Andrew, you're a little late, but you've delivered the answer. I spent so much time on this issue and it was a pretty simple solution. All the hours going through junk, turning Max inside out, removing hardware to try and solve it, formatting...HKEY_LOCAL_MACHINESOFTWAREVST...I deleted this registry entry and now things work fine as they should. I guess I'm glad to have finally found it, but 2 months worth of banging my head against the wall for such a small but useful tidbit of information... sigh....I don't have the manual handy but I'll check to see if vst~ entry mentions anything about utilizing the registry path. I really don't think this a very useful feature as it adds considerable wait time to the initial loading of the object. Some people won't object to this, but if the feature isn't documented, how are people to know that vst~ is just searching through your vstplugins folder in the registry?Well, I don't have to kill myself. That's a relief.Thank you.
- Sep 01 2007 | 1:11 amIt's the difference between[plug PSP84]and[plug "c:/Program Files/Steinberg/Vstplugins/PSP84"]or whatever.Also, many VST plug in installers (including Pluggo) look for this key so they know where to put your plugs.I can see it might be a problem if you have a zillion plugs floating around. I'll log a request to make it optional.May the force be with you-A
- Sep 01 2007 | 4:30 amThe option is already "optional". Just add the VST folder to the file preferences dialog in Max. Done deal. 8-(I have about 130 plugins in my VST folder. So, not so many as a lot of peoples.Thanks again... 8-)