Post by Steve the FiddlePost by Gale AndrewsPost by Steve the FiddlePost by Gale AndrewsPost by Steve the FiddlePost by Gale AndrewsPost by Steve the FiddlePost by Gale AndrewsPost by Steve the Fiddlehttp://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.
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.
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?
Post by Steve the FiddlePost by Gale AndrewsBy all means we
can say that custom plugins are not lost on modern Ubuntu/Debian.
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?
"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.
Post by Steve the FiddleHowever, on Linux it is usual for file extensions to be lower case.
Post by Gale AndrewsI 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
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".
Post by Steve the Fiddle"~/.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.
Post by Steve the FiddlePost by Gale AndrewsWhen 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
Post by Steve the FiddleSteve
Post by Gale AndrewsGale
Post by Steve the FiddlePost by Gale AndrewsPost by Steve the FiddlePost by Gale AndrewsPost by Steve the FiddlePost by Gale Andrews~/.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.
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?
Post by Steve the Fiddle3) 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
/** \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
Post by Steve the FiddleAudacity 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
Post by Gale AndrewsGale
Post by Steve the FiddleThe full list of locations on my machine where Audacity apparently looks
for
"~/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
Post by Gale Andrews.
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
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
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
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel