Quantcast

Magnifier ("fisheye") for 2.2.0!

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Nightlies (was: Magnifier ("fisheye") for 2.2.0!)

Gale
Administrator
I am not sure why this is posted outside the Team list.


On 12 April 2017 at 13:51, James Crook <[hidden email]> wrote:

> On 4/12/2017 8:03 AM, Peter Sampson wrote:
>> On Wed, Apr 12, 2017 at 3:35 AM, Gale Andrews <[hidden email]> wrote:
>>
>
>>> I'm opposed to alphas (nightly builds) being internal only.
>>> We want more users involved in those too.
>>>
>> +1
>>
>> Me too, I want the scores/hundreds of nighlies downloads to continue, as I
>> stated before many of these people are testing/using - their silence is an
>> indication that all is probably well with their uase of these builds.
> Most of those downloads are coming from sites like Softpedia which list
> the alphas with, and as if they were, stable downloads - so that they
> have another 'mirror' that they do not pay bandwidth charges on for the
> software.  I would say most of those users are expecting to get a stable
> Audacity.

I only knew of Softpedia and Download 3K
http://www.download3k.com/Install-Audacity-Audacity.html

who were hotlinking to the latest Windows alpha build. They now
link directly to http://gaclrecords.org.uk/win-nightly/ (Softpedia
call it "External mirror 1 - alpha"), so their users now avoid
seeing:
http://gaclrecords.org.uk/win-nightly/hotlinking.html .

Both pages are very clear these are not stable builds so I am
a little more optimistic than James that some of the 50 to 100
downloads for a build that is current for a day are at the least
interested in seeing what's in the latest code.

We have no contact with these people so cannot engage them
yet.


> I think we should get people to sign up if they want alphas
> - So that we know that they know what they are actually getting
> - So that we increase the chance of getting feedback

We could also put people off. I strongly disagree that the alpha
download pages should be gated. I agree it may be good to
facilitate engaging those users better.

This assumes we actually agree to having a call for action that
James refers to as "Big Bug Hunt":
http://wiki.audacityteam.org/wiki/Calls_to_Action .

I might call it "Big Bug Squash".  They gotta test the fix too.

The options I see for a "place" for these users are a Google Group,
or a new forum subdomain (which could carry a board for "early
adopters" too if we have such an "early access" program).

Of course I could just spruce up the text on the alpha download page
and mention feedback@ and http://www.audacityteam.org/community .


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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Gale
Administrator
In reply to this post by Robert Hänggi
Hi Robert,

Is Bugzilla accessible enough for you to create a bug report or add a
comment to an existing bug?



Gale


On 12 April 2017 at 13:45, Robert Hänggi <[hidden email]> wrote:

> Hi Peter
>
> 2017-04-12 11:30 GMT+02:00, Peter Sampson <[hidden email]>:
>> On Wed, Apr 12, 2017 at 10:15 AM, Robert Hänggi <[hidden email]>
>> wrote:
>>
>>> 2017-04-12 9:03 GMT+02:00, Peter Sampson
>>> <[hidden email]>:
>>> >
>>> > +1
>>> >
>>> > Me too, I want the scores/hundreds of nighlies downloads to continue,
>>> > as
>>> I
>>> > staed before many of these people are testing/using - their silence is
>>> > an
>>> > indication that all is probably well with their uase of these builds.
>>> >
>>> > We cannot however apect all (any) of them to do the intricate testing
>>> > of
>>> > minute
>>> > changes in the commit log - thta remains down to us (unless we recruit
>>> more
>>> > formal testers).
>>> >
>>> Well, if you need help in the QA department, I'm willing to join in
>>> order to reduce the burden.
>>>
>>
>> Hi Robert,
>>
>> there are three main sorts of ongoing QA testing that we do:
>>
>> a) big new feature testing, for example: James' recent themes, the upcoming
>> menu
>> changes, Paul's Scrubbing for 2.1.3.
>>
>> This is the sort of testing that Paul will require when he lets out his
>> Fish-eye into
>> the nightlies (or privaye build?) for QA examination - and involves direct
>> feedback
>> to the developer (as we are currently doing with Themes for James on Q2A).
>>
>> This can be quite exciting, working with the developer(s) on new features.
>>
>
> Currently, I'm watching the menu changes and experiment with e.g. MIDI output.
> The latter is a long-term feature and probably not relevant to QA
> directly. However, I've noticed that a lot of playback/preview and
> other features are broken due to the recent changes in track/channel
> management are broken.
> For instance, try to swap the channels of a stereo track (drop-down menu)...
>
> I'm building Audacity on a fairly regular basis myself.
> I actually don't need the nightlies for that (except perhaps for
> testing on Linux, which I just started with).
>
>>
>> b) The Minutiae testing for the small changes.  This involves monitoring
>> the commit
>> logs and testing the changes, and testing around the changes, that are made
>> there.
>> These changes can be tweaks/extensions to existing functionality or bug
>> fixes.
>> For bug fixes these are tracked on Bugzilla.
>>
>> This can be drudge-work but rewarding in its way as it helps us to crush
>> bugs.
>
> See above.
> I'm following the log changes with the command line (git log/show).
> I must now check out David's additions.
>>
>>
>> c) Then of course there's the testing of workflows etc. that we do for
>> Releases
>> Candidates (and KTT if we ever were to have those).
>
> At some time, I must also "invent" some accessibility workflows.
> A lot of it seems to become buggy since 2.2.0 development.
>
>>
>> This is essential and by its nature short-term and time critical.
>>
>>
>> So which sort of testing interests you - any of it, all of it?
>>
>
> All except strictly visual or mouse specific things
>
> Best
> Robert
>
>> Cheers,
>> Peter.
>>
>>
>>>
>>> Robert
>>>
>>> >
>>> >>
>>> >> Nightly builds are not betas, as Buanzo said.
>>> >>
>>> >> And if we have simultaneous KTT and experimental as
>>> >> James envisages, I think it would be confusing to call both
>>> >> of those "betas".
>>> >>
>>> >>
>>> >>
>>> >> Gale
>>> >>
>>> >> >> If Fish-Eye is in KTT then I assume the intention would be for
>>> >> >> it to be in 2.2.0, all things being equal, but I have also heard
>>> >> >> that
>>> >> >> the interface is in need of work. The RM will have to decide if
>>> >> >> Fish-Eye is in 2.2.0 and if so ensure that resources are sufficient
>>> >> >> to document it properly.
>>> >> >>
>>> >> >>
>>> >> >> Gale
>>> >> >>
>>> >> >> On 11 April 2017 at 01:36, Vaughan Johnson <[hidden email]>
>>> >> wrote:
>>> >> >>> So as to not put the brakes on Paul's enthusiasm, can't it be done
>>> in
>>> >> >>> code restricted by #ifdefs ?  Paul could make progress, people
>>> >> >>> could
>>> >> >>> play with it if they have time. Even if it's not ready in both
>>> >> >>> code
>>> >> >>> and manual for next release, Paul's expressing enthusiasm for it
>>> >> >>> and
>>> >> >>> we should encourage that. And likely put it into release after
>>> >> >>> next.
>>> >> >>>
>>> >> >>> If it can be done under #ifdef's, I don't even see any reason to
>>> >> >>> discuss whether it's in next release. Do-ocracy.
>>> >> >>>
>>> >> >>> This was a benefit of doing beta releases -- they could be
>>> >> >>> underdocumented and even have bugs!  So now we're talking about
>>> >> >>> experimental releases -- that's the same thing Gale fought so hard
>>> >> >>> against, and from which we decided to do only 'stable' releases.
>>> >> >>> Nightlies are good but have a minuscule footpring compared to what
>>> >> >>> betas did.
>>> >> >>>
>>> >> >>> - Vaughan
>>> >> >>>
>>> >> >>>
>>> >> >>> On Mon, Apr 10, 2017 at 4:20 AM, Peter Sampson
>>> >> >>> <[hidden email]> wrote:
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <
>>> >> [hidden email]>
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson
>>> >> >>>>> <[hidden email]> wrote:
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews
>>> >> >>>>>> <[hidden email]
>>> >> >
>>> >> >>>>>> wrote:
>>> >> >>>>>>>
>>> >> >>>>>>> On 5 April 2017 at 17:25, Paul Licameli <
>>> [hidden email]>
>>> >> wrote:
>>> >> >>>>>>> > I may punt track panel refactoring for yet one more release,
>>> >> while
>>> >> >>>>>>> > waiting
>>> >> >>>>>>> > for James and Pokechu22 and David to finish their projects.
>>> >> >>>>>>> > I
>>> >> could
>>> >> >>>>>>> > prepare
>>> >> >>>>>>> > it during code freeze time as my "big bang" for the start of
>>> >> 2.2.1; as
>>> >> >>>>>>> > it
>>> >> >>>>>>> > was, I prepared a different big bang for 2.2.0, finishing up
>>> >> >>>>>>> > the
>>> >> >>>>>>> > removal of
>>> >> >>>>>>> > naked news.
>>> >> >>>>>>> >
>>> >> >>>>>>> > I may decide instead to have some fun doing a much delayed
>>> >> feature,
>>> >> >>>>>>> > the
>>> >> >>>>>>> > magnifier!  (I don't think "fisheye" is an apt name, unless
>>> >> >>>>>>> > it
>>> >> also
>>> >> >>>>>>> > makes a
>>> >> >>>>>>> > magnification on the vertical scale.  Which might be a
>>> >> >>>>>>> > useful
>>> >> thing in
>>> >> >>>>>>> > spectral selection, but is beyond the scope of what I
>>> >> >>>>>>> > intend.)
>>> >> >>>>>>> >
>>> >> >>>>>>> > I will not submit the old prototype but reimplement its user
>>> >> interface
>>> >> >>>>>>> > in
>>> >> >>>>>>> > ways that require fewer changes to TrackPanel.cpp but more
>>> >> >>>>>>> > to
>>> >> the time
>>> >> >>>>>>> > ruler.
>>> >> >>>>>>> >
>>> >> >>>>>>> > Details of how it might work are here:
>>> >> >>>>>>> >
>>> >> >>>>>>> > http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.
>>> >> 27s_proposal_for_2.2.0
>>> >> >>>>>>> >
>>> >> >>>>>>> > An old picture of the fisheye is in the section above.  That
>>> >> should
>>> >> >>>>>>> > look
>>> >> >>>>>>> > much the same.  Ignore the preference dialog.
>>> >> >>>>>>>
>>> >> >>>>>>> Is Punch-in or preparations therefore still on the cards for
>>> >> >>>>>>> 2.2.0,
>>> >> >>>>>>> Paul?
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> Punch-in is *far* more important (a long-standing very popular
>>> >> feature
>>> >> >>>>>> request) than
>>> >> >>>>>> Fish-eye.
>>> >> >>>>>>
>>> >> >>>>>> AnI don't think we have the time or the QA capacity for
>>> >> >>>>>> Fish-eye
>>> >> >>>>>> in
>>> >> >>>>>> 2.2.0, especially if
>>> >> >>>>>> we are still aiming for 3-4 month release cycles - it's already
>>> >> >>>>>> a
>>> >> month
>>> >> >>>>>> since we released
>>> >> >>>>>> 2.1.3
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> A month?  It's not yet three weeks since 17 March!
>>> >> >>>>>
>>> >> >>>>> One banner feature or another implies some use of QA capacity.
>>> >> >>>>> I
>>> >> don't
>>> >> >>>>> see how punch-and-roll would be any easier on QA instead.  What
>>> >> >>>>> do
>>> >> we expect
>>> >> >>>>> will already take up capacity?  Testing the theming changes and
>>> >> >>>>> MIDI
>>> >> >>>>> playback?
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> What will take up a loit of my capacity is the large number of
>>> >> documentation
>>> >> >>>> changes in the Manual
>>> >> >>>> for things like revised menu structure, thems, "record beside" as
>>> >> default.
>>> >> >>>> As most of this is stuff that
>>> >> >>>> is in flux it's not something I can or want to undertake right
>>> >> >>>> now
>>> -
>>> >> so I am
>>> >> >>>> collecting a host of P1s.
>>> >> >>>> Plus I have to allocate some time for James to work with him on
>>> >> potentially
>>> >> >>>> trying to automate
>>> >> >>>> image capture for the Manual.
>>> >> >>>>
>>> >> >>>> Gale is already overworked and is not in the best of health, I
>>> >> understand.
>>> >> >>>>
>>> >> >>>> And Steve has less time for QA these days, undertaking other
>>> >> >>>> tasks.
>>> >> >>>>
>>> >> >>>> Peter.
>>> >> >>>>
>>> >> >>>>>
>>> >> >>>>>
>>> >> >>>>> Fisheye is something that has waited a long time.  The difficult
>>> >> parts,
>>> >> >>>>> for distorted drawing of tracks and proper mouse interactions,
>>> were
>>> >> done in
>>> >> >>>>> 2.1.1, lying latent.  Recoding the user interface should not be
>>> >> >>>>> so
>>> >> >>>>> difficult.  (Though agreeing on details is another thing.)
>>> >> >>>>>
>>> >> >>>>> Punch-and-roll recording is a nice to have, but Steve was
>>> >> >>>>> persuading
>>> >> us
>>> >> >>>>> (and persuaded me) that the easy, minimal, destructive version
>>> >> should not be
>>> >> >>>>> shipped as a feature.  I have not thought through a good design
>>> for
>>> >> >>>>> something more complete.
>>> >> >>>>>
>>> >> >>>>> As I said before, it set me thinking about the problem of
>>> >> >>>>> overlapping
>>> >> >>>>> clips in a track, with automatic cross-fading, and some way to
>>> >> >>>>> store
>>> >> >>>>> multiple takes.  That might stand by itself as a useful feature,
>>> >> preliminary
>>> >> >>>>> to doing punch-and-roll right.  But there are lots of corner
>>> >> >>>>> cases
>>> >> >>>>> to
>>> >> >>>>> consider, and some reorganization of the persistent data in .aup
>>> >> projects,
>>> >> >>>>> while fisheye entails no such difficulties.
>>> >> >>>>>
>>> >> >>>>> So, what's most demanded may not be what's most accessible.  Or,
>>> >> >>>>> you
>>> >> can't
>>> >> >>>>> always get what you want.
>>> >> >>>>>
>>> >> >>>>> Now I have the Rolling Stones stuck in my head.
>>> >> >>>>>
>>> >> >>>>> PRL
>>> >> >>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>> > But before I do this, I want to agree on a better way to
>>> >> >>>>>>> > share
>>> >> >>>>>>> > binaries
>>> >> >>>>>>> > built from branches with Peter if details must be debated.
>>> >> >>>>>>> > I
>>> >> >>>>>>> > do
>>> >> not
>>> >> >>>>>>> > want a
>>> >> >>>>>>> > repetition of last summer's thrashing of the new scrubbing
>>> >> feature,
>>> >> >>>>>>> > polluting the master history with experiments that only get
>>> >> reverted.
>>> >> >>>>>>> > I
>>> >> >>>>>>> > want to mature a topic branch and merge it into master only
>>> >> >>>>>>> > when
>>> >> we
>>> >> >>>>>>> > are all
>>> >> >>>>>>> > mostly satisfied with the design choices and the remainder
>>> >> >>>>>>> > of
>>> >> work is
>>> >> >>>>>>> > just
>>> >> >>>>>>> > bug fixing.
>>> >> >>>>>>>
>>> >> >>>>>>> Sounds good. What is the issue e.g. are you not keen to
>>> >> >>>>>>> release
>>> >> binaries
>>> >> >>>>>>> for
>>> >> >>>>>>> your topic branch?
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>> Mark Young dealt with this in the past with Time Record testing
>>> by
>>> >> making
>>> >> >>>>>> private
>>> >> >>>>>> builds and posting them for me.
>>> >> >>>>>>
>>> >> >>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>>
>>> >> >>>>>>> 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
>>> >> >>>>>>> [hidden email]
>>> >> >>>>>>> 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
>>> >> >>>>>> [hidden email]
>>> >> >>>>>> 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
>>> >> >>>> [hidden email]
>>> >> >>>> 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
>>> >> >>> [hidden email]
>>> >> >>> 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
>>> >> >> [hidden email]
>>> >> >> 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
>>> >> > [hidden email]
>>> >> > 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
>>> >> [hidden email]
>>> >> 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
>>> [hidden email]
>>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Robert Hänggi
Hi Gale

Yes, it should be possible. Just a matter of getting used to it, I suppose.
I even have an account there although not yet used for logging bugs.

Robert

2017-04-12 22:59 GMT+02:00, Gale Andrews <[hidden email]>:

> Hi Robert,
>
> Is Bugzilla accessible enough for you to create a bug report or add a
> comment to an existing bug?
>
>
>
> Gale
>
>
> On 12 April 2017 at 13:45, Robert Hänggi <[hidden email]> wrote:
>> Hi Peter
>>
>> 2017-04-12 11:30 GMT+02:00, Peter Sampson
>> <[hidden email]>:
>>> On Wed, Apr 12, 2017 at 10:15 AM, Robert Hänggi <[hidden email]>
>>> wrote:
>>>
>>>> 2017-04-12 9:03 GMT+02:00, Peter Sampson
>>>> <[hidden email]>:
>>>> >
>>>> > +1
>>>> >
>>>> > Me too, I want the scores/hundreds of nighlies downloads to continue,
>>>> > as
>>>> I
>>>> > staed before many of these people are testing/using - their silence is
>>>> > an
>>>> > indication that all is probably well with their uase of these builds.
>>>> >
>>>> > We cannot however apect all (any) of them to do the intricate testing
>>>> > of
>>>> > minute
>>>> > changes in the commit log - thta remains down to us (unless we recruit
>>>> more
>>>> > formal testers).
>>>> >
>>>> Well, if you need help in the QA department, I'm willing to join in
>>>> order to reduce the burden.
>>>>
>>>
>>> Hi Robert,
>>>
>>> there are three main sorts of ongoing QA testing that we do:
>>>
>>> a) big new feature testing, for example: James' recent themes, the
>>> upcoming
>>> menu
>>> changes, Paul's Scrubbing for 2.1.3.
>>>
>>> This is the sort of testing that Paul will require when he lets out his
>>> Fish-eye into
>>> the nightlies (or privaye build?) for QA examination - and involves
>>> direct
>>> feedback
>>> to the developer (as we are currently doing with Themes for James on
>>> Q2A).
>>>
>>> This can be quite exciting, working with the developer(s) on new
>>> features.
>>>
>>
>> Currently, I'm watching the menu changes and experiment with e.g. MIDI
>> output.
>> The latter is a long-term feature and probably not relevant to QA
>> directly. However, I've noticed that a lot of playback/preview and
>> other features are broken due to the recent changes in track/channel
>> management are broken.
>> For instance, try to swap the channels of a stereo track (drop-down
>> menu)...
>>
>> I'm building Audacity on a fairly regular basis myself.
>> I actually don't need the nightlies for that (except perhaps for
>> testing on Linux, which I just started with).
>>
>>>
>>> b) The Minutiae testing for the small changes.  This involves monitoring
>>> the commit
>>> logs and testing the changes, and testing around the changes, that are
>>> made
>>> there.
>>> These changes can be tweaks/extensions to existing functionality or bug
>>> fixes.
>>> For bug fixes these are tracked on Bugzilla.
>>>
>>> This can be drudge-work but rewarding in its way as it helps us to crush
>>> bugs.
>>
>> See above.
>> I'm following the log changes with the command line (git log/show).
>> I must now check out David's additions.
>>>
>>>
>>> c) Then of course there's the testing of workflows etc. that we do for
>>> Releases
>>> Candidates (and KTT if we ever were to have those).
>>
>> At some time, I must also "invent" some accessibility workflows.
>> A lot of it seems to become buggy since 2.2.0 development.
>>
>>>
>>> This is essential and by its nature short-term and time critical.
>>>
>>>
>>> So which sort of testing interests you - any of it, all of it?
>>>
>>
>> All except strictly visual or mouse specific things
>>
>> Best
>> Robert
>>
>>> Cheers,
>>> Peter.
>>>
>>>
>>>>
>>>> Robert
>>>>
>>>> >
>>>> >>
>>>> >> Nightly builds are not betas, as Buanzo said.
>>>> >>
>>>> >> And if we have simultaneous KTT and experimental as
>>>> >> James envisages, I think it would be confusing to call both
>>>> >> of those "betas".
>>>> >>
>>>> >>
>>>> >>
>>>> >> Gale
>>>> >>
>>>> >> >> If Fish-Eye is in KTT then I assume the intention would be for
>>>> >> >> it to be in 2.2.0, all things being equal, but I have also heard
>>>> >> >> that
>>>> >> >> the interface is in need of work. The RM will have to decide if
>>>> >> >> Fish-Eye is in 2.2.0 and if so ensure that resources are
>>>> >> >> sufficient
>>>> >> >> to document it properly.
>>>> >> >>
>>>> >> >>
>>>> >> >> Gale
>>>> >> >>
>>>> >> >> On 11 April 2017 at 01:36, Vaughan Johnson <[hidden email]>
>>>> >> wrote:
>>>> >> >>> So as to not put the brakes on Paul's enthusiasm, can't it be
>>>> >> >>> done
>>>> in
>>>> >> >>> code restricted by #ifdefs ?  Paul could make progress, people
>>>> >> >>> could
>>>> >> >>> play with it if they have time. Even if it's not ready in both
>>>> >> >>> code
>>>> >> >>> and manual for next release, Paul's expressing enthusiasm for it
>>>> >> >>> and
>>>> >> >>> we should encourage that. And likely put it into release after
>>>> >> >>> next.
>>>> >> >>>
>>>> >> >>> If it can be done under #ifdef's, I don't even see any reason to
>>>> >> >>> discuss whether it's in next release. Do-ocracy.
>>>> >> >>>
>>>> >> >>> This was a benefit of doing beta releases -- they could be
>>>> >> >>> underdocumented and even have bugs!  So now we're talking about
>>>> >> >>> experimental releases -- that's the same thing Gale fought so
>>>> >> >>> hard
>>>> >> >>> against, and from which we decided to do only 'stable' releases.
>>>> >> >>> Nightlies are good but have a minuscule footpring compared to
>>>> >> >>> what
>>>> >> >>> betas did.
>>>> >> >>>
>>>> >> >>> - Vaughan
>>>> >> >>>
>>>> >> >>>
>>>> >> >>> On Mon, Apr 10, 2017 at 4:20 AM, Peter Sampson
>>>> >> >>> <[hidden email]> wrote:
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <
>>>> >> [hidden email]>
>>>> >> >>>> wrote:
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson
>>>> >> >>>>> <[hidden email]> wrote:
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>> On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews
>>>> >> >>>>>> <[hidden email]
>>>> >> >
>>>> >> >>>>>> wrote:
>>>> >> >>>>>>>
>>>> >> >>>>>>> On 5 April 2017 at 17:25, Paul Licameli <
>>>> [hidden email]>
>>>> >> wrote:
>>>> >> >>>>>>> > I may punt track panel refactoring for yet one more
>>>> >> >>>>>>> > release,
>>>> >> while
>>>> >> >>>>>>> > waiting
>>>> >> >>>>>>> > for James and Pokechu22 and David to finish their projects.
>>>> >> >>>>>>> > I
>>>> >> could
>>>> >> >>>>>>> > prepare
>>>> >> >>>>>>> > it during code freeze time as my "big bang" for the start
>>>> >> >>>>>>> > of
>>>> >> 2.2.1; as
>>>> >> >>>>>>> > it
>>>> >> >>>>>>> > was, I prepared a different big bang for 2.2.0, finishing
>>>> >> >>>>>>> > up
>>>> >> >>>>>>> > the
>>>> >> >>>>>>> > removal of
>>>> >> >>>>>>> > naked news.
>>>> >> >>>>>>> >
>>>> >> >>>>>>> > I may decide instead to have some fun doing a much delayed
>>>> >> feature,
>>>> >> >>>>>>> > the
>>>> >> >>>>>>> > magnifier!  (I don't think "fisheye" is an apt name, unless
>>>> >> >>>>>>> > it
>>>> >> also
>>>> >> >>>>>>> > makes a
>>>> >> >>>>>>> > magnification on the vertical scale.  Which might be a
>>>> >> >>>>>>> > useful
>>>> >> thing in
>>>> >> >>>>>>> > spectral selection, but is beyond the scope of what I
>>>> >> >>>>>>> > intend.)
>>>> >> >>>>>>> >
>>>> >> >>>>>>> > I will not submit the old prototype but reimplement its
>>>> >> >>>>>>> > user
>>>> >> interface
>>>> >> >>>>>>> > in
>>>> >> >>>>>>> > ways that require fewer changes to TrackPanel.cpp but more
>>>> >> >>>>>>> > to
>>>> >> the time
>>>> >> >>>>>>> > ruler.
>>>> >> >>>>>>> >
>>>> >> >>>>>>> > Details of how it might work are here:
>>>> >> >>>>>>> >
>>>> >> >>>>>>> > http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.
>>>> >> 27s_proposal_for_2.2.0
>>>> >> >>>>>>> >
>>>> >> >>>>>>> > An old picture of the fisheye is in the section above.
>>>> >> >>>>>>> > That
>>>> >> should
>>>> >> >>>>>>> > look
>>>> >> >>>>>>> > much the same.  Ignore the preference dialog.
>>>> >> >>>>>>>
>>>> >> >>>>>>> Is Punch-in or preparations therefore still on the cards for
>>>> >> >>>>>>> 2.2.0,
>>>> >> >>>>>>> Paul?
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>> Punch-in is *far* more important (a long-standing very popular
>>>> >> feature
>>>> >> >>>>>> request) than
>>>> >> >>>>>> Fish-eye.
>>>> >> >>>>>>
>>>> >> >>>>>> AnI don't think we have the time or the QA capacity for
>>>> >> >>>>>> Fish-eye
>>>> >> >>>>>> in
>>>> >> >>>>>> 2.2.0, especially if
>>>> >> >>>>>> we are still aiming for 3-4 month release cycles - it's
>>>> >> >>>>>> already
>>>> >> >>>>>> a
>>>> >> month
>>>> >> >>>>>> since we released
>>>> >> >>>>>> 2.1.3
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> A month?  It's not yet three weeks since 17 March!
>>>> >> >>>>>
>>>> >> >>>>> One banner feature or another implies some use of QA capacity.
>>>> >> >>>>> I
>>>> >> don't
>>>> >> >>>>> see how punch-and-roll would be any easier on QA instead.  What
>>>> >> >>>>> do
>>>> >> we expect
>>>> >> >>>>> will already take up capacity?  Testing the theming changes and
>>>> >> >>>>> MIDI
>>>> >> >>>>> playback?
>>>> >> >>>>
>>>> >> >>>>
>>>> >> >>>> What will take up a loit of my capacity is the large number of
>>>> >> documentation
>>>> >> >>>> changes in the Manual
>>>> >> >>>> for things like revised menu structure, thems, "record beside"
>>>> >> >>>> as
>>>> >> default.
>>>> >> >>>> As most of this is stuff that
>>>> >> >>>> is in flux it's not something I can or want to undertake right
>>>> >> >>>> now
>>>> -
>>>> >> so I am
>>>> >> >>>> collecting a host of P1s.
>>>> >> >>>> Plus I have to allocate some time for James to work with him on
>>>> >> potentially
>>>> >> >>>> trying to automate
>>>> >> >>>> image capture for the Manual.
>>>> >> >>>>
>>>> >> >>>> Gale is already overworked and is not in the best of health, I
>>>> >> understand.
>>>> >> >>>>
>>>> >> >>>> And Steve has less time for QA these days, undertaking other
>>>> >> >>>> tasks.
>>>> >> >>>>
>>>> >> >>>> Peter.
>>>> >> >>>>
>>>> >> >>>>>
>>>> >> >>>>>
>>>> >> >>>>> Fisheye is something that has waited a long time.  The
>>>> >> >>>>> difficult
>>>> >> parts,
>>>> >> >>>>> for distorted drawing of tracks and proper mouse interactions,
>>>> were
>>>> >> done in
>>>> >> >>>>> 2.1.1, lying latent.  Recoding the user interface should not be
>>>> >> >>>>> so
>>>> >> >>>>> difficult.  (Though agreeing on details is another thing.)
>>>> >> >>>>>
>>>> >> >>>>> Punch-and-roll recording is a nice to have, but Steve was
>>>> >> >>>>> persuading
>>>> >> us
>>>> >> >>>>> (and persuaded me) that the easy, minimal, destructive version
>>>> >> should not be
>>>> >> >>>>> shipped as a feature.  I have not thought through a good design
>>>> for
>>>> >> >>>>> something more complete.
>>>> >> >>>>>
>>>> >> >>>>> As I said before, it set me thinking about the problem of
>>>> >> >>>>> overlapping
>>>> >> >>>>> clips in a track, with automatic cross-fading, and some way to
>>>> >> >>>>> store
>>>> >> >>>>> multiple takes.  That might stand by itself as a useful
>>>> >> >>>>> feature,
>>>> >> preliminary
>>>> >> >>>>> to doing punch-and-roll right.  But there are lots of corner
>>>> >> >>>>> cases
>>>> >> >>>>> to
>>>> >> >>>>> consider, and some reorganization of the persistent data in
>>>> >> >>>>> .aup
>>>> >> projects,
>>>> >> >>>>> while fisheye entails no such difficulties.
>>>> >> >>>>>
>>>> >> >>>>> So, what's most demanded may not be what's most accessible.
>>>> >> >>>>> Or,
>>>> >> >>>>> you
>>>> >> can't
>>>> >> >>>>> always get what you want.
>>>> >> >>>>>
>>>> >> >>>>> Now I have the Rolling Stones stuck in my head.
>>>> >> >>>>>
>>>> >> >>>>> PRL
>>>> >> >>>>>
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>> > But before I do this, I want to agree on a better way to
>>>> >> >>>>>>> > share
>>>> >> >>>>>>> > binaries
>>>> >> >>>>>>> > built from branches with Peter if details must be debated.
>>>> >> >>>>>>> > I
>>>> >> >>>>>>> > do
>>>> >> not
>>>> >> >>>>>>> > want a
>>>> >> >>>>>>> > repetition of last summer's thrashing of the new scrubbing
>>>> >> feature,
>>>> >> >>>>>>> > polluting the master history with experiments that only get
>>>> >> reverted.
>>>> >> >>>>>>> > I
>>>> >> >>>>>>> > want to mature a topic branch and merge it into master only
>>>> >> >>>>>>> > when
>>>> >> we
>>>> >> >>>>>>> > are all
>>>> >> >>>>>>> > mostly satisfied with the design choices and the remainder
>>>> >> >>>>>>> > of
>>>> >> work is
>>>> >> >>>>>>> > just
>>>> >> >>>>>>> > bug fixing.
>>>> >> >>>>>>>
>>>> >> >>>>>>> Sounds good. What is the issue e.g. are you not keen to
>>>> >> >>>>>>> release
>>>> >> binaries
>>>> >> >>>>>>> for
>>>> >> >>>>>>> your topic branch?
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>> Mark Young dealt with this in the past with Time Record
>>>> >> >>>>>> testing
>>>> by
>>>> >> making
>>>> >> >>>>>> private
>>>> >> >>>>>> builds and posting them for me.
>>>> >> >>>>>>
>>>> >> >>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>>
>>>> >> >>>>>>> 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
>>>> >> >>>>>>> [hidden email]
>>>> >> >>>>>>> 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
>>>> >> >>>>>> [hidden email]
>>>> >> >>>>>> 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
>>>> >> >>>> [hidden email]
>>>> >> >>>> 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
>>>> >> >>> [hidden email]
>>>> >> >>> 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
>>>> >> >> [hidden email]
>>>> >> >> 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
>>>> >> > [hidden email]
>>>> >> > 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
>>>> >> [hidden email]
>>>> >> 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
>>>> [hidden email]
>>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Gale
Administrator
On 12 April 2017 at 23:21, Robert Hänggi <[hidden email]> wrote:
> Hi Gale
>
> Yes, it should be possible. Just a matter of getting used to it, I suppose.
> I even have an account there although not yet used for logging bugs.

OK. I look forward to seeing you there some time.


Gale

> 2017-04-12 22:59 GMT+02:00, Gale Andrews <[hidden email]>:
>> Hi Robert,
>>
>> Is Bugzilla accessible enough for you to create a bug report or add a
>> comment to an existing bug?
>>
>>
>>
>> Gale
>>
>>
>> On 12 April 2017 at 13:45, Robert Hänggi <[hidden email]> wrote:
>>> Hi Peter
>>>
>>> 2017-04-12 11:30 GMT+02:00, Peter Sampson
>>> <[hidden email]>:
>>>> On Wed, Apr 12, 2017 at 10:15 AM, Robert Hänggi <[hidden email]>
>>>> wrote:
>>>>
>>>>> 2017-04-12 9:03 GMT+02:00, Peter Sampson
>>>>> <[hidden email]>:
>>>>> >
>>>>> > +1
>>>>> >
>>>>> > Me too, I want the scores/hundreds of nighlies downloads to continue,
>>>>> > as
>>>>> I
>>>>> > staed before many of these people are testing/using - their silence is
>>>>> > an
>>>>> > indication that all is probably well with their uase of these builds.
>>>>> >
>>>>> > We cannot however apect all (any) of them to do the intricate testing
>>>>> > of
>>>>> > minute
>>>>> > changes in the commit log - thta remains down to us (unless we recruit
>>>>> more
>>>>> > formal testers).
>>>>> >
>>>>> Well, if you need help in the QA department, I'm willing to join in
>>>>> order to reduce the burden.
>>>>>
>>>>
>>>> Hi Robert,
>>>>
>>>> there are three main sorts of ongoing QA testing that we do:
>>>>
>>>> a) big new feature testing, for example: James' recent themes, the
>>>> upcoming
>>>> menu
>>>> changes, Paul's Scrubbing for 2.1.3.
>>>>
>>>> This is the sort of testing that Paul will require when he lets out his
>>>> Fish-eye into
>>>> the nightlies (or privaye build?) for QA examination - and involves
>>>> direct
>>>> feedback
>>>> to the developer (as we are currently doing with Themes for James on
>>>> Q2A).
>>>>
>>>> This can be quite exciting, working with the developer(s) on new
>>>> features.
>>>>
>>>
>>> Currently, I'm watching the menu changes and experiment with e.g. MIDI
>>> output.
>>> The latter is a long-term feature and probably not relevant to QA
>>> directly. However, I've noticed that a lot of playback/preview and
>>> other features are broken due to the recent changes in track/channel
>>> management are broken.
>>> For instance, try to swap the channels of a stereo track (drop-down
>>> menu)...
>>>
>>> I'm building Audacity on a fairly regular basis myself.
>>> I actually don't need the nightlies for that (except perhaps for
>>> testing on Linux, which I just started with).
>>>
>>>>
>>>> b) The Minutiae testing for the small changes.  This involves monitoring
>>>> the commit
>>>> logs and testing the changes, and testing around the changes, that are
>>>> made
>>>> there.
>>>> These changes can be tweaks/extensions to existing functionality or bug
>>>> fixes.
>>>> For bug fixes these are tracked on Bugzilla.
>>>>
>>>> This can be drudge-work but rewarding in its way as it helps us to crush
>>>> bugs.
>>>
>>> See above.
>>> I'm following the log changes with the command line (git log/show).
>>> I must now check out David's additions.
>>>>
>>>>
>>>> c) Then of course there's the testing of workflows etc. that we do for
>>>> Releases
>>>> Candidates (and KTT if we ever were to have those).
>>>
>>> At some time, I must also "invent" some accessibility workflows.
>>> A lot of it seems to become buggy since 2.2.0 development.
>>>
>>>>
>>>> This is essential and by its nature short-term and time critical.
>>>>
>>>>
>>>> So which sort of testing interests you - any of it, all of it?
>>>>
>>>
>>> All except strictly visual or mouse specific things
>>>
>>> Best
>>> Robert
>>>
>>>> Cheers,
>>>> Peter.
>>>>
>>>>
>>>>>
>>>>> Robert
>>>>>
>>>>> >
>>>>> >>
>>>>> >> Nightly builds are not betas, as Buanzo said.
>>>>> >>
>>>>> >> And if we have simultaneous KTT and experimental as
>>>>> >> James envisages, I think it would be confusing to call both
>>>>> >> of those "betas".
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> Gale
>>>>> >>
>>>>> >> >> If Fish-Eye is in KTT then I assume the intention would be for
>>>>> >> >> it to be in 2.2.0, all things being equal, but I have also heard
>>>>> >> >> that
>>>>> >> >> the interface is in need of work. The RM will have to decide if
>>>>> >> >> Fish-Eye is in 2.2.0 and if so ensure that resources are
>>>>> >> >> sufficient
>>>>> >> >> to document it properly.
>>>>> >> >>
>>>>> >> >>
>>>>> >> >> Gale
>>>>> >> >>
>>>>> >> >> On 11 April 2017 at 01:36, Vaughan Johnson <[hidden email]>
>>>>> >> wrote:
>>>>> >> >>> So as to not put the brakes on Paul's enthusiasm, can't it be
>>>>> >> >>> done
>>>>> in
>>>>> >> >>> code restricted by #ifdefs ?  Paul could make progress, people
>>>>> >> >>> could
>>>>> >> >>> play with it if they have time. Even if it's not ready in both
>>>>> >> >>> code
>>>>> >> >>> and manual for next release, Paul's expressing enthusiasm for it
>>>>> >> >>> and
>>>>> >> >>> we should encourage that. And likely put it into release after
>>>>> >> >>> next.
>>>>> >> >>>
>>>>> >> >>> If it can be done under #ifdef's, I don't even see any reason to
>>>>> >> >>> discuss whether it's in next release. Do-ocracy.
>>>>> >> >>>
>>>>> >> >>> This was a benefit of doing beta releases -- they could be
>>>>> >> >>> underdocumented and even have bugs!  So now we're talking about
>>>>> >> >>> experimental releases -- that's the same thing Gale fought so
>>>>> >> >>> hard
>>>>> >> >>> against, and from which we decided to do only 'stable' releases.
>>>>> >> >>> Nightlies are good but have a minuscule footpring compared to
>>>>> >> >>> what
>>>>> >> >>> betas did.
>>>>> >> >>>
>>>>> >> >>> - Vaughan
>>>>> >> >>>
>>>>> >> >>>
>>>>> >> >>> On Mon, Apr 10, 2017 at 4:20 AM, Peter Sampson
>>>>> >> >>> <[hidden email]> wrote:
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <
>>>>> >> [hidden email]>
>>>>> >> >>>> wrote:
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>> On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson
>>>>> >> >>>>> <[hidden email]> wrote:
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>> On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews
>>>>> >> >>>>>> <[hidden email]
>>>>> >> >
>>>>> >> >>>>>> wrote:
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> On 5 April 2017 at 17:25, Paul Licameli <
>>>>> [hidden email]>
>>>>> >> wrote:
>>>>> >> >>>>>>> > I may punt track panel refactoring for yet one more
>>>>> >> >>>>>>> > release,
>>>>> >> while
>>>>> >> >>>>>>> > waiting
>>>>> >> >>>>>>> > for James and Pokechu22 and David to finish their projects.
>>>>> >> >>>>>>> > I
>>>>> >> could
>>>>> >> >>>>>>> > prepare
>>>>> >> >>>>>>> > it during code freeze time as my "big bang" for the start
>>>>> >> >>>>>>> > of
>>>>> >> 2.2.1; as
>>>>> >> >>>>>>> > it
>>>>> >> >>>>>>> > was, I prepared a different big bang for 2.2.0, finishing
>>>>> >> >>>>>>> > up
>>>>> >> >>>>>>> > the
>>>>> >> >>>>>>> > removal of
>>>>> >> >>>>>>> > naked news.
>>>>> >> >>>>>>> >
>>>>> >> >>>>>>> > I may decide instead to have some fun doing a much delayed
>>>>> >> feature,
>>>>> >> >>>>>>> > the
>>>>> >> >>>>>>> > magnifier!  (I don't think "fisheye" is an apt name, unless
>>>>> >> >>>>>>> > it
>>>>> >> also
>>>>> >> >>>>>>> > makes a
>>>>> >> >>>>>>> > magnification on the vertical scale.  Which might be a
>>>>> >> >>>>>>> > useful
>>>>> >> thing in
>>>>> >> >>>>>>> > spectral selection, but is beyond the scope of what I
>>>>> >> >>>>>>> > intend.)
>>>>> >> >>>>>>> >
>>>>> >> >>>>>>> > I will not submit the old prototype but reimplement its
>>>>> >> >>>>>>> > user
>>>>> >> interface
>>>>> >> >>>>>>> > in
>>>>> >> >>>>>>> > ways that require fewer changes to TrackPanel.cpp but more
>>>>> >> >>>>>>> > to
>>>>> >> the time
>>>>> >> >>>>>>> > ruler.
>>>>> >> >>>>>>> >
>>>>> >> >>>>>>> > Details of how it might work are here:
>>>>> >> >>>>>>> >
>>>>> >> >>>>>>> > http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.
>>>>> >> 27s_proposal_for_2.2.0
>>>>> >> >>>>>>> >
>>>>> >> >>>>>>> > An old picture of the fisheye is in the section above.
>>>>> >> >>>>>>> > That
>>>>> >> should
>>>>> >> >>>>>>> > look
>>>>> >> >>>>>>> > much the same.  Ignore the preference dialog.
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> Is Punch-in or preparations therefore still on the cards for
>>>>> >> >>>>>>> 2.2.0,
>>>>> >> >>>>>>> Paul?
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>> Punch-in is *far* more important (a long-standing very popular
>>>>> >> feature
>>>>> >> >>>>>> request) than
>>>>> >> >>>>>> Fish-eye.
>>>>> >> >>>>>>
>>>>> >> >>>>>> AnI don't think we have the time or the QA capacity for
>>>>> >> >>>>>> Fish-eye
>>>>> >> >>>>>> in
>>>>> >> >>>>>> 2.2.0, especially if
>>>>> >> >>>>>> we are still aiming for 3-4 month release cycles - it's
>>>>> >> >>>>>> already
>>>>> >> >>>>>> a
>>>>> >> month
>>>>> >> >>>>>> since we released
>>>>> >> >>>>>> 2.1.3
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>> A month?  It's not yet three weeks since 17 March!
>>>>> >> >>>>>
>>>>> >> >>>>> One banner feature or another implies some use of QA capacity.
>>>>> >> >>>>> I
>>>>> >> don't
>>>>> >> >>>>> see how punch-and-roll would be any easier on QA instead.  What
>>>>> >> >>>>> do
>>>>> >> we expect
>>>>> >> >>>>> will already take up capacity?  Testing the theming changes and
>>>>> >> >>>>> MIDI
>>>>> >> >>>>> playback?
>>>>> >> >>>>
>>>>> >> >>>>
>>>>> >> >>>> What will take up a loit of my capacity is the large number of
>>>>> >> documentation
>>>>> >> >>>> changes in the Manual
>>>>> >> >>>> for things like revised menu structure, thems, "record beside"
>>>>> >> >>>> as
>>>>> >> default.
>>>>> >> >>>> As most of this is stuff that
>>>>> >> >>>> is in flux it's not something I can or want to undertake right
>>>>> >> >>>> now
>>>>> -
>>>>> >> so I am
>>>>> >> >>>> collecting a host of P1s.
>>>>> >> >>>> Plus I have to allocate some time for James to work with him on
>>>>> >> potentially
>>>>> >> >>>> trying to automate
>>>>> >> >>>> image capture for the Manual.
>>>>> >> >>>>
>>>>> >> >>>> Gale is already overworked and is not in the best of health, I
>>>>> >> understand.
>>>>> >> >>>>
>>>>> >> >>>> And Steve has less time for QA these days, undertaking other
>>>>> >> >>>> tasks.
>>>>> >> >>>>
>>>>> >> >>>> Peter.
>>>>> >> >>>>
>>>>> >> >>>>>
>>>>> >> >>>>>
>>>>> >> >>>>> Fisheye is something that has waited a long time.  The
>>>>> >> >>>>> difficult
>>>>> >> parts,
>>>>> >> >>>>> for distorted drawing of tracks and proper mouse interactions,
>>>>> were
>>>>> >> done in
>>>>> >> >>>>> 2.1.1, lying latent.  Recoding the user interface should not be
>>>>> >> >>>>> so
>>>>> >> >>>>> difficult.  (Though agreeing on details is another thing.)
>>>>> >> >>>>>
>>>>> >> >>>>> Punch-and-roll recording is a nice to have, but Steve was
>>>>> >> >>>>> persuading
>>>>> >> us
>>>>> >> >>>>> (and persuaded me) that the easy, minimal, destructive version
>>>>> >> should not be
>>>>> >> >>>>> shipped as a feature.  I have not thought through a good design
>>>>> for
>>>>> >> >>>>> something more complete.
>>>>> >> >>>>>
>>>>> >> >>>>> As I said before, it set me thinking about the problem of
>>>>> >> >>>>> overlapping
>>>>> >> >>>>> clips in a track, with automatic cross-fading, and some way to
>>>>> >> >>>>> store
>>>>> >> >>>>> multiple takes.  That might stand by itself as a useful
>>>>> >> >>>>> feature,
>>>>> >> preliminary
>>>>> >> >>>>> to doing punch-and-roll right.  But there are lots of corner
>>>>> >> >>>>> cases
>>>>> >> >>>>> to
>>>>> >> >>>>> consider, and some reorganization of the persistent data in
>>>>> >> >>>>> .aup
>>>>> >> projects,
>>>>> >> >>>>> while fisheye entails no such difficulties.
>>>>> >> >>>>>
>>>>> >> >>>>> So, what's most demanded may not be what's most accessible.
>>>>> >> >>>>> Or,
>>>>> >> >>>>> you
>>>>> >> can't
>>>>> >> >>>>> always get what you want.
>>>>> >> >>>>>
>>>>> >> >>>>> Now I have the Rolling Stones stuck in my head.
>>>>> >> >>>>>
>>>>> >> >>>>> PRL
>>>>> >> >>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> > But before I do this, I want to agree on a better way to
>>>>> >> >>>>>>> > share
>>>>> >> >>>>>>> > binaries
>>>>> >> >>>>>>> > built from branches with Peter if details must be debated.
>>>>> >> >>>>>>> > I
>>>>> >> >>>>>>> > do
>>>>> >> not
>>>>> >> >>>>>>> > want a
>>>>> >> >>>>>>> > repetition of last summer's thrashing of the new scrubbing
>>>>> >> feature,
>>>>> >> >>>>>>> > polluting the master history with experiments that only get
>>>>> >> reverted.
>>>>> >> >>>>>>> > I
>>>>> >> >>>>>>> > want to mature a topic branch and merge it into master only
>>>>> >> >>>>>>> > when
>>>>> >> we
>>>>> >> >>>>>>> > are all
>>>>> >> >>>>>>> > mostly satisfied with the design choices and the remainder
>>>>> >> >>>>>>> > of
>>>>> >> work is
>>>>> >> >>>>>>> > just
>>>>> >> >>>>>>> > bug fixing.
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> Sounds good. What is the issue e.g. are you not keen to
>>>>> >> >>>>>>> release
>>>>> >> binaries
>>>>> >> >>>>>>> for
>>>>> >> >>>>>>> your topic branch?
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>> Mark Young dealt with this in the past with Time Record
>>>>> >> >>>>>> testing
>>>>> by
>>>>> >> making
>>>>> >> >>>>>> private
>>>>> >> >>>>>> builds and posting them for me.
>>>>> >> >>>>>>
>>>>> >> >>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>>
>>>>> >> >>>>>>> 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
>>>>> >> >>>>>>> [hidden email]
>>>>> >> >>>>>>> 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
>>>>> >> >>>>>> [hidden email]
>>>>> >> >>>>>> 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
>>>>> >> >>>> [hidden email]
>>>>> >> >>>> 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
>>>>> >> >>> [hidden email]
>>>>> >> >>> 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
>>>>> >> >> [hidden email]
>>>>> >> >> 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
>>>>> >> > [hidden email]
>>>>> >> > 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
>>>>> >> [hidden email]
>>>>> >> 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
>>>>> [hidden email]
>>>>> 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
>>> [hidden email]
>>> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
12
Loading...