Plug-in path on Linux

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

Plug-in path on Linux

Stevethefiddle
This came up today on feedback@ and concerns the plug-in path on Linux.

The default path for shipped plug-ins is:
usr/share/audacity/plug-ins
or
usr/local/share/audacity/plug-ins

Both of these locations require root privileges to write to.

Users may also install plug-ins in their home directory (only requires normal use privileges) as described in the Manual (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install and wiki (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install) by creating a folder:
~/.audacity-files/plug-ins

So far so good...

but we also have an undocumented folder in:
~/.audacity-data/Plug-Ins

(note also the non-Linux-like capitalization)

This seems to have been added 7+ years ago (by Richard Ash ?)

wxString FileNames::PlugInDir()
{
   return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins") ).GetFullPath() );
}

Does anyone know why?
Do we actually want this?

Steve

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

Re: Plug-in path on Linux

Gale
Administrator
On 15 May 2017 at 10:10, Steve the Fiddle <[hidden email]> wrote:

> This came up today on feedback@ and concerns the plug-in path on Linux.
>
> The default path for shipped plug-ins is:
> usr/share/audacity/plug-ins
> or
> usr/local/share/audacity/plug-ins
>
> Both of these locations require root privileges to write to.
>
> Users may also install plug-ins in their home directory (only requires
> normal use privileges) as described in the Manual
> (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
> and wiki
> (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install) by
> creating a folder:
> ~/.audacity-files/plug-ins
>
> So far so good...
>
> but we also have an undocumented folder in:
> ~/.audacity-data/Plug-Ins
>
> (note also the non-Linux-like capitalization)
>
> This seems to have been added 7+ years ago (by Richard Ash ?)
>
> wxString FileNames::PlugInDir()
> {
>    return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins")
> ).GetFullPath() );
> }
>
> Does anyone know why?

The Plug-Ins folder in Audacity's application data folder is documented on:
http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install

It's the Wiki page that does not mention that folder.


> Do we actually want this?

Does it violate anything on Linux apart from perhaps dubious capitalisation?

It does have the merit of already existing in the user's own space.


Gale

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

Re: Plug-in path on Linux

Stevethefiddle


On 16 May 2017 at 02:10, Gale Andrews <[hidden email]> wrote:
On 15 May 2017 at 10:10, Steve the Fiddle <[hidden email]> wrote:
> This came up today on feedback@ and concerns the plug-in path on Linux.
>
> The default path for shipped plug-ins is:
> usr/share/audacity/plug-ins
> or
> usr/local/share/audacity/plug-ins
>
> Both of these locations require root privileges to write to.
>
> Users may also install plug-ins in their home directory (only requires
> normal use privileges) as described in the Manual
> (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
> and wiki
> (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install) by
> creating a folder:
> ~/.audacity-files/plug-ins
>
> So far so good...
>
> but we also have an undocumented folder in:
> ~/.audacity-data/Plug-Ins
>
> (note also the non-Linux-like capitalization)
>
> This seems to have been added 7+ years ago (by Richard Ash ?)
>
> wxString FileNames::PlugInDir()
> {
>    return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins")
> ).GetFullPath() );
> }
>
> Does anyone know why?

The Plug-Ins folder in Audacity's application data folder is documented on:
http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install

OK, I missed that, but that documentation is confusing:

It says, or at least implies that ~/.audacity-files/plug-ins is read only.
It has incorrect capitalization for file names (very important on a case sensitive file system)
It then contradicts itself and says that ~/.../Plug-Ins is read/write



It's the Wiki page that does not mention that folder.


> Do we actually want this?

Does it violate anything on Linux apart from perhaps dubious capitalisation?

Needless duplication and confusion.
Increased risk of user error, documentation errors (as seen in the current user manual) and programming errors.
Increased complexity to the search path.
Increased complexity to the documentation

Is the existence of ~/audacity-data/Plug-Ins intentional, or just the result of a 'harmless' coding error?
If intentional, what's the reason?

As we saw in this forum topic: https://forum.audacityteam.org/viewtopic.php?f=50&t=95305 there are some other strange issues with the plug-in search path.

Needless complication is bad for so many reasons that if this additional "Plug-Ins" path is "needless", then I think it should be removed.

Is this DataDir() + "Plug-Ins" path relevant on any other platform, or can it just be deleted?

 

It does have the merit of already existing in the user's own space.

Not really a "merit" as we could just as easily create ~/audacity-file/plug-ins if we wanted to (though I don't see a great need to do so, and it would be better would be for a "plug-in manager" to handle plug-in installation on all platforms).

Steve
 


Gale

------------------------------------------------------------------------------

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

Re: Plug-in path on Linux

Gale
Administrator
Yes, the Plug-Ins folder in the application data folder works on all
platforms for Nyquist, LADSPA and VST plugins.

Now that Audacity is all-in-one on Mac, that folder is essential on
Mac. Otherwise, users will have to drill down into the Contents
folder of the app to add plugins, and will lose their new plugins
when Audacity is upgraded.

So unequivocal -1 from me to deleting it on Mac.

On Ubuntu, your script for returning Nyquist plugin paths returns
undocumented paths:

/home/gale/nyquist
/home/gale/plugins
/home/gale/plug-ins

And I can't make ~/plug-ins see Nyquist plugins. Can you? Are those
three folders not needless duplication (or the reverse, ~/.audacity-files
is needless duplication - and requires showing hidden folders)?

Is there a standard in Linux FHS for this? I can't see one:
http://www.pathname.com/fhs/pub/fhs-2.3.html


Steve wrote:
> It would be better would be for a "plug-in manager" to handle
> plug-in installation on all platforms).

I don't understand that point. Does that not happen now on Linux?
That is, put the plugin somewhere then enable it in Plug-in Manager?



Gale


On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]> wrote:

>
>
> On 16 May 2017 at 02:10, Gale Andrews <[hidden email]> wrote:
>>
>> On 15 May 2017 at 10:10, Steve the Fiddle <[hidden email]>
>> wrote:
>> > This came up today on feedback@ and concerns the plug-in path on Linux.
>> >
>> > The default path for shipped plug-ins is:
>> > usr/share/audacity/plug-ins
>> > or
>> > usr/local/share/audacity/plug-ins
>> >
>> > Both of these locations require root privileges to write to.
>> >
>> > Users may also install plug-ins in their home directory (only requires
>> > normal use privileges) as described in the Manual
>> >
>> > (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> > and wiki
>> > (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install) by
>> > creating a folder:
>> > ~/.audacity-files/plug-ins
>> >
>> > So far so good...
>> >
>> > but we also have an undocumented folder in:
>> > ~/.audacity-data/Plug-Ins
>> >
>> > (note also the non-Linux-like capitalization)
>> >
>> > This seems to have been added 7+ years ago (by Richard Ash ?)
>> >
>> > wxString FileNames::PlugInDir()
>> > {
>> >    return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins")
>> > ).GetFullPath() );
>> > }
>> >
>> > Does anyone know why?
>>
>> The Plug-Ins folder in Audacity's application data folder is documented
>> on:
>>
>> http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>
>
> OK, I missed that, but that documentation is confusing:
>
> It says, or at least implies that ~/.audacity-files/plug-ins is read only.
> It has incorrect capitalization for file names (very important on a case
> sensitive file system)
> It then contradicts itself and says that ~/.../Plug-Ins is read/write
>
>>
>>
>> It's the Wiki page that does not mention that folder.
>>
>>
>> > Do we actually want this?
>>
>> Does it violate anything on Linux apart from perhaps dubious
>> capitalisation?
>
>
> Needless duplication and confusion.
> Increased risk of user error, documentation errors (as seen in the current
> user manual) and programming errors.
> Increased complexity to the search path.
> Increased complexity to the documentation
>
> Is the existence of ~/audacity-data/Plug-Ins intentional, or just the result
> of a 'harmless' coding error?
> If intentional, what's the reason?
>
> As we saw in this forum topic:
> https://forum.audacityteam.org/viewtopic.php?f=50&t=95305 there are some
> other strange issues with the plug-in search path.
>
> Needless complication is bad for so many reasons that if this additional
> "Plug-Ins" path is "needless", then I think it should be removed.
>
> Is this DataDir() + "Plug-Ins" path relevant on any other platform, or can
> it just be deleted?
>
>
>>
>>
>> It does have the merit of already existing in the user's own space.
>
>
> Not really a "merit" as we could just as easily create
> ~/audacity-file/plug-ins if we wanted to (though I don't see a great need to
> do so, and it would be better would be for a "plug-in manager" to handle
> plug-in installation on all platforms).
>
> Steve
>
>>
>>
>>
>> Gale
>>
>>
>> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Plug-in path on Linux

Gale
Administrator
In reply to this post by Stevethefiddle
On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]> wrote:
> http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
> It says, or at least implies that ~/.audacity-files/plug-ins is read only.
> It has incorrect capitalization for file names (very important on a case
> sensitive file system)
> It then contradicts itself and says that ~/.../Plug-Ins is read/write

The read-only implication was just a stray bullet point that got left in.

I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins so
I changed the subfolder name to lower case.

Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
plugins, which is unexpected given ~/.audacity-data/Plug-Ins does so.
The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
plugins.

You can change ~/.audacity-data/Plug-Ins to ~/.audacity-data/plug-ins
and your plugins will still be seen.

See if this is better:
http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
.


Gale

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

Re: Plug-in path on Linux

Stevethefiddle
In reply to this post by Gale


On 16 May 2017 at 17:48, Gale Andrews <[hidden email]> wrote:
Yes, the Plug-Ins folder in the application data folder works on all
platforms for Nyquist, LADSPA and VST plugins.

OK, thanks. I thought it might be relevant to other platforms.
 

Now that Audacity is all-in-one on Mac, that folder is essential on
Mac. Otherwise, users will have to drill down into the Contents
folder of the app to add plugins, and will lose their new plugins
when Audacity is upgraded.

So unequivocal -1 from me to deleting it on Mac.

Good. That makes sense for Mac.

 

On Ubuntu, your script for returning Nyquist plugin paths returns
undocumented paths:

/home/gale/nyquist
/home/gale/plugins
/home/gale/plug-ins

And I can't make ~/plug-ins see Nyquist plugins. Can you?

Just tried it with Audacity 2.1.3 release build. I deleted pluginregistry, pluginsettings and audacity.cfg files first, then put a know good Nyquist Effect plug-in into ~/plug-ins and the plug-in was correctly loaded.
It also worked with ~/nyquist and ~/plugins.
 
Are those
three folders not needless duplication (or the reverse, ~/.audacity-files
is needless duplication - and requires showing hidden folders)?

It looks like a lot of duplication to me.
 

Is there a standard in Linux FHS for this? I can't see one:
http://www.pathname.com/fhs/pub/fhs-2.3.html

Looking at other applications on my computer, the most common system is for an application to have a "dot directory", in which all of its configuration files, including application specific plug-ins, extensions, themes, filters, settings and so on are kept.

For example, Gimp has a folder:
~/.gimp-2.8
in which there is:
brushes/
curves/
dynamics/
...
scripts/
templates/
themes/
tmp/
tool-options/
tool-presets/
and then a bunch of plain text configuration files.

Similarly Mozilla Firefox has its "extensions", profile, settings and so on in ~/.mozilla

Dropbox uses ~/.dropbox

Filezilla uses ~/.filezilla

and so on.


So for Audacity, the "standard" structure would be:
~/.audacity

which would contain: "plug-ins/" (or "plugins/"), "autosave/", "chains/" and plain text configuration files.

We're not going to be able to do that overnight.
 



Steve wrote:
> It would be better would be for a "plug-in manager" to handle
> plug-in installation on all platforms).

I don't understand that point. Does that not happen now on Linux?
That is, put the plugin somewhere then enable it in Plug-in Manager?

I mean for the Plug-in manager to "install" plug-ins in the appropriate location.
Download the plug-in to your Desktop or anywhere, select it in the plug-in manager, and the plug-in manager installs it (copies it to an appropriate location and enabled it in Audacity).

Steve
 



Gale


On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]> wrote:
>
>
> On 16 May 2017 at 02:10, Gale Andrews <[hidden email]> wrote:
>>
>> On 15 May 2017 at 10:10, Steve the Fiddle <[hidden email]>
>> wrote:
>> > This came up today on feedback@ and concerns the plug-in path on Linux.
>> >
>> > The default path for shipped plug-ins is:
>> > usr/share/audacity/plug-ins
>> > or
>> > usr/local/share/audacity/plug-ins
>> >
>> > Both of these locations require root privileges to write to.
>> >
>> > Users may also install plug-ins in their home directory (only requires
>> > normal use privileges) as described in the Manual
>> >
>> > (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> > and wiki
>> > (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install) by
>> > creating a folder:
>> > ~/.audacity-files/plug-ins
>> >
>> > So far so good...
>> >
>> > but we also have an undocumented folder in:
>> > ~/.audacity-data/Plug-Ins
>> >
>> > (note also the non-Linux-like capitalization)
>> >
>> > This seems to have been added 7+ years ago (by Richard Ash ?)
>> >
>> > wxString FileNames::PlugInDir()
>> > {
>> >    return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins")
>> > ).GetFullPath() );
>> > }
>> >
>> > Does anyone know why?
>>
>> The Plug-Ins folder in Audacity's application data folder is documented
>> on:
>>
>> http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>
>
> OK, I missed that, but that documentation is confusing:
>
> It says, or at least implies that ~/.audacity-files/plug-ins is read only.
> It has incorrect capitalization for file names (very important on a case
> sensitive file system)
> It then contradicts itself and says that ~/.../Plug-Ins is read/write
>
>>
>>
>> It's the Wiki page that does not mention that folder.
>>
>>
>> > Do we actually want this?
>>
>> Does it violate anything on Linux apart from perhaps dubious
>> capitalisation?
>
>
> Needless duplication and confusion.
> Increased risk of user error, documentation errors (as seen in the current
> user manual) and programming errors.
> Increased complexity to the search path.
> Increased complexity to the documentation
>
> Is the existence of ~/audacity-data/Plug-Ins intentional, or just the result
> of a 'harmless' coding error?
> If intentional, what's the reason?
>
> As we saw in this forum topic:
> https://forum.audacityteam.org/viewtopic.php?f=50&t=95305 there are some
> other strange issues with the plug-in search path.
>
> Needless complication is bad for so many reasons that if this additional
> "Plug-Ins" path is "needless", then I think it should be removed.
>
> Is this DataDir() + "Plug-Ins" path relevant on any other platform, or can
> it just be deleted?
>
>
>>
>>
>> It does have the merit of already existing in the user's own space.
>
>
> Not really a "merit" as we could just as easily create
> ~/audacity-file/plug-ins if we wanted to (though I don't see a great need to
> do so, and it would be better would be for a "plug-in manager" to handle
> plug-in installation on all platforms).
>
> Steve
>
>>
>>
>>
>> Gale
>>
>>
>> ------------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

Re: Plug-in path on Linux

Gale
Administrator
On 16 May 2017 at 19:56, Steve the Fiddle <[hidden email]> wrote:
[...]

> Looking at other applications on my computer, the most common system is for
> an application to have a "dot directory", in which all of its configuration
> files, including application specific plug-ins, extensions, themes, filters,
> settings and so on are kept.
>
> For example, Gimp has a folder:
> ~/.gimp-2.8
> in which there is:
> brushes/
> curves/
> dynamics/
> ...
> scripts/
> templates/
> themes/
> tmp/
> tool-options/
> tool-presets/
> and then a bunch of plain text configuration files.
>
> Similarly Mozilla Firefox has its "extensions", profile, settings and so on
> in ~/.mozilla
>
> Dropbox uses ~/.dropbox
>
> Filezilla uses ~/.filezilla
>
> and so on.
>
>
> So for Audacity, the "standard" structure would be:
> ~/.audacity
>
> which would contain: "plug-ins/" (or "plugins/"), "autosave/", "chains/" and
> plain text configuration files.

Still, that isn't a long way from ~/.audacity_data so I only see a
medium priority to change to ~/.audacity.

To me, DataDir() + "Plug-Ins" is a reasonable approach and
is uniform on all three platforms.It's perhaps a little superfluous
on Windows but once the user knows how to show that directory
it is arguably easier for a standard user than giving a password
to add plugins to Program Files\Audacity\Plug-Ins.

To me the actual problem is too many other folders that accept
only Nyquist plugins. But as in the Forum complaint you linked to,
actually provide a system path for Nyquist plugins that sysadmins
can use.


> We're not going to be able to do that overnight.

>>
>>
>>
>>
>> Steve wrote:
>> > It would be better would be for a "plug-in manager" to handle
>> > plug-in installation on all platforms).
>>
>> I don't understand that point. Does that not happen now on Linux?
>> That is, put the plugin somewhere then enable it in Plug-in Manager?
>
>
> I mean for the Plug-in manager to "install" plug-ins in the appropriate
> location.
> Download the plug-in to your Desktop or anywhere, select it in the plug-in
> manager, and the plug-in manager installs it (copies it to an appropriate
> location and enabled it in Audacity).

Wow, that may be OK if any plugins were available as packages via
OneGet/Chocolatey on Windows or HomeBrew/MacPorts on Mac.

I can't see Audacity handling some of the complex commercial VST
installers that are common on Windows.


Gale

>>
>>
>>
>>
>> Gale
>>
>>
>> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> >
>> > On 16 May 2017 at 02:10, Gale Andrews <[hidden email]> wrote:
>> >>
>> >> On 15 May 2017 at 10:10, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >> > This came up today on feedback@ and concerns the plug-in path on
>> >> > Linux.
>> >> >
>> >> > The default path for shipped plug-ins is:
>> >> > usr/share/audacity/plug-ins
>> >> > or
>> >> > usr/local/share/audacity/plug-ins
>> >> >
>> >> > Both of these locations require root privileges to write to.
>> >> >
>> >> > Users may also install plug-ins in their home directory (only
>> >> > requires
>> >> > normal use privileges) as described in the Manual
>> >> >
>> >> >
>> >> > (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >> > and wiki
>> >> > (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install)
>> >> > by
>> >> > creating a folder:
>> >> > ~/.audacity-files/plug-ins
>> >> >
>> >> > So far so good...
>> >> >
>> >> > but we also have an undocumented folder in:
>> >> > ~/.audacity-data/Plug-Ins
>> >> >
>> >> > (note also the non-Linux-like capitalization)
>> >> >
>> >> > This seems to have been added 7+ years ago (by Richard Ash ?)
>> >> >
>> >> > wxString FileNames::PlugInDir()
>> >> > {
>> >> >    return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins")
>> >> > ).GetFullPath() );
>> >> > }
>> >> >
>> >> > Does anyone know why?
>> >>
>> >> The Plug-Ins folder in Audacity's application data folder is documented
>> >> on:
>> >>
>> >>
>> >> http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >
>> >
>> > OK, I missed that, but that documentation is confusing:
>> >
>> > It says, or at least implies that ~/.audacity-files/plug-ins is read
>> > only.
>> > It has incorrect capitalization for file names (very important on a case
>> > sensitive file system)
>> > It then contradicts itself and says that ~/.../Plug-Ins is read/write
>> >
>> >>
>> >>
>> >> It's the Wiki page that does not mention that folder.
>> >>
>> >>
>> >> > Do we actually want this?
>> >>
>> >> Does it violate anything on Linux apart from perhaps dubious
>> >> capitalisation?
>> >
>> >
>> > Needless duplication and confusion.
>> > Increased risk of user error, documentation errors (as seen in the
>> > current
>> > user manual) and programming errors.
>> > Increased complexity to the search path.
>> > Increased complexity to the documentation
>> >
>> > Is the existence of ~/audacity-data/Plug-Ins intentional, or just the
>> > result
>> > of a 'harmless' coding error?
>> > If intentional, what's the reason?
>> >
>> > As we saw in this forum topic:
>> > https://forum.audacityteam.org/viewtopic.php?f=50&t=95305 there are some
>> > other strange issues with the plug-in search path.
>> >
>> > Needless complication is bad for so many reasons that if this additional
>> > "Plug-Ins" path is "needless", then I think it should be removed.
>> >
>> > Is this DataDir() + "Plug-Ins" path relevant on any other platform, or
>> > can
>> > it just be deleted?
>> >
>> >
>> >>
>> >>
>> >> It does have the merit of already existing in the user's own space.
>> >
>> >
>> > Not really a "merit" as we could just as easily create
>> > ~/audacity-file/plug-ins if we wanted to (though I don't see a great
>> > need to
>> > do so, and it would be better would be for a "plug-in manager" to handle
>> > plug-in installation on all platforms).
>> >
>> > Steve
>> >
>> >>
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Plug-in path on Linux

Stevethefiddle
In reply to this post by Gale


On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]> wrote:
> http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
> It says, or at least implies that ~/.audacity-files/plug-ins is read only.
> It has incorrect capitalization for file names (very important on a case
> sensitive file system)
> It then contradicts itself and says that ~/.../Plug-Ins is read/write

The read-only implication was just a stray bullet point that got left in.

I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins so
I changed the subfolder name to lower case.

Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
plugins, which is unexpected given ~/.audacity-data/Plug-Ins does so.
The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
plugins.

You can change ~/.audacity-data/Plug-Ins to ~/.audacity-data/plug-ins
and your plugins will still be seen.

See if this is better:
http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

That looks correct now, but the number of options (including the undocumented options) is far more complicated than it needs to be imo. I don't see why users need more than one location in their home directory for Nyquist plug-ins (in addition to the 'system' location).

The full list of locations on my machine where Audacity apparently looks for Nyquist plug-ins:

"~/nyquist"
"~/plugins"
"~/plug-ins"
"~/.audacity-files/nyquist"
"~/.audacity-files/plugins"
"~/.audacity-files/plug-ins"
"/usr/local/share/audacity/nyquist"
"/usr/local/share/audacity/plugins"
"/usr/local/share/audacity/plug-ins"
"/usr/local/share/doc/audacity/nyquist"
"/usr/local/share/doc/audacity/plugins"
"/usr/local/share/doc/audacity/plug-ins"
"/usr/local/share/locale/nyquist"
"/usr/local/share/locale/plugins"
"/usr/local/share/locale/plug-ins"
"~/locale/nyquist"
"~/locale/plugins"
"~/locale/plug-ins"

and

"~/.audacity-data/Plug-Ins"

Steve

 

.


Gale

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


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

Re: Plug-in path on Linux

Stevethefiddle
In reply to this post by Gale


On 16 May 2017 at 20:56, Gale Andrews <[hidden email]> wrote:
On 16 May 2017 at 19:56, Steve the Fiddle <[hidden email]> wrote:
[...]
> Looking at other applications on my computer, the most common system is for
> an application to have a "dot directory", in which all of its configuration
> files, including application specific plug-ins, extensions, themes, filters,
> settings and so on are kept.
>
> For example, Gimp has a folder:
> ~/.gimp-2.8
> in which there is:
> brushes/
> curves/
> dynamics/
> ...
> scripts/
> templates/
> themes/
> tmp/
> tool-options/
> tool-presets/
> and then a bunch of plain text configuration files.
>
> Similarly Mozilla Firefox has its "extensions", profile, settings and so on
> in ~/.mozilla
>
> Dropbox uses ~/.dropbox
>
> Filezilla uses ~/.filezilla
>
> and so on.
>
>
> So for Audacity, the "standard" structure would be:
> ~/.audacity
>
> which would contain: "plug-ins/" (or "plugins/"), "autosave/", "chains/" and
> plain text configuration files.

Still, that isn't a long way from ~/.audacity_data so I only see a
medium priority to change to ~/.audacity.

To me, DataDir() + "Plug-Ins" is a reasonable approach and
is uniform on all three platforms.It's perhaps a little superfluous
on Windows but once the user knows how to show that directory
it is arguably easier for a standard user than giving a password
to add plugins to Program Files\Audacity\Plug-Ins.

To me the actual problem is too many other folders that accept
only Nyquist plugins. But as in the Forum complaint you linked to,
actually provide a system path for Nyquist plugins that sysadmins
can use.


> We're not going to be able to do that overnight.

>>
>>
>>
>>
>> Steve wrote:
>> > It would be better would be for a "plug-in manager" to handle
>> > plug-in installation on all platforms).
>>
>> I don't understand that point. Does that not happen now on Linux?
>> That is, put the plugin somewhere then enable it in Plug-in Manager?
>
>
> I mean for the Plug-in manager to "install" plug-ins in the appropriate
> location.
> Download the plug-in to your Desktop or anywhere, select it in the plug-in
> manager, and the plug-in manager installs it (copies it to an appropriate
> location and enabled it in Audacity).

Wow, that may be OK if any plugins were available as packages via
OneGet/Chocolatey on Windows or HomeBrew/MacPorts on Mac.

I can't see Audacity handling some of the complex commercial VST
installers that are common on Windows.

If a complex commercial VST  plug-in has its own installer, then no need for us to handle the installation.

Steve
 


Gale

>>
>>
>>
>>
>> Gale
>>
>>
>> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> >
>> > On 16 May 2017 at 02:10, Gale Andrews <[hidden email]> wrote:
>> >>
>> >> On 15 May 2017 at 10:10, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >> > This came up today on feedback@ and concerns the plug-in path on
>> >> > Linux.
>> >> >
>> >> > The default path for shipped plug-ins is:
>> >> > usr/share/audacity/plug-ins
>> >> > or
>> >> > usr/local/share/audacity/plug-ins
>> >> >
>> >> > Both of these locations require root privileges to write to.
>> >> >
>> >> > Users may also install plug-ins in their home directory (only
>> >> > requires
>> >> > normal use privileges) as described in the Manual
>> >> >
>> >> >
>> >> > (http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >> > and wiki
>> >> > (http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins#install)
>> >> > by
>> >> > creating a folder:
>> >> > ~/.audacity-files/plug-ins
>> >> >
>> >> > So far so good...
>> >> >
>> >> > but we also have an undocumented folder in:
>> >> > ~/.audacity-data/Plug-Ins
>> >> >
>> >> > (note also the non-Linux-like capitalization)
>> >> >
>> >> > This seems to have been added 7+ years ago (by Richard Ash ?)
>> >> >
>> >> > wxString FileNames::PlugInDir()
>> >> > {
>> >> >    return FileNames::MkDir( wxFileName( DataDir(), wxT("Plug-Ins")
>> >> > ).GetFullPath() );
>> >> > }
>> >> >
>> >> > Does anyone know why?
>> >>
>> >> The Plug-Ins folder in Audacity's application data folder is documented
>> >> on:
>> >>
>> >>
>> >> http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >
>> >
>> > OK, I missed that, but that documentation is confusing:
>> >
>> > It says, or at least implies that ~/.audacity-files/plug-ins is read
>> > only.
>> > It has incorrect capitalization for file names (very important on a case
>> > sensitive file system)
>> > It then contradicts itself and says that ~/.../Plug-Ins is read/write
>> >
>> >>
>> >>
>> >> It's the Wiki page that does not mention that folder.
>> >>
>> >>
>> >> > Do we actually want this?
>> >>
>> >> Does it violate anything on Linux apart from perhaps dubious
>> >> capitalisation?
>> >
>> >
>> > Needless duplication and confusion.
>> > Increased risk of user error, documentation errors (as seen in the
>> > current
>> > user manual) and programming errors.
>> > Increased complexity to the search path.
>> > Increased complexity to the documentation
>> >
>> > Is the existence of ~/audacity-data/Plug-Ins intentional, or just the
>> > result
>> > of a 'harmless' coding error?
>> > If intentional, what's the reason?
>> >
>> > As we saw in this forum topic:
>> > https://forum.audacityteam.org/viewtopic.php?f=50&t=95305 there are some
>> > other strange issues with the plug-in search path.
>> >
>> > Needless complication is bad for so many reasons that if this additional
>> > "Plug-Ins" path is "needless", then I think it should be removed.
>> >
>> > Is this DataDir() + "Plug-Ins" path relevant on any other platform, or
>> > can
>> > it just be deleted?
>> >
>> >
>> >>
>> >>
>> >> It does have the merit of already existing in the user's own space.
>> >
>> >
>> > Not really a "merit" as we could just as easily create
>> > ~/audacity-file/plug-ins if we wanted to (though I don't see a great
>> > need to
>> > do so, and it would be better would be for a "plug-in manager" to handle
>> > plug-in installation on all platforms).
>> >
>> > Steve
>> >
>> >>
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

Re: Plug-in path on Linux

Gale
Administrator
In reply to this post by Stevethefiddle
On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]> wrote:

>
>
> On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>>
>> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> > It says, or at least implies that ~/.audacity-files/plug-ins is read
>> > only.
>> > It has incorrect capitalization for file names (very important on a case
>> > sensitive file system)
>> > It then contradicts itself and says that ~/.../Plug-Ins is read/write
>>
>> The read-only implication was just a stray bullet point that got left in.
>>
>> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins so
>> I changed the subfolder name to lower case.
>>
>> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does so.
>> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>> plugins.
>>
>> You can change ~/.audacity-data/Plug-Ins to ~/.audacity-data/plug-ins
>> and your plugins will still be seen.
>>
>> See if this is better:
>>
>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>
>
> That looks correct now, but the number of options (including the
> undocumented options) is far more complicated than it needs to be imo. I
> don't see why users need more than one location in their home directory for
> Nyquist plug-ins (in addition to the 'system' location).

Looks like we may be in agreement then, though arguably the current
"system" locations for Nyquist plugins on Linux are suboptimal because
they don't preserve the plugins through updates of Audacity. I think we
could do with a system location for Nyquist plugins that doesn't have
that problem.


Gale



> The full list of locations on my machine where Audacity apparently looks for
> Nyquist plug-ins:
>
> "~/nyquist"
> "~/plugins"
> "~/plug-ins"
> "~/.audacity-files/nyquist"
> "~/.audacity-files/plugins"
> "~/.audacity-files/plug-ins"
> "/usr/local/share/audacity/nyquist"
> "/usr/local/share/audacity/plugins"
> "/usr/local/share/audacity/plug-ins"
> "/usr/local/share/doc/audacity/nyquist"
> "/usr/local/share/doc/audacity/plugins"
> "/usr/local/share/doc/audacity/plug-ins"
> "/usr/local/share/locale/nyquist"
> "/usr/local/share/locale/plugins"
> "/usr/local/share/locale/plug-ins"
> "~/locale/nyquist"
> "~/locale/plugins"
> "~/locale/plug-ins"
>
> and
>
> "~/.audacity-data/Plug-Ins"
>
> Steve
>
>
>>
>>
>> .
>>
>>
>> Gale
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Plug-in path on Linux

Stevethefiddle


On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]> wrote:
>
>
> On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>>
>> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> > It says, or at least implies that ~/.audacity-files/plug-ins is read
>> > only.
>> > It has incorrect capitalization for file names (very important on a case
>> > sensitive file system)
>> > It then contradicts itself and says that ~/.../Plug-Ins is read/write
>>
>> The read-only implication was just a stray bullet point that got left in.
>>
>> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins so
>> I changed the subfolder name to lower case.
>>
>> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does so.
>> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>> plugins.
>>
>> You can change ~/.audacity-data/Plug-Ins to ~/.audacity-data/plug-ins
>> and your plugins will still be seen.
>>
>> See if this is better:
>>
>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>
>
> That looks correct now, but the number of options (including the
> undocumented options) is far more complicated than it needs to be imo. I
> don't see why users need more than one location in their home directory for
> Nyquist plug-ins (in addition to the 'system' location).

Looks like we may be in agreement then, though arguably the current
"system" locations for Nyquist plugins on Linux are suboptimal because
they don't preserve the plugins through updates of Audacity.

I don't see that here.

We do (correctly) overwrite shipped plug-ins, which is normal for Linux and necessary to allow shipped plug-ins to be updated to the latest version, but user installed plug-ins survive both the uninstalling and reinstalling of Audacity from the command line.

I've not tested what happens when uninstalling / reinstalling via a distribution's package manager, but I'd have thought that was a matter for the distro maintainer.

 
I think we
could do with a system location for Nyquist plugins that doesn't have
that problem.

Speaking specifically about Linux:

1) Users should not overwrite system files unless they know what they are doing.
2) A system administrator should be able to install additional plug-ins system wide (for all users) by putting them into a system folder.
3) A regular user should only be able to install plug-ins within their user space.

Looking at this more deeply, it's more complex than first appears.

My documentation is wrong. The Nyquist plug-in path (get '*system-directory* 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of "audacityPathList":

From the code:

/** \brief A list of directories that should be searched for Audacity files
* (plug-ins, help files, etc.).
*
* On Unix this will include the directory Audacity was installed into,
* plus the current user's .audacity-data/Plug-Ins directory.  Additional
* directories can be specified using the AUDACITY_PATH environment
* variable.  On Windows or Mac OS, this will include the directory
* which contains the Audacity program. */
wxArrayString audacityPathList;

The subset comes form: GetNyquistSearchPath
which is not documented.

The first use of GetNyquistSearchPath was in NyquistEffectsModule::FindPlugins, so I believe the intention was to be a list of where plug-ins may be located, but it also includes additional locations where other Nyquist related files are located.

(I'm not sure why some of these directories are not working for you Gale, but the code says they 'should' work, so I'll assume 'user error' for the sake of this discussion.)

Audacity can find Nyquist plug-ins in any of the directories, but that is NOT to say that all of these directories are the 'correct' locations for Nyquist plug-ins.

Example, the "Nyquist search path" (from GetNyquistSearchPath) includes the Nyquist .LSP files. This is reasonable because Nyquist needs to be able to find its LISP functions, but .NY plug-ins should not be mixed in with the .LSP files.

I need to analyze where Audacity is looking and why....

Steve
 


Gale



> The full list of locations on my machine where Audacity apparently looks for
> Nyquist plug-ins:
>
> "~/nyquist"
> "~/plugins"
> "~/plug-ins"
> "~/.audacity-files/nyquist"
> "~/.audacity-files/plugins"
> "~/.audacity-files/plug-ins"
> "/usr/local/share/audacity/nyquist"
> "/usr/local/share/audacity/plugins"
> "/usr/local/share/audacity/plug-ins"
> "/usr/local/share/doc/audacity/nyquist"
> "/usr/local/share/doc/audacity/plugins"
> "/usr/local/share/doc/audacity/plug-ins"
> "/usr/local/share/locale/nyquist"
> "/usr/local/share/locale/plugins"
> "/usr/local/share/locale/plug-ins"
> "~/locale/nyquist"
> "~/locale/plugins"
> "~/locale/plug-ins"
>
> and
>
> "~/.audacity-data/Plug-Ins"
>
> Steve
>
>
>>
>>
>> .
>>
>>
>> Gale
>>
>>
>> ------------------------------------------------------------------------------



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

Re: Plug-in path on Linux

Stevethefiddle
This (below) is my analysis of the Nyquist plug-in path on Linux.

I'm not aware of this being documented, but I think it should be documented somewhere (Cc: to manual@)
I also think it shows some issues that need to be addressed. In particular, those marked "INCORRECT".


Re: "~/.audacity-data/Plug-Ins"

I'm not convinced by the unconventional and (as far as I can see) unnecessary location.

If it really does support all types of plug-ins (Nyquist, Linux VST, LADSPA and LV2), then it is certainly more convenient for users that want to download arbitrary "shared object" files than installing LADSPA / LV2 or VST plug-ins correctly, but:

a) Is there a security risk?
b) Even if not a security risk, should we not encourage users to install shared plug-ins properly?
c) Installing plug-ins that are "approved" by the distro maintainers are easily installed via the package manager.

Steve


--- START ---

CORRECT (System):

"/usr/[local/]share/audacity/nyquist"
CORRECT location for system wide .LSP files

"/usr/[local/]share/audacity/plugins"
LEGACY location for system wide .NY plug-ins (depricated)

"/usr/[local/]share/audacity/plug-ins"
CORRECT location for system wide .NY plug-ins

"/usr/[local/]share/doc/audacity/nyquist"
CORRECT location for system wide Nyquist documentation
(documentation could also be in the manual, but Nyquist won't
look there by default)
 
"/usr/[local/]share/doc/audacity/plugins"
LEGACY location for system wide Nyquist Plug-ins (depricated)

"/usr/[local/]share/doc/audacity/plug-ins"
CORRECT location for system wide Audacity/Nyquist Plug-ins
(documentation could also be in the manual, but Nyquist won't
look there by default)

---

CORRECT (User):

"~/.audacity-files/nyquist"
CORRECT location for user .LSP files

"~/.audacity-files/plugins"
LEGACY location for user .NY plug-ins (depricated)

"~/.audacity-files/plug-ins"
CORRECT location for user .NY plug-ins

---
---

CONVENIENT BUT UNNECESSARY AND NOT 'NIX-LIKE:

"~/.audacity-data/Plug-Ins"
UNCONVENTIONAL location for all(?) types of plug-in including .NY plug-ins

---
---

NOT USED (System):

"/usr/[local/]share/locale/nyquist"
CORRECT location for system wide Nyquist Locale information

"/usr/[local/]share/locale/plugins"
LEGACY location for system wide Nyquist Plug-in Locale information (depricated)

"/usr/[local/]share/locale/plug-ins"
CORRECT location for system wide Nyquist Plug-in Locale information

---

NOT USED (User):
 
"~/locale/nyquist"
CORRECT location for user Nyquist Locale information

"~/locale/plugins"
LEGACY location for user Nyquist Plug-in Locale information (depricated)

"~/locale/plug-ins"
CORRECT location for user Nyquist Plug-in Locale information

---
---

INCORRECT (User):

These are dangerous clutter.
Users should be able to create non-dot directories for their own data without risk of affecting applications.

"~/nyquist"
INCORRECT. This would more properly be a user location for stand-alone Nyquist.


"~/plugins"
INCORRECT: This is dangerous clutter.

"~/plug-ins"
INCORRECT: This is dangerous clutter.


--- END ---

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

Re: Plug-in path on Linux

Gale
Administrator
In reply to this post by Stevethefiddle
On 17 May 2017 at 14:27, Steve the Fiddle <[hidden email]> wrote:

>
>
> On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
>>
>> On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> >
>> > On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>> >>
>> >> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >> >
>> >> >
>> >> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >> > It says, or at least implies that ~/.audacity-files/plug-ins is read
>> >> > only.
>> >> > It has incorrect capitalization for file names (very important on a
>> >> > case
>> >> > sensitive file system)
>> >> > It then contradicts itself and says that ~/.../Plug-Ins is read/write
>> >>
>> >> The read-only implication was just a stray bullet point that got left
>> >> in.
>> >>
>> >> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins so
>> >> I changed the subfolder name to lower case.
>> >>
>> >> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>> >> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does so.
>> >> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>> >> plugins.
>> >>
>> >> You can change ~/.audacity-data/Plug-Ins to ~/.audacity-data/plug-ins
>> >> and your plugins will still be seen.
>> >>
>> >> See if this is better:
>> >>
>> >>
>> >> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>> >
>> >
>> > That looks correct now, but the number of options (including the
>> > undocumented options) is far more complicated than it needs to be imo. I
>> > don't see why users need more than one location in their home directory
>> > for
>> > Nyquist plug-ins (in addition to the 'system' location).
>>
>> Looks like we may be in agreement then, though arguably the current
>> "system" locations for Nyquist plugins on Linux are suboptimal because
>> they don't preserve the plugins through updates of Audacity.
>
>
> I don't see that here.
>
> We do (correctly) overwrite shipped plug-ins, which is normal for Linux and
> necessary to allow shipped plug-ins to be updated to the latest version, but
> user installed plug-ins survive both the uninstalling and reinstalling of
> Audacity from the command line.
>
> I've not tested what happens when uninstalling / reinstalling via a
> distribution's package manager, but I'd have thought that was a matter for
> the distro maintainer.

What happens with a distro package is the primary concern of most
users and so the primary concern of the documentation.

http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

says that "Updating the repository package of Audacity may remove
plug-ins that are not part of the package."  I don't think it was I who
added that text in the first place, but I expect that the caution is
warranted.


>> I think we
>> could do with a system location for Nyquist plugins that doesn't have
>> that problem.
>
>
> Speaking specifically about Linux:
>
> 1) Users should not overwrite system files unless they know what they are
> doing.
> 2) A system administrator should be able to install additional plug-ins
> system wide (for all users) by putting them into a system folder.

I assume a sysadmin on Linux would be installing a repository package
of Audacity, so if the above caution is correct and the sysadmin wants
users to have e.g. the ACX-Check plugin, should the sysadmin have to
keep reinstalling ACX-Check with each Audacity update?


> 3) A regular user should only be able to install plug-ins within their user
> space.
>
> Looking at this more deeply, it's more complex than first appears.
>
> My documentation is wrong. The Nyquist plug-in path (get '*system-directory*
> 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of
> "audacityPathList":
>
> From the code:
>
> /** \brief A list of directories that should be searched for Audacity files
> * (plug-ins, help files, etc.).
> *
> * On Unix this will include the directory Audacity was installed into,
> * plus the current user's .audacity-data/Plug-Ins directory.  Additional
> * directories can be specified using the AUDACITY_PATH environment
> * variable.  On Windows or Mac OS, this will include the directory
> * which contains the Audacity program. */
> wxArrayString audacityPathList;
>
> The subset comes form: GetNyquistSearchPath
> which is not documented.
>
> The first use of GetNyquistSearchPath was in
> NyquistEffectsModule::FindPlugins, so I believe the intention was to be a
> list of where plug-ins may be located, but it also includes additional
> locations where other Nyquist related files are located.
>
> (I'm not sure why some of these directories are not working for you Gale,
> but the code says they 'should' work, so I'll assume 'user error' for the
> sake of this discussion.)

I have not retested yet, but I suspect a need to start with a fresh
pluginregistry.cfg is just as likely a cause.



Gale


> Audacity can find Nyquist plug-ins in any of the directories, but that is
> NOT to say that all of these directories are the 'correct' locations for
> Nyquist plug-ins.
>
> Example, the "Nyquist search path" (from GetNyquistSearchPath) includes the
> Nyquist .LSP files. This is reasonable because Nyquist needs to be able to
> find its LISP functions, but .NY plug-ins should not be mixed in with the
> .LSP files.
>
> I need to analyze where Audacity is looking and why....
>
> Steve
>
>>
>>
>>
>> Gale
>>
>>
>>
>> > The full list of locations on my machine where Audacity apparently looks
>> > for
>> > Nyquist plug-ins:
>> >
>> > "~/nyquist"
>> > "~/plugins"
>> > "~/plug-ins"
>> > "~/.audacity-files/nyquist"
>> > "~/.audacity-files/plugins"
>> > "~/.audacity-files/plug-ins"
>> > "/usr/local/share/audacity/nyquist"
>> > "/usr/local/share/audacity/plugins"
>> > "/usr/local/share/audacity/plug-ins"
>> > "/usr/local/share/doc/audacity/nyquist"
>> > "/usr/local/share/doc/audacity/plugins"
>> > "/usr/local/share/doc/audacity/plug-ins"
>> > "/usr/local/share/locale/nyquist"
>> > "/usr/local/share/locale/plugins"
>> > "/usr/local/share/locale/plug-ins"
>> > "~/locale/nyquist"
>> > "~/locale/plugins"
>> > "~/locale/plug-ins"
>> >
>> > and
>> >
>> > "~/.audacity-data/Plug-Ins"
>> >
>> > Steve
>> >
>> >
>> >>
>> >>
>> >> .
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: [Audacity-manual] Plug-in path on Linux

Gale
Administrator
In reply to this post by Stevethefiddle
On 17 May 2017 at 15:37, Steve the Fiddle <[hidden email]> wrote:

> This (below) is my analysis of the Nyquist plug-in path on Linux.
>
> I'm not aware of this being documented, but I think it should be documented
> somewhere (Cc: to manual@)
> I also think it shows some issues that need to be addressed. In particular,
> those marked "INCORRECT".
>
>
> Re: "~/.audacity-data/Plug-Ins"
>
> I'm not convinced by the unconventional and (as far as I can see)
> unnecessary location.

We have agreed we need some folder like this on Mac.


> If it really does support all types of plug-ins (Nyquist, Linux VST, LADSPA
> and LV2),

I never said it supported LV2. It doesn't AFAICT. Audacity can see LV2
folders placed there, but if you enable the effect it does not appear in
the Effect menu and reverts to "New" in Plug-in Manager.  Move the
folder to ~/.lv2, and the effect works fine.

"~/.audacity-data/Plug-Ins" supports Nyquist, VST (yes on Linux too)
and LADSPA on all platforms. So it supports the same as the Plug-Ins
folder in the Audacity executable directory on Windows, and the same
as the equivalent folder on Mac if you really want to drill down to it.


> then it is certainly more convenient for users that want to
> download arbitrary "shared object" files than installing LADSPA / LV2 or
> VST plug-ins correctly, but:
>
> a) Is there a security risk?
> b) Even if not a security risk, should we not encourage users to install
> shared plug-ins properly?
> c) Installing plug-ins that are "approved" by the distro maintainers are
> easily installed via the package manager.

What security risk do you have in mind?

Looking for more LV2 plugins on Linux just now, I found several that had
to be compiled and apparently manually installed.  There did not seem to
be a concept of "install properly" there.

Personally I am fine with "~/.audacity/plug-ins" on Linux (supporting Nyquist,
LADSPA and VST) and to trim the plethora of Nyquist-only plugin locations.

Please update http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

further if you see the need. I think it is sufficiently correct now, but please
tell me if I am missing something obvious. I don't think we need to
document folders that are deprecated or that we may hopefully not be
supporting any longer.



Gale


> --- START ---
>
> CORRECT (System):
>
> "/usr/[local/]share/audacity/nyquist"
> CORRECT location for system wide .LSP files
>
> "/usr/[local/]share/audacity/plugins"
> LEGACY location for system wide .NY plug-ins (depricated)
>
> "/usr/[local/]share/audacity/plug-ins"
> CORRECT location for system wide .NY plug-ins
>
> "/usr/[local/]share/doc/audacity/nyquist"
> CORRECT location for system wide Nyquist documentation
> (documentation could also be in the manual, but Nyquist won't
> look there by default)
>
> "/usr/[local/]share/doc/audacity/plugins"
> LEGACY location for system wide Nyquist Plug-ins (depricated)
>
> "/usr/[local/]share/doc/audacity/plug-ins"
> CORRECT location for system wide Audacity/Nyquist Plug-ins
> (documentation could also be in the manual, but Nyquist won't
> look there by default)
>
> ---
>
> CORRECT (User):
>
> "~/.audacity-files/nyquist"
> CORRECT location for user .LSP files
>
> "~/.audacity-files/plugins"
> LEGACY location for user .NY plug-ins (depricated)
>
> "~/.audacity-files/plug-ins"
> CORRECT location for user .NY plug-ins
>
> ---
> ---
>
> CONVENIENT BUT UNNECESSARY AND NOT 'NIX-LIKE:
>
> "~/.audacity-data/Plug-Ins"
> UNCONVENTIONAL location for all(?) types of plug-in including .NY plug-ins
>
> ---
> ---
>
> NOT USED (System):
>
> "/usr/[local/]share/locale/nyquist"
> CORRECT location for system wide Nyquist Locale information
>
> "/usr/[local/]share/locale/plugins"
> LEGACY location for system wide Nyquist Plug-in Locale information
> (depricated)
>
> "/usr/[local/]share/locale/plug-ins"
> CORRECT location for system wide Nyquist Plug-in Locale information
>
> ---
>
> NOT USED (User):
>
> "~/locale/nyquist"
> CORRECT location for user Nyquist Locale information
>
> "~/locale/plugins"
> LEGACY location for user Nyquist Plug-in Locale information (depricated)
>
> "~/locale/plug-ins"
> CORRECT location for user Nyquist Plug-in Locale information
>
> ---
> ---
>
> INCORRECT (User):
>
> These are dangerous clutter.
> Users should be able to create non-dot directories for their own data
> without risk of affecting applications.
>
> "~/nyquist"
> INCORRECT. This would more properly be a user location for stand-alone
> Nyquist.
>
>
> "~/plugins"
> INCORRECT: This is dangerous clutter.
>
> "~/plug-ins"
> INCORRECT: This is dangerous clutter.
>
>
> --- END ---
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-manual mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-manual

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

Re: [Audacity-manual] Plug-in path on Linux

Stevethefiddle


On 17 May 2017 at 21:32, Gale Andrews <[hidden email]> wrote:
On 17 May 2017 at 15:37, Steve the Fiddle <[hidden email]> wrote:
> This (below) is my analysis of the Nyquist plug-in path on Linux.
>
> I'm not aware of this being documented, but I think it should be documented
> somewhere (Cc: to manual@)
> I also think it shows some issues that need to be addressed. In particular,
> those marked "INCORRECT".
>
>
> Re: "~/.audacity-data/Plug-Ins"
>
> I'm not convinced by the unconventional and (as far as I can see)
> unnecessary location.

We have agreed we need some folder like this on Mac.

It could easily be made Mac specific, or Mac + Windows, if that's the right thing to do.

By saying "I'm not convinced..." I was trying to convey the sense that I was giving my "opinion" and that I don't "know for sure" what the right thing to do is. Input from a 'nix expert would be helpful.
 


> If it really does support all types of plug-ins (Nyquist, Linux VST, LADSPA
> and LV2),

I never said it supported LV2. It doesn't AFAICT. Audacity can see LV2
folders placed there, but if you enable the effect it does not appear in
the Effect menu and reverts to "New" in Plug-in Manager.  Move the
folder to ~/.lv2, and the effect works fine.

OK, so that's less useful than if it were universal.
 

"~/.audacity-data/Plug-Ins" supports Nyquist, VST (yes on Linux too)
and LADSPA on all platforms. So it supports the same as the Plug-Ins
folder in the Audacity executable directory on Windows, and the same
as the equivalent folder on Mac if you really want to drill down to it.


> then it is certainly more convenient for users that want to
> download arbitrary "shared object" files than installing LADSPA / LV2 or
> VST plug-ins correctly, but:
>
> a) Is there a security risk?
> b) Even if not a security risk, should we not encourage users to install
> shared plug-ins properly?
> c) Installing plug-ins that are "approved" by the distro maintainers are
> easily installed via the package manager.

What security risk do you have in mind?

Looking for more LV2 plugins on Linux just now, I found several that had
to be compiled and apparently manually installed.  There did not seem to
be a concept of "install properly" there.

My understanding is that the "recommended" way to install LV2 (or anything else) is with the distros package manager, though of course Linux grants users the freedom to do whatever they like on their own machine. Plug-ins that are provided in a distribution's repository 'should' be safe to use. I don't think the same can be said for arbitrary downloads from the Internet.
 

Personally I am fine with "~/.audacity/plug-ins" on Linux (supporting Nyquist,
LADSPA and VST) and to trim the plethora of Nyquist-only plugin locations.

Please update http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

further if you see the need. I think it is sufficiently correct now, but please
tell me if I am missing something obvious. I don't think we need to
document folders that are deprecated or that we may hopefully not be
supporting any longer.



Gale


> --- START ---
>
> CORRECT (System):
>
> "/usr/[local/]share/audacity/nyquist"
> CORRECT location for system wide .LSP files
>
> "/usr/[local/]share/audacity/plugins"
> LEGACY location for system wide .NY plug-ins (depricated)
>
> "/usr/[local/]share/audacity/plug-ins"
> CORRECT location for system wide .NY plug-ins
>
> "/usr/[local/]share/doc/audacity/nyquist"
> CORRECT location for system wide Nyquist documentation
> (documentation could also be in the manual, but Nyquist won't
> look there by default)
>
> "/usr/[local/]share/doc/audacity/plugins"
> LEGACY location for system wide Nyquist Plug-ins (depricated)
>
> "/usr/[local/]share/doc/audacity/plug-ins"
> CORRECT location for system wide Audacity/Nyquist Plug-ins
> (documentation could also be in the manual, but Nyquist won't
> look there by default)
>
> ---
>
> CORRECT (User):
>
> "~/.audacity-files/nyquist"
> CORRECT location for user .LSP files
>
> "~/.audacity-files/plugins"
> LEGACY location for user .NY plug-ins (depricated)
>
> "~/.audacity-files/plug-ins"
> CORRECT location for user .NY plug-ins
>
> ---
> ---
>
> CONVENIENT BUT UNNECESSARY AND NOT 'NIX-LIKE:
>
> "~/.audacity-data/Plug-Ins"
> UNCONVENTIONAL location for all(?) types of plug-in including .NY plug-ins
>
> ---
> ---
>
> NOT USED (System):
>
> "/usr/[local/]share/locale/nyquist"
> CORRECT location for system wide Nyquist Locale information
>
> "/usr/[local/]share/locale/plugins"
> LEGACY location for system wide Nyquist Plug-in Locale information
> (depricated)
>
> "/usr/[local/]share/locale/plug-ins"
> CORRECT location for system wide Nyquist Plug-in Locale information
>
> ---
>
> NOT USED (User):
>
> "~/locale/nyquist"
> CORRECT location for user Nyquist Locale information
>
> "~/locale/plugins"
> LEGACY location for user Nyquist Plug-in Locale information (depricated)
>
> "~/locale/plug-ins"
> CORRECT location for user Nyquist Plug-in Locale information
>
> ---
> ---
>
> INCORRECT (User):
>
> These are dangerous clutter.
> Users should be able to create non-dot directories for their own data
> without risk of affecting applications.
>
> "~/nyquist"
> INCORRECT. This would more properly be a user location for stand-alone
> Nyquist.
>
>
> "~/plugins"
> INCORRECT: This is dangerous clutter.
>
> "~/plug-ins"
> INCORRECT: This is dangerous clutter.
>
>
> --- END ---
> ------------------------------------------------------------------------------



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

Re: Plug-in path on Linux

Stevethefiddle
In reply to this post by Gale


On 17 May 2017 at 20:03, Gale Andrews <[hidden email]> wrote:
On 17 May 2017 at 14:27, Steve the Fiddle <[hidden email]> wrote:
>
>
> On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
>>
>> On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> >
>> > On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>> >>
>> >> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >> >
>> >> >
>> >> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >> > It says, or at least implies that ~/.audacity-files/plug-ins is read
>> >> > only.
>> >> > It has incorrect capitalization for file names (very important on a
>> >> > case
>> >> > sensitive file system)
>> >> > It then contradicts itself and says that ~/.../Plug-Ins is read/write
>> >>
>> >> The read-only implication was just a stray bullet point that got left
>> >> in.
>> >>
>> >> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins so
>> >> I changed the subfolder name to lower case.
>> >>
>> >> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>> >> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does so.
>> >> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>> >> plugins.
>> >>
>> >> You can change ~/.audacity-data/Plug-Ins to ~/.audacity-data/plug-ins
>> >> and your plugins will still be seen.
>> >>
>> >> See if this is better:
>> >>
>> >>
>> >> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>> >
>> >
>> > That looks correct now, but the number of options (including the
>> > undocumented options) is far more complicated than it needs to be imo. I
>> > don't see why users need more than one location in their home directory
>> > for
>> > Nyquist plug-ins (in addition to the 'system' location).
>>
>> Looks like we may be in agreement then, though arguably the current
>> "system" locations for Nyquist plugins on Linux are suboptimal because
>> they don't preserve the plugins through updates of Audacity.
>
>
> I don't see that here.
>
> We do (correctly) overwrite shipped plug-ins, which is normal for Linux and
> necessary to allow shipped plug-ins to be updated to the latest version, but
> user installed plug-ins survive both the uninstalling and reinstalling of
> Audacity from the command line.
>
> I've not tested what happens when uninstalling / reinstalling via a
> distribution's package manager, but I'd have thought that was a matter for
> the distro maintainer.

What happens with a distro package is the primary concern of most
users and so the primary concern of the documentation.

http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

says that "Updating the repository package of Audacity may remove
plug-ins that are not part of the package."  I don't think it was I who
added that text in the first place, but I expect that the caution is
warranted.

I've just tested as follows:

1) Install Audacity from the Ubuntu repository with Synaptic (from end for 'apt')
2) Add a plug-in to /usr/share/audacity/plug-ins/
3) Reinstall Audacity from the Ubuntu repository.
The plug-in added in step 2 still exists.

4) "Complete removal" of Audacity via Synaptic
The plug-in added in step 2 still exists.

So it seems that the warning in the manual is incorrect, at least on Ubuntu (and if I recall correctly, it's the same on Debian).

Steve
 


>> I think we
>> could do with a system location for Nyquist plugins that doesn't have
>> that problem.
>
>
> Speaking specifically about Linux:
>
> 1) Users should not overwrite system files unless they know what they are
> doing.
> 2) A system administrator should be able to install additional plug-ins
> system wide (for all users) by putting them into a system folder.

I assume a sysadmin on Linux would be installing a repository package
of Audacity, so if the above caution is correct and the sysadmin wants
users to have e.g. the ACX-Check plugin, should the sysadmin have to
keep reinstalling ACX-Check with each Audacity update?


> 3) A regular user should only be able to install plug-ins within their user
> space.
>
> Looking at this more deeply, it's more complex than first appears.
>
> My documentation is wrong. The Nyquist plug-in path (get '*system-directory*
> 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of
> "audacityPathList":
>
> From the code:
>
> /** \brief A list of directories that should be searched for Audacity files
> * (plug-ins, help files, etc.).
> *
> * On Unix this will include the directory Audacity was installed into,
> * plus the current user's .audacity-data/Plug-Ins directory.  Additional
> * directories can be specified using the AUDACITY_PATH environment
> * variable.  On Windows or Mac OS, this will include the directory
> * which contains the Audacity program. */
> wxArrayString audacityPathList;
>
> The subset comes form: GetNyquistSearchPath
> which is not documented.
>
> The first use of GetNyquistSearchPath was in
> NyquistEffectsModule::FindPlugins, so I believe the intention was to be a
> list of where plug-ins may be located, but it also includes additional
> locations where other Nyquist related files are located.
>
> (I'm not sure why some of these directories are not working for you Gale,
> but the code says they 'should' work, so I'll assume 'user error' for the
> sake of this discussion.)

I have not retested yet, but I suspect a need to start with a fresh
pluginregistry.cfg is just as likely a cause.



Gale


> Audacity can find Nyquist plug-ins in any of the directories, but that is
> NOT to say that all of these directories are the 'correct' locations for
> Nyquist plug-ins.
>
> Example, the "Nyquist search path" (from GetNyquistSearchPath) includes the
> Nyquist .LSP files. This is reasonable because Nyquist needs to be able to
> find its LISP functions, but .NY plug-ins should not be mixed in with the
> .LSP files.
>
> I need to analyze where Audacity is looking and why....
>
> Steve
>
>>
>>
>>
>> Gale
>>
>>
>>
>> > The full list of locations on my machine where Audacity apparently looks
>> > for
>> > Nyquist plug-ins:
>> >
>> > "~/nyquist"
>> > "~/plugins"
>> > "~/plug-ins"
>> > "~/.audacity-files/nyquist"
>> > "~/.audacity-files/plugins"
>> > "~/.audacity-files/plug-ins"
>> > "/usr/local/share/audacity/nyquist"
>> > "/usr/local/share/audacity/plugins"
>> > "/usr/local/share/audacity/plug-ins"
>> > "/usr/local/share/doc/audacity/nyquist"
>> > "/usr/local/share/doc/audacity/plugins"
>> > "/usr/local/share/doc/audacity/plug-ins"
>> > "/usr/local/share/locale/nyquist"
>> > "/usr/local/share/locale/plugins"
>> > "/usr/local/share/locale/plug-ins"
>> > "~/locale/nyquist"
>> > "~/locale/plugins"
>> > "~/locale/plug-ins"
>> >
>> > and
>> >
>> > "~/.audacity-data/Plug-Ins"
>> >
>> > Steve
>> >
>> >
>> >>
>> >>
>> >> .
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

Re: Plug-in path on Linux

Gale
Administrator
On 18 May 2017 at 00:18, Steve the Fiddle <[hidden email]> wrote:

>
>
> On 17 May 2017 at 20:03, Gale Andrews <[hidden email]> wrote:
>>
>> On 17 May 2017 at 14:27, Steve the Fiddle <[hidden email]>
>> wrote:
>> >
>> >
>> > On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
>> >>
>> >> On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]>
>> >> wrote:
>> >> >
>> >> >
>> >> > On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>> >> >>
>> >> >> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>> >> >> wrote:
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>> >> >> > It says, or at least implies that ~/.audacity-files/plug-ins is
>> >> >> > read
>> >> >> > only.
>> >> >> > It has incorrect capitalization for file names (very important on
>> >> >> > a
>> >> >> > case
>> >> >> > sensitive file system)
>> >> >> > It then contradicts itself and says that ~/.../Plug-Ins is
>> >> >> > read/write
>> >> >>
>> >> >> The read-only implication was just a stray bullet point that got
>> >> >> left
>> >> >> in.
>> >> >>
>> >> >> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins
>> >> >> so
>> >> >> I changed the subfolder name to lower case.
>> >> >>
>> >> >> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>> >> >> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does
>> >> >> so.
>> >> >> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>> >> >> plugins.
>> >> >>
>> >> >> You can change ~/.audacity-data/Plug-Ins to
>> >> >> ~/.audacity-data/plug-ins
>> >> >> and your plugins will still be seen.
>> >> >>
>> >> >> See if this is better:
>> >> >>
>> >> >>
>> >> >>
>> >> >> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>> >> >
>> >> >
>> >> > That looks correct now, but the number of options (including the
>> >> > undocumented options) is far more complicated than it needs to be
>> >> > imo. I
>> >> > don't see why users need more than one location in their home
>> >> > directory
>> >> > for
>> >> > Nyquist plug-ins (in addition to the 'system' location).
>> >>
>> >> Looks like we may be in agreement then, though arguably the current
>> >> "system" locations for Nyquist plugins on Linux are suboptimal because
>> >> they don't preserve the plugins through updates of Audacity.
>> >
>> >
>> > I don't see that here.
>> >
>> > We do (correctly) overwrite shipped plug-ins, which is normal for Linux
>> > and
>> > necessary to allow shipped plug-ins to be updated to the latest version,
>> > but
>> > user installed plug-ins survive both the uninstalling and reinstalling
>> > of
>> > Audacity from the command line.
>> >
>> > I've not tested what happens when uninstalling / reinstalling via a
>> > distribution's package manager, but I'd have thought that was a matter
>> > for
>> > the distro maintainer.
>>
>> What happens with a distro package is the primary concern of most
>> users and so the primary concern of the documentation.
>>
>>
>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>
>> says that "Updating the repository package of Audacity may remove
>> plug-ins that are not part of the package."  I don't think it was I who
>> added that text in the first place, but I expect that the caution is
>> warranted.
>
>
> I've just tested as follows:
>
> 1) Install Audacity from the Ubuntu repository with Synaptic (from end for
> 'apt')
> 2) Add a plug-in to /usr/share/audacity/plug-ins/
> 3) Reinstall Audacity from the Ubuntu repository.
> The plug-in added in step 2 still exists.
>
> 4) "Complete removal" of Audacity via Synaptic
> The plug-in added in step 2 still exists.
>
> So it seems that the warning in the manual is incorrect, at least on Ubuntu
> (and if I recall correctly, it's the same on Debian).
>
> Steve

Is that justification to completely remove the warning that custom plugins
"could" be lost if system-installed? I would guess not, given someone on
Linux must have added the warning in the first place.  By all means we
can say that custom plugins are not lost on modern Ubuntu/Debian.

Two other questions about:
http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

We mention .NY plugins there but most plugins except David Sky's oldest
ones have lower case extension. Given Linux is case sensitive, should we
say ".ny or .NY" instead?

I don't think it helpful to excise mention of ~/.audacity-data/Plug-Ins as
"not recommended". It is clearly less work to use that folder than have
to create two folders yourself, as the person writing to feedback@ said.
Perhaps ~/.audacity-data/Plug-Ins is not recommended for VST and
LADSPA plugins - if you are lucky enough to have a pre-built package
available.

When we do rationalise this, I would hope we get rid of the non-standard
~/.audacity-files which supports Nyquist plugins only but has nothing in its
name to suggest it has anything to do with plugins. I do agree we could
find a more nix-like location for ~/.audacity-data/Plug-Ins.


Gale

>> >> >> ~/.audacity-data/plug-ins
>> >> >> and your plugins will still be seen.


>> >> I think we
>> >> could do with a system location for Nyquist plugins that doesn't have
>> >> that problem.
>> >
>> >
>> > Speaking specifically about Linux:
>> >
>> > 1) Users should not overwrite system files unless they know what they
>> > are
>> > doing.
>> > 2) A system administrator should be able to install additional plug-ins
>> > system wide (for all users) by putting them into a system folder.
>>
>> I assume a sysadmin on Linux would be installing a repository package
>> of Audacity, so if the above caution is correct and the sysadmin wants
>> users to have e.g. the ACX-Check plugin, should the sysadmin have to
>> keep reinstalling ACX-Check with each Audacity update?
>>
>>
>> > 3) A regular user should only be able to install plug-ins within their
>> > user
>> > space.
>> >
>> > Looking at this more deeply, it's more complex than first appears.
>> >
>> > My documentation is wrong. The Nyquist plug-in path (get
>> > '*system-directory*
>> > 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of
>> > "audacityPathList":
>> >
>> > From the code:
>> >
>> > /** \brief A list of directories that should be searched for Audacity
>> > files
>> > * (plug-ins, help files, etc.).
>> > *
>> > * On Unix this will include the directory Audacity was installed into,
>> > * plus the current user's .audacity-data/Plug-Ins directory.  Additional
>> > * directories can be specified using the AUDACITY_PATH environment
>> > * variable.  On Windows or Mac OS, this will include the directory
>> > * which contains the Audacity program. */
>> > wxArrayString audacityPathList;
>> >
>> > The subset comes form: GetNyquistSearchPath
>> > which is not documented.
>> >
>> > The first use of GetNyquistSearchPath was in
>> > NyquistEffectsModule::FindPlugins, so I believe the intention was to be
>> > a
>> > list of where plug-ins may be located, but it also includes additional
>> > locations where other Nyquist related files are located.
>> >
>> > (I'm not sure why some of these directories are not working for you
>> > Gale,
>> > but the code says they 'should' work, so I'll assume 'user error' for
>> > the
>> > sake of this discussion.)
>>
>> I have not retested yet, but I suspect a need to start with a fresh
>> pluginregistry.cfg is just as likely a cause.
>>
>>
>>
>> Gale
>>
>>
>> > Audacity can find Nyquist plug-ins in any of the directories, but that
>> > is
>> > NOT to say that all of these directories are the 'correct' locations for
>> > Nyquist plug-ins.
>> >
>> > Example, the "Nyquist search path" (from GetNyquistSearchPath) includes
>> > the
>> > Nyquist .LSP files. This is reasonable because Nyquist needs to be able
>> > to
>> > find its LISP functions, but .NY plug-ins should not be mixed in with
>> > the
>> > .LSP files.
>> >
>> > I need to analyze where Audacity is looking and why....
>> >
>> > Steve
>> >
>> >>
>> >>
>> >>
>> >> Gale
>> >>
>> >>
>> >>
>> >> > The full list of locations on my machine where Audacity apparently
>> >> > looks
>> >> > for
>> >> > Nyquist plug-ins:
>> >> >
>> >> > "~/nyquist"
>> >> > "~/plugins"
>> >> > "~/plug-ins"
>> >> > "~/.audacity-files/nyquist"
>> >> > "~/.audacity-files/plugins"
>> >> > "~/.audacity-files/plug-ins"
>> >> > "/usr/local/share/audacity/nyquist"
>> >> > "/usr/local/share/audacity/plugins"
>> >> > "/usr/local/share/audacity/plug-ins"
>> >> > "/usr/local/share/doc/audacity/nyquist"
>> >> > "/usr/local/share/doc/audacity/plugins"
>> >> > "/usr/local/share/doc/audacity/plug-ins"
>> >> > "/usr/local/share/locale/nyquist"
>> >> > "/usr/local/share/locale/plugins"
>> >> > "/usr/local/share/locale/plug-ins"
>> >> > "~/locale/nyquist"
>> >> > "~/locale/plugins"
>> >> > "~/locale/plug-ins"
>> >> >
>> >> > and
>> >> >
>> >> > "~/.audacity-data/Plug-Ins"
>> >> >
>> >> > Steve
>> >> >
>> >> >
>> >> >>
>> >> >>
>> >> >> .
>> >> >>
>> >> >>
>> >> >> Gale
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >> ------------------------------------------------------------------------------
>> >>
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > audacity-devel mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

Re: Plug-in path on Linux

Stevethefiddle
On 28 May 2017 at 16:50, Gale Andrews <[hidden email]> wrote:

> On 18 May 2017 at 00:18, Steve the Fiddle <[hidden email]> wrote:
>>
>>
>> On 17 May 2017 at 20:03, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 17 May 2017 at 14:27, Steve the Fiddle <[hidden email]>
>>> wrote:
>>> >
>>> >
>>> > On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
>>> >>
>>> >> On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]>
>>> >> wrote:
>>> >> >
>>> >> >
>>> >> > On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>>> >> >>
>>> >> >> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>>> >> >> wrote:
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>>> >> >> > It says, or at least implies that ~/.audacity-files/plug-ins is
>>> >> >> > read
>>> >> >> > only.
>>> >> >> > It has incorrect capitalization for file names (very important on
>>> >> >> > a
>>> >> >> > case
>>> >> >> > sensitive file system)
>>> >> >> > It then contradicts itself and says that ~/.../Plug-Ins is
>>> >> >> > read/write
>>> >> >>
>>> >> >> The read-only implication was just a stray bullet point that got
>>> >> >> left
>>> >> >> in.
>>> >> >>
>>> >> >> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins
>>> >> >> so
>>> >> >> I changed the subfolder name to lower case.
>>> >> >>
>>> >> >> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>>> >> >> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does
>>> >> >> so.
>>> >> >> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>>> >> >> plugins.
>>> >> >>
>>> >> >> You can change ~/.audacity-data/Plug-Ins to
>>> >> >> ~/.audacity-data/plug-ins
>>> >> >> and your plugins will still be seen.
>>> >> >>
>>> >> >> See if this is better:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>> >> >
>>> >> >
>>> >> > That looks correct now, but the number of options (including the
>>> >> > undocumented options) is far more complicated than it needs to be
>>> >> > imo. I
>>> >> > don't see why users need more than one location in their home
>>> >> > directory
>>> >> > for
>>> >> > Nyquist plug-ins (in addition to the 'system' location).
>>> >>
>>> >> Looks like we may be in agreement then, though arguably the current
>>> >> "system" locations for Nyquist plugins on Linux are suboptimal because
>>> >> they don't preserve the plugins through updates of Audacity.
>>> >
>>> >
>>> > I don't see that here.
>>> >
>>> > We do (correctly) overwrite shipped plug-ins, which is normal for Linux
>>> > and
>>> > necessary to allow shipped plug-ins to be updated to the latest version,
>>> > but
>>> > user installed plug-ins survive both the uninstalling and reinstalling
>>> > of
>>> > Audacity from the command line.
>>> >
>>> > I've not tested what happens when uninstalling / reinstalling via a
>>> > distribution's package manager, but I'd have thought that was a matter
>>> > for
>>> > the distro maintainer.
>>>
>>> What happens with a distro package is the primary concern of most
>>> users and so the primary concern of the documentation.
>>>
>>>
>>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>>
>>> says that "Updating the repository package of Audacity may remove
>>> plug-ins that are not part of the package."  I don't think it was I who
>>> added that text in the first place, but I expect that the caution is
>>> warranted.
>>
>>
>> I've just tested as follows:
>>
>> 1) Install Audacity from the Ubuntu repository with Synaptic (from end for
>> 'apt')
>> 2) Add a plug-in to /usr/share/audacity/plug-ins/
>> 3) Reinstall Audacity from the Ubuntu repository.
>> The plug-in added in step 2 still exists.
>>
>> 4) "Complete removal" of Audacity via Synaptic
>> The plug-in added in step 2 still exists.
>>
>> So it seems that the warning in the manual is incorrect, at least on Ubuntu
>> (and if I recall correctly, it's the same on Debian).
>>
>> Steve
>
> Is that justification to completely remove the warning that custom plugins
> "could" be lost if system-installed? I would guess not, given someone on
> Linux must have added the warning in the first place.

As I think you said previously, it was probably me that added that
warning. Perhaps it was true at the time, or perhaps there was a flaw
in my testing procedure that lead to an incorrect conclusion that
custom plug-ins 'could' be lost, but either way, it does not appear to
be the case now.

If there is evidence that it is the case now, then it needs to be
logged on bugzilla, and I would agree that the warning should be
reinstated in the manual.

> By all means we
> can say that custom plugins are not lost on modern Ubuntu/Debian.
>
> Two other questions about:
> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>
> We mention .NY plugins there but most plugins except David Sky's oldest
> ones have lower case extension. Given Linux is case sensitive, should we
> say ".ny or .NY" instead?

Connie says:
"File formats with any implication of extension or the final file
should be fully capitalized without preceding period (full stop)"

So according to that it should be "NY" rather than ".ny" or ".NY".
However, on Linux it is usual for file extensions to be lower case.

>
> I don't think it helpful to excise mention of ~/.audacity-data/Plug-Ins as
> "not recommended". It is clearly less work to use that folder than have
> to create two folders yourself, as the person writing to feedback@ said.
> Perhaps ~/.audacity-data/Plug-Ins is not recommended for VST and
> LADSPA plugins - if you are lucky enough to have a pre-built package
> available.

A new installation of Audacity 2.2.0 on Linux does not create a
"~/.audacity-data/Plug-Ins" folder (which imo is correct), though if
plug-ins are installed in that location, Audacity 2.2.0 will still be
able to see them, so no nasty surprises for existing users.

The person writing to feedback@ wanted clarification regarding the
"~/.audacity-data/Plug-Ins" folder. My current view is that Audacity
will see some types of plug-ins in this folder, but that it is not the
'correct' location for any types of plug-in on Linux and is therefore
not recommended.


>
> When we do rationalise this, I would hope we get rid of the non-standard
> ~/.audacity-files which supports Nyquist plugins only but has nothing in its
> name to suggest it has anything to do with plugins. I do agree we could
> find a more nix-like location for ~/.audacity-data/Plug-Ins.


The most nix-like solution would be to have a folder called
"~/.audacity" containing the Audacity configuration files, and
additional sub-directories for additional components such as plug-ins,
chains, auto-save, and whatever else we may have in the future.

I'm not proposing to change that now as I've not reviewed how much
work would be involved in doing so. I think if we do make this change
at some time, we should help users that are upgrading by importing
their previous settings into the new configuration folder.

I don't see changing to "~/.audacity/" as high priority as the dual
"~/.audacity-data/" and "~/.audacity-files/" continues to work well
enough, but we do need to document it clearly and avoid making it
worse (more complicated or confusing). If you think that it deserves
higher priority, then it could be logged as an enhancement on bugzilla
with an appropriate P rating.

Steve

>
>
> Gale
>
>>> >> >> ~/.audacity-data/plug-ins
>>> >> >> and your plugins will still be seen.
>
>
>>> >> I think we
>>> >> could do with a system location for Nyquist plugins that doesn't have
>>> >> that problem.
>>> >
>>> >
>>> > Speaking specifically about Linux:
>>> >
>>> > 1) Users should not overwrite system files unless they know what they
>>> > are
>>> > doing.
>>> > 2) A system administrator should be able to install additional plug-ins
>>> > system wide (for all users) by putting them into a system folder.
>>>
>>> I assume a sysadmin on Linux would be installing a repository package
>>> of Audacity, so if the above caution is correct and the sysadmin wants
>>> users to have e.g. the ACX-Check plugin, should the sysadmin have to
>>> keep reinstalling ACX-Check with each Audacity update?
>>>
>>>
>>> > 3) A regular user should only be able to install plug-ins within their
>>> > user
>>> > space.
>>> >
>>> > Looking at this more deeply, it's more complex than first appears.
>>> >
>>> > My documentation is wrong. The Nyquist plug-in path (get
>>> > '*system-directory*
>>> > 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of
>>> > "audacityPathList":
>>> >
>>> > From the code:
>>> >
>>> > /** \brief A list of directories that should be searched for Audacity
>>> > files
>>> > * (plug-ins, help files, etc.).
>>> > *
>>> > * On Unix this will include the directory Audacity was installed into,
>>> > * plus the current user's .audacity-data/Plug-Ins directory.  Additional
>>> > * directories can be specified using the AUDACITY_PATH environment
>>> > * variable.  On Windows or Mac OS, this will include the directory
>>> > * which contains the Audacity program. */
>>> > wxArrayString audacityPathList;
>>> >
>>> > The subset comes form: GetNyquistSearchPath
>>> > which is not documented.
>>> >
>>> > The first use of GetNyquistSearchPath was in
>>> > NyquistEffectsModule::FindPlugins, so I believe the intention was to be
>>> > a
>>> > list of where plug-ins may be located, but it also includes additional
>>> > locations where other Nyquist related files are located.
>>> >
>>> > (I'm not sure why some of these directories are not working for you
>>> > Gale,
>>> > but the code says they 'should' work, so I'll assume 'user error' for
>>> > the
>>> > sake of this discussion.)
>>>
>>> I have not retested yet, but I suspect a need to start with a fresh
>>> pluginregistry.cfg is just as likely a cause.
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>> > Audacity can find Nyquist plug-ins in any of the directories, but that
>>> > is
>>> > NOT to say that all of these directories are the 'correct' locations for
>>> > Nyquist plug-ins.
>>> >
>>> > Example, the "Nyquist search path" (from GetNyquistSearchPath) includes
>>> > the
>>> > Nyquist .LSP files. This is reasonable because Nyquist needs to be able
>>> > to
>>> > find its LISP functions, but .NY plug-ins should not be mixed in with
>>> > the
>>> > .LSP files.
>>> >
>>> > I need to analyze where Audacity is looking and why....
>>> >
>>> > Steve
>>> >
>>> >>
>>> >>
>>> >>
>>> >> Gale
>>> >>
>>> >>
>>> >>
>>> >> > The full list of locations on my machine where Audacity apparently
>>> >> > looks
>>> >> > for
>>> >> > Nyquist plug-ins:
>>> >> >
>>> >> > "~/nyquist"
>>> >> > "~/plugins"
>>> >> > "~/plug-ins"
>>> >> > "~/.audacity-files/nyquist"
>>> >> > "~/.audacity-files/plugins"
>>> >> > "~/.audacity-files/plug-ins"
>>> >> > "/usr/local/share/audacity/nyquist"
>>> >> > "/usr/local/share/audacity/plugins"
>>> >> > "/usr/local/share/audacity/plug-ins"
>>> >> > "/usr/local/share/doc/audacity/nyquist"
>>> >> > "/usr/local/share/doc/audacity/plugins"
>>> >> > "/usr/local/share/doc/audacity/plug-ins"
>>> >> > "/usr/local/share/locale/nyquist"
>>> >> > "/usr/local/share/locale/plugins"
>>> >> > "/usr/local/share/locale/plug-ins"
>>> >> > "~/locale/nyquist"
>>> >> > "~/locale/plugins"
>>> >> > "~/locale/plug-ins"
>>> >> >
>>> >> > and
>>> >> >
>>> >> > "~/.audacity-data/Plug-Ins"
>>> >> >
>>> >> > Steve
>>> >> >
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >> .
>>> >> >>
>>> >> >>
>>> >> >> Gale
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> ------------------------------------------------------------------------------
>>> >>
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Check out the vibrant tech community on one of the world's most
>>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> > _______________________________________________
>>> > audacity-devel mailing list
>>> > [hidden email]
>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Plug-in path on Linux

Gale
Administrator
On 29 May 2017 at 20:06, Steve the Fiddle <[hidden email]> wrote:

> On 28 May 2017 at 16:50, Gale Andrews <[hidden email]> wrote:
>> On 18 May 2017 at 00:18, Steve the Fiddle <[hidden email]> wrote:
>>>
>>>
>>> On 17 May 2017 at 20:03, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 17 May 2017 at 14:27, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>> >
>>>> >
>>>> > On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
>>>> >>
>>>> >> On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]>
>>>> >> wrote:
>>>> >> >
>>>> >> >
>>>> >> > On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>>>> >> >>
>>>> >> >> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>>>> >> >> wrote:
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>>>> >> >> > It says, or at least implies that ~/.audacity-files/plug-ins is
>>>> >> >> > read
>>>> >> >> > only.
>>>> >> >> > It has incorrect capitalization for file names (very important on
>>>> >> >> > a
>>>> >> >> > case
>>>> >> >> > sensitive file system)
>>>> >> >> > It then contradicts itself and says that ~/.../Plug-Ins is
>>>> >> >> > read/write
>>>> >> >>
>>>> >> >> The read-only implication was just a stray bullet point that got
>>>> >> >> left
>>>> >> >> in.
>>>> >> >>
>>>> >> >> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins
>>>> >> >> so
>>>> >> >> I changed the subfolder name to lower case.
>>>> >> >>
>>>> >> >> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>>>> >> >> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does
>>>> >> >> so.
>>>> >> >> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>>>> >> >> plugins.
>>>> >> >>
>>>> >> >> You can change ~/.audacity-data/Plug-Ins to
>>>> >> >> ~/.audacity-data/plug-ins
>>>> >> >> and your plugins will still be seen.
>>>> >> >>
>>>> >> >> See if this is better:
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>>> >> >
>>>> >> >
>>>> >> > That looks correct now, but the number of options (including the
>>>> >> > undocumented options) is far more complicated than it needs to be
>>>> >> > imo. I
>>>> >> > don't see why users need more than one location in their home
>>>> >> > directory
>>>> >> > for
>>>> >> > Nyquist plug-ins (in addition to the 'system' location).
>>>> >>
>>>> >> Looks like we may be in agreement then, though arguably the current
>>>> >> "system" locations for Nyquist plugins on Linux are suboptimal because
>>>> >> they don't preserve the plugins through updates of Audacity.
>>>> >
>>>> >
>>>> > I don't see that here.
>>>> >
>>>> > We do (correctly) overwrite shipped plug-ins, which is normal for Linux
>>>> > and
>>>> > necessary to allow shipped plug-ins to be updated to the latest version,
>>>> > but
>>>> > user installed plug-ins survive both the uninstalling and reinstalling
>>>> > of
>>>> > Audacity from the command line.
>>>> >
>>>> > I've not tested what happens when uninstalling / reinstalling via a
>>>> > distribution's package manager, but I'd have thought that was a matter
>>>> > for
>>>> > the distro maintainer.
>>>>
>>>> What happens with a distro package is the primary concern of most
>>>> users and so the primary concern of the documentation.
>>>>
>>>>
>>>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>>>
>>>> says that "Updating the repository package of Audacity may remove
>>>> plug-ins that are not part of the package."  I don't think it was I who
>>>> added that text in the first place, but I expect that the caution is
>>>> warranted.
>>>
>>>
>>> I've just tested as follows:
>>>
>>> 1) Install Audacity from the Ubuntu repository with Synaptic (from end for
>>> 'apt')
>>> 2) Add a plug-in to /usr/share/audacity/plug-ins/
>>> 3) Reinstall Audacity from the Ubuntu repository.
>>> The plug-in added in step 2 still exists.
>>>
>>> 4) "Complete removal" of Audacity via Synaptic
>>> The plug-in added in step 2 still exists.
>>>
>>> So it seems that the warning in the manual is incorrect, at least on Ubuntu
>>> (and if I recall correctly, it's the same on Debian).
>>>
>>> Steve
>>
>> Is that justification to completely remove the warning that custom plugins
>> "could" be lost if system-installed? I would guess not, given someone on
>> Linux must have added the warning in the first place.
>
> As I think you said previously, it was probably me that added that
> warning. Perhaps it was true at the time, or perhaps there was a flaw
> in my testing procedure that lead to an incorrect conclusion that
> custom plug-ins 'could' be lost, but either way, it does not appear to
> be the case now.
>
> If there is evidence that it is the case now, then it needs to be
> logged on bugzilla, and I would agree that the warning should be
> reinstated in the manual.

The ɡrey area in my mind is the distro install of Audacity to
/usr/share/audacity/plug-ins. Is such an install under our control,
regardless of distro, as to whether plugins that are not set to be
installed by makefile.am are removed?


>> By all means we
>> can say that custom plugins are not lost on modern Ubuntu/Debian.
>>
>> Two other questions about:
>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>
>> We mention .NY plugins there but most plugins except David Sky's oldest
>> ones have lower case extension. Given Linux is case sensitive, should we
>> say ".ny or .NY" instead?
>
> Connie says:
> "File formats with any implication of extension or the final file
> should be fully capitalized without preceding period (full stop)"
>
> So according to that it should be "NY" rather than ".ny" or ".NY".

Thanks. That's correct as was intended at the time, largely because
adding the dot seems to confuse some Windows users. Case
sensitive systems were not considered.

The capitalisation was for standout rather than do so by bolding,
which could make the page look like a checkerboard if it referred
to many extensions. A little confusingly, the bolding shown in
Consistency does not mean that the extension should be bold -
the bold is to distinguish the "correct" representation from "incorrect".

So at the moment the installation page isn't following Connie anyway
as the extension on the page includes the dot. And some Nyquist
plugins may be in the wild with .NY extension. So I would guess the
least egregious way to bend Connie's current rules would be to say
"the Nyquist file with ny or NY extension", unbolded.


> However, on Linux it is usual for file extensions to be lower case.
>
>>
>> I don't think it helpful to excise mention of ~/.audacity-data/Plug-Ins as
>> "not recommended". It is clearly less work to use that folder than have
>> to create two folders yourself, as the person writing to feedback@ said.
>> Perhaps ~/.audacity-data/Plug-Ins is not recommended for VST and
>> LADSPA plugins - if you are lucky enough to have a pre-built package
>> available.
>
> A new installation of Audacity 2.2.0 on Linux does not create a
> "~/.audacity-data/Plug-Ins" folder (which imo is correct), though if
> plug-ins are installed in that location, Audacity 2.2.0 will still be
> able to see them, so no nasty surprises for existing users.

So this is another inconsistency. On Windows and Mac, the Plug-Ins
folder is always created when Audacity creates its folder for
application data. That doesn't happen for me on Ubuntu 14.04 but the
Fedora 25 user who wrote to feedback@ claimed the repository build
of Audacity already had "~/.audacity-data/Plug-Ins".


> The person writing to feedback@ wanted clarification regarding the
> "~/.audacity-data/Plug-Ins" folder. My current view is that Audacity
> will see some types of plug-ins in this folder but that it is not the
> 'correct' location for any types of plug-in on Linux and is therefore
> not recommended.

Fedora seem persuaded?  But given Audacity built by us does not
appear to create this Plug-Ins folder on Linux, which I thought it
did, I'd agree we "could" ignore this folder. One problem with doing
that is it's inconsistent with mentioning ~/.audacity-data/Plug-Ins for
LADSPA and VST on
http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
 .

If we remove ~/.audacity-data/Plug-Ins as a named path for LADSPA
and VST, then the list we give for those plugins is incomplete.

On the whole I'd recommend you mention that ~/.audacity-data/Plug-Ins
may already exist after installing some repository versions of Audacity
(assuming that is true) or if it does not exist may be created and used
for Nyquist plugins. It's fine by me to discredit other locations for
Nyquist plugins.


>> When we do rationalise this, I would hope we get rid of the non-standard
>> ~/.audacity-files which supports Nyquist plugins only but has nothing in its
>> name to suggest it has anything to do with plugins. I do agree we could
>> find a more nix-like location for ~/.audacity-data/Plug-Ins.
>
>
> The most nix-like solution would be to have a folder called
> "~/.audacity" containing the Audacity configuration files, and
> additional sub-directories for additional components such as plug-ins,
> chains, auto-save, and whatever else we may have in the future.
>
> I'm not proposing to change that now as I've not reviewed how much
> work would be involved in doing so. I think if we do make this change
> at some time, we should help users that are upgrading by importing
> their previous settings into the new configuration folder.
>
> I don't see changing to "~/.audacity/" as high priority as the dual
> "~/.audacity-data/" and "~/.audacity-files/" continues to work well
> enough, but we do need to document it clearly and avoid making it
> worse (more complicated or confusing). If you think that it deserves
> higher priority, then it could be logged as an enhancement on bugzilla
> with an appropriate P rating.

I can't see changing to "~/.audacity/" as high priority either, in practical
terms. But until we change I do think the Manual should recognise that
~/.audacity-data/Plug-Ins, if it exists for any reason, works for Nyquist
plugins. Otherwise users who already followed past versions of the
Manual and have Nyquist plugins in that folder could be misled into
thinking that is no longer supported.



Gale


> Steve
>
>>
>>
>> Gale
>>
>>>> >> >> ~/.audacity-data/plug-ins
>>>> >> >> and your plugins will still be seen.
>>
>>
>>>> >> I think we
>>>> >> could do with a system location for Nyquist plugins that doesn't have
>>>> >> that problem.
>>>> >
>>>> >
>>>> > Speaking specifically about Linux:
>>>> >
>>>> > 1) Users should not overwrite system files unless they know what they
>>>> > are
>>>> > doing.
>>>> > 2) A system administrator should be able to install additional plug-ins
>>>> > system wide (for all users) by putting them into a system folder.
>>>>
>>>> I assume a sysadmin on Linux would be installing a repository package
>>>> of Audacity, so if the above caution is correct and the sysadmin wants
>>>> users to have e.g. the ACX-Check plugin, should the sysadmin have to
>>>> keep reinstalling ACX-Check with each Audacity update?
>>>>
>>>>
>>>> > 3) A regular user should only be able to install plug-ins within their
>>>> > user
>>>> > space.
>>>> >
>>>> > Looking at this more deeply, it's more complex than first appears.
>>>> >
>>>> > My documentation is wrong. The Nyquist plug-in path (get
>>>> > '*system-directory*
>>>> > 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of
>>>> > "audacityPathList":
>>>> >
>>>> > From the code:
>>>> >
>>>> > /** \brief A list of directories that should be searched for Audacity
>>>> > files
>>>> > * (plug-ins, help files, etc.).
>>>> > *
>>>> > * On Unix this will include the directory Audacity was installed into,
>>>> > * plus the current user's .audacity-data/Plug-Ins directory.  Additional
>>>> > * directories can be specified using the AUDACITY_PATH environment
>>>> > * variable.  On Windows or Mac OS, this will include the directory
>>>> > * which contains the Audacity program. */
>>>> > wxArrayString audacityPathList;
>>>> >
>>>> > The subset comes form: GetNyquistSearchPath
>>>> > which is not documented.
>>>> >
>>>> > The first use of GetNyquistSearchPath was in
>>>> > NyquistEffectsModule::FindPlugins, so I believe the intention was to be
>>>> > a
>>>> > list of where plug-ins may be located, but it also includes additional
>>>> > locations where other Nyquist related files are located.
>>>> >
>>>> > (I'm not sure why some of these directories are not working for you
>>>> > Gale,
>>>> > but the code says they 'should' work, so I'll assume 'user error' for
>>>> > the
>>>> > sake of this discussion.)
>>>>
>>>> I have not retested yet, but I suspect a need to start with a fresh
>>>> pluginregistry.cfg is just as likely a cause.
>>>>
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> > Audacity can find Nyquist plug-ins in any of the directories, but that
>>>> > is
>>>> > NOT to say that all of these directories are the 'correct' locations for
>>>> > Nyquist plug-ins.
>>>> >
>>>> > Example, the "Nyquist search path" (from GetNyquistSearchPath) includes
>>>> > the
>>>> > Nyquist .LSP files. This is reasonable because Nyquist needs to be able
>>>> > to
>>>> > find its LISP functions, but .NY plug-ins should not be mixed in with
>>>> > the
>>>> > .LSP files.
>>>> >
>>>> > I need to analyze where Audacity is looking and why....
>>>> >
>>>> > Steve
>>>> >
>>>> >>
>>>> >>
>>>> >>
>>>> >> Gale
>>>> >>
>>>> >>
>>>> >>
>>>> >> > The full list of locations on my machine where Audacity apparently
>>>> >> > looks
>>>> >> > for
>>>> >> > Nyquist plug-ins:
>>>> >> >
>>>> >> > "~/nyquist"
>>>> >> > "~/plugins"
>>>> >> > "~/plug-ins"
>>>> >> > "~/.audacity-files/nyquist"
>>>> >> > "~/.audacity-files/plugins"
>>>> >> > "~/.audacity-files/plug-ins"
>>>> >> > "/usr/local/share/audacity/nyquist"
>>>> >> > "/usr/local/share/audacity/plugins"
>>>> >> > "/usr/local/share/audacity/plug-ins"
>>>> >> > "/usr/local/share/doc/audacity/nyquist"
>>>> >> > "/usr/local/share/doc/audacity/plugins"
>>>> >> > "/usr/local/share/doc/audacity/plug-ins"
>>>> >> > "/usr/local/share/locale/nyquist"
>>>> >> > "/usr/local/share/locale/plugins"
>>>> >> > "/usr/local/share/locale/plug-ins"
>>>> >> > "~/locale/nyquist"
>>>> >> > "~/locale/plugins"
>>>> >> > "~/locale/plug-ins"
>>>> >> >
>>>> >> > and
>>>> >> >
>>>> >> > "~/.audacity-data/Plug-Ins"
>>>> >> >
>>>> >> > Steve
>>>> >> >
>>>> >> >
>>>> >> >>
>>>> >> >>
>>>> >> >> .
>>>> >> >>
>>>> >> >>
>>>> >> >> Gale
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> ------------------------------------------------------------------------------
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > ------------------------------------------------------------------------------
>>>> > Check out the vibrant tech community on one of the world's most
>>>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> > _______________________________________________
>>>> > audacity-devel mailing list
>>>> > [hidden email]
>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>> >
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Re: Plug-in path on Linux

Stevethefiddle
On 29 May 2017 at 22:22, Gale Andrews <[hidden email]> wrote:

> On 29 May 2017 at 20:06, Steve the Fiddle <[hidden email]> wrote:
>> On 28 May 2017 at 16:50, Gale Andrews <[hidden email]> wrote:
>>> On 18 May 2017 at 00:18, Steve the Fiddle <[hidden email]> wrote:
>>>>
>>>>
>>>> On 17 May 2017 at 20:03, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 17 May 2017 at 14:27, Steve the Fiddle <[hidden email]>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> > On 17 May 2017 at 01:05, Gale Andrews <[hidden email]> wrote:
>>>>> >>
>>>>> >> On 16 May 2017 at 20:59, Steve the Fiddle <[hidden email]>
>>>>> >> wrote:
>>>>> >> >
>>>>> >> >
>>>>> >> > On 16 May 2017 at 19:32, Gale Andrews <[hidden email]> wrote:
>>>>> >> >>
>>>>> >> >> On 16 May 2017 at 09:17, Steve the Fiddle <[hidden email]>
>>>>> >> >> wrote:
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> >
>>>>> >> >> > http://manual.audacityteam.org/man/installing_effect_generator_and_analyzer_plug_ins_on_linux.html#nyquist_install
>>>>> >> >> > It says, or at least implies that ~/.audacity-files/plug-ins is
>>>>> >> >> > read
>>>>> >> >> > only.
>>>>> >> >> > It has incorrect capitalization for file names (very important on
>>>>> >> >> > a
>>>>> >> >> > case
>>>>> >> >> > sensitive file system)
>>>>> >> >> > It then contradicts itself and says that ~/.../Plug-Ins is
>>>>> >> >> > read/write
>>>>> >> >>
>>>>> >> >> The read-only implication was just a stray bullet point that got
>>>>> >> >> left
>>>>> >> >> in.
>>>>> >> >>
>>>>> >> >> I can confirm plugins cannot be seen in ~/.audacity-files/Plug-Ins
>>>>> >> >> so
>>>>> >> >> I changed the subfolder name to lower case.
>>>>> >> >>
>>>>> >> >> Note that ~/.audacity-files/plug-ins does not see VST or LADSPA
>>>>> >> >> plugins, which is unexpected given ~/.audacity-data/Plug-Ins does
>>>>> >> >> so.
>>>>> >> >> The Manual was saying that ~/.audacity-files/plug-ins saw LADSPA
>>>>> >> >> plugins.
>>>>> >> >>
>>>>> >> >> You can change ~/.audacity-data/Plug-Ins to
>>>>> >> >> ~/.audacity-data/plug-ins
>>>>> >> >> and your plugins will still be seen.
>>>>> >> >>
>>>>> >> >> See if this is better:
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>>>> >> >
>>>>> >> >
>>>>> >> > That looks correct now, but the number of options (including the
>>>>> >> > undocumented options) is far more complicated than it needs to be
>>>>> >> > imo. I
>>>>> >> > don't see why users need more than one location in their home
>>>>> >> > directory
>>>>> >> > for
>>>>> >> > Nyquist plug-ins (in addition to the 'system' location).
>>>>> >>
>>>>> >> Looks like we may be in agreement then, though arguably the current
>>>>> >> "system" locations for Nyquist plugins on Linux are suboptimal because
>>>>> >> they don't preserve the plugins through updates of Audacity.
>>>>> >
>>>>> >
>>>>> > I don't see that here.
>>>>> >
>>>>> > We do (correctly) overwrite shipped plug-ins, which is normal for Linux
>>>>> > and
>>>>> > necessary to allow shipped plug-ins to be updated to the latest version,
>>>>> > but
>>>>> > user installed plug-ins survive both the uninstalling and reinstalling
>>>>> > of
>>>>> > Audacity from the command line.
>>>>> >
>>>>> > I've not tested what happens when uninstalling / reinstalling via a
>>>>> > distribution's package manager, but I'd have thought that was a matter
>>>>> > for
>>>>> > the distro maintainer.
>>>>>
>>>>> What happens with a distro package is the primary concern of most
>>>>> users and so the primary concern of the documentation.
>>>>>
>>>>>
>>>>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>>>>
>>>>> says that "Updating the repository package of Audacity may remove
>>>>> plug-ins that are not part of the package."  I don't think it was I who
>>>>> added that text in the first place, but I expect that the caution is
>>>>> warranted.
>>>>
>>>>
>>>> I've just tested as follows:
>>>>
>>>> 1) Install Audacity from the Ubuntu repository with Synaptic (from end for
>>>> 'apt')
>>>> 2) Add a plug-in to /usr/share/audacity/plug-ins/
>>>> 3) Reinstall Audacity from the Ubuntu repository.
>>>> The plug-in added in step 2 still exists.
>>>>
>>>> 4) "Complete removal" of Audacity via Synaptic
>>>> The plug-in added in step 2 still exists.
>>>>
>>>> So it seems that the warning in the manual is incorrect, at least on Ubuntu
>>>> (and if I recall correctly, it's the same on Debian).
>>>>
>>>> Steve
>>>
>>> Is that justification to completely remove the warning that custom plugins
>>> "could" be lost if system-installed? I would guess not, given someone on
>>> Linux must have added the warning in the first place.
>>
>> As I think you said previously, it was probably me that added that
>> warning. Perhaps it was true at the time, or perhaps there was a flaw
>> in my testing procedure that lead to an incorrect conclusion that
>> custom plug-ins 'could' be lost, but either way, it does not appear to
>> be the case now.
>>
>> If there is evidence that it is the case now, then it needs to be
>> logged on bugzilla, and I would agree that the warning should be
>> reinstated in the manual.
>
> The ɡrey area in my mind is the distro install of Audacity to
> /usr/share/audacity/plug-ins. Is such an install under our control,
> regardless of distro, as to whether plugins that are not set to be
> installed by makefile.am are removed?

My understanding is that has more to do with the package manager than
the distro.
When updating or uninstalling, the package manager should only remove
those components that are part of the package that is being updated /
uninstalled. It should not remove dependencies, user configuration
files, or anything else (because it cannot know that they are not used
elsewhere).

Perhaps the confusion arose because if a plug-in that is shipped with
Audacity is overwritten with a custom version, then that custom
version will be overwritten or removed on updating / uninstalling.
That behaviour is "correct", and is no different to users modifying
any file that is part of the installed package.

>
>
>>> By all means we
>>> can say that custom plugins are not lost on modern Ubuntu/Debian.
>>>
>>> Two other questions about:
>>> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux
>>>
>>> We mention .NY plugins there but most plugins except David Sky's oldest
>>> ones have lower case extension. Given Linux is case sensitive, should we
>>> say ".ny or .NY" instead?
>>
>> Connie says:
>> "File formats with any implication of extension or the final file
>> should be fully capitalized without preceding period (full stop)"
>>
>> So according to that it should be "NY" rather than ".ny" or ".NY".
>
> Thanks. That's correct as was intended at the time, largely because
> adding the dot seems to confuse some Windows users. Case
> sensitive systems were not considered.
>
> The capitalisation was for standout rather than do so by bolding,
> which could make the page look like a checkerboard if it referred
> to many extensions. A little confusingly, the bolding shown in
> Consistency does not mean that the extension should be bold -
> the bold is to distinguish the "correct" representation from "incorrect".
>
> So at the moment the installation page isn't following Connie anyway
> as the extension on the page includes the dot. And some Nyquist
> plugins may be in the wild with .NY extension. So I would guess the
> least egregious way to bend Connie's current rules would be to say
> "the Nyquist file with ny or NY extension", unbolded.

Done.

>
>
>> However, on Linux it is usual for file extensions to be lower case.
>>
>>>
>>> I don't think it helpful to excise mention of ~/.audacity-data/Plug-Ins as
>>> "not recommended". It is clearly less work to use that folder than have
>>> to create two folders yourself, as the person writing to feedback@ said.
>>> Perhaps ~/.audacity-data/Plug-Ins is not recommended for VST and
>>> LADSPA plugins - if you are lucky enough to have a pre-built package
>>> available.
>>
>> A new installation of Audacity 2.2.0 on Linux does not create a
>> "~/.audacity-data/Plug-Ins" folder (which imo is correct), though if
>> plug-ins are installed in that location, Audacity 2.2.0 will still be
>> able to see them, so no nasty surprises for existing users.
>
> So this is another inconsistency. On Windows and Mac, the Plug-Ins
> folder is always created when Audacity creates its folder for
> application data.

Yes, we agreed that "Plug-Ins" folder should exist on those platforms,
especially on Mac.

> That doesn't happen for me on Ubuntu 14.04 but the
> Fedora 25 user who wrote to feedback@ claimed the repository build
> of Audacity already had "~/.audacity-data/Plug-Ins".

Audacity 2.1.4 creates that folder. Audacity 2.2.0 doesn't, but it is
still supported if it exists, so nothing gets broken.

>
>
>> The person writing to feedback@ wanted clarification regarding the
>> "~/.audacity-data/Plug-Ins" folder. My current view is that Audacity
>> will see some types of plug-ins in this folder but that it is not the
>> 'correct' location for any types of plug-in on Linux and is therefore
>> not recommended.
>
> Fedora seem persuaded?  But given Audacity built by us does not
> appear to create this Plug-Ins folder on Linux, which I thought it
> did, I'd agree we "could" ignore this folder. One problem with doing
> that is it's inconsistent with mentioning ~/.audacity-data/Plug-Ins for
> LADSPA and VST on
> http://alphamanual.audacityteam.org/man/Installing_Effect,_Generator_and_Analyzer_plug-ins_on_Linux

On Linux, native VST's are still pretty rare, but as with other
packages, would normally be installed with a package manager. Anyone
building native VST plug-ins from source should know what they are
doing and ensure that the .so file are placed in the VST plug-in path.
Similarly for the more common LADSPA and LV2 plug-ins.

When building from source, installation is often much like it is for
Audacity: configure, make, then sudo make install to copy the binaries
into the correct system locations.

>  .
>
> If we remove ~/.audacity-data/Plug-Ins as a named path for LADSPA
> and VST, then the list we give for those plugins is incomplete.

As above, I don't think "~/audacity-data/Plug-Ins" is the most
appropriate location for LADSPA or VST plug-ins on Linux, and we
should update those sections of the manual.

>
> On the whole I'd recommend you mention that ~/.audacity-data/Plug-Ins
> may already exist after installing some repository versions of Audacity
> (assuming that is true) or if it does not exist may be created and used
> for Nyquist plugins. It's fine by me to discredit other locations for
> Nyquist plugins.
>
>
>>> When we do rationalise this, I would hope we get rid of the non-standard
>>> ~/.audacity-files which supports Nyquist plugins only but has nothing in its
>>> name to suggest it has anything to do with plugins. I do agree we could
>>> find a more nix-like location for ~/.audacity-data/Plug-Ins.
>>
>>
>> The most nix-like solution would be to have a folder called
>> "~/.audacity" containing the Audacity configuration files, and
>> additional sub-directories for additional components such as plug-ins,
>> chains, auto-save, and whatever else we may have in the future.
>>
>> I'm not proposing to change that now as I've not reviewed how much
>> work would be involved in doing so. I think if we do make this change
>> at some time, we should help users that are upgrading by importing
>> their previous settings into the new configuration folder.
>>
>> I don't see changing to "~/.audacity/" as high priority as the dual
>> "~/.audacity-data/" and "~/.audacity-files/" continues to work well
>> enough, but we do need to document it clearly and avoid making it
>> worse (more complicated or confusing). If you think that it deserves
>> higher priority, then it could be logged as an enhancement on bugzilla
>> with an appropriate P rating.
>
> I can't see changing to "~/.audacity/" as high priority either, in practical
> terms. But until we change I do think the Manual should recognise that
> ~/.audacity-data/Plug-Ins, if it exists for any reason, works for Nyquist
> plugins. Otherwise users who already followed past versions of the
> Manual and have Nyquist plugins in that folder could be misled into
> thinking that is no longer supported.

The manual does say that other locations are supported though not
recommended. I think that's the correct advice. We could add more
detail, but with the risk of confusing users more than it helps.

Steve

>
>
>
> Gale
>
>
>> Steve
>>
>>>
>>>
>>> Gale
>>>
>>>>> >> >> ~/.audacity-data/plug-ins
>>>>> >> >> and your plugins will still be seen.
>>>
>>>
>>>>> >> I think we
>>>>> >> could do with a system location for Nyquist plugins that doesn't have
>>>>> >> that problem.
>>>>> >
>>>>> >
>>>>> > Speaking specifically about Linux:
>>>>> >
>>>>> > 1) Users should not overwrite system files unless they know what they
>>>>> > are
>>>>> > doing.
>>>>> > 2) A system administrator should be able to install additional plug-ins
>>>>> > system wide (for all users) by putting them into a system folder.
>>>>>
>>>>> I assume a sysadmin on Linux would be installing a repository package
>>>>> of Audacity, so if the above caution is correct and the sysadmin wants
>>>>> users to have e.g. the ACX-Check plugin, should the sysadmin have to
>>>>> keep reinstalling ACX-Check with each Audacity update?
>>>>>
>>>>>
>>>>> > 3) A regular user should only be able to install plug-ins within their
>>>>> > user
>>>>> > space.
>>>>> >
>>>>> > Looking at this more deeply, it's more complex than first appears.
>>>>> >
>>>>> > My documentation is wrong. The Nyquist plug-in path (get
>>>>> > '*system-directory*
>>>>> > 'plug-in) is not "the path to Nyquist plug-ins", it is a subset of
>>>>> > "audacityPathList":
>>>>> >
>>>>> > From the code:
>>>>> >
>>>>> > /** \brief A list of directories that should be searched for Audacity
>>>>> > files
>>>>> > * (plug-ins, help files, etc.).
>>>>> > *
>>>>> > * On Unix this will include the directory Audacity was installed into,
>>>>> > * plus the current user's .audacity-data/Plug-Ins directory.  Additional
>>>>> > * directories can be specified using the AUDACITY_PATH environment
>>>>> > * variable.  On Windows or Mac OS, this will include the directory
>>>>> > * which contains the Audacity program. */
>>>>> > wxArrayString audacityPathList;
>>>>> >
>>>>> > The subset comes form: GetNyquistSearchPath
>>>>> > which is not documented.
>>>>> >
>>>>> > The first use of GetNyquistSearchPath was in
>>>>> > NyquistEffectsModule::FindPlugins, so I believe the intention was to be
>>>>> > a
>>>>> > list of where plug-ins may be located, but it also includes additional
>>>>> > locations where other Nyquist related files are located.
>>>>> >
>>>>> > (I'm not sure why some of these directories are not working for you
>>>>> > Gale,
>>>>> > but the code says they 'should' work, so I'll assume 'user error' for
>>>>> > the
>>>>> > sake of this discussion.)
>>>>>
>>>>> I have not retested yet, but I suspect a need to start with a fresh
>>>>> pluginregistry.cfg is just as likely a cause.
>>>>>
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> > Audacity can find Nyquist plug-ins in any of the directories, but that
>>>>> > is
>>>>> > NOT to say that all of these directories are the 'correct' locations for
>>>>> > Nyquist plug-ins.
>>>>> >
>>>>> > Example, the "Nyquist search path" (from GetNyquistSearchPath) includes
>>>>> > the
>>>>> > Nyquist .LSP files. This is reasonable because Nyquist needs to be able
>>>>> > to
>>>>> > find its LISP functions, but .NY plug-ins should not be mixed in with
>>>>> > the
>>>>> > .LSP files.
>>>>> >
>>>>> > I need to analyze where Audacity is looking and why....
>>>>> >
>>>>> > Steve
>>>>> >
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Gale
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> > The full list of locations on my machine where Audacity apparently
>>>>> >> > looks
>>>>> >> > for
>>>>> >> > Nyquist plug-ins:
>>>>> >> >
>>>>> >> > "~/nyquist"
>>>>> >> > "~/plugins"
>>>>> >> > "~/plug-ins"
>>>>> >> > "~/.audacity-files/nyquist"
>>>>> >> > "~/.audacity-files/plugins"
>>>>> >> > "~/.audacity-files/plug-ins"
>>>>> >> > "/usr/local/share/audacity/nyquist"
>>>>> >> > "/usr/local/share/audacity/plugins"
>>>>> >> > "/usr/local/share/audacity/plug-ins"
>>>>> >> > "/usr/local/share/doc/audacity/nyquist"
>>>>> >> > "/usr/local/share/doc/audacity/plugins"
>>>>> >> > "/usr/local/share/doc/audacity/plug-ins"
>>>>> >> > "/usr/local/share/locale/nyquist"
>>>>> >> > "/usr/local/share/locale/plugins"
>>>>> >> > "/usr/local/share/locale/plug-ins"
>>>>> >> > "~/locale/nyquist"
>>>>> >> > "~/locale/plugins"
>>>>> >> > "~/locale/plug-ins"
>>>>> >> >
>>>>> >> > and
>>>>> >> >
>>>>> >> > "~/.audacity-data/Plug-Ins"
>>>>> >> >
>>>>> >> > Steve
>>>>> >> >
>>>>> >> >
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> .
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> Gale
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> ------------------------------------------------------------------------------
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > ------------------------------------------------------------------------------
>>>>> > Check out the vibrant tech community on one of the world's most
>>>>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> > _______________________________________________
>>>>> > audacity-devel mailing list
>>>>> > [hidden email]
>>>>> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>> >
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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