Mac: Upgraders see ghosts of nyquist plug-ins.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Mac: Upgraders see ghosts of nyquist plug-ins.

James Crook
Bill reported an issue on Mac where an upgrader to 2.1.3 will see
Nyquist plug-ins twice, once for the new ones in Audacity.app/Contents,
once for the old ones that were on an earlier path recorded in
pluginsettings.cfg

My understanding is that users see these ghost plug-ins even when the
actual duplicate Nyquist files have already been deleted.


It seems to me that it is likely that there is a technical fix we could
make in 2.1.3.  We could check that the files exist.  To avoid doing a
possibly expensive check with every launch of Audacity, we could perhaps
limit it.

Possible ways to limit it include:

Only when we see some duplicate Nyquist effect..
Only when we see configured Nyquist effects NOT on one of the preset
nyquist paths for 2.1.3.
Only when the user clicks on an effect that fails to launch.


If the ghost Nyquist Plug-ins rate a P2 (or of course P1), I'm inclined
to hold the release, discuss and decide on the fix, and make new
dmg/exe/zip.  If P3, I'm inclined to let them through.

Gale, what rating do you give the reported problem?

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Mac: Upgraders see ghosts of nyquist plug-ins.

Gale
Administrator
It is working as we expect, now has some documentation and was
mentioned previously (twice, I think).

Tracking it as P3 would provide another place the user could find
out about it. But in terms of actual importance to fix it, I think it's
arguably only P4 enh, because when there is a duplicated effect
in the Effect menu and the user hovers over the entry, they can
see the path to each plugin in the cascading menu. So it's not that
unintuitive that the old item would fail if the user knows they have
deleted it.

As discussed, what is less intuitive is figuring how to remove the
deleted item from the Effect Menu and from the Plug-in Manager.
Perhaps that deserves a higher rating than P4.

I think if we want to stop deleted items showing up in Effect Menu
when launching Audacity, or stop them failing when clicked on,
we want to do that for all effect types as a holistic solution. As you
say, we could check existence on clicking the item. We could then
show a specific error that the file location doesn't exist, rather than
the generic "Failed to initialize" error.

Also, how much of an issue will plugins be when installing 2.1.4
over 2.1.3? The Manual now says to use
~/Library/Application Support/audacity/Plug-Ins as the Audacity
plugins folder, but if users put optional plugins in the Plug-Ins
folder in the bundle, the current "dumb" DMG will just remove
the optional plugins when installing the new version. This is
worse than when we had an Audacity folder, in which case Mac
provides an option to retain files that are not part of the new
installation.

So that raises if the DMG should contain a PKG installer that gives
an option to retain files that are not in the installation.

A PKG installer could also be a way to look for and delete duplicate
NY files that are found in pluginregistry.cfg, deleting the files and
deleting their lines in pluginregistry.cfg. Of course I say that without
any conception of how hard it is to do, but it seems a more "direct"
way of doing it.  It would still have some ongoing benefit if done
after 2.1.3, when users update from pre-2.1.3 to the current version.


Gale


On 3 February 2017 at 23:09, James Crook <[hidden email]> wrote:

> Bill reported an issue on Mac where an upgrader to 2.1.3 will see
> Nyquist plug-ins twice, once for the new ones in Audacity.app/Contents,
> once for the old ones that were on an earlier path recorded in
> pluginsettings.cfg
>
> My understanding is that users see these ghost plug-ins even when the
> actual duplicate Nyquist files have already been deleted.
>
>
> It seems to me that it is likely that there is a technical fix we could
> make in 2.1.3.  We could check that the files exist.  To avoid doing a
> possibly expensive check with every launch of Audacity, we could perhaps
> limit it.
>
> Possible ways to limit it include:
>
> Only when we see some duplicate Nyquist effect..
> Only when we see configured Nyquist effects NOT on one of the preset
> nyquist paths for 2.1.3.
> Only when the user clicks on an effect that fails to launch.
>
>
> If the ghost Nyquist Plug-ins rate a P2 (or of course P1), I'm inclined
> to hold the release, discuss and decide on the fix, and make new
> dmg/exe/zip.  If P3, I'm inclined to let them through.
>
> Gale, what rating do you give the reported problem?
>
> --James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Mac: Upgraders see ghosts of nyquist plug-ins.

James Crook
I don't think the dmg should contain a pkg installer.
If we need things to fix duplicates we can/should do it from within
Audacity.

If a user puts optional Nyquist plug ins within Audacity.app/Contents
(which is not what we recommend) then I think they are a knowledgeable /
experienced user, and when upgrading 2.1.3 -> 2.1.4 won't be too
surprised that when they replace Audacity.App those plug-ins are gone.

The holistic solution suggests that when a plug in fails to load because
it is absent, we should scan for absent plug-ins, remove them, and
update pluginsettings.cfg.  We can also do the scan when opening
add/remove effects.  This approach might be an issue for rare users who
keep plug-ins on a USB key, but I think the benefits outweigh that issue.

If we're going to do it for 2.1.3, we should do it before going to RC1.

Do we have bugzilla numbers for the ghost bug(s)?  I am still worrying
that ghosts might cause lots of support queries for 2.1.3 mac which
could be avoided.

--James.


On 2/4/2017 3:20 AM, Gale Andrews wrote:

> It is working as we expect, now has some documentation and was
> mentioned previously (twice, I think).
>
> Tracking it as P3 would provide another place the user could find
> out about it. But in terms of actual importance to fix it, I think it's
> arguably only P4 enh, because when there is a duplicated effect
> in the Effect menu and the user hovers over the entry, they can
> see the path to each plugin in the cascading menu. So it's not that
> unintuitive that the old item would fail if the user knows they have
> deleted it.
>
> As discussed, what is less intuitive is figuring how to remove the
> deleted item from the Effect Menu and from the Plug-in Manager.
> Perhaps that deserves a higher rating than P4.
>
> I think if we want to stop deleted items showing up in Effect Menu
> when launching Audacity, or stop them failing when clicked on,
> we want to do that for all effect types as a holistic solution. As you
> say, we could check existence on clicking the item. We could then
> show a specific error that the file location doesn't exist, rather than
> the generic "Failed to initialize" error.
>
> Also, how much of an issue will plugins be when installing 2.1.4
> over 2.1.3? The Manual now says to use
> ~/Library/Application Support/audacity/Plug-Ins as the Audacity
> plugins folder, but if users put optional plugins in the Plug-Ins
> folder in the bundle, the current "dumb" DMG will just remove
> the optional plugins when installing the new version. This is
> worse than when we had an Audacity folder, in which case Mac
> provides an option to retain files that are not part of the new
> installation.
>
> So that raises if the DMG should contain a PKG installer that gives
> an option to retain files that are not in the installation.
>
> A PKG installer could also be a way to look for and delete duplicate
> NY files that are found in pluginregistry.cfg, deleting the files and
> deleting their lines in pluginregistry.cfg. Of course I say that without
> any conception of how hard it is to do, but it seems a more "direct"
> way of doing it.  It would still have some ongoing benefit if done
> after 2.1.3, when users update from pre-2.1.3 to the current version.
>
>
> Gale
>
>
> On 3 February 2017 at 23:09, James Crook <[hidden email]> wrote:
>> Bill reported an issue on Mac where an upgrader to 2.1.3 will see
>> Nyquist plug-ins twice, once for the new ones in Audacity.app/Contents,
>> once for the old ones that were on an earlier path recorded in
>> pluginsettings.cfg
>>
>> My understanding is that users see these ghost plug-ins even when the
>> actual duplicate Nyquist files have already been deleted.
>>
>>
>> It seems to me that it is likely that there is a technical fix we could
>> make in 2.1.3.  We could check that the files exist.  To avoid doing a
>> possibly expensive check with every launch of Audacity, we could perhaps
>> limit it.
>>
>> Possible ways to limit it include:
>>
>> Only when we see some duplicate Nyquist effect..
>> Only when we see configured Nyquist effects NOT on one of the preset
>> nyquist paths for 2.1.3.
>> Only when the user clicks on an effect that fails to launch.
>>
>>
>> If the ghost Nyquist Plug-ins rate a P2 (or of course P1), I'm inclined
>> to hold the release, discuss and decide on the fix, and make new
>> dmg/exe/zip.  If P3, I'm inclined to let them through.
>>
>> Gale, what rating do you give the reported problem?
>>
>> --James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Mac: Upgraders see ghosts of nyquist plug-ins.

Gale
Administrator
At this stage my suggestion would be to proceed with RC1.


On 4 February 2017 at 10:27, James Crook <[hidden email]> wrote:
> I don't think the dmg should contain a pkg installer.

Why is that? It is normal enough for more "advanced" applications.

I was guessing it would be potentially much quicker for the installer to
handle the shipped duplicates than sorting out a "holistic" solution of
how to handle missing effects in the Audacity interface and Plug-in
Manager.


> If we need things to fix duplicates we can/should do it from within
> Audacity.
>
> If a user puts optional Nyquist plug ins within Audacity.app/Contents
> (which is not what we recommend) then I think they are a knowledgeable /
> experienced user, and when upgrading 2.1.3 -> 2.1.4 won't be too
> surprised that when they replace Audacity.App those plug-ins are gone.

I'm thinking of those who don't RTFM. I would expect at least some
users who happen to know "Show Package Contents" to see the
bundled Plug-Ins folder as the closest thing to the old Plug-Ins folder
in the Audacity installation folder.

I think fully experienced users would know they should not put optional
files inside an app bundle, but less experienced might not know.

I didn't add a FAQ about why Audacity on Mac no longer comes with
a folder. How about adding a sentence about all in one to the release
announcement, with a mention of the new Audacity plugins folder
~/Library/Application Support/audacity/Plug-Ins? Mac cognosecenti will
greatly approve all in one  (it may even make some of them upgrade).


> The holistic solution suggests that when a plug in fails to load because
> it is absent, we should scan for absent plug-ins, remove them, and
> update pluginsettings.cfg.

You meant pluginregistry.cfg, I think.

If we wait to advise about missing plugins until user tries to access
a missing one, shouldn't we then only advise about the one they
clicked, which is the one the user is thinking about? It could get
confusing to click one effect then be presented with a list of all effects
that are missing.

I only suggested updating pluginregistry.cfg for missing duplicates of
shipped plugins (if we want to avoid the display issue in Audacity).

It might be rather heavy handed to remove all missing plugins from
pluginregistry.cfg. I'm actually wondering if we should even disable
effects when missing, providing we say on clicking the effect that it's
missing

Reasoning: suppose it's an accidental deletion or rename, or user
reorganised the plugins in a subfolder and we don't do recursive search
for that type of plugin. If the user is told where the plugin was and puts it
back there, then providing it is not deregistered (and currently, providing
user doesn't open Plug-in Manager), then the plugin will immediately
become available again in the menu.

If we deregister or disable then the user has got to go back into Plug-in
Manager and re-enable it. That does not seem user-friendly to me.

OTOH if the user deliberately removed the plugin it seems reasonable
to me that they should have to go into Plug-in Manager to deregister
the effect and that Plug-in Manager should have let the user deregister
it from pluginregistry.cfg (belongs in summary bug 1018).


> We can also do the scan when opening add/remove effects.  This approach
> might be an issue for rare users who keep plug-ins on a USB key, but I think
> the benefits outweigh that issue.

Yes IMO it's reasonable to do a scan for all missing effects when opening
Add / Remove Plug-ins... . I don't think we should deregister/disable missing
effects there either. I think it would be helpful to categorize them
as "missing".


> If we're going to do it for 2.1.3, we should do it before going to RC1.
>
> Do we have bugzilla numbers for the ghost bug(s)?  I am still worrying
> that ghosts might cause lots of support queries for 2.1.3 mac which
> could be avoided.

There is no unintended bug that I am aware of. The user can see the
paths of the duplicates, as we intend. If we were concerned we should
have done something about this earlier, IMO.

I don't think the existing bug 1018 is likely to see promotion above P3
but I do think it would be reasonable to promote it to P3. The difficulty
in managing duplicated effects that users delete due to all-in-one could
be stated in the release notes as an example of why 1018 should be
addressed.

Sorting out what do to about 1018 will probably be a good test of Q2A,
if we install it.


Gale

> On 2/4/2017 3:20 AM, Gale Andrews wrote:
>> It is working as we expect, now has some documentation and was
>> mentioned previously (twice, I think).
>>
>> Tracking it as P3 would provide another place the user could find
>> out about it. But in terms of actual importance to fix it, I think it's
>> arguably only P4 enh, because when there is a duplicated effect
>> in the Effect menu and the user hovers over the entry, they can
>> see the path to each plugin in the cascading menu. So it's not that
>> unintuitive that the old item would fail if the user knows they have
>> deleted it.
>>
>> As discussed, what is less intuitive is figuring how to remove the
>> deleted item from the Effect Menu and from the Plug-in Manager.
>> Perhaps that deserves a higher rating than P4.
>>
>> I think if we want to stop deleted items showing up in Effect Menu
>> when launching Audacity, or stop them failing when clicked on,
>> we want to do that for all effect types as a holistic solution. As you
>> say, we could check existence on clicking the item. We could then
>> show a specific error that the file location doesn't exist, rather than
>> the generic "Failed to initialize" error.
>>
>> Also, how much of an issue will plugins be when installing 2.1.4
>> over 2.1.3? The Manual now says to use
>> ~/Library/Application Support/audacity/Plug-Ins as the Audacity
>> plugins folder, but if users put optional plugins in the Plug-Ins
>> folder in the bundle, the current "dumb" DMG will just remove
>> the optional plugins when installing the new version. This is
>> worse than when we had an Audacity folder, in which case Mac
>> provides an option to retain files that are not part of the new
>> installation.
>>
>> So that raises if the DMG should contain a PKG installer that gives
>> an option to retain files that are not in the installation.
>>
>> A PKG installer could also be a way to look for and delete duplicate
>> NY files that are found in pluginregistry.cfg, deleting the files and
>> deleting their lines in pluginregistry.cfg. Of course I say that without
>> any conception of how hard it is to do, but it seems a more "direct"
>> way of doing it.  It would still have some ongoing benefit if done
>> after 2.1.3, when users update from pre-2.1.3 to the current version.
>>
>>
>> Gale
>>
>>
>> On 3 February 2017 at 23:09, James Crook <[hidden email]> wrote:
>>> Bill reported an issue on Mac where an upgrader to 2.1.3 will see
>>> Nyquist plug-ins twice, once for the new ones in Audacity.app/Contents,
>>> once for the old ones that were on an earlier path recorded in
>>> pluginsettings.cfg
>>>
>>> My understanding is that users see these ghost plug-ins even when the
>>> actual duplicate Nyquist files have already been deleted.
>>>
>>>
>>> It seems to me that it is likely that there is a technical fix we could
>>> make in 2.1.3.  We could check that the files exist.  To avoid doing a
>>> possibly expensive check with every launch of Audacity, we could perhaps
>>> limit it.
>>>
>>> Possible ways to limit it include:
>>>
>>> Only when we see some duplicate Nyquist effect..
>>> Only when we see configured Nyquist effects NOT on one of the preset
>>> nyquist paths for 2.1.3.
>>> Only when the user clicks on an effect that fails to launch.
>>>
>>>
>>> If the ghost Nyquist Plug-ins rate a P2 (or of course P1), I'm inclined
>>> to hold the release, discuss and decide on the fix, and make new
>>> dmg/exe/zip.  If P3, I'm inclined to let them through.
>>>
>>> Gale, what rating do you give the reported problem?
>>>
>>> --James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality