[Audacity-devel] Magnifier ("fisheye") for 2.2.0!

Is Punch-in or preparations therefore still on the cards for 2.2.0, Paul?

Post by Paul Licameli
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

Peter Sampson

2017-04-05 17:58:02 UTC

Post by Paul Licameli
I may punt track panel refactoring for yet one more release, while

waiting

Post by Paul Licameli
for James and Pokechu22 and David to finish their projects. I could

prepare

Post by Paul Licameli
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

Post by Paul Licameli
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

Post by Paul Licameli
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.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
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

Post by Paul Licameli
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

Post by Paul Licameli
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

Post by Paul Licameli
mostly satisfied with the design choices and the remainder of work is

just

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

Post by Paul Licameli
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-04-05 18:35:55 UTC

On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson <

Post by Paul Licameli
I may punt track panel refactoring for yet one more release, while

waiting

Post by Paul Licameli
for James and Pokechu22 and David to finish their projects. I could

prepare

Post by Paul Licameli
it during code freeze time as my "big bang" for the start of 2.2.1; as

Post by Paul Licameli
was, I prepared a different big bang for 2.2.0, finishing up the

removal of

Post by Paul Licameli
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

Post by Paul Licameli
ways that require fewer changes to TrackPanel.cpp but more to the time
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.27s

_proposal_for_2.2.0

Post by Paul Licameli
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

Post by Paul Licameli
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

all

Post by Paul Licameli
mostly satisfied with the design choices and the remainder of work is

just

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

------------------------------------------------------------
------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-04-05 22:12:51 UTC

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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.

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

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

Post by Paul Licameli
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

Post by Paul Licameli
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

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

Post by Gale Andrews
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Peter Sampson

2017-04-10 11:20:38 UTC

Post by Paul Licameli
I may punt track panel refactoring for yet one more release, while

waiting

Post by Paul Licameli
for James and Pokechu22 and David to finish their projects. I could

prepare

Post by Paul Licameli
it during code freeze time as my "big bang" for the start of 2.2.1; as

Post by Paul Licameli
was, I prepared a different big bang for 2.2.0, finishing up the

removal of

Post by Paul Licameli
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

Post by Paul Licameli
ways that require fewer changes to TrackPanel.cpp but more to the time
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.27s

_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above. That should

look

Post by Paul Licameli
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

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.

Post by Paul Licameli
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

Post by Paul Licameli
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

Post by Paul Licameli
repetition of last summer's thrashing of the new scrubbing feature,
polluting the master history with experiments that only get reverted.

Post by Paul Licameli
want to mature a topic branch and merge it into master only when we

are all

Post by Paul Licameli
mostly satisfied with the design choices and the remainder of work is

just

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

Vaughan Johnson

2017-04-11 00:36:07 UTC

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

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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

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.

Post by Paul Licameli
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

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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Vaughan Johnson

2017-04-11 00:37:06 UTC

I meant "footprint" of course. -- V

Post by Vaughan Johnson
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

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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

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.

Post by Paul Licameli
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

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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-04-11 02:44:37 UTC

#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

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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

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.

Post by Paul Licameli
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

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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Vaughan Johnson

2017-04-11 03:57:34 UTC

Post by Gale Andrews
#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.

Post by Gale Andrews
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.

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

Post by Gale Andrews
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

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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

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.

Post by Paul Licameli
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

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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-04-12 02:35:02 UTC

Post by Gale Andrews
#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 .

Post by Vaughan Johnson
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.

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

Post by Gale Andrews
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.

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.

Post by Vaughan Johnson
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

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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

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.

Post by Paul Licameli
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

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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Peter Sampson

2017-04-12 07:03:37 UTC

Post by Gale Andrews
#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
http://wiki.audacityteam.org/wiki/Experimental_Features .

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

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

Post by Gale Andrews
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.

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.

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

Post by Gale Andrews
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

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

Post by Paul Licameli
I may punt track panel refactoring for yet one more release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects. I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I intend.)
I will not submit the old prototype but reimplement its user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above. That

should

Post by Paul Licameli
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

Post by Peter Sampson
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

Post by Peter Sampson
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What do

we expect

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

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions, were

done in

Post by Paul Licameli
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

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

Post by Paul Licameli
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

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible. Or, you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder of

work is

Post by Paul Licameli
just
bug fixing.

Sounds good. What is the issue e.g. are you not keen to release

binaries

Post by Gale Andrews
for
your topic branch?

Mark Young dealt with this in the past with Time Record testing by

making

Post by Peter Sampson
private
builds and posting them for me.

Post by Gale Andrews
Gale
------------------------------------------------------------

------------------

Post by Gale Andrews
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

------------------

Post by Peter Sampson
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

------------------

Post by Vaughan Johnson
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

Robert Hänggi

2017-04-12 09:15:03 UTC

Post by Peter Sampson
+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

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews

Post by Paul Licameli
I may punt track panel refactoring for yet one more release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects. I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I intend.)
I will not submit the old prototype but reimplement its user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above. That

should

Post by Paul Licameli
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What do

we expect

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

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions, were

done in

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

preliminary

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible. Or, you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder of

work is

Post by Paul Licameli
just
bug fixing.

Sounds good. What is the issue e.g. are you not keen to release

binaries

Post by Gale Andrews
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.

Post by Gale Andrews
Gale
------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

Post by Paul Licameli
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Peter Sampson

2017-04-12 09:30:47 UTC

Post by Robert HÃ¤nggi

Post by Peter Sampson
+1
Me too, I want the scores/hundreds of nighlies downloads to continue, as

Post by Peter Sampson
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

Post by Peter Sampson
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.

Post by Robert HÃ¤nggi
Robert

Post by Vaughan Johnson
So as to not put the brakes on Paul's enthusiasm, can't it be done

Post by Vaughan Johnson
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

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews

On 5 April 2017 at 17:25, Paul Licameli <

Post by Paul Licameli
I may punt track panel refactoring for yet one more release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects. I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I intend.)
I will not submit the old prototype but reimplement its user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above. That

should

Post by Paul Licameli
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What do

we expect

Post by Paul Licameli
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

Post by Gale Andrews
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.

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions,

were

Post by Gale Andrews
done in

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

Post by Paul Licameli
shipped as a feature. I have not thought through a good design

for

Post by Paul Licameli
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

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible. Or, you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder of

work is

Post by Paul Licameli
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

Post by Gale Andrews
making

private
builds and posting them for me.

Gale
------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

Robert Hänggi

2017-04-12 12:45:13 UTC

Hi Peter

2017-04-12 9:03 GMT+02:00, Peter Sampson

Post by Peter Sampson
+1
Me too, I want the scores/hundreds of nighlies downloads to continue, as

Post by Peter Sampson
formal testers).

Well, if you need help in the QA department, I'm willing to join in
order to reduce the burden.

Hi Robert,
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).

Post by Peter Sampson
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.

Post by Peter Sampson
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.

Post by Peter Sampson
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

Post by Peter Sampson
Cheers,
Peter.

Robert

Post by Vaughan Johnson
So as to not put the brakes on Paul's enthusiasm, can't it be done

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews

On 5 April 2017 at 17:25, Paul Licameli <

Post by Paul Licameli
I may punt track panel refactoring for yet one more release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects.
I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I intend.)
I will not submit the old prototype but reimplement its user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above. That

should

Post by Paul Licameli
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What do

we expect

Post by Paul Licameli
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

Post by Gale Andrews
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.

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions,

were

Post by Gale Andrews
done in

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

Post by Paul Licameli
shipped as a feature. I have not thought through a good design

for

preliminary

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible. Or, you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only
when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder of

work is

Post by Paul Licameli
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

Post by Gale Andrews
making

private
builds and posting them for me.

Gale
------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

Gale Andrews

2017-04-12 20:59:32 UTC

Hi Robert,

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

Gale

Post by Robert HÃ¤nggi
Hi Peter

2017-04-12 9:03 GMT+02:00, Peter Sampson

Post by Peter Sampson
+1
Me too, I want the scores/hundreds of nighlies downloads to continue, as

Post by Peter Sampson
formal testers).

Well, if you need help in the QA department, I'm willing to join in
order to reduce the burden.

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

See above.
I'm following the log changes with the command line (git log/show).
I must now check out David's additions.

Post by Peter Sampson
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.

Post by Peter Sampson
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

Post by Peter Sampson
Cheers,
Peter.

Robert

Post by Vaughan Johnson
So as to not put the brakes on Paul's enthusiasm, can't it be done

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews

On 5 April 2017 at 17:25, Paul Licameli <

Post by Paul Licameli
I may punt track panel refactoring for yet one more release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects.
I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless
it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I
intend.)
I will not submit the old prototype but reimplement its user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above. That

should

Post by Paul Licameli
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What do

we expect

Post by Paul Licameli
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

Post by Gale Andrews
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.

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions,

were

Post by Gale Andrews
done in

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

Post by Paul Licameli
shipped as a feature. I have not thought through a good design

for

preliminary

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible. Or, you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only
when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder of

work is

Post by Paul Licameli
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

Post by Gale Andrews
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Robert Hänggi

2017-04-12 22:21:31 UTC

Hi Gale

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

Robert

Post by Peter Sampson
Hi Robert,
Is Bugzilla accessible enough for you to create a bug report or add a
comment to an existing bug?
Gale

Post by Robert HÃ¤nggi
Hi Peter
2017-04-12 11:30 GMT+02:00, Peter Sampson

2017-04-12 9:03 GMT+02:00, Peter Sampson

Post by Peter Sampson
+1
Me too, I want the scores/hundreds of nighlies downloads to continue, as

Post by Peter Sampson
formal testers).

Well, if you need help in the QA department, I'm willing to join in
order to reduce the burden.

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

See above.
I'm following the log changes with the command line (git log/show).
I must now check out David's additions.

Post by Peter Sampson
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.

Post by Peter Sampson
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

Post by Peter Sampson
Cheers,
Peter.

Robert

Post by Vaughan Johnson
So as to not put the brakes on Paul's enthusiasm, can't it be done

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews

On 5 April 2017 at 17:25, Paul Licameli <

Post by Paul Licameli
I may punt track panel refactoring for yet one more
release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects.
I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start
of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless
it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a
useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I
intend.)
I will not submit the old prototype but reimplement its
user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more
to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above.
That

should

Post by Paul Licameli
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What do

we expect

Post by Paul Licameli
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

Post by Gale Andrews
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.

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions,

were

Post by Gale Andrews
done in

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

Post by Paul Licameli
shipped as a feature. I have not thought through a good design

for

Post by Paul Licameli
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

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible.
Or,
you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only
when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder
of

work is

Post by Paul Licameli
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

Post by Gale Andrews
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-04-12 23:41:43 UTC

Post by Robert HÃ¤nggi
Hi Gale
Yes, it should be possible. Just a matter of getting used to it, I suppose.
I even have an account there although not yet used for logging bugs.

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

Gale

Post by Robert HÃ¤nggi

Post by Peter Sampson
Hi Robert,
Is Bugzilla accessible enough for you to create a bug report or add a
comment to an existing bug?
Gale

Post by Robert HÃ¤nggi
Hi Peter
2017-04-12 11:30 GMT+02:00, Peter Sampson

2017-04-12 9:03 GMT+02:00, Peter Sampson

Post by Peter Sampson
+1
Me too, I want the scores/hundreds of nighlies downloads to continue, as

Post by Peter Sampson
formal testers).

Well, if you need help in the QA department, I'm willing to join in
order to reduce the burden.

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

See above.
I'm following the log changes with the command line (git log/show).
I must now check out David's additions.

Post by Peter Sampson
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.

Post by Peter Sampson
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

Post by Peter Sampson
Cheers,
Peter.

Robert

Post by Vaughan Johnson
So as to not put the brakes on Paul's enthusiasm, can't it be done

On Wed, Apr 5, 2017 at 7:35 PM, Paul Licameli <

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

On Wed, Apr 5, 2017 at 6:50 PM, Gale Andrews

On 5 April 2017 at 17:25, Paul Licameli <

Post by Paul Licameli
I may punt track panel refactoring for yet one more
release,

while

Post by Paul Licameli
waiting
for James and Pokechu22 and David to finish their projects.
I

could

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start
of

2.2.1; as

Post by Paul Licameli
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,

Post by Paul Licameli
the
magnifier! (I don't think "fisheye" is an apt name, unless
it

also

Post by Paul Licameli
makes a
magnification on the vertical scale. Which might be a
useful

thing in

Post by Paul Licameli
spectral selection, but is beyond the scope of what I
intend.)
I will not submit the old prototype but reimplement its
user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more
to

the time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
An old picture of the fisheye is in the section above.
That

should

Post by Paul Licameli
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

Post by Paul Licameli
see how punch-and-roll would be any easier on QA instead. What
do

we expect

Post by Paul Licameli
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

Post by Gale Andrews
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.

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult

parts,

Post by Paul Licameli
for distorted drawing of tracks and proper mouse interactions,

were

Post by Gale Andrews
done in

Post by Paul Licameli
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

Post by Paul Licameli
(and persuaded me) that the easy, minimal, destructive version

should not be

Post by Paul Licameli
shipped as a feature. I have not thought through a good design

for

Post by Paul Licameli
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

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible.
Or,
you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing

feature,

Post by Paul Licameli
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
I
want to mature a topic branch and merge it into master only
when

Post by Paul Licameli
are all
mostly satisfied with the design choices and the remainder
of

work is

Post by Paul Licameli
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

Post by Gale Andrews
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
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2017-04-12 12:51:14 UTC

Post by Gale Andrews
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.

Peter Sampson

2017-04-12 13:09:17 UTC

Post by James Crook

Post by Gale Andrews
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

Post by Peter Sampson
stated before many of these people are testing/using - their silence is

Post by Peter Sampson
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? * ;-))

Post by James Crook
--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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2017-04-12 20:48:47 UTC

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

Post by James Crook

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

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

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

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

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

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

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

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

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

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

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

Gale

Paul Licameli

2017-04-11 18:06:18 UTC

Post by Gale Andrews
#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

Post by Gale Andrews
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

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

Post by 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

Post by Paul Licameli
prepare
it during code freeze time as my "big bang" for the start of

2.2.1; as

Post by Paul Licameli
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

Post by Paul Licameli
spectral selection, but is beyond the scope of what I intend.)
I will not submit the old prototype but reimplement its user

interface

Post by Paul Licameli
in
ways that require fewer changes to TrackPanel.cpp but more to the

time

Post by Paul Licameli
ruler.
http://wiki.audacityteam.org/wiki/Proposal_Fish_Eye#Paul.

27s_proposal_for_2.2.0

Post by Paul Licameli
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

Post by Peter Sampson
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

Post by Paul Licameli
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

Post by Peter Sampson
changes in the Manual
for things like revised menu structure, thems, "record beside" as

default.

Post by Peter Sampson
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

Post by Peter Sampson
collecting a host of P1s.
Plus I have to allocate some time for James to work with him on

potentially

Post by Peter Sampson
trying to automate
image capture for the Manual.
Gale is already overworked and is not in the best of health, I

understand.

Post by Peter Sampson
And Steve has less time for QA these days, undertaking other tasks.
Peter.

Post by Paul Licameli
Fisheye is something that has waited a long time. The difficult parts,
for distorted drawing of tracks and proper mouse interactions, were

done in

not be

preliminary

Post by Paul Licameli
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,

Post by Paul Licameli
while fisheye entails no such difficulties.
So, what's most demanded may not be what's most accessible. Or, you

can't

Post by Paul Licameli
always get what you want.
Now I have the Rolling Stones stuck in my head.
PRL

Post by Paul Licameli
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

Post by Paul Licameli
want a
repetition of last summer's thrashing of the new scrubbing feature,
polluting the master history with experiments that only get

reverted.

Post by Paul Licameli
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

Post by Paul Licameli
just
bug fixing.

Sounds good. What is the issue e.g. are you not keen to release

binaries

Post by Gale Andrews
for
your topic branch?

Mark Young dealt with this in the past with Time Record testing by

making

Post by Peter Sampson
private
builds and posting them for me.

Post by Gale Andrews
Gale
------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

------------------------------------------------------------

------------------

Gale Andrews

2017-04-12 02:06:59 UTC

Post by Gale Andrews
#ifdef code in Experimental.h historically tends to languish. Could
Fish-Eye be an experimental module?

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

Post by Paul Licameli
But I know of no such thing existing, at the level of detail needed.
PRL

Post by Paul Licameli
On Wed, Apr 5, 2017 at 1:58 PM, Peter Sampson

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

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.

Post by Paul Licameli
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

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

------------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw

2017-04-05 23:34:00 UTC