[Audacity-devel] Early 2.1.4 projects

Post by Paul Licameli
Is it too soon to talk about my ambitions for early 2.1.4 work?

From RMs perspective it's fine. If we are to have short release cycles
we need to discuss what is likely to be in the next release whilst
working on the current one.

Post by Paul Licameli
If you ask, I could explain something about the big mess of stuff you may
have observed me stewing up on my fork, not all of which is mature enough
to push just yet.

The 'various' branch looks interesting and I look forward to these.

--James.

Paul Licameli

2017-03-12 15:43:41 UTC

Post by Paul Licameli
Is it too soon to talk about my ambitions for early 2.1.4 work?

From RMs perspective it's fine. If we are to have short release cycles
we need to discuss what is likely to be in the next release whilst
working on the current one.

Post by Paul Licameli
If you ask, I could explain something about the big mess of stuff you may
have observed me stewing up on my fork, not all of which is mature enough
to push just yet.

The 'various' branch looks interesting and I look forward to these.
--James.

That is all about the dogged cleanup effort for various minor unreported
bugs I found, and pervasive improvement of certain idioms. Not anything
that is noticeably new and exciting to the user.

"various" now includes all changes to achieve the happy state of
no-naked-newness (and the same for malloc) in src, though not in lib-src.
Glad to finish what I started with that.

I want "various" to include what I will merge at the opening gun. But
there are a few commits in it I must still review and test. That work is
almost complete.

When that is done, I think I would next pick some commits of
exception-safety (formerly called "bug437") into various, which rewrite
various things in RAII idiom, because that is a generalization of the sort
of work for no-naked-new. I would not yet merge the other parts of that
branch, which add throws and catches.

The three parts of proper programming with exceptions are throwing,
catching, and in between, "ducking." So I mean to put proper ducking in
all the many places I identified as needing it.

PRL

Post by James Crook
------------------------------------------------------------
------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Paul Licameli

2017-03-14 17:44:17 UTC

I now consider the "various" branch up to e051457 to be merge-ready into
2.1.4.

No naked news!

PRL

Post by Paul Licameli
Is it too soon to talk about my ambitions for early 2.1.4 work?

From RMs perspective it's fine. If we are to have short release cycles
we need to discuss what is likely to be in the next release whilst
working on the current one.

Post by Paul Licameli
If you ask, I could explain something about the big mess of stuff you

may

Post by Paul Licameli
have observed me stewing up on my fork, not all of which is mature

enough

Post by Paul Licameli
to push just yet.

The 'various' branch looks interesting and I look forward to these.
--James.

That is all about the dogged cleanup effort for various minor unreported
bugs I found, and pervasive improvement of certain idioms. Not anything
that is noticeably new and exciting to the user.
"various" now includes all changes to achieve the happy state of
no-naked-newness (and the same for malloc) in src, though not in lib-src.
Glad to finish what I started with that.
I want "various" to include what I will merge at the opening gun. But
there are a few commits in it I must still review and test. That work is
almost complete.
When that is done, I think I would next pick some commits of
exception-safety (formerly called "bug437") into various, which rewrite
various things in RAII idiom, because that is a generalization of the sort
of work for no-naked-new. I would not yet merge the other parts of that
branch, which add throws and catches.
The three parts of proper programming with exceptions are throwing,
catching, and in between, "ducking." So I mean to put proper ducking in
all the many places I identified as needing it.
PRL

James Crook

2017-03-15 17:41:04 UTC

Post by Paul Licameli
I now consider the "various" branch up to e051457 to be merge-ready into
2.1.4.
No naked news!
PRL

Paul Licameli

2017-03-15 18:14:16 UTC

What will justify the bump in number to 2.2? Theming changes? Arbitrary
choice?

You know I have no shortage of ideas for features, but I don't know that
any one of them is mature enough, or which to prioritize. Fisheye, for
instance: I mostly dislike the user interface choices I made and want to
put the event handling mostly in the ruler, not the TrackPanel. But that
is work I have not done, and maybe won't soon.

One new ambition is to do something to allow overlapping of clips and
automatic cross-fading. I have been persuaded that it is a prerequisite
for a decent implementation of that other thing, punch and roll recording.
This is only in idea stage. There is much detail to puzzle out about how
it would interact with editing and effects. I wonder what minimal project
would make it a useful feature. I might not get much beyond thinking about
it. If we figure out a process for sharing binaries among the team, this
might become a long-maturing experimental branch I keep in the fork.

I want to finish what I started with the code quality initiatives of
2.1.6. That now includes proper error handling with exceptions whenever
BlockFile operations fail. And that means throws in proper places, catches
in other places, and minute examination of much else in between for proper
stack unwinding.

I would also like the much deferred track panel code reorganization to be
done with. By itself this will make little difference to the user. But
there will be this at least: all click-drag-release operations can then be
stopped with Esc key, now including those that would otherwise push the
undo stack but would instead properly roll back state.

Another part of track panel cleanup I have not yet written, is to delegate
all the drawing to other source code files, as I have accomplished for
event handling.

The track-iters2 branch aims to simplify the idioms for iterating over
tracks. Get rid of all type tests followed by C-style pointer casts of
Track objects, and instead use template magic to make something more
concise and type-safe. Also get rid of most uses of GetLink and GetLinked,
instead iterating over the channels of a track, however many: removing the
assumption of at-most-two-ness in many places, and commenting the few where
the assumption remains. You can look in track-iters2 for examples of how
the iterations simplify. This branch is still rather chaotic and in need
of careful review and test. I really like the style improvement here, but,
I prioritize this branch below the others. I don't know that it delivers
anything but nicer style.

PRL

Post by Paul Licameli
I now consider the "various" branch up to e051457 to be merge-ready into
2.1.4.
No naked news!
PRL

I think it's likely to be called 2.2.0 rather than 2.1.4.
I'm expecting we'll plan to release 4 months after RM is chosen.
I'm expecting that we will include the menu rearrangement and option of
dark theme from Dark Audacity.
I'm expecting we will include all of your 'various' branch.
Which other branches of yours do you think we should aim to include too?
--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

James Crook

2017-03-15 21:53:50 UTC

Post by Paul Licameli
What will justify the bump in number to 2.2? Theming changes? Arbitrary
choice?

See http://audacity.238276.n2.nabble.com/Version-Numbering-td7578163.html

I think the general consensus is 2.2.0 and that our numbering isn't
entirely logical. The Dark Audacity changes are very visible change.
The motivations expressed for 2.2.0 over 2.1.4 are less that the change
itself is radical, more that we want to signal that our project is
active/vibrant.

RM for 2.2.0 will be decided later, so the responses below are hat-less.

Post by Paul Licameli
You know I have no shortage of ideas for features, but I don't know that
any one of them is mature enough, or which to prioritize. Fisheye, for
instance: I mostly dislike the user interface choices I made and want to
put the event handling mostly in the ruler, not the TrackPanel. But that
is work I have not done, and maybe won't soon.

Finding general principles as to why you don't like the UI choices, and
what UI you do like can help increase the likelihood of experimental UI
working out. I don't see FishEye as a contender for 2.2.0.

Post by Paul Licameli
One new ambition is to do something to allow overlapping of clips and
automatic cross-fading. I have been persuaded that it is a prerequisite
for a decent implementation of that other thing, punch and roll recording.
This is only in idea stage. There is much detail to puzzle out about how
it would interact with editing and effects. I wonder what minimal project
would make it a useful feature. I might not get much beyond thinking about
it. If we figure out a process for sharing binaries among the team, this
might become a long-maturing experimental branch I keep in the fork.

IF you get a minimal-usable-version done, then fosshub/audacity-devel
would be an appropriate place, I would think. It would help the
initiative to get engaged early adopters, as it would be new 'work in
progress' to try out.

One option for minimal project is 'clip bumping' where instead of
dragging stopping when you encroach on an existing clip, that clip is
bumped to the first space it can fit in on another track, or possibly a
new track.

Post by Paul Licameli
I want to finish what I started with the code quality initiatives of
2.1.6. That now includes proper error handling with exceptions whenever
BlockFile operations fail. And that means throws in proper places, catches
in other places, and minute examination of much else in between for proper
stack unwinding.

I think that would be excellent for 2.2.0

Post by Paul Licameli
I would also like the much deferred track panel code reorganization to be
done with. By itself this will make little difference to the user. But
there will be this at least: all click-drag-release operations can then be
stopped with Esc key, now including those that would otherwise push the
undo stack but would instead properly roll back state.

Again, excellent for 2.2.0.

Post by Paul Licameli
Another part of track panel cleanup I have not yet written, is to delegate
all the drawing to other source code files, as I have accomplished for
event handling.

Also good for 2.2.0

Post by Paul Licameli
The track-iters2 branch aims to simplify the idioms for iterating over
tracks. Get rid of all type tests followed by C-style pointer casts of
Track objects, and instead use template magic to make something more
concise and type-safe. Also get rid of most uses of GetLink and GetLinked,
instead iterating over the channels of a track, however many: removing the
assumption of at-most-two-ness in many places, and commenting the few where
the assumption remains. You can look in track-iters2 for examples of how
the iterations simplify. This branch is still rather chaotic and in need
of careful review and test. I really like the style improvement here, but,
I prioritize this branch below the others. I don't know that it delivers
anything but nicer style.

I agree with that assessment. GetLink IS an embarrassment, but is not
blocking us in the same way as the TrackPanel as a whole is.

--James.

Paul Licameli

2017-03-15 22:38:49 UTC

Post by Paul Licameli
What will justify the bump in number to 2.2? Theming changes? Arbitrary
choice?

See http://audacity.238276.n2.nabble.com/Version-Numbering-td7578163.html
I think the general consensus is 2.2.0 and that our numbering isn't
entirely logical. The Dark Audacity changes are very visible change.
The motivations expressed for 2.2.0 over 2.1.4 are less that the change
itself is radical, more that we want to signal that our project is
active/vibrant.
RM for 2.2.0 will be decided later, so the responses below are hat-less.

Do you not like the notion of a magnifier?

After rebasing this code I wrote almost two years ago and trying it again,
I see that I wasn't imaginative enough in considering alternatives. Having
extended the ruler in 2.1.3 for scrubbing, I now consider more enhancements
of the ruler as perhaps the better way to implement it.

recording.

Post by Paul Licameli
This is only in idea stage. There is much detail to puzzle out about how
it would interact with editing and effects. I wonder what minimal

project

Post by Paul Licameli
would make it a useful feature. I might not get much beyond thinking

about

Post by Paul Licameli
it. If we figure out a process for sharing binaries among the team, this
might become a long-maturing experimental branch I keep in the fork.

IF you get a minimal-usable-version done, then fosshub/audacity-devel
would be an appropriate place, I would think. It would help the
initiative to get engaged early adopters, as it would be new 'work in
progress' to try out.
One option for minimal project is 'clip bumping' where instead of
dragging stopping when you encroach on an existing clip, that clip is
bumped to the first space it can fit in on another track, or possibly a
new track.

catches

Post by Paul Licameli
in other places, and minute examination of much else in between for

proper

Post by Paul Licameli
stack unwinding.

I think that would be excellent for 2.2.0

Post by Paul Licameli
stopped with Esc key, now including those that would otherwise push the
undo stack but would instead properly roll back state.

Again, excellent for 2.2.0.

Post by Paul Licameli
Another part of track panel cleanup I have not yet written, is to

delegate

Post by Paul Licameli
all the drawing to other source code files, as I have accomplished for
event handling.

Also good for 2.2.0

Another thing I might consider, after this track panel reorganization, is
making simultaneous wave and spectrogram views of one track.

GetLinked,

Post by Paul Licameli
instead iterating over the channels of a track, however many: removing

the

Post by Paul Licameli
assumption of at-most-two-ness in many places, and commenting the few

where

Post by Paul Licameli
the assumption remains. You can look in track-iters2 for examples of how
the iterations simplify. This branch is still rather chaotic and in need
of careful review and test. I really like the style improvement here,

but,

Post by Paul Licameli
I prioritize this branch below the others. I don't know that it delivers
anything but nicer style.

I agree with that assessment. GetLink IS an embarrassment, but is not
blocking us in the same way as the TrackPanel as a whole is.

How seriously should we consider the possibility of more-than-stereo tracks
for some future version?

PRL

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

James Crook

2017-03-15 23:17:58 UTC

Post by James Crook
Finding general principles as to why you don't like the UI choices,
and what UI you do like can help increase the likelihood of
experimental UI working out. I don't see FishEye as a contender for
2.2.0.

Do you not like the notion of a magnifier?

I like the idea of a magnifier, but am not keen on the FishEye UI choices.

Post by Paul Licameli
After rebasing this code I wrote almost two years ago and trying it again,
I see that I wasn't imaginative enough in considering alternatives. Having
extended the ruler in 2.1.3 for scrubbing, I now consider more enhancements
of the ruler as perhaps the better way to implement it.

Post by Paul Licameli
Another thing I might consider, after this track panel reorganization, is
making simultaneous wave and spectrogram views of one track.

+1. But a bit too special case.
More general is to split as a container track, that can contain multiple
views. Thus you could have waveform db and waveform linear, multiple
spectrogram views with different window sizes in the same track.

Post by Paul Licameli
How seriously should we consider the possibility of more-than-stereo tracks
for some future version?

Paul Licameli

2017-03-16 00:45:26 UTC

Do you not like the notion of a magnifier?

I like the idea of a magnifier, but am not keen on the FishEye UI choices.

So you built and tried it?

You don't like the appearance, or the interaction?

It's the interaction I no longer like.

And incidentally I'd rather now call it "magnifier" than fisheye.

Post by Paul Licameli
After rebasing this code I wrote almost two years ago and trying it

again,

Post by Paul Licameli
I see that I wasn't imaginative enough in considering alternatives.

Having

Post by Paul Licameli
extended the ruler in 2.1.3 for scrubbing, I now consider more

enhancements

Post by Paul Licameli
of the ruler as perhaps the better way to implement it.

Post by Paul Licameli
Another thing I might consider, after this track panel reorganization, is
making simultaneous wave and spectrogram views of one track.

Oh yes, and one might imagine even other visualizations.

The hard part is getting from one view of each track to two, with the code
that we have.

PRL

Post by Paul Licameli
How seriously should we consider the possibility of more-than-stereo

tracks

Post by Paul Licameli
for some future version?

It depends what that means. I am not personally interested in surround
sound. I am though interested in simultaneously recording 4 people in a
panel discussion, and having that as a 'track group'. I would like to
operate on that track group as a single thing a lot of the time, so
sync-lock within the group, amplify/fade-in/fade-out/reverb on that
group as a whole and so on, which is already how 'stereo track' behaves
for two tracks.
--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

James Crook

2017-03-16 16:30:40 UTC

Post by James Crook
I like the idea of a magnifier, but am not keen on the FishEye UI choices.

So you built and tried it?

I thought I had, at an earlier stage of development, but it is possible
I had only looked at your write up on the wiki page.

So I built fisheye-on-2.1.3 to look at a more recent version.

Post by Paul Licameli
You don't like the appearance, or the interaction?
It's the interaction I no longer like.
And incidentally I'd rather now call it "magnifier" than fisheye.

Interaction.

I think it's at an early stage of design, but these points might help:

1) With magnifier on, one is expecting to do detailed work inside the
magnified region. So I think the region should stay in a fixed position
on screen when scrolling using the horizontal scroll bar rather than
fixed to waveform.

2) I'd like 'f' to be a magnifier on/off button. Rather than
right-click to start/stop dragging of fish eye, I'd like a widget on the
timeline to drag, and I'd like going too far over left/right edge limits
to scroll the underlying wave in the other direction.

3) (I think) magnifier is giving a multiplicative zoom relative to the
overall zoom. I think actually more useful is having it have an
independent zoom. I might set it to 1pixel-per-sample and then set the
overall zoom to get the amount of context I want.

4) I'm not convinced that the compression zones actually help. An
alternative solution is to superimpose the magnified view over a much
faded out view of the unmagnified wave (in the magnified section).

Post by Paul Licameli
Oh yes, and one might imagine even other visualizations.
The hard part is getting from one view of each track to two, with the code
that we have.

Right. And magnifier is a special case of that as you have two views
(at different zooms) combined in the one view .

One can imagine a very expensive to calculate and detailed spectrogram,
in place of your current magnified portion of the view. Keeping its
width down to a quarter the track width would reduce computational cost
by a factor of four, and gain the magnifier benefit of detail seen in
context.

--James.

Gale Andrews

2017-03-16 00:51:32 UTC

On 15 March 2017 at 23:17, James Crook <***@indigo.ie> wrote:
[...]

I am not personally interested in surround sound.

Multi-channel playback is near the top of
http://wiki.audacityteam.org/wiki/Feature_Requests#Highest-rated_Feature_Requests
.

Gale

Paul Licameli

2017-03-16 02:09:39 UTC

Post by Gale Andrews
[...]

I am not personally interested in surround sound.

Multi-channel playback is near the top of
http://wiki.audacityteam.org/wiki/Feature_Requests#Highest-
rated_Feature_Requests

I do not propose to accomplish that in one version, but I would accomplish
a necessary preliminary reorganization of code: in the many places where
the code must "do something" to "both channels," I would abstract that to
"all channels" not assuming at most two. Then it would be easier to vary
the implementation details of just how we group channels into tracks. The
way that this is done now isn't pretty.

My Windows desktop is designed as a "gaming" PC though I don't use it for
that purpose. I wonder if it would be capable of testing out multi-channel
playback.

PRL

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

David Bailes

2017-03-21 10:03:59 UTC

Post by Paul Licameli
What will justify the bump in number to 2.2? Theming changes? Arbitrary
choice?

See http://audacity.238276.n2.nabble.com/Version-Numbering-td7578163.html
I think the general consensus is 2.2.0 and that our numbering isn't
entirely logical. The Dark Audacity changes are very visible change.
The motivations expressed for 2.2.0 over 2.1.4 are less that the change
itself is radical, more that we want to signal that our project is
active/vibrant.
RM for 2.2.0 will be decided later, so the responses below are hat-less.

recording.

Post by Paul Licameli
This is only in idea stage. There is much detail to puzzle out about how
it would interact with editing and effects. I wonder what minimal

project

Post by Paul Licameli
would make it a useful feature. I might not get much beyond thinking

about

Post by Paul Licameli
it. If we figure out a process for sharing binaries among the team, this
might become a long-maturing experimental branch I keep in the fork.

IF you get a minimal-usable-version done, then fosshub/audacity-devel
would be an appropriate place, I would think. It would help the
initiative to get engaged early adopters, as it would be new 'work in
progress' to try out.
One option for minimal project is 'clip bumping' where instead of
dragging stopping when you encroach on an existing clip, that clip is
bumped to the first space it can fit in on another track, or possibly a
new track.

'clip bumping' doesn't sound very usable to me, and would almost certainly
be problematic from an accessibility point of view.
If you moved a clip A which bumps another clip into anther track (possibly
off screen), then you change your mind, do you have to "undo" to restore
the bumped clip back to its original track?

David.

catches

Post by Paul Licameli
in other places, and minute examination of much else in between for

proper

Post by Paul Licameli
stack unwinding.

I think that would be excellent for 2.2.0

Post by Paul Licameli
stopped with Esc key, now including those that would otherwise push the
undo stack but would instead properly roll back state.

Again, excellent for 2.2.0.

Post by Paul Licameli
Another part of track panel cleanup I have not yet written, is to

delegate

Post by Paul Licameli
all the drawing to other source code files, as I have accomplished for
event handling.

Also good for 2.2.0

GetLinked,

Post by Paul Licameli
instead iterating over the channels of a track, however many: removing

the

Post by Paul Licameli
assumption of at-most-two-ness in many places, and commenting the few

where

but,

Post by Paul Licameli
I prioritize this branch below the others. I don't know that it delivers
anything but nicer style.

I agree with that assessment. GetLink IS an embarrassment, but is not
blocking us in the same way as the TrackPanel as a whole is.
--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

James Crook

2017-03-21 10:20:49 UTC

Post by David Bailes
'clip bumping' doesn't sound very usable to me, and would almost certainly
be problematic from an accessibility point of view.
If you moved a clip A which bumps another clip into anther track (possibly
off screen), then you change your mind, do you have to "undo" to restore
the bumped clip back to its original track?

Sorry. My description was not clear enough. Clip bumping always
preserves time position. So if the track below is empty enough the
bumped clip moves down into it. Or a new track is created if needed for
the bumped track. So you now get a mix at the overlap.

If you continue dragging so there is space again, or drag back in the
same movement, the clip unbumps back to the track where it was.

Many details would need to be right. For example it should not move a
clip to a new track with different pan/gain or mute-solo.

--James.

David Bailes

2017-03-22 10:24:52 UTC

Post by David Bailes

(possibly

Post by David Bailes
off screen), then you change your mind, do you have to "undo" to restore
the bumped clip back to its original track?

Sorry. My description was not clear enough. Clip bumping always
preserves time position. So if the track below is empty enough the
bumped clip moves down into it.

I can't imagine a user wanting the clip bumped into an existing track.

Post by David Bailes
Or a new track is created if needed for
the bumped track. So you now get a mix at the overlap.
If you continue dragging so there is space again, or drag back in the
same movement, the clip unbumps back to the track where it was.
Many details would need to be right. For example it should not move a
clip to a new track with different pan/gain or mute-solo.

I still can't see how this could be made usable for users of screen
readers. Having the two overlapping clips in separate tracks would make it
difficult in subsequent interactions to know that those two clips are
related.

I think that all users would prefer overlapping clips to be in the same
track. Having clips bumped into other tracks is not a step towards
implementing that, and so I don't think it would be useful development
effort.

David.

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

Paul Licameli

2017-03-22 12:03:22 UTC