[ardour-dev] build from last evening's tarball fails

Mark Knecht markknecht at gmail.com
Tue Nov 9 06:59:46 PST 2004

On Tue, 09 Nov 2004 06:57:53 -0500, Paul Davis
<paul at linuxaudiosystems.com> wrote:
> >On Mon, 08 Nov 2004 21:27:31 -0500, Paul Davis
> ><paul at linuxaudiosystems.com> wrote:
> >> >Humm....looks like a bad idea on Ardour's part:
> >> ><SNIP>
> >> >ardour: [INFO]: detecting VST plugins along /home/mark/vst_dir
> >> ><SNIP>
> >>
> >> you built it with VST support ... what else is it supposed to do?
> >>
> >
> >What it's doing, but a bit more gracefully.
> in an earlier version of libfst, torben and i actually tried very hard
> to catch errors and problems from plugins as we instantiated them. it
> turned out that for all the interesting problems, the failure was
> indistinguishable under wine from a GPF, and catching it and
> recovering from it was essentially impossible.
> from what i read on the vst-plugins list, the favored approach on
> windows to loading potentially errant plugins is to use an
> assume-failure model: write the plugin name to a well-known file
> before its first loading and mark it as failed. if the load succeeds,
> mark it as working. if the host crashes while loading, the next time
> it starts up, it knows that the plugin is marked failed, and doesn't
> load it.
> this is what i meant by a blacklist.
> --p

In reflecting on this last night I think this sounds like a reasonable
process. I'd like to maybe have the blacklist available for editing,
which I'm sure it would be. I'd also like to see the blacklisting
program remember 'information' (size, date, etc.) so that should a new
version of the dll show up then Ardour gets a chance to try it.

Anyway, sicne Ardour doesn't handle MIDI today it makes sense that I
break my VSTs into different directories for now.


More information about the Ardour-Dev mailing list