MaxMSP 4.6 certainly does install pluggo.
It is sort of odd that they'd leave the debugging output.
But in some sense I'm glad they did since I can tell why my computer
takes so long to quit audacity.
On Tue, Jul 29, 2008 at 4:57 PM, Gale Andrews <gale@...> wrote:
> | From "Michael Chinen" <mchinen@...>
> | Tue, 29 Jul 2008 15:02:52 -0400
> | Subject: [Audacity-devel] pluggo
>> On Tue, Jul 29, 2008 at 2:50 PM, Richard Ash <richard@...> wrote:
>> > This is on Mac OS, right?
>> > Audacity loads Audio Units plug-ins from the default system directories
>> > and they appear in the Effects menu. So if the MAX / MSP stuff is on
>> > your machine in the system wide path, then you will get it loaded by
>> > default (and unloaded at the end).
>> > The easiest proof of this would be if you built with audio units support
>> > disabled (option to configure), and the problem went away.
>> It takes about 10 seconds to unload all the pluggo stuff. Is there an
>> option to disable this in preferences? Ten seconds is the world to
>> me, being longer than my short-time attention span, so In my view
>> there should be an option. If it isn't there I'd be willing to
>> implement it.
> Or move MAX/MSP to a non-system path? If we were to do this I think it
> would be just as important to have a (non-Linux??) VST option to ignore
> system paths (only look in the Audacity plug-ins folder). Third-party VSTs
> in system folders often cause Audacity to fail to launch, and the only
> other solution is to remove the VST bridge and do without any VSTs at
> all until the culprit plug-ins are identified.
Max users probably won't want to do that, since the install puts it
there, so I'd opt for the option to remove non audacity paths.
Also if the bad VST plugin is a frequent issue it might be good to
build a loader that loads the pluggins in different background threads
that have timeouts.