Re: [Audacity-devel] VST Effects and Audacity stability...
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2009-07-30 21:19:59
|
| From James Crook <cr...@in...> | Thu, 30 Jul 2009 12:16:53 +0100 | Subject: [Audacity-devel] VST Effects and Audacity stability... > I like this. > > We could choose to add only validated effects to the menu, plus an > option of 'other VST effects' for the others... > > As a start, I think there are several aspects to dll status: > > User > * enabled, disabled > (and if enabled...) > * load-on-use, load-at-start. (always load on use for VST) > * load-safely, load-quickly (could be always load-safely) > > Steve said: > Perhaps a user option to rescan either all plug-in locations or a > specific directory so that if the user has installed an effect that they > want to try, but know they have many unsupported plug-ins in other > locations they don't have to rescan everything. I'm worried about the user being bamboozled by all these options. Seems to me we can't afford load-on-start to be on by default, and if user turns it on and has a lot of plug-ins, they will be regretting the CPU usage and blaming Audacity for the problem. So I wonder if it needs to be an option? What would be the time penalty for an individual VST of load-on-use as against load-on-start? Assuming "load safely" includes re-scanning for added/removed plug-ins, there could be a button (only active when "load quickly" enabled) to "Re-scan now". At the risk of adding more options, but extending Steve's idea, I wonder about an option to only use the Audacity plug-ins folder (i.e. as defined by us) for VST plug-ins. Presumably does not appear on Linux? Several users have suggested this to me already. Some people won't want this because it might mean duplicating copies of VST effects they want for other apps. but if someone has loads of VSTi's but only uses Audacity for editing I think this would be handy. Re the crashes, are we more confident that we are correctly ignoring most VSTi's now, so that crashes will be confined to any more rogue effects like the two Leland mentioned? The feedback where people have tried the Nightly Builds to cure crash-on-launch has been mostly good, but this is still a small user base compared to what 2.0 will be. If we are not confident, I really wonder if VST enabling should be off by default, and on first run we should ask user if they want to enable it/explain briefly that VSTi are not supported and point to Preferences if they want to configure the options. This isn't what I would especially want, but I want all these crashes on launch much less still, and I've even seen adverse comments that as VST support was previously optional, we shouldn't be forcing it on users by default. I hope of course when we've eliminated the crashing/CPU usage drawbacks on a default configuration that we won't be getting too many more comments like that. Gale > Leland wrote: > > I want to run something by all y'all to see if it's worth the effort. > > > > The new embedded VST support has caused several issues including: > > > > 1) Crashes at startup > > 2) Slow startup > > 3) Excessive CPU usage > > 4) Increased memory usage > > > > I've made a lot of progress with #1, but I've run into a couple of VSTs > > that simply will not work. These crash other apps (like Sonar 8), so > > it's not just Audacity that has a problem with them. One has been > > documented to not run on WinXP and the other one corrupts heap when > > Audacity is exiting. Now, I'm not ruling out poor coding/understanding > > on my part since I've been able to fix most of the identified errors > > with changes to the way I was doing things. But, the two effects I > > mentioned are definitely broken and I'm sure we're run into others. > > > > The reason these two effects crash Audacity is that they access invalid > > memory which causes the process to terminate. With some trickery, the > > exception can be captured, but there's no way to know the state of > > Audacity's memory/stack, so there's no guarantee that Audacity can > > recover, especially in the corrupted heap case. > > > > One application I've tried takes a "checkpoint" before loading each > > effect and allows itself to crash. Upon next startup it knows that it > > was attempting to load the effect and displays a dialog informing the > > user that an effect caused it to crash and asks the user to retry or > > ignore the effect. > > > > Number 2 is a result of the scanning/loading of VSTs at startup. Other > > applications handle this in a couple of ways. > > > > For example, AudioMulch simply finds all DLLs in the plugins directory > > and shows them to the user. The DLL isn't loaded to verify it is even a > > VST, so this allows startup to be very quick. But, the user could see > > "bogus" VSTs listed. > > > > Other apps scan the directories once, validating the VSTs, and then > > storing the gathered info in a config file. Then, whenever the user > > add/removes VSTs, the would go into preferences (for instance) and > > re-scan the directories to update the cached information. > > > > Number 3 was reported only on OSX and with certain effects, but it could > > occur on Windows too. This is caused by the fact I "opened" the effect > > during initialization and the "close" it at termination. The best > > solution here is to no open the effect until it's needed. I've tested > > this and it drops CPU load dramatically...well, it puts it back inline > > with what it was before. > > > > Nobody has reported #4, but it will be a problem when the user has many > > VSTs installed since each DLL is loaded and the effect is "open" all the > > time. > > > > Now onto what I have in mind... > > > > I'll be addressing #2 by going with the gather and cache method of > > identifying the valid VSTs. Seems to me to be the best way to go. Upon > > first execution of Audacity, VSTs will be searched for with an > > indication of progress so the user doesn't think Audacity is frozen. > > I'll add a checkbox in Preferences to rescan at next startup so the > > cached information can be updated. > > > > For #3, I'll be change VSTEffect so that it doesn't keep the effect > > "open" all the time. I will open and close it only when needed. This > > may require more coding to retain the parameter state across open/close > > pairs. > > > > To resolve #4, I will defer loading the DLL until and if the user > > actually uses the effect. Once loaded it will remain loaded until > > Audacity exits. > > > > The resolution for #2 provides the base for resolving #1 as I will be > > making changes that will allow Audacity to run as the main application > > (as it does today) and as a child process whose sole purpose is to > > gather the VST information and pass it back to the main process. By > > gathering the information in a child process any bad VSTs will not cause > > the main process to fail and Audacity will be able to recover and bypass > > the bogus effect. > > > > Now, I haven't tried most of this yet, so I may find that it's all > > bogus, but I wanted to see what y'all thought about it. > > > > Leland |