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

Magnifier ("fisheye") for 2.2.0!

Paul Licameli
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.

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.

PRL


------------------------------------------------------------------------------
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 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?


> 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?



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!

Peter Sampson-2


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

 


> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Paul Licameli


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?

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Gale
Administrator
On 5 April 2017 at 19:35, 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.

A non-destructive punch and roll would I guess be more consuming
in QA time than Fish Eye, but I don't see the return on QA time
spent on Fish Eye as very great.


> What do we expect will already take up capacity?  Testing the theming
> changes and MIDI playback?
>
> 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.)

That's why I wondered if you might have some extra capacity for
preparations for punch-in.


> 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 am on record as not agreeing with that view (though of course it depends
what the minimal version is like). We do have an Undo button.

I think "record beside" as default raises the importance of punch-in. It makes
punch-in look even more like a missing feature than it did.


>   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.

Does preparatory work on punch-and-roll help with providing pre and post roll
for Sound Activated Recording? That is a very obvious feature lack too.


Gale


> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

MartynShaw
In reply to this post by Paul Licameli
Hi

Do-er decides here, I think.  Paul, if you want to do 'Magnifier' then please go for it!  I'd like to see it.

I didn't read the Proposal page, tldr.

TTFN
Martyn

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.

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.

PRL


------------------------------------------------------------------------------
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!

Peter Sampson-2
In reply to this post by Paul Licameli


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Vaughan Johnson-4
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Vaughan Johnson-4
I meant "footprint" of course. -- V

On Mon, Apr 10, 2017 at 5:36 PM, 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
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 Vaughan Johnson-4
#ifdef code in Experimental.h historically tends to languish. Could
Fish-Eye be an experimental module?

I am not opposed to the concept of "experimental releases" as have
been recently proposed. I assume they will be advertised as
undocumented or mostly so and as not having been through an official
QA process (except for such features that are in both KTT and
experimental release). I expect if anything that experimental releases
could be more stable than the Betas were.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Vaughan Johnson-4
On Mon, Apr 10, 2017 at 7:44 PM, Gale Andrews <[hidden email]> wrote:
> #ifdef code in Experimental.h historically tends to languish.

It should be on, i.e., 1 , for alphas.

And betas (KTT, experimentals, whatever called). I don't see why
proliferate names for fine distinctions among the same idea. We
stopped doing betas because it was supposedly too complicated to have
'beta' and 'release'.

Historically (longer ago), they did not languish. We can fix whatever
current languishing tendency has come to be.


>Could
> Fish-Eye be an experimental module?

Up to Paul to find out whether modules are up to it. Or how he wants to do it.


>
> I am not opposed to the concept of "experimental releases" as have
> been recently proposed. I assume they will be advertised as
> undocumented or mostly so and as not having been through an official
> QA process (except for such features that are in both KTT and
> experimental release). I expect if anything that experimental releases
> could be more stable than the Betas were.

Why? Please, I really don't understand the difference.


Audacity made more of it's name and popularity , earlier on, with
betas, than finals or "stable", iirc.

"Beta" used to be common nomenclature for most software.. And
differentiated.  Both release and beta were available publicly. Alphas
were internal-only.  I don't see why we need to try to reinvent
nomenclature.


- V


>
> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Paul Licameli
In reply to this post by Gale


On Mon, Apr 10, 2017 at 10:44 PM, Gale Andrews <[hidden email]> wrote:
#ifdef code in Experimental.h historically tends to languish. Could
Fish-Eye be an experimental module?

"Module," "plug-in," I have heard these terms a lot and honestly don't understand them.  Before we can have plug-ins we must have the "socket" to plug into.  That is we need Audacity to be a host with a defined protocol for the plug-in to follow.  But I know of no such thing existing, at the level of detail needed.

PRL
 

I am not opposed to the concept of "experimental releases" as have
been recently proposed. I assume they will be advertised as
undocumented or mostly so and as not having been through an official
QA process (except for such features that are in both KTT and
experimental release). I expect if anything that experimental releases
could be more stable than the Betas were.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Gale
Administrator
On 11 April 2017 at 19:06, Paul Licameli <[hidden email]> wrote:

>
>
> On Mon, Apr 10, 2017 at 10:44 PM, Gale Andrews <[hidden email]>
> wrote:
>>
>> #ifdef code in Experimental.h historically tends to languish. Could
>> Fish-Eye be an experimental module?
>
>
> "Module," "plug-in," I have heard these terms a lot and honestly don't
> understand them.  Before we can have plug-ins we must have the "socket" to
> plug into.  That is we need Audacity to be a host with a defined protocol
> for the plug-in to follow.

I think Leland has the same view, which seems to be espoused too
on this very old Wiki page:
http://wiki.audacityteam.org/wiki/Modular_Architecture_Initiative .

Of the "modules" we have now, I am only somewhat familiar with
mod-nyq-bench.



Gale


> But I know of no such thing existing, at the level of detail needed.
>
> PRL
>
>>
>>
>> I am not opposed to the concept of "experimental releases" as have
>> been recently proposed. I assume they will be advertised as
>> undocumented or mostly so and as not having been through an official
>> QA process (except for such features that are in both KTT and
>> experimental release). I expect if anything that experimental releases
>> could be more stable than the Betas were.
>>
>> 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
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 Vaughan Johnson-4
On 11 April 2017 at 04:57, Vaughan Johnson <[hidden email]> wrote:
> On Mon, Apr 10, 2017 at 7:44 PM, Gale Andrews <[hidden email]> wrote:
>> #ifdef code in Experimental.h historically tends to languish.
>
> It should be on, i.e., 1 , for alphas.

There is a lot there that is very incomplete or abandoned by
the author. I think resurrection would have to be selective.

There is a page here about these features but it has not been
kept updated:
http://wiki.audacityteam.org/wiki/Experimental_Features .


> And betas (KTT, experimentals, whatever called). I don't see why
> proliferate names for fine distinctions among the same idea. We
> stopped doing betas because it was supposedly too complicated to have
> 'beta' and 'release'.

It's more work. But as you know, James now sees such builds
as a way of getting more user involvement and testing.


> Historically (longer ago), they did not languish. We can fix whatever
> current languishing tendency has come to be.
>
>
>>Could
>> Fish-Eye be an experimental module?
>
> Up to Paul to find out whether modules are up to it. Or how he wants to do it.
>
>
>>
>> I am not opposed to the concept of "experimental releases" as have
>> been recently proposed. I assume they will be advertised as
>> undocumented or mostly so and as not having been through an official
>> QA process (except for such features that are in both KTT and
>> experimental release). I expect if anything that experimental releases
>> could be more stable than the Betas were.
>
> Why? Please, I really don't understand the difference.

I think one reason was that the Audacity code itself was
very unstable through the mid-period Betas. It wasn't
until 1.3.13 after much bug fixing that I think we got back
to the stability that 1.3.3/1.3.4 had.

James has told me he sees "experimental" as containing new
features that are not expected to be implemented until the
release after next.

By contrast it is expected that new features in KTT will mainly
make it into the next release. So I assume KTT are likely to be
more stable than experimentals.

However I think James sees it that because experimentals are
"auteur" builds (even if they rollup other auteur's features) that
the "auteur" will be personally invested in achieving stability
even in these.



> Audacity made more of it's name and popularity , earlier on, with
> betas, than finals or "stable", iirc.
>
> "Beta" used to be common nomenclature for most software.. And
> differentiated.  Both release and beta were available publicly. Alphas
> were internal-only.  I don't see why we need to try to reinvent
> nomenclature.

I'm opposed to alphas (nightly builds) being internal only.
We want more users involved in those too.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Peter Sampson-2


On Wed, Apr 12, 2017 at 3:35 AM, Gale Andrews <[hidden email]> wrote:
On 11 April 2017 at 04:57, Vaughan Johnson <[hidden email]> wrote:
> On Mon, Apr 10, 2017 at 7:44 PM, Gale Andrews <[hidden email]> wrote:
>> #ifdef code in Experimental.h historically tends to languish.
>
> It should be on, i.e., 1 , for alphas.

There is a lot there that is very incomplete or abandoned by
the author. I think resurrection would have to be selective.

There is a page here about these features but it has not been
kept updated:
http://wiki.audacityteam.org/wiki/Experimental_Features .


> And betas (KTT, experimentals, whatever called). I don't see why
> proliferate names for fine distinctions among the same idea. We
> stopped doing betas because it was supposedly too complicated to have
> 'beta' and 'release'.

It's more work. But as you know, James now sees such builds
as a way of getting more user involvement and testing.


> Historically (longer ago), they did not languish. We can fix whatever
> current languishing tendency has come to be.
>
>
>>Could
>> Fish-Eye be an experimental module?
>
> Up to Paul to find out whether modules are up to it. Or how he wants to do it.
>
>
>>
>> I am not opposed to the concept of "experimental releases" as have
>> been recently proposed. I assume they will be advertised as
>> undocumented or mostly so and as not having been through an official
>> QA process (except for such features that are in both KTT and
>> experimental release). I expect if anything that experimental releases
>> could be more stable than the Betas were.
>
> Why? Please, I really don't understand the difference.

I think one reason was that the Audacity code itself was
very unstable through the mid-period Betas. It wasn't
until 1.3.13 after much bug fixing that I think we got back
to the stability that 1.3.3/1.3.4 had.

James has told me he sees "experimental" as containing new
features that are not expected to be implemented until the
release after next.

By contrast it is expected that new features in KTT will mainly
make it into the next release. So I assume KTT are likely to be
more stable than experimentals.

However I think James sees it that because experimentals are
"auteur" builds (even if they rollup other auteur's features) that
the "auteur" will be personally invested in achieving stability
even in these.



> Audacity made more of it's name and popularity , earlier on, with
> betas, than finals or "stable", iirc.
>
> "Beta" used to be common nomenclature for most software.. And
> differentiated.  Both release and beta were available publicly. Alphas
> were internal-only.  I don't see why we need to try to reinvent
> nomenclature.

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
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).
 

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Robert Hänggi
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.

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Peter Sampson-2


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.


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.


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).

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?

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Magnifier ("fisheye") for 2.2.0!

Robert Hänggi
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

James Crook
In reply to this post by Peter Sampson-2
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 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


--James.




------------------------------------------------------------------------------
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: Nightlies (was: Magnifier ("fisheye") for 2.2.0!)

Peter Sampson-2


On Wed, Apr 12, 2017 at 1:51 PM, 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 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

Sounds like a reasonable plan.

So where do I sign up?   ;-))



--James.




------------------------------------------------------------------------------
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...