[Audacity-devel] Planning Ahead for 2.1.4

Hi,

I have a further Timer Recording enhancement I'm working on that will allow
processes to be executed at different stages of the Timer Recording. It
would for example allow a user to launch a Web stream and then kill it
after the recording. I'd like to submit it when ready for Audacity vNext.

Mark

Post by James Crook
We're probably coming to a quieter spell in 2.1.3 development as we
spend time clearing bugs, getting signing of executables sorted, the
manual updated, more testing and heading for freeze and translation on
9th Oct (with semifreddo 1st October).
Looking ahead to 2.1.4 we should be thinking about what we want to have
in that release. We should be doing some thinking right now, and maybe
some coding, in readiness for that release cycle. We could perhaps take
on something that would justify a 2.2.0 name.
- Vaughan's 2-in-1 (touch screen mode)
- Roger's MIDI playback/alignment code
- Paul's FishEye work (localised track zoom)
With any of these I could also do some work on plug-in preferences,
working with the developer, so that the new feature is as a module, if
team think that is a good idea.
Also for Audacity 2.1.4/2.2.0 I am expecting that we'll do more cherry
picking from DarkAudacity 2.1.3x features. I am expecting for example
that we will update the icons to the more modern look, still with a
light theme, and with the dark theme as an option. Even if we
can't/don't do one of the 2.2.0 initiatives, the new look should be good
for Audacity publicity, and show that the project is active/vibrant. It
would be nice to do a "dot zero" release, but we don't have to. There
will be plenty enough without.
We also have code from MC Sharma for new effects, and we have code from
Bill Unruh for a spectrogram display that preserves peak heights better,
and that distinguishes interpolated points from calculated. I'm very
concerned that we have contributors whose code sits parked and unused,
often because of unresolved differences in ideas about how to proceed.
We are obviously not going to accept every piece of code offered into
Audacity, but it really is wasteful to have code, like Roger's MIDI
code, written but not reaching users by any route at all.
The new effects and Bill's spectrogram code are code I would like to try
with DarkAudacity users. That gets the code to some users, and maybe
encourages Audacity to use the ideas. I've suggested the MIDI code for
DarkAudacity 2.1.4x too, and that seems to have sparked some interest in
having it for Audacity 2.1.4.
Overall I think now is a good time to have some discussion here about
2.1.4 (let us keep calling it 2.1.4 until we have definite agreement we
are going for 2.2.0). So with this post I am opening a thread for
discussing what we do/plan with 2.1.4. It isn't so helpful to discuss
"Would be nice" features if we don't have code or developers
engaged/interested - but all the features I have mentioned here have
code to back them up.
--James.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

James Crook

2016-09-04 10:39:55 UTC

Post by Mark Young
Hi,
I have a further Timer Recording enhancement I'm working on that will allow
processes to be executed at different stages of the Timer Recording. It
would for example allow a user to launch a Web stream and then kill it
after the recording. I'd like to submit it when ready for Audacity vNext.

Please say more about it. We currently have a policy of not opening
TCP/IP connections from Audacity itself (opening a browser is OK),
because we don't have the developer bandwidth to audit TCP/IP code
(including within wxWidgets) to the levels that would be needed. So I
assume this is wxShell()'ing a script. Please say a bit more. Where
will the script itself be stored?

--James.

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

Vaughan Johnson

2016-09-04 12:30:10 UTC

James: "...we should be thinking about what we want to have in that
release. We should be doing some thinking right now,"

Writing class? "should be ... thinking" twice in 2 consecutive sentences?
yet ur comfortable complaining about my using 'u'.

===

James: "...and maybe
some coding, in readiness for that release cycle"

Hum, as we've done for years, w/ #pragmas. ur not suggesting anything new
, James.

===

James: "Possibilities for a 2.2.0 designation include:

- Vaughan's 2-in-1 (touch screen mode)
"

It's spelled 2n1. i'm certainly not motivated these days , either by
morale (ongoing attacks at me) or $.

-- but repeated thx to Peter & Gale for defending me.

===

Thx,
Vaughan

David Engebretson Jr

2016-09-04 16:29:09 UTC

As a daily user of Audacity, and an aspiring midi user, and also an aspiring
Audacity developer, I vote for Roger's midi. Especially if it is something
that will give more options to the blindness community and the ever
expanding availability of accessible DAW's.

If there is a path to getting ASIO built in, I will be happy to use my
gentle demeanor to approach Steinberg regarding licensing. Please, to those
who have been nay sayers in the past, I've heard your repetitive negativity
regarding ASIO and it's logged in my consciousness. I don't want to hear
the same old negative "general" commentary regarding ASIO ish's. Maybe some
background into why there is such repetitive negativity regarding the
situation would be helpful, constructive critique of plus's and minus's
would be helpful.

Peace,
David
***@comcast.net

-----Original Message-----
From: James Crook
Sent: Sunday, September 04, 2016 3:09 AM
To: Audacity-Devel list
Subject: [Audacity-devel] Planning Ahead for 2.1.4

We're probably coming to a quieter spell in 2.1.3 development as we
spend time clearing bugs, getting signing of executables sorted, the
manual updated, more testing and heading for freeze and translation on
9th Oct (with semifreddo 1st October).

Looking ahead to 2.1.4 we should be thinking about what we want to have
in that release. We should be doing some thinking right now, and maybe
some coding, in readiness for that release cycle. We could perhaps take
on something that would justify a 2.2.0 name.

Possibilities for a 2.2.0 designation include:

- Vaughan's 2-in-1 (touch screen mode)
- Roger's MIDI playback/alignment code
- Paul's FishEye work (localised track zoom)

With any of these I could also do some work on plug-in preferences,
working with the developer, so that the new feature is as a module, if
team think that is a good idea.

Also for Audacity 2.1.4/2.2.0 I am expecting that we'll do more cherry
picking from DarkAudacity 2.1.3x features. I am expecting for example
that we will update the icons to the more modern look, still with a
light theme, and with the dark theme as an option. Even if we
can't/don't do one of the 2.2.0 initiatives, the new look should be good
for Audacity publicity, and show that the project is active/vibrant. It
would be nice to do a "dot zero" release, but we don't have to. There
will be plenty enough without.

We also have code from MC Sharma for new effects, and we have code from
Bill Unruh for a spectrogram display that preserves peak heights better,
and that distinguishes interpolated points from calculated. I'm very
concerned that we have contributors whose code sits parked and unused,
often because of unresolved differences in ideas about how to proceed.
We are obviously not going to accept every piece of code offered into
Audacity, but it really is wasteful to have code, like Roger's MIDI
code, written but not reaching users by any route at all.

The new effects and Bill's spectrogram code are code I would like to try
with DarkAudacity users. That gets the code to some users, and maybe
encourages Audacity to use the ideas. I've suggested the MIDI code for
DarkAudacity 2.1.4x too, and that seems to have sparked some interest in
having it for Audacity 2.1.4.

Overall I think now is a good time to have some discussion here about
2.1.4 (let us keep calling it 2.1.4 until we have definite agreement we
are going for 2.2.0). So with this post I am opening a thread for
discussing what we do/plan with 2.1.4. It isn't so helpful to discuss
"Would be nice" features if we don't have code or developers
engaged/interested - but all the features I have mentioned here have
code to back them up.

--James.

Peter Sampson

2016-09-05 17:07:12 UTC

Scrubbing Phase-3 - further improve the user interface for Audacity's
Scrubbing
http://wiki.audacityteam.org/wiki/Proposal:_Improvements_to_Scrubbing_-_Phase-3

Could benefit from being on this 2.1.4 planning agenda.

Peter

On Sun, Sep 4, 2016 at 5:29 PM, David Engebretson Jr <

Post by David Engebretson Jr
As a daily user of Audacity, and an aspiring midi user, and also an aspiring
Audacity developer, I vote for Roger's midi. Especially if it is something
that will give more options to the blindness community and the ever
expanding availability of accessible DAW's.
If there is a path to getting ASIO built in, I will be happy to use my
gentle demeanor to approach Steinberg regarding licensing. Please, to those
who have been nay sayers in the past, I've heard your repetitive negativity
regarding ASIO and it's logged in my consciousness. I don't want to hear
the same old negative "general" commentary regarding ASIO ish's. Maybe some
background into why there is such repetitive negativity regarding the
situation would be helpful, constructive critique of plus's and minus's
would be helpful.
Peace,
David
-----Original Message-----
From: James Crook
Sent: Sunday, September 04, 2016 3:09 AM
To: Audacity-Devel list
Subject: [Audacity-devel] Planning Ahead for 2.1.4
We're probably coming to a quieter spell in 2.1.3 development as we
spend time clearing bugs, getting signing of executables sorted, the
manual updated, more testing and heading for freeze and translation on
9th Oct (with semifreddo 1st October).
Looking ahead to 2.1.4 we should be thinking about what we want to have
in that release. We should be doing some thinking right now, and maybe
some coding, in readiness for that release cycle. We could perhaps take
on something that would justify a 2.2.0 name.
- Vaughan's 2-in-1 (touch screen mode)
- Roger's MIDI playback/alignment code
- Paul's FishEye work (localised track zoom)
With any of these I could also do some work on plug-in preferences,
working with the developer, so that the new feature is as a module, if
team think that is a good idea.
Also for Audacity 2.1.4/2.2.0 I am expecting that we'll do more cherry
picking from DarkAudacity 2.1.3x features. I am expecting for example
that we will update the icons to the more modern look, still with a
light theme, and with the dark theme as an option. Even if we
can't/don't do one of the 2.2.0 initiatives, the new look should be good
for Audacity publicity, and show that the project is active/vibrant. It
would be nice to do a "dot zero" release, but we don't have to. There
will be plenty enough without.
We also have code from MC Sharma for new effects, and we have code from
Bill Unruh for a spectrogram display that preserves peak heights better,
and that distinguishes interpolated points from calculated. I'm very
concerned that we have contributors whose code sits parked and unused,
often because of unresolved differences in ideas about how to proceed.
We are obviously not going to accept every piece of code offered into
Audacity, but it really is wasteful to have code, like Roger's MIDI
code, written but not reaching users by any route at all.
The new effects and Bill's spectrogram code are code I would like to try
with DarkAudacity users. That gets the code to some users, and maybe
encourages Audacity to use the ideas. I've suggested the MIDI code for
DarkAudacity 2.1.4x too, and that seems to have sparked some interest in
having it for Audacity 2.1.4.
Overall I think now is a good time to have some discussion here about
2.1.4 (let us keep calling it 2.1.4 until we have definite agreement we
are going for 2.2.0). So with this post I am opening a thread for
discussing what we do/plan with 2.1.4. It isn't so helpful to discuss
"Would be nice" features if we don't have code or developers
engaged/interested - but all the features I have mentioned here have
code to back them up.
--James.
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2016-09-05 18:16:23 UTC

I have done more than I wanted to do in 2.1.3 for scrubbing, flying without
a spec, trying too many experiments, and failing to please everybody. I
gave in to demands for it, but I wanted to work on quality not features, as
I thought we had agreed in winter, and finish my sweep of memory allocation
code instead. But as it is, some improvement in scrubbing got accelerated
to 2.1.3, and my sweep is in an unfinished state yet.

I would happily do nothing for scrubbing for the next release. If others
feel competent to implement the Phase 3 ideas, if that's mostly about
redefining the buttons and clicks and appearance of the ruler, I will let
them. If redoing speed control is involved, or yet more engine
improvements, that requires more serious thought and I would want to be
involved. I would not be happy to see the disctinction of pinned and
unpinned scrubbing retracted.

My own opinion about unfinished scrubbing priorities is that I would rather
focus on the problem of making a decent keyboard-only alternative
interface, and making that work with jog wheel peripherals like that
Contour ShuttlePro. That could be orthogonal to the other questions about
improving the graphical version.

But instead of doing even that: I hear much from people who use -- or
disdain to use -- Audacity for recording narration. The most insistent
thing I hear is that it needs a puch and roll recording feature to be a
better tool for that use.

I would like to have that feature in 2.1.4 in at least a crude form.
(Which in fact I have implemented privately, over a year ago. I regret
sitting on it whenever I hear the reiterated demands for it.)

A more sophisticated form would not be a simple destructive re-recording,
but include some way of remembering alternative takes and alternating among
them. That opens the door to the big question of layering of clips, which
would have implications beyond just this recording feature. I don't think
I want to be that ambitious in 2.1.4, but it's a thing to think about for
yet further future.

PRL

On Mon, Sep 5, 2016 at 1:07 PM, Peter Sampson <

Post by Peter Sampson
Scrubbing Phase-3 - further improve the user interface for Audacity's
Scrubbing
http://wiki.audacityteam.org/wiki/Proposal:_Improvements_
to_Scrubbing_-_Phase-3
Could benefit from being on this 2.1.4 planning agenda.
Peter
On Sun, Sep 4, 2016 at 5:29 PM, David Engebretson Jr <

------------------------------------------------------------
------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2016-09-06 01:25:34 UTC

Thanks, Paul.

I think punch-in fits in well with changes James is pondering
to make default record "same track" rather than "new track".

I think there was a general spec for scrubbing, but many
different models that had that same general aim. That
spec did not come until after we abandoned CTRL-click
scrub.

Would your destructive scrub (as I think your current
rough idea is) lay any sort of base or have reusability for
layered-non destructive scrub? My impression of
scrubbing was that we had no clear specification at
the outset and we have at the moment a number of
related features with different interfaces.

Gale

Post by Paul Licameli
I have done more than I wanted to do in 2.1.3 for scrubbing, flying without
a spec, trying too many experiments, and failing to please everybody. I
gave in to demands for it, but I wanted to work on quality not features, as
I thought we had agreed in winter, and finish my sweep of memory allocation
code instead. But as it is, some improvement in scrubbing got accelerated
to 2.1.3, and my sweep is in an unfinished state yet.
I would happily do nothing for scrubbing for the next release. If others
feel competent to implement the Phase 3 ideas, if that's mostly about
redefining the buttons and clicks and appearance of the ruler, I will let
them. If redoing speed control is involved, or yet more engine
improvements, that requires more serious thought and I would want to be
involved. I would not be happy to see the disctinction of pinned and
unpinned scrubbing retracted.
My own opinion about unfinished scrubbing priorities is that I would rather
focus on the problem of making a decent keyboard-only alternative interface,
and making that work with jog wheel peripherals like that Contour
ShuttlePro. That could be orthogonal to the other questions about improving
the graphical version.
But instead of doing even that: I hear much from people who use -- or
disdain to use -- Audacity for recording narration. The most insistent
thing I hear is that it needs a puch and roll recording feature to be a
better tool for that use.
I would like to have that feature in 2.1.4 in at least a crude form. (Which
in fact I have implemented privately, over a year ago. I regret sitting on
it whenever I hear the reiterated demands for it.)
A more sophisticated form would not be a simple destructive re-recording,
but include some way of remembering alternative takes and alternating among
them. That opens the door to the big question of layering of clips, which
would have implications beyond just this recording feature. I don't think I
want to be that ambitious in 2.1.4, but it's a thing to think about for yet
further future.
PRL
On Mon, Sep 5, 2016 at 1:07 PM, Peter Sampson

Post by Peter Sampson
Scrubbing Phase-3 - further improve the user interface for Audacity's
Scrubbing
http://wiki.audacityteam.org/wiki/Proposal:_Improvements_to_Scrubbing_-_Phase-3
Could benefit from being on this 2.1.4 planning agenda.
Peter
On Sun, Sep 4, 2016 at 5:29 PM, David Engebretson Jr

Post by David Engebretson Jr
As a daily user of Audacity, and an aspiring midi user, and also an aspiring
Audacity developer, I vote for Roger's midi. Especially if it is something
that will give more options to the blindness community and the ever
expanding availability of accessible DAW's.
If there is a path to getting ASIO built in, I will be happy to use my
gentle demeanor to approach Steinberg regarding licensing. Please, to those
who have been nay sayers in the past, I've heard your repetitive negativity
regarding ASIO and it's logged in my consciousness. I don't want to hear
the same old negative "general" commentary regarding ASIO ish's. Maybe some
background into why there is such repetitive negativity regarding the
situation would be helpful, constructive critique of plus's and minus's
would be helpful.
Peace,
David
-----Original Message-----
From: James Crook
Sent: Sunday, September 04, 2016 3:09 AM
To: Audacity-Devel list
Subject: [Audacity-devel] Planning Ahead for 2.1.4
We're probably coming to a quieter spell in 2.1.3 development as we
spend time clearing bugs, getting signing of executables sorted, the
manual updated, more testing and heading for freeze and translation on
9th Oct (with semifreddo 1st October).
Looking ahead to 2.1.4 we should be thinking about what we want to have
in that release. We should be doing some thinking right now, and maybe
some coding, in readiness for that release cycle. We could perhaps take
on something that would justify a 2.2.0 name.
- Vaughan's 2-in-1 (touch screen mode)
- Roger's MIDI playback/alignment code
- Paul's FishEye work (localised track zoom)
With any of these I could also do some work on plug-in preferences,
working with the developer, so that the new feature is as a module, if
team think that is a good idea.
Also for Audacity 2.1.4/2.2.0 I am expecting that we'll do more cherry
picking from DarkAudacity 2.1.3x features. I am expecting for example
that we will update the icons to the more modern look, still with a
light theme, and with the dark theme as an option. Even if we
can't/don't do one of the 2.2.0 initiatives, the new look should be good
for Audacity publicity, and show that the project is active/vibrant. It
would be nice to do a "dot zero" release, but we don't have to. There
will be plenty enough without.
We also have code from MC Sharma for new effects, and we have code from
Bill Unruh for a spectrogram display that preserves peak heights better,
and that distinguishes interpolated points from calculated. I'm very
concerned that we have contributors whose code sits parked and unused,
often because of unresolved differences in ideas about how to proceed.
We are obviously not going to accept every piece of code offered into
Audacity, but it really is wasteful to have code, like Roger's MIDI
code, written but not reaching users by any route at all.
The new effects and Bill's spectrogram code are code I would like to try
with DarkAudacity users. That gets the code to some users, and maybe
encourages Audacity to use the ideas. I've suggested the MIDI code for
DarkAudacity 2.1.4x too, and that seems to have sparked some interest in
having it for Audacity 2.1.4.
Overall I think now is a good time to have some discussion here about
2.1.4 (let us keep calling it 2.1.4 until we have definite agreement we
are going for 2.2.0). So with this post I am opening a thread for
discussing what we do/plan with 2.1.4. It isn't so helpful to discuss
"Would be nice" features if we don't have code or developers
engaged/interested - but all the features I have mentioned here have
code to back them up.
--James.
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Paul Licameli

2016-09-06 01:35:07 UTC

Post by Gale Andrews
Thanks, Paul.
I think punch-in fits in well with changes James is pondering
to make default record "same track" rather than "new track".
I think there was a general spec for scrubbing, but many
different models that had that same general aim. That
spec did not come until after we abandoned CTRL-click
scrub.
Would your destructive scrub (as I think your current
rough idea is) lay any sort of base or have reusability for
layered-non destructive scrub? My impression of
scrubbing was that we had no clear specification at
the outset and we have at the moment a number of
related features with different interfaces.

I don't understand the question. Punch and roll recording, and scrubbing,
are unrelated.

Rather than pursue the perfect scrubbing feature, I want to add a new and
much demanded feature for the narration niche.

PRL

Post by Gale Andrews
Gale

Post by Paul Licameli
I have done more than I wanted to do in 2.1.3 for scrubbing, flying

without

Post by Paul Licameli
a spec, trying too many experiments, and failing to please everybody. I
gave in to demands for it, but I wanted to work on quality not features,

Post by Paul Licameli
I thought we had agreed in winter, and finish my sweep of memory

allocation

Post by Paul Licameli
code instead. But as it is, some improvement in scrubbing got

accelerated

Post by Paul Licameli
to 2.1.3, and my sweep is in an unfinished state yet.
I would happily do nothing for scrubbing for the next release. If others
feel competent to implement the Phase 3 ideas, if that's mostly about
redefining the buttons and clicks and appearance of the ruler, I will let
them. If redoing speed control is involved, or yet more engine
improvements, that requires more serious thought and I would want to be
involved. I would not be happy to see the disctinction of pinned and
unpinned scrubbing retracted.
My own opinion about unfinished scrubbing priorities is that I would

rather

Post by Paul Licameli
focus on the problem of making a decent keyboard-only alternative

interface,

Post by Paul Licameli
and making that work with jog wheel peripherals like that Contour
ShuttlePro. That could be orthogonal to the other questions about

improving

Post by Paul Licameli
the graphical version.
But instead of doing even that: I hear much from people who use -- or
disdain to use -- Audacity for recording narration. The most insistent
thing I hear is that it needs a puch and roll recording feature to be a
better tool for that use.
I would like to have that feature in 2.1.4 in at least a crude form.

(Which

Post by Paul Licameli
in fact I have implemented privately, over a year ago. I regret sitting

Post by Paul Licameli
it whenever I hear the reiterated demands for it.)
A more sophisticated form would not be a simple destructive re-recording,
but include some way of remembering alternative takes and alternating

among

Post by Paul Licameli
them. That opens the door to the big question of layering of clips,

which

Post by Paul Licameli
would have implications beyond just this recording feature. I don't

think I

Post by Paul Licameli
want to be that ambitious in 2.1.4, but it's a thing to think about for

yet

Post by Paul Licameli
further future.
PRL
On Mon, Sep 5, 2016 at 1:07 PM, Peter Sampson

Post by Peter Sampson
Scrubbing Phase-3 - further improve the user interface for Audacity's
Scrubbing
http://wiki.audacityteam.org/wiki/Proposal:_Improvements_

to_Scrubbing_-_Phase-3

Post by Peter Sampson
Could benefit from being on this 2.1.4 planning agenda.
Peter
On Sun, Sep 4, 2016 at 5:29 PM, David Engebretson Jr

hear

Post by David Engebretson Jr
the same old negative "general" commentary regarding ASIO ish's. Maybe some
background into why there is such repetitive negativity regarding the
situation would be helpful, constructive critique of plus's and minus's
would be helpful.
Peace,
David
-----Original Message-----
From: James Crook
Sent: Sunday, September 04, 2016 3:09 AM
To: Audacity-Devel list
Subject: [Audacity-devel] Planning Ahead for 2.1.4
We're probably coming to a quieter spell in 2.1.3 development as we
spend time clearing bugs, getting signing of executables sorted, the
manual updated, more testing and heading for freeze and translation on
9th Oct (with semifreddo 1st October).
Looking ahead to 2.1.4 we should be thinking about what we want to have
in that release. We should be doing some thinking right now, and maybe
some coding, in readiness for that release cycle. We could perhaps take
on something that would justify a 2.2.0 name.
- Vaughan's 2-in-1 (touch screen mode)
- Roger's MIDI playback/alignment code
- Paul's FishEye work (localised track zoom)
With any of these I could also do some work on plug-in preferences,
working with the developer, so that the new feature is as a module, if
team think that is a good idea.
Also for Audacity 2.1.4/2.2.0 I am expecting that we'll do more cherry
picking from DarkAudacity 2.1.3x features. I am expecting for example
that we will update the icons to the more modern look, still with a
light theme, and with the dark theme as an option. Even if we
can't/don't do one of the 2.2.0 initiatives, the new look should be

good

Post by David Engebretson Jr
for Audacity publicity, and show that the project is active/vibrant.

Post by David Engebretson Jr
would be nice to do a "dot zero" release, but we don't have to. There
will be plenty enough without.
We also have code from MC Sharma for new effects, and we have code from
Bill Unruh for a spectrogram display that preserves peak heights

better,

Post by David Engebretson Jr
and that distinguishes interpolated points from calculated. I'm very
concerned that we have contributors whose code sits parked and unused,
often because of unresolved differences in ideas about how to proceed.
We are obviously not going to accept every piece of code offered into
Audacity, but it really is wasteful to have code, like Roger's MIDI
code, written but not reaching users by any route at all.
The new effects and Bill's spectrogram code are code I would like to

try

Post by David Engebretson Jr
with DarkAudacity users. That gets the code to some users, and maybe
encourages Audacity to use the ideas. I've suggested the MIDI code for
DarkAudacity 2.1.4x too, and that seems to have sparked some interest

Post by David Engebretson Jr
having it for Audacity 2.1.4.
Overall I think now is a good time to have some discussion here about
2.1.4 (let us keep calling it 2.1.4 until we have definite agreement we
are going for 2.2.0). So with this post I am opening a thread for
discussing what we do/plan with 2.1.4. It isn't so helpful to discuss
"Would be nice" features if we don't have code or developers
engaged/interested - but all the features I have mentioned here have
code to back them up.
--James.
------------------------------------------------------------

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

Post by David Engebretson Jr
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------

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

Post by David Engebretson Jr
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

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

Post by Peter Sampson
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

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

Post by Paul Licameli
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale Andrews

2016-09-06 01:45:48 UTC

Sorry, Paul. I don't blame you not understanding the question.

I meant:

" Would your destructive punch-in (as I think your current
rough idea is) lay any sort of base or have reusability for
layered-non destructive punch-in?

The rest of it was what I meant to write.

Punch-in isn't niche or narrators only. It's always had the same
level of user requests as "scrubbing". Scroll down a little from
this link:
http://wiki.audacityteam.org/wiki/Feature_Requests#Highest-rated .

There is an element of controversy about destructive scrubbing
of course.

Thanks

Gale

I don't understand the question. Punch and roll recording, and scrubbing,
are unrelated.
Rather than pursue the perfect scrubbing feature, I want to add a new and
much demanded feature for the narration niche.
PRL

Post by Gale Andrews
Gale

Post by Paul Licameli
I have done more than I wanted to do in 2.1.3 for scrubbing, flying without
a spec, trying too many experiments, and failing to please everybody. I
gave in to demands for it, but I wanted to work on quality not features, as
I thought we had agreed in winter, and finish my sweep of memory allocation
code instead. But as it is, some improvement in scrubbing got accelerated
to 2.1.3, and my sweep is in an unfinished state yet.
I would happily do nothing for scrubbing for the next release. If others
feel competent to implement the Phase 3 ideas, if that's mostly about
redefining the buttons and clicks and appearance of the ruler, I will let
them. If redoing speed control is involved, or yet more engine
improvements, that requires more serious thought and I would want to be
involved. I would not be happy to see the disctinction of pinned and
unpinned scrubbing retracted.
My own opinion about unfinished scrubbing priorities is that I would rather
focus on the problem of making a decent keyboard-only alternative interface,
and making that work with jog wheel peripherals like that Contour
ShuttlePro. That could be orthogonal to the other questions about improving
the graphical version.
But instead of doing even that: I hear much from people who use -- or
disdain to use -- Audacity for recording narration. The most insistent
thing I hear is that it needs a puch and roll recording feature to be a
better tool for that use.
I would like to have that feature in 2.1.4 in at least a crude form.
(Which
in fact I have implemented privately, over a year ago. I regret sitting on
it whenever I hear the reiterated demands for it.)
A more sophisticated form would not be a simple destructive
re-recording,
but include some way of remembering alternative takes and alternating among
them. That opens the door to the big question of layering of clips, which
would have implications beyond just this recording feature. I don't think I
want to be that ambitious in 2.1.4, but it's a thing to think about for yet
further future.
PRL
On Mon, Sep 5, 2016 at 1:07 PM, Peter Sampson

Post by Peter Sampson
Scrubbing Phase-3 - further improve the user interface for Audacity's
Scrubbing
http://wiki.audacityteam.org/wiki/Proposal:_Improvements_to_Scrubbing_-_Phase-3
Could benefit from being on this 2.1.4 planning agenda.
Peter
On Sun, Sep 4, 2016 at 5:29 PM, David Engebretson Jr

Post by David Engebretson Jr
As a daily user of Audacity, and an aspiring midi user, and also an aspiring
Audacity developer, I vote for Roger's midi. Especially if it is something
that will give more options to the blindness community and the ever
expanding availability of accessible DAW's.
If there is a path to getting ASIO built in, I will be happy to use my
gentle demeanor to approach Steinberg regarding licensing. Please, to those
who have been nay sayers in the past, I've heard your repetitive negativity
regarding ASIO and it's logged in my consciousness. I don't want to hear
the same old negative "general" commentary regarding ASIO ish's.
Maybe
some
background into why there is such repetitive negativity regarding the
situation would be helpful, constructive critique of plus's and minus's
would be helpful.
Peace,
David
-----Original Message-----
From: James Crook
Sent: Sunday, September 04, 2016 3:09 AM
To: Audacity-Devel list
Subject: [Audacity-devel] Planning Ahead for 2.1.4
We're probably coming to a quieter spell in 2.1.3 development as we
spend time clearing bugs, getting signing of executables sorted, the
manual updated, more testing and heading for freeze and translation on
9th Oct (with semifreddo 1st October).
Looking ahead to 2.1.4 we should be thinking about what we want to have
in that release. We should be doing some thinking right now, and maybe
some coding, in readiness for that release cycle. We could perhaps take
on something that would justify a 2.2.0 name.
- Vaughan's 2-in-1 (touch screen mode)
- Roger's MIDI playback/alignment code
- Paul's FishEye work (localised track zoom)
With any of these I could also do some work on plug-in preferences,
working with the developer, so that the new feature is as a module, if
team think that is a good idea.
Also for Audacity 2.1.4/2.2.0 I am expecting that we'll do more cherry
picking from DarkAudacity 2.1.3x features. I am expecting for example
that we will update the icons to the more modern look, still with a
light theme, and with the dark theme as an option. Even if we
can't/don't do one of the 2.2.0 initiatives, the new look should be good
for Audacity publicity, and show that the project is active/vibrant.
It
would be nice to do a "dot zero" release, but we don't have to. There
will be plenty enough without.
We also have code from MC Sharma for new effects, and we have code from
Bill Unruh for a spectrogram display that preserves peak heights better,
and that distinguishes interpolated points from calculated. I'm very
concerned that we have contributors whose code sits parked and unused,
often because of unresolved differences in ideas about how to proceed.
We are obviously not going to accept every piece of code offered into
Audacity, but it really is wasteful to have code, like Roger's MIDI
code, written but not reaching users by any route at all.
The new effects and Bill's spectrogram code are code I would like to try
with DarkAudacity users. That gets the code to some users, and maybe
encourages Audacity to use the ideas. I've suggested the MIDI code for
DarkAudacity 2.1.4x too, and that seems to have sparked some interest in
having it for Audacity 2.1.4.
Overall I think now is a good time to have some discussion here about
2.1.4 (let us keep calling it 2.1.4 until we have definite agreement we
are going for 2.2.0). So with this post I am opening a thread for
discussing what we do/plan with 2.1.4. It isn't so helpful to discuss
"Would be nice" features if we don't have code or developers
engaged/interested - but all the features I have mentioned here have
code to back them up.
--James.
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

Gale Andrews

2016-09-06 02:22:24 UTC