Re: [Audacity-quality] Handling code issues and library/build policy discussions on bugzilla

[Vaughan Johnson <vaughan@au...>]

On 4/19/2011 12:01 AM, gale@... wrote:
> 
> Summary:  Sorry for length of this, but recent bugzilla posts suggest
> we should try to have a clearer policy about when/how to raise 
> compilation or library/build policy issues.
> 
> [...]
> I think the current idea is that compilation and linking errors, plus 
> compilation warnings (if in our code, not lib-src) are better posted
> on -devel. 

+1.



>Ignore if lib-src warning. 

+1.

- Vaughan

Re: [Audacity-quality] ;debugflags trace in Nyquist header

[Gale Andrews <gale@au...>]

| From Steve the Fiddle <stevethefiddle@...> 
| Tue, 19 Apr 2011 21:33:04 +0100
| Subject: [Audacity-quality] ;debugflags trace in Nyquist header
> I may have been premature in posting
> http://bugzilla.audacityteam.org/show_bug.cgi?id=376
> 
> The debugflags header is described on the Audacity wiki here:
> http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#debugflags
> I assumed that with *tracenable* set to true, that the debug window
> would automatically open when the plug-in is run, however this only
> appears to be true for plug-ins that run without user interaction -
> that is, for plug-ins that have no ;control lines.
> 
> Does anyone know what is supposed to happen?

Please see my response in the bug:
http://bugzilla.audacityteam.org/show_bug.cgi?id=376#c2




Gale 

Re: [Audacity-quality] [Audacity-devel] Handling code issues and library/build policy discussions on bugzilla

[James Crook <crookj@in...>]

My response here is just to audacity-quality.
I'm responding to the one bug report:

> "source code has invalid std::cout in Nyquist should be wcout"
> http://bugzilla.audacityteam.org/show_bug.cgi?id=374    I think should probably have been on -devel too. Ed seems convinced there is a problem, but no-one else is sure what it is.
I want to explain why I closed bug report 374 as INVALID.  The bug title 
does not describe a problem.  If it was to be a valid bug it would need 
to be something more like "Nyquist produces incorrect foreign language 
characters with UTF16 encoding".  In spite of my many talents I am not 
psychic and I was not able to divine what the problem was from the 
description given.  Ed wants me to change a line of code.  But why?

I've written an intro to using bugzilla on the wiki that covers this and 
some other points about using bugzilla.
http://wiki.audacityteam.org/wiki/Using_Bugzilla



--James.









> I think the current idea is that compilation and linking errors, plus
> compilation warnings (if in our code, not lib-src) are better posted
> on -devel. Ignore if lib-src warning. Is that correct? That seems OK,
> but if a response about a warning falls between the cracks, then as
> with patches, we must be sure items get moved to bugzilla so they
> don't get lost.
>
> Meantime Ed has also told me that he would like a component for
> "Compilation" instead of these issues going into "Other" as now.
> This would be an issue like:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=117
>
> where the problem is with optional behaviour on Linux. I'm not sure if
> "Compiling" is a component.  I could envisage "Compiler" for something
> to do with GCC or VS, or "Libraries".
>
> Or we could fit to the nearest component and keyword it as
> "Building/Linking".
>
> We're also trying having a summary bug:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=300
>
> to control component bugs about building and linking, but I'm not sure
> it works all that well given some higher priority issues need their own
> release notes.
>
>
>
>
>
> Gale
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>

Re: [Audacity-quality] backward compatibility of new plug-ins

[Steve the Fiddle <stevethefiddle@gm...>]

On Tue, Apr 19, 2011 at 5:48 PM, Gale Andrews <gale@...> wrote:
>
> | From James Crook <crookj@...>
> | Mon, 18 Apr 2011 18:51:33 +0100
> | Subject: [Audacity-quality] backward compatibility of new plug-ins
>> >> On 18/04/2011 04:41, Steve the Fiddle wrote:
>> > > Last time this was discussed it was suggested that where possible
>> >> plug-ins should be backwardly compatible with previous versions of
>> > > Audacity.
>>
>> If that were a non-mandatory recommendation, and I were writing nyquist
>> plug-ins, I would not stick to it.
>>
>> For compiled code we are adopting the opposite convention, and all
>> developers are agreed on this.  GUI plug-ins will have a version number
>> and ONLY work with that version of Audacity.  They will be rejected
>> otherwise, even if they could work.  So it forces a new version and a
>> new compile of the plug-in.  This is based on extensive experience of
>> version compatibility issues.  It is possible to be more permissive, but
>> doing it well is complex and risky and the simple strategy is far far
>> better for a program where the API/interface is still being developed.
>>
>> This is not a 'ruling' one way or the other - I'm just giving background
>> information.
>
> I would say that is not entirely analogous to the state of Nyquist
> development, though?
>
> For me, it's about making some effort to indicate Audacity version
> support for plug-ins when practical.  See below.
>
>
> Steve wrote:
>> > I was about to upload the "bandstop.ny" plug-in
>> > (http://forum.audacityteam.org/viewtopic.php?f=42&t=54196 ) to the
>> > wiki, but checking it before uploading I notice that it says on the
>> > interface:
>> > "Requires Audacity 1.3.8 or later."
>
> You must have added that - I didn't get involved in that discussion.

Yes I think I did. I probably first wrote the plug-in around the time
that Audacity 1.3.8 was released, and I assume that I've used a
function that had only just become available. Looking at the code now
I'm not sure what's in there that requires 1.3.8 or later, in fact, I
may have updated the plug-in to allow backward compatibility but
forgotten to update the note in the ;info.

This does highlight the need for there to be some note in the plug-in
as to the minimum Audacity version required - it's not always obvious
which version is required.

>
>> > Now that we're up to 1.3.13 I think it looks distinctly odd that it
>> > says that it requires a "really old beta version or later", and it
>> > will look even stranger after 2.0 has been released.
>> >
>> > In this particular case the plug-in could be modified to support
>> > earlier versions of Audacity, but I'm not convinced that this is such
>> > a good idea. People learning to write Nyquist plug-ins will often look
>> > at existing plug-ins to learn how they work. Writing plug-ins that use
>> > awkward workarounds for limitations that existed in old or obsolete
>> > versions of Audacity does not offer a good example of how to write
>> > plug-ins and in many cases will produce overly complicated code.
>> >
>> > I would consider that any beta version prior to the current beta
>> > release is obsolete.
>> >
>> > It is likely that many new plug-ins will require features that are
>> > only available in later versions of Audacity 1.3, but I don't think
>> > that it is reasonable to expect plug-in authors to know exactly which
>> > beta version introduced that feature, or any specific versions that
>> > the plug-in will not work in due to Audacity bugs.
>> >
>> > There are currently a lot of "version 3" Nyquist plug-ins, and version
>> > 3 plug-ins do not work in Audacity 1.2.x
>> > We do not say on either
>> > http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins or on
>> > http://audacity.sourceforge.net/download/nyquistplugins which plug-ins
>> > do not work on Audacity 1.2.x (though I think that the plug-ins on the
>> > sourceforge page do work with Audacity 1.2.6)
>
> We do say in a div on:
> http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins
>
> "Note: Plug-ins marked 3 are type 3 Nyquist plug-ins which do not work in
>  Audacity 1.2.x or earlier."
>
> I added that, but I would like some indication of Audacity version support
> in plug-ins *if possible*. That's especially important given the above div
> incorrectly implies that plug-ins that are not version 3 will work in 1.2.6.

Yes I think that will need changing.
Perhaps it would be better to mark which plug-ins *are* compatible
with Audacity 1.2.6?
If a plug-in is "version 3", then it is immediately ruled out as
compatible with 1.2.6
"Version 1" plug-ins would need testing, except for those that are
really old and already known to work with 1.2.6

>
> I think we should recognise that people on older OS'es will always need
> older versions of Audacity. These will always be available for download.
> For example, someone on OS X 10.3 can't use later than Audacity 1.3.3.
> Someone who loves FTP support in Audacity can't use later than 1.3.3.
> That doesn't mean that plug-in developers have to be circumscribed,
> just that ideally someone who needs 1.3.3 should know which plug-ins
> will be viable for them.
>
> I would say if a "min version" (i.e. minimum Audacity version) was
> listed alongside "View" / "Download" that would be a very user-friendly
> thing to do.

I think that's a very good idea, though it may be difficult to do
accurately for plug-ins that have appeared over the last couple of
years, unless they actually say somewhere in the code. I guess the
assumption will be that the plug-in will work on the Audacity release
version that was current at the time the plug-in was made?

>
> I appreciate there are practical limitations in some cases in knowing if
> the min version is really 1.3.8 or 1.3.10 or 1.3.13 and that bugs are a
> factor too. In that case maybe we should hedge min version with a
> "disclaimer" - "always use the current stable or beta version of
> Audacity where possible". I guess you know which plug-ins depend
> on the 1.3.8 and 1.3.13 Nyquist improvements?

I can spot some of the new features, but some are quite subtle. For
example, a first order high pass filter can run on a stereo track in
Audacity 1.2.6, but any higher order high-pass filters can't. There's
quite a few little differences like that. The only really sure way to
know is to test them.

>
> And I think the guidelines for plug-in authors should suggest
> supplying some Audacity version information (again where practical).

I've added a note to the "Conventions for Nyquist Plug-ins" topic on
the forum http://forum.audacityteam.org/viewtopic.php?f=39&t=42106

Steve

>
>> > Not all "version 1" plug-ins will work with Audacity 1.2.6! Some
>> > "version 1" plug-ins may require recent versions of Audacity 1.3.x.
>> > "version 1" refers to the interface elements of the plug-in and not to
>> > the internal code, so the plug-in "version number" does not indicate
>> > which version of Audacity the plug-in will work with.
>> >
>> > Examples of current plug-ins that do not work with Audacity 1.2.x
>> > include: Regular Interval Label, Vocoder, Channel Mixer, Vocal
>> > Removal, Noise Gate, High-Pass filter, Low-pass filter...
>> > Increasingly there will be plug-ins that do not work with early beta versions.
>> > Does it need to be noted on the plug-in interface, in the Nyquist
>> > plug-in web page descriptions, or commented in the plug-in code as to
>> > which version(s) of Audacity are supported?
>
> I would say in a code comment (in case someone other than you
> uploads the plug-in) and in the Wiki.  No need in the interface.
>
> I guess the other issue is if we need to list plug-ins on Wiki that are
> available in current stable Audacity. So maybe after 2.0 it should
> be reviewed for example whether we want to retain HP/LP plug-ins
> on that page. I've also got somewhere a package of older David Sky
> plug-ins which would provide some support for people who wanted
> legacy plug-ins.
>
>
>
>
> Gale

[Audacity-quality] ;debugflags trace in Nyquist header

[Steve the Fiddle <stevethefiddle@gm...>]

I may have been premature in posting
http://bugzilla.audacityteam.org/show_bug.cgi?id=376

The debugflags header is described on the Audacity wiki here:
http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#debugflags
I assumed that with *tracenable* set to true, that the debug window
would automatically open when the plug-in is run, however this only
appears to be true for plug-ins that run without user interaction -
that is, for plug-ins that have no ;control lines.

Does anyone know what is supposed to happen?

Steve

[Audacity-quality] Effect menu

[Steve the Fiddle <stevethefiddle@gm...>]

Is the Effect menu supposed to be the same on all platforms?
On Linux I get (below the line):

__________________
Plugins 1 to 15
Plugins 16 to 30
Plugins 31 to 45

Whereas on Windows I just get one really long list.

Also, shouldn't it be "Plug-ins" not "Plugins"?

Steve

Re: [Audacity-quality] backward compatibility of new plug-ins

[Gale Andrews <gale@au...>]

| From James Crook <crookj@...> 
| Mon, 18 Apr 2011 18:51:33 +0100
| Subject: [Audacity-quality] backward compatibility of new plug-ins
> >> On 18/04/2011 04:41, Steve the Fiddle wrote:
> > > Last time this was discussed it was suggested that where possible
> >> plug-ins should be backwardly compatible with previous versions of
> > > Audacity.
> 
> If that were a non-mandatory recommendation, and I were writing nyquist 
> plug-ins, I would not stick to it.
> 
> For compiled code we are adopting the opposite convention, and all 
> developers are agreed on this.  GUI plug-ins will have a version number 
> and ONLY work with that version of Audacity.  They will be rejected 
> otherwise, even if they could work.  So it forces a new version and a 
> new compile of the plug-in.  This is based on extensive experience of 
> version compatibility issues.  It is possible to be more permissive, but 
> doing it well is complex and risky and the simple strategy is far far 
> better for a program where the API/interface is still being developed.
> 
> This is not a 'ruling' one way or the other - I'm just giving background 
> information.

I would say that is not entirely analogous to the state of Nyquist 
development, though? 

For me, it's about making some effort to indicate Audacity version 
support for plug-ins when practical.  See below. 


Steve wrote:
> > I was about to upload the "bandstop.ny" plug-in
> > (http://forum.audacityteam.org/viewtopic.php?f=42&t=54196 ) to the
> > wiki, but checking it before uploading I notice that it says on the
> > interface:
> > "Requires Audacity 1.3.8 or later."

You must have added that - I didn't get involved in that discussion.


> > Now that we're up to 1.3.13 I think it looks distinctly odd that it
> > says that it requires a "really old beta version or later", and it
> > will look even stranger after 2.0 has been released.
> > 
> > In this particular case the plug-in could be modified to support
> > earlier versions of Audacity, but I'm not convinced that this is such
> > a good idea. People learning to write Nyquist plug-ins will often look
> > at existing plug-ins to learn how they work. Writing plug-ins that use
> > awkward workarounds for limitations that existed in old or obsolete
> > versions of Audacity does not offer a good example of how to write
> > plug-ins and in many cases will produce overly complicated code.
> > 
> > I would consider that any beta version prior to the current beta
> > release is obsolete.
> > 
> > It is likely that many new plug-ins will require features that are
> > only available in later versions of Audacity 1.3, but I don't think
> > that it is reasonable to expect plug-in authors to know exactly which
> > beta version introduced that feature, or any specific versions that
> > the plug-in will not work in due to Audacity bugs.
> > 
> > There are currently a lot of "version 3" Nyquist plug-ins, and version
> > 3 plug-ins do not work in Audacity 1.2.x
> > We do not say on either
> > http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins or on
> > http://audacity.sourceforge.net/download/nyquistplugins which plug-ins
> > do not work on Audacity 1.2.x (though I think that the plug-ins on the
> > sourceforge page do work with Audacity 1.2.6)

We do say in a div on: 
http://wiki.audacityteam.org/wiki/Download_Nyquist_Plug-ins

"Note: Plug-ins marked 3 are type 3 Nyquist plug-ins which do not work in
  Audacity 1.2.x or earlier."

I added that, but I would like some indication of Audacity version support
in plug-ins *if possible*. That's especially important given the above div
incorrectly implies that plug-ins that are not version 3 will work in 1.2.6. 

I think we should recognise that people on older OS'es will always need 
older versions of Audacity. These will always be available for download. 
For example, someone on OS X 10.3 can't use later than Audacity 1.3.3.
Someone who loves FTP support in Audacity can't use later than 1.3.3.
That doesn't mean that plug-in developers have to be circumscribed, 
just that ideally someone who needs 1.3.3 should know which plug-ins
will be viable for them. 

I would say if a "min version" (i.e. minimum Audacity version) was 
listed alongside "View" / "Download" that would be a very user-friendly 
thing to do. 

I appreciate there are practical limitations in some cases in knowing if 
the min version is really 1.3.8 or 1.3.10 or 1.3.13 and that bugs are a 
factor too. In that case maybe we should hedge min version with a 
"disclaimer" - "always use the current stable or beta version of 
Audacity where possible". I guess you know which plug-ins depend
on the 1.3.8 and 1.3.13 Nyquist improvements? 

And I think the guidelines for plug-in authors should suggest 
supplying some Audacity version information (again where practical).


> > Not all "version 1" plug-ins will work with Audacity 1.2.6! Some
> > "version 1" plug-ins may require recent versions of Audacity 1.3.x.
> > "version 1" refers to the interface elements of the plug-in and not to
> > the internal code, so the plug-in "version number" does not indicate
> > which version of Audacity the plug-in will work with.
> > 
> > Examples of current plug-ins that do not work with Audacity 1.2.x
> > include: Regular Interval Label, Vocoder, Channel Mixer, Vocal
> > Removal, Noise Gate, High-Pass filter, Low-pass filter...
> > Increasingly there will be plug-ins that do not work with early beta versions.
> > Does it need to be noted on the plug-in interface, in the Nyquist
> > plug-in web page descriptions, or commented in the plug-in code as to
> > which version(s) of Audacity are supported?

I would say in a code comment (in case someone other than you 
uploads the plug-in) and in the Wiki.  No need in the interface.

I guess the other issue is if we need to list plug-ins on Wiki that are 
available in current stable Audacity. So maybe after 2.0 it should 
be reviewed for example whether we want to retain HP/LP plug-ins 
on that page. I've also got somewhere a package of older David Sky  
plug-ins which would provide some support for people who wanted 
legacy plug-ins. 




Gale 

[Audacity-quality] Handling code issues and library/build policy discussions on bugzilla

[<gale@au...>]

Summary:  Sorry for length of this, but recent bugzilla posts suggest
we should try to have a clearer policy about when/how to raise 
compilation or library/build policy issues.

I hope posting this will save a bit of a time in the longer run. 


---


Ed's last four new "bugs" have been about library or build policies
(in case of bugs 364 and 365 actually related to current bugs, but not 
well researched or pointed to, IMO); or about a possible error in the 
code (that does not AFAIK cause an actual issue). 

Details below:

Entered as "remove unneeded taglib"   
Now titled as "Switch from libidtag to taglib?":
http://bugzilla.audacityteam.org/show_bug.cgi?id=364

Entered as "remove unneeded slv2"
now "LV2 support unfinished": 
http://bugzilla.audacityteam.org/show_bug.cgi?id=365

"considerations for keeping ANSI builds" 
resolved WONTFIX:
http://bugzilla.audacityteam.org/show_bug.cgi?id=371

"source code has invalid std::cout in Nyquist should be wcout"
http://bugzilla.audacityteam.org/show_bug.cgi?id=374

My take is that as 364/365 were about the possible need to remove  
libraries or standardise whether they were built, -devel would have 
been better (though I think recording the outcome on bugzilla for 
tracking was/is worth doing). 

My take on 371 was that it was too vague and not thought through
to be a bug. Given that, it should have been raised with me, or on 
feedback@...  Not raised on -quality until the issues are clear.

374 I think should probably have been on -devel too. Ed seems 
convinced there is a problem, but no-one else is sure what it is. 

I think the current idea is that compilation and linking errors, plus 
compilation warnings (if in our code, not lib-src) are better posted
on -devel. Ignore if lib-src warning. Is that correct? That seems OK, 
but if a response about a warning falls between the cracks, then as 
with patches, we must be sure items get moved to bugzilla so they
don't get lost. 

Meantime Ed has also told me that he would like a component for 
"Compilation" instead of these issues going into "Other" as now.  
This would be an issue like:
http://bugzilla.audacityteam.org/show_bug.cgi?id=117

where the problem is with optional behaviour on Linux. I'm not sure if
"Compiling" is a component.  I could envisage "Compiler" for something 
to do with GCC or VS, or "Libraries". 

Or we could fit to the nearest component and keyword it as
"Building/Linking". 

We're also trying having a summary bug:
http://bugzilla.audacityteam.org/show_bug.cgi?id=300

to control component bugs about building and linking, but I'm not sure
it works all that well given some higher priority issues need their own 
release notes. 





Gale