How about
“2 digits before label”
“2 digits after label”
That would be ideal, but the multi-choice selection box is not resizeable and so it would end up looking like this:
I think the shorter wording would have to be “Label numbering format” but it loses the point about minimum which I feel is important. I think the slash is confusing. How about this if we have the longer wording:
You could still have the old “split line” ;control text too.
We do not usually change file name or plug-in name for updated plug-ins, so yes - “equalabel.ny” and “Regular Interval Labels…”
Bear in mind there was no 1.3.4 for Mac.
Is “Minimum supported Audacity version: 1.3.4 (Windows, Linux), 1.3.5 (Mac)” better considering it’s essentially upload information?
Gale
I like “Minimum number of digits in label” with the parentheses “2 (before label)”.
I don’t think it needs plural “labels” here as the numbering applies to each label, (and there may only be one label).
Done.
I didn’t know there was no 1.3.4 for Mac.
I’ve gone with:
;; Requires Audacity 1.3.4 or later.
Which I think covers all bases (Audacity 1.3.5 for Mac is a later version number than Audacity 1.3.4).
I have no strong opinion about this small detail, so feel free to change the wording if you prefer.
Done.
As modifications to plug-ins could change the supported Audacity versions, I think the best place to put the version requirement comment is immediately after any “release notes”. That way, if a plug-in is modified and the author updates the copyright date details or notes new features/bug fixes, then the version requirements will be updated if necessary at the same time.
The full credit/copyright/notes comment block is:
;; <Plug-in name> by <author> <date>
;; <additional credits>
;; Released under terms of the GNU General Public License version 2
;; http://www.gnu.org/copyleft/gpl.html .
;; <additional notes>
;; <release notes>
;; Audacity version requirements.
This comment block is immediately after the Nyquist header information, but before any ;control lines.
Does that sound like a good Pro Forma?
Hopefully this is the final version:
equalabel.ny (6.15 KB)
Yes. I was puzzled we had the following arrangement in notch.ny:
;control freq "Frequency" real "Hz" 60 0 10000
;control q "Q (higher value reduces width)" real "" 1 0.1 20
;; notch.ny by Steve Daulton and Bill Wharrie, September 2010.
;; Released under terms of the GNU General Public License version 2:
;; http://www.gnu.org/licenses/old-licenses/gpl-2.0.html .
;; (multichan-expand) provides legacy support for old versions of Audacity
;; in which the (notch2) function only supports mono tracks.
However given we say in our distributed plug-ins:
;; Released under terms of the GNU General Public License version 2
I prefer:
;; GNU General Public License v2.0 - GNU Project - Free Software Foundation
to:
;; The GNU General Public License v3.0 - GNU Project - Free Software Foundation
because that link is actually to the v3 GPL.
Yes. I’ll change to
;; GNU General Public License v2.0 - GNU Project - Free Software Foundation
otherwise “as is”.
However can we give more guidance to authors about deciding on a category? We have
“http://audacityteam.org/namespace#TimeAnalyser”
for equalabel.ny. I presume this is because there is no suitable subcategory under
“LV2” ?
But is there a list of the namespace categories anywhere? We should still have a list even if we can add a namespace category at will.
Gale
Strictly speaking, the ;control lines are part of the Audacity header. In “notch.ny” the comment block was placed after the Audacity header - that is, after the ;control lines.
In terms of readability I think it is better if the ;control lines are kept with the Nyquist code (as they set the values for variables used in the code). This then places the comment block above all of the “code” (as in “equalabel.ny”). I prefer the comment block here.
Agreed.
Thanks.
“TimeAnalyser” is not within the LV2 specification as listed here: Missing Page
but rather than using the “Missing Page” URI, it uses “http://audacityteam.org/namespace#” (as mentioned here: http://audacity.238276.n2.nabble.com/LRDF-support-for-Linux-td259112.html )
In the absence of other information I left this category as it was in the original plug-in.
I think that the problem is that the LV2 specification is written primarily for “audio processors”, hence there is just one category for “Any plugin that analyses input to output some useful information” and that is http://lv2plug.in/ns/lv2core/#AnalyserPlugin
The LV2 categories that are listed on the Audacity wiki are essentially a subset of the full LV2 specification.
I can see that the LV2 specification makes a useful starting point for Audacity plug-in categories, especially as some LADSPA/LV2 plug-ins may already contain this category information (though I don’t know if any currently available LADSPA/LV2 plug-ins actually do contain this information). However, I think that for Audacity plug-ins the LV2 specification is not adequate. Perhaps Audacity-Nyquist plug-ins require their own specification rather than being tied to LV2.
How best to specify categories in Nyquist plug-ins will IMHO depend largely on how the Audacity developers eventually decide to implement plug-in categories. Until we know what the developers have in mind it is difficult to know how to best advise plug-in authors.
Hi Steve,
In Conventions for Nyquist Plug-ins you suggest omitting the category, which would suggest committing new or updated plug-ins without the ;categories line. That doesn’t seem like a good idea, as anyone who can compile Audacity can turn EFFECT_CATEGORIES back on which would then work for Nyquist effects.
Maybe better to point to the categories links you have in your post above, and suggest the author leave ;categories out if they are unsure?
Gale
Yes - this was in response to my enquiry on -devel.
I’ve already e-mailed you regarding this, but feel free to reply either by e-mail or in the “Conventions” topic.
The latest version of this plug-in is now shipped with Audacity as standard.