Early 2.1.4 projects

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

Early 2.1.4 projects

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

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.

But no more just now, I don't want to jinx RC3 and the St. Paddy's Day release.

PRL


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

Re: Early 2.1.4 projects

James Crook
On 3/12/2017 1:22 AM, Paul Licameli wrote:
> 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.

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


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

Re: Early 2.1.4 projects

Paul Licameli


On Sun, Mar 12, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
On 3/12/2017 1:22 AM, Paul Licameli wrote:
> 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.

> 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
 


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


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

Re: Early 2.1.4 projects

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

No naked news!

PRL



On Sun, Mar 12, 2017 at 11:43 AM, Paul Licameli <[hidden email]> wrote:


On Sun, Mar 12, 2017 at 10:21 AM, James Crook <[hidden email]> wrote:
On 3/12/2017 1:22 AM, Paul Licameli wrote:
> 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.

> 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
 


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



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

James Crook
On 3/14/2017 5:44 PM, Paul Licameli wrote:
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

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


On Wed, Mar 15, 2017 at 1:41 PM, James Crook <[hidden email]> wrote:
On 3/14/2017 5:44 PM, Paul Licameli wrote:
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

James Crook
On 3/15/2017 6:14 PM, Paul Licameli wrote:
> 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.

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

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

> 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

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

> 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

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

Paul Licameli


On Wed, Mar 15, 2017 at 5:53 PM, James Crook <[hidden email]> wrote:
On 3/15/2017 6:14 PM, Paul Licameli wrote:
> 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.

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

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.
 

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

> 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

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

> 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

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

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

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

PRL

 

--James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

James Crook
On 3/15/2017 10:38 PM, Paul Licameli wrote:
> On Wed, Mar 15, 2017 at 5:53 PM, James Crook <[hidden email]> wrote:
>
>> 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.

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

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

> How seriously should we consider the possibility of more-than-stereo tracks
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

Paul Licameli


On Wed, Mar 15, 2017 at 7:17 PM, James Crook <[hidden email]> wrote:
On 3/15/2017 10:38 PM, Paul Licameli wrote:
> On Wed, Mar 15, 2017 at 5:53 PM, James Crook <[hidden email]> wrote:
>
>> 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.

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.
 

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

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

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
 

> How seriously should we consider the possibility of more-than-stereo tracks
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

Gale
Administrator
In reply to this post by James Crook
On 15 March 2017 at 23:17, James Crook <[hidden email]> 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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

Paul Licameli


On Wed, Mar 15, 2017 at 8:51 PM, Gale Andrews <[hidden email]> wrote:
On 15 March 2017 at 23:17, James Crook <[hidden email]> 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

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

 

.

Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

James Crook
In reply to this post by Paul Licameli
On 3/16/2017 12:45 AM, Paul Licameli wrote:

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

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



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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

David Bailes-3
In reply to this post by James Crook
On Wed, Mar 15, 2017 at 9:53 PM, James Crook <[hidden email]> wrote:
On 3/15/2017 6:14 PM, Paul Licameli wrote:
> 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.

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

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

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

> 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

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

> 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

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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

James Crook
On 3/21/2017 10:03 AM, David Bailes wrote:
> '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.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

David Bailes-3
On Tue, Mar 21, 2017 at 10:20 AM, James Crook <[hidden email]> wrote:
On 3/21/2017 10:03 AM, David Bailes wrote:
> '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.

I can't imagine a user wanting the clip bumped into an existing track.
 
  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.


--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Early 2.1.4 projects

Paul Licameli


On Wed, Mar 22, 2017 at 6:24 AM, David Bailes <[hidden email]> wrote:
On Tue, Mar 21, 2017 at 10:20 AM, James Crook <[hidden email]> wrote:
On 3/21/2017 10:03 AM, David Bailes wrote:
> '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.

I can't imagine a user wanting the clip bumped into an existing track.
 
  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.

I agree with David that bumping clips does not appeal to me.

How overlapping clips should be done -- I don't really know yet.  Will I make any effort that way in 2.2.0?  Maybe other things will take all my time.

PRL

 

David.


--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...