I’ve split this topic as it is probably worth considering the broader question of where Nyquist plug-in data files should be installed.
Below I’ve suggested where I think they would be best on Linux. What about Windows and Mac OS X ?
I’ve been thinking about where the best place would be for the Nyqref.dat and Xlispref.dat files on a Linux machine.
It is quite common for application data to be in hidden files of hidden folders in the user’s home directory.
The user’s home directory is usually: /home//
So for example, the data files could go into: /home//.little_helper/
The dot prefix to the folder name indicates that it is a hidden folder.
The naming convention is to use lower case and no spaces.
However, this is not a full blown application, it is just a plug-in, and users will not want their home folder littered with a load of plug-in data files.
On Linux, plug-ins and modules may be placed in: /home//.audacity-files/
This is in keeping with Linux conventions, so I’d suggest that the “proper” place for the data files on Linux would be: /home//.audacity-files/plug-ins/little-helper/
So, on Linux, the plug-in could check for the presence of the data files with something like this (and throw a meaningful error if not found)
In the case of Robert’s “Little Helper” plug-in, there are 2 data files (155kb and 368kB). These two files of pre-formatted data are far too big to comfortably maintain within the program file. It makes sense in this case to separate out the data from the program.
With other plug-ins it could be other types of data, for example a drum machine that I’ve been working on uses both “pattern” data files and drum samples.
In the future there could be help files (though at present there is no way to display them from the Nyquist plug-in interface other than the tiny text screens or debug window.
A convolution reverb (although impractically slow in Nyquist) would require “impulse” data.
I’m not thinking particularly about “presets”, though that would be another possibility.
In the far distant future plug-ins might support “skins”, in which case there would be graphic data to store somewhere.
These are not files that the user would need to access directly (apart from installing and uninstalling). They are files that contain data that is used by the plug-in.
Probably not essential, though I think that we need to consider “uninstalling” plug-ins (deleting the plug-in and it’s data files). We also need to avoid data files from different plug-ins colliding, so it would seem sensible for the data to be in a (sub-)folder with the same (or closely related) name as the plug-in.
A major advantage of having a “standard” location (though probably platform specific) for plug-in data files, is that it can be easily documented in the plug-in “Installation Instructions”
I had the same thoughts in mind, when I was writing the little helper plug-in (i.e. the complete Nyquist/Xlisp Reference). The Tool , as it presents itself on my Computer has those files in the plug-in folder of audacity (Windows 7):
LittleHelper.ny and LittleHelper.dir (with the above mentioned two files)
Additionally, There are the two Excel templates and a few sounds (for the sound examples) also there (but not included in the official release).
I prefer to have the files that end in *.ny all in the same place or on the same level. Hence, the seperation with the sub folder.
It may be easier for the users if the plug-in itself would also be in this folder in order to facilitate the install and uninstall process.
Since I always have a seperate backup of Audacity, it would be most inconvenient for me to have the different parts of an effect at another location than the plug-in folder of Audacity.
Another question that arises is if the data files are read only or if there anything has to be stored (i.e. presets for example). Those files can’t always be stored in the application folder. Should we use the folder instead where Audacity saves its config file and some presets? Or rather the User folder (which is somewhat over-polluted already, at least on Windows).
It crystalises out that the routines that are responsible for the path creation in the plug-in have to be rather sophisticated to ensure that all possible storage places of the data files (as chosen by the user) are covered on all platforms. This is necessary because ther is no proper plug-in management yet within Audacity and the plug-ins have no installation routine on their own.
On Linux, write access is not a problem if data is stored anywhere in their home folder, for example in a subdirectory of:
By default a user has full read write access to everything in their home folder.
Could OS X do the same as Linux?
On Windows I perhaps it should be somewhere in “Application Data” ?