Re: [Audacity-devel] Experimental features

[James C. <cr...@in...>]

On 23/01/2016 14:22, Paul Licameli wrote:
> I thought the purpose of these #ifdefs is to make it easy to turn 
> features off if they are not good enough for production yet.  But 
> scrubbing and spectral selection and sync lock seem here to stay.
That's one function of #ifdefs, not the only function.

> You commented much about the scrubbing code.  I meant to collect it 
> into one file, except some calls to it remaining in TrackPanel.cpp, 
> and that is a small phase of TrackPanel cleanup I mean to do without 
> the rest of it when I address scrubbing usability.
Yes, I commented most about the basic scrubbing, because I am assuming 
the #ifdefs you care the most about are the ones for your code.  To do 
other #ifdefs, we'd have to do that exercise of working through them 
too.  The examples I picked are illustrative of what's needed to remove 
the #ifdefs.  EXPERIMENTAL_SYNC_LOCK should be easier to remove as an 
#ifdef than many/(most?) of yours, so maybe we should do the exercise on 
that one first.

Shall we have a go at doing that clean up for EXPERIMENTAL_SYNC_LOCK 
together?

Yes, 'meant to' is good, but 'meant to' is not the same as having done 
so.  So if you never do, we will at least still have the #ifdefs so we 
can see the fragments of code that are about 'the same concern' and be 
more easily able to bring them together.

> If the bigger cleanup is done, the code to handle selections gets 
> pulled out of track panel too into one file (though still a rather 
> large one), and that would include most of spectral selection code, 
> except for what is in TrackArtist.
Yes.

Side-discussion on selections:

    Selection is one of the harder abstractions to 'pull out' on its
    own.  Even if we don't implement for future extensions, and we
    probably shouldn't, we should be thinking about future extensions,
    multiple-selection, fuzzy selection and computed-selection, as we do
    so.  The 'difficulty' is that effects and other things that behave a
    bit like effects, like cut and paste, make assumptions about what a
    selection is, rather than 'negotiating' with the selection as to
    what each part of the effect-selection combination can do.  To
    support simple code, the selection code will in due course need to
    have fallback methods, e.g. to iterate to do a multiple selection,
    rather than expect the effect to be smart and be able to deal
    directly/efficiently with (possibly overlapping)
    multiple/fuzzy/computed selection.  We need also to decide if
    passing band pass filtered data to effects and then remixing, to
    support spectral selection on more effects, is a good idea or not.


> But I thought the big cleanup is held back until other people do work 
> with PortAudio.
Yes, we're holding off on doing the big cleanup, but I personally hope 
we will do it for 2.1.3, and therefore that we discuss the refactoring.  
And we can do smaller very local cleanups, e.g. of pulling exactly 
duplicated code into subroutines, were small steps are easy to take.

PortAudio update can happen in parallel with bug fixes.  Small clean ups 
can happen at the same time as that too.  It wasn't until now clear to 
me that you still want to go ahead with separating views from data for 
2.1.3 - which is surely needed in the big cleanup of TrackPanel.  You 
sounded earlier like you were still thinking about how the connection 
between data and view would work, so not actually quite ready for the 
big TrackPanel clean up, though still thinking of it as very doable 
within the 2.1.3 cycle.

I too think big clean up of TrackPanel is doable for the 2.1.3 release, 
and worth doing for it - with a feature driving it.  I think it's not 
PortAudio holding it up, so much as (a) a bit of refining the plan 
needed and (b) anxiety (mostly from people other than me) that such a 
big clean up is high risk of introducing bugs.

side-discussion on risk:

    Because the clean up is mostly in artist code, my view is that bugs
    are likely to be very visible, and not hard bugs like new
    audio/timing glitches might be.   I'm not expecting rework of the
    underlying data structures that hold the audio.  We (or you) will be
    cleaning up code higher up than that and moving code around.  So I
    see the 'risk' as well worth taking to get to the cleaner more
    maintainable code.

Discussing the refactoring right now is good, I think, as there is 
discussing to do about it.   Whoever is RM can decide when changes from 
big clean ups are OK to go into audmain/master.


--James.