Quantcast

Transcription Toolbar

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

Transcription Toolbar

Peter Sampson-2
Recent testing and documentation work ahs led to to put some focus on the
Transcription Toolbar - something I usually overlook as I have no personal use
for it.


If we are to have the Transcription Toolbar we really should make sure that we
make it work properly (and indeed as it, sort of, used to work a long while ago
in the erlier 1.3 betas)

This means that we need to fix P3 Bug #133
Play-at-Speed slider: Change of playback speed is no longer automatic
http://bugzilla.audacityteam.org/show_bug.cgi?id=133

And its closely related cousin would really need fixing too, bug #235
Transcription Toolbar Play-at-Speed slider: Change of playback speed auto-restarts from cursor
http://bugzilla.audacityteam.org/show_bug.cgi?id=235
Audacity 1.3.5 shows this behavior.

133, which has been open since February 2010 was kludge  "fixed" by removing the dynamic
changing
of the Play-at-Speed slider.  If my reading of the bug thread is correct then the "fix"
to make it
non-dynamic was because it couldn't be made to work on (some) linux platforms.

There was some discussion back then that the kludge fix was to be preferred since that then gave
us the same behavior on all three platforms.  Also discussions back then that the Linux platform was
perhaps the most important to as as it is more "open source".

This has led to a situation for now over seven years where we have denied the possible dynamic
behavior of the Play-at-Speed slider to our majority Windows and Mac users, who combined vastly
outnumber
the relative minority of Linux users.

Fixing this, at least for, Windows and Mac, would be a great benefit to thos users of Play-at-Speed
who suffer from RSI.  Plus, as Gale points out in the bug thread, it would benefit VI usrs (who are
mainly Windows users) as it would enable them to restore and reuse their Play-at-Speed shortcuts.


While we are fixing those two bugs, we really need to sort #815:
Transcription Toolbar Play button should be down after clicking it, not Transport Play button
http://bugzilla.audacityteam.org/show_bug.cgi?id=815
This is currently listed as a P4Enh - but I believe it exhibits erroneous, misleading, behavior and
deserves
at a least a P3 and a release note.


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

There is a counter-argument that could be raised ...

Now that we have Scrubbing/Seeking which does have dynamic play-at-speed control, it could be
argued that we no longer need the Transcription Toolbar and could retire it.

I do not subscribe to this view.

Cheers,
Peter.


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

Re: Transcription Toolbar

Stevethefiddle
On 4 April 2017 at 14:12, Peter Sampson <[hidden email]> wrote:

> Recent testing and documentation work ahs led to to put some focus on the
> Transcription Toolbar - something I usually overlook as I have no personal
> use
> for it.
>
>
> If we are to have the Transcription Toolbar we really should make sure that
> we
> make it work properly (and indeed as it, sort of, used to work a long while
> ago
> in the erlier 1.3 betas)
>
> This means that we need to fix P3 Bug #133
> Play-at-Speed slider: Change of playback speed is no longer automatic
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>
> And its closely related cousin would really need fixing too, bug #235
> Transcription Toolbar Play-at-Speed slider: Change of playback speed
> auto-restarts from cursor
> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
> Audacity 1.3.5 shows this behavior.
>
> 133, which has been open since February 2010 was kludge  "fixed" by removing
> the dynamic
> changing of the Play-at-Speed slider.  If my reading of the bug thread is
> correct then the "fix"
> to make it non-dynamic was because it couldn't be made to work on (some)
> linux platforms.
>
> There was some discussion back then that the kludge fix was to be preferred
> since that then gave
> us the same behavior on all three platforms.  Also discussions back then
> that the Linux platform was
> perhaps the most important to as as it is more "open source".

I don't think the Audacity developers have ever subscribed to that
view, though it's true that the Linux community, despite their small
numbers, are major contributors to open source software. Quite the
opposite in fact. If an issue 'only' affects Linux, then it is treated
as less important because Linux is a minority platform (see below).

>
> This has led to a situation for now over seven years where we have denied
> the possible dynamic
> behavior of the Play-at-Speed slider to our majority Windows and Mac users,
> who combined vastly
> outnumber the relative minority of Linux users.
>
> Fixing this, at least for, Windows and Mac, would be a great benefit to thos
> users of Play-at-Speed
> who suffer from RSI.  Plus, as Gale points out in the bug thread, it would
> benefit VI usrs (who are
> mainly Windows users) as it would enable them to restore and reuse their
> Play-at-Speed shortcuts.

That's not a fix, it's avoidance. On Linux it's a crash issue that has
been known about for years (should be P1 imo, but Linux is a minority
platform).

Steve


> While we are fixing those two bugs, we really need to sort #815:
> Transcription Toolbar Play button should be down after clicking it, not
> Transport Play button
> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
> This is currently listed as a P4Enh - but I believe it exhibits erroneous,
> misleading, behavior and
> deserves at a least a P3 and a release note.
>
>
> -------------------------------------------------------------------------------------------------------------
>
> There is a counter-argument that could be raised ...
>
> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
> control, it could be
> argued that we no longer need the Transcription Toolbar and could retire it.
>
> I do not subscribe to this view.
>
> Cheers,
> Peter.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Transcription Toolbar

Gale
Administrator
Are we talking about 276 being known for years:
http://bugzilla.audacityteam.org/show_bug.cgi?id=276
"PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?

That was P1 towards the end of 2.1.3-alpha but then demoted
back to P2 because James could not yet fix it by making
monitoring always on.

Although we should update PortAudio I don't think there
is anything merged into it that would directly help 276. Or
a developer could test the unmerged code for PortAudio's
pulseaudio API and see if it's going to help.

I am guessing to make P1 "stick" for 276 there would have
to be a developer committed to work on it again.

Would I read into James's comment on bug 133:
http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8

that Paul's work on better memory management might
have already made the Play-at-Speed slider less prone to
lock up?



Gale


On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]> wrote:

> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]> wrote:
>> Recent testing and documentation work ahs led to to put some focus on the
>> Transcription Toolbar - something I usually overlook as I have no personal
>> use
>> for it.
>>
>>
>> If we are to have the Transcription Toolbar we really should make sure that
>> we
>> make it work properly (and indeed as it, sort of, used to work a long while
>> ago
>> in the erlier 1.3 betas)
>>
>> This means that we need to fix P3 Bug #133
>> Play-at-Speed slider: Change of playback speed is no longer automatic
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>>
>> And its closely related cousin would really need fixing too, bug #235
>> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>> auto-restarts from cursor
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>> Audacity 1.3.5 shows this behavior.
>>
>> 133, which has been open since February 2010 was kludge  "fixed" by removing
>> the dynamic
>> changing of the Play-at-Speed slider.  If my reading of the bug thread is
>> correct then the "fix"
>> to make it non-dynamic was because it couldn't be made to work on (some)
>> linux platforms.
>>
>> There was some discussion back then that the kludge fix was to be preferred
>> since that then gave
>> us the same behavior on all three platforms.  Also discussions back then
>> that the Linux platform was
>> perhaps the most important to as as it is more "open source".
>
> I don't think the Audacity developers have ever subscribed to that
> view, though it's true that the Linux community, despite their small
> numbers, are major contributors to open source software. Quite the
> opposite in fact. If an issue 'only' affects Linux, then it is treated
> as less important because Linux is a minority platform (see below).
>
>>
>> This has led to a situation for now over seven years where we have denied
>> the possible dynamic
>> behavior of the Play-at-Speed slider to our majority Windows and Mac users,
>> who combined vastly
>> outnumber the relative minority of Linux users.
>>
>> Fixing this, at least for, Windows and Mac, would be a great benefit to thos
>> users of Play-at-Speed
>> who suffer from RSI.  Plus, as Gale points out in the bug thread, it would
>> benefit VI usrs (who are
>> mainly Windows users) as it would enable them to restore and reuse their
>> Play-at-Speed shortcuts.
>
> That's not a fix, it's avoidance. On Linux it's a crash issue that has
> been known about for years (should be P1 imo, but Linux is a minority
> platform).
>
> Steve
>
>
>> While we are fixing those two bugs, we really need to sort #815:
>> Transcription Toolbar Play button should be down after clicking it, not
>> Transport Play button
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>> This is currently listed as a P4Enh - but I believe it exhibits erroneous,
>> misleading, behavior and
>> deserves at a least a P3 and a release note.
>>
>>
>> -------------------------------------------------------------------------------------------------------------
>>
>> There is a counter-argument that could be raised ...
>>
>> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
>> control, it could be
>> argued that we no longer need the Transcription Toolbar and could retire it.
>>
>> I do not subscribe to this view.
>>
>> Cheers,
>> Peter.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

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

Re: Transcription Toolbar

Peter Sampson-2


On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
Are we talking about 276 being known for years:
http://bugzilla.audacityteam.org/show_bug.cgi?id=276
"PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?

That was P1 towards the end of 2.1.3-alpha but then demoted
back to P2 because James could not yet fix it by making
monitoring always on.

No I am not talking about that - unless that is what is stopping 133 and 235
being fixed for our majority Windows and Mac users.

My understanding from reading the 133 bug thread was that we had this working
at least the dynamic speed change - but with the 235 "restart from" issue on both
Windows and Mac - and testing on 1.3.5 shows that to be the case.

We were apparently  unable to make this work properly on Linux - and then took the
decision tothereby remove it from Windows and Mac users - just so that we could be
the same (with degraded behavior) on all three platforms.  Rather this should have
remained open as a Linux bug to be fixed (possibly with a Linux kludge pro-tem
workaround fix).

So what I am appealing for here is that we restore the dynamic Play-at-Speed for at
least Windows and ac - and fix the associated bug #235.  This in the name of making
the Transcription toolbar prperly useful - and more usable by RSI sufferers and VI users.

Thanks,
Peter

 

Although we should update PortAudio I don't think there
is anything merged into it that would directly help 276. Or
a developer could test the unmerged code for PortAudio's
pulseaudio API and see if it's going to help.

I am guessing to make P1 "stick" for 276 there would have
to be a developer committed to work on it again.

Would I read into James's comment on bug 133:
http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8

that Paul's work on better memory management might
have already made the Play-at-Speed slider less prone to
lock up?



Gale


On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]> wrote:
> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]> wrote:
>> Recent testing and documentation work ahs led to to put some focus on the
>> Transcription Toolbar - something I usually overlook as I have no personal
>> use
>> for it.
>>
>>
>> If we are to have the Transcription Toolbar we really should make sure that
>> we
>> make it work properly (and indeed as it, sort of, used to work a long while
>> ago
>> in the erlier 1.3 betas)
>>
>> This means that we need to fix P3 Bug #133
>> Play-at-Speed slider: Change of playback speed is no longer automatic
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>>
>> And its closely related cousin would really need fixing too, bug #235
>> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>> auto-restarts from cursor
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>> Audacity 1.3.5 shows this behavior.
>>
>> 133, which has been open since February 2010 was kludge  "fixed" by removing
>> the dynamic
>> changing of the Play-at-Speed slider.  If my reading of the bug thread is
>> correct then the "fix"
>> to make it non-dynamic was because it couldn't be made to work on (some)
>> linux platforms.
>>
>> There was some discussion back then that the kludge fix was to be preferred
>> since that then gave
>> us the same behavior on all three platforms.  Also discussions back then
>> that the Linux platform was
>> perhaps the most important to as as it is more "open source".
>
> I don't think the Audacity developers have ever subscribed to that
> view, though it's true that the Linux community, despite their small
> numbers, are major contributors to open source software. Quite the
> opposite in fact. If an issue 'only' affects Linux, then it is treated
> as less important because Linux is a minority platform (see below).
>
>>
>> This has led to a situation for now over seven years where we have denied
>> the possible dynamic
>> behavior of the Play-at-Speed slider to our majority Windows and Mac users,
>> who combined vastly
>> outnumber the relative minority of Linux users.
>>
>> Fixing this, at least for, Windows and Mac, would be a great benefit to thos
>> users of Play-at-Speed
>> who suffer from RSI.  Plus, as Gale points out in the bug thread, it would
>> benefit VI usrs (who are
>> mainly Windows users) as it would enable them to restore and reuse their
>> Play-at-Speed shortcuts.
>
> That's not a fix, it's avoidance. On Linux it's a crash issue that has
> been known about for years (should be P1 imo, but Linux is a minority
> platform).
>
> Steve
>
>
>> While we are fixing those two bugs, we really need to sort #815:
>> Transcription Toolbar Play button should be down after clicking it, not
>> Transport Play button
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>> This is currently listed as a P4Enh - but I believe it exhibits erroneous,
>> misleading, behavior and
>> deserves at a least a P3 and a release note.
>>
>>
>> -------------------------------------------------------------------------------------------------------------
>>
>> There is a counter-argument that could be raised ...
>>
>> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
>> control, it could be
>> argued that we no longer need the Transcription Toolbar and could retire it.
>>
>> I do not subscribe to this view.
>>
>> Cheers,
>> Peter.
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

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


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

Re: Transcription Toolbar

James Crook
I've not revisited this recently, but my recollection from way back was that the play-at-speed code was extremely bad code, reallocating (and leaking) an internal time track for every movement of the slider. 

Paul's new code for vari-speed used by his scrubbing, in my opinion, should be used if we reenable varying play at speed.  That means it is a bit more work than just a #define, but still reasonable to request it for 2.2.0.


On 4/5/2017 11:47 AM, Peter Sampson wrote:
On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews [hidden email] wrote:

Are we talking about 276 being known for years:
http://bugzilla.audacityteam.org/show_bug.cgi?id=276
"PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?

That was P1 towards the end of 2.1.3-alpha but then demoted
back to P2 because James could not yet fix it by making
monitoring always on.

No I am not talking about that - unless that is what is stopping 133 and 235
being fixed for our majority Windows and Mac users.

My understanding from reading the 133 bug thread was that we had this
working
at least the dynamic speed change - but with the 235 "restart from" issue
on both
Windows and Mac - and testing on 1.3.5 shows that to be the case.

We were apparently  unable to make this work properly on Linux - and then
took the
decision tothereby remove it from Windows and Mac users - just so that we
could be
the same (with degraded behavior) on all three platforms.  Rather this
should have
remained open as a Linux bug to be fixed (possibly with a Linux kludge
pro-tem
workaround fix).

So what I am appealing for here is that we restore the dynamic
Play-at-Speed for at
least Windows and ac - and fix the associated bug #235.  This in the name
of making
the Transcription toolbar prperly useful - and more usable by RSI sufferers
and VI users.

Thanks,
Peter



Although we should update PortAudio I don't think there
is anything merged into it that would directly help 276. Or
a developer could test the unmerged code for PortAudio's
pulseaudio API and see if it's going to help.

I am guessing to make P1 "stick" for 276 there would have
to be a developer committed to work on it again.

Would I read into James's comment on bug 133:
http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8

that Paul's work on better memory management might
have already made the Play-at-Speed slider less prone to
lock up?



Gale


On 4 April 2017 at 15:31, Steve the Fiddle [hidden email]
wrote:
On 4 April 2017 at 14:12, Peter Sampson [hidden email]
wrote:
Recent testing and documentation work ahs led to to put some focus on
the
Transcription Toolbar - something I usually overlook as I have no
personal
use
for it.


If we are to have the Transcription Toolbar we really should make sure
that
we
make it work properly (and indeed as it, sort of, used to work a long
while
ago
in the erlier 1.3 betas)

This means that we need to fix P3 Bug #133
Play-at-Speed slider: Change of playback speed is no longer automatic
http://bugzilla.audacityteam.org/show_bug.cgi?id=133

And its closely related cousin would really need fixing too, bug #235
Transcription Toolbar Play-at-Speed slider: Change of playback speed
auto-restarts from cursor
http://bugzilla.audacityteam.org/show_bug.cgi?id=235
Audacity 1.3.5 shows this behavior.

133, which has been open since February 2010 was kludge  "fixed" by
removing
the dynamic
changing of the Play-at-Speed slider.  If my reading of the bug thread
is
correct then the "fix"
to make it non-dynamic was because it couldn't be made to work on (some)
linux platforms.

There was some discussion back then that the kludge fix was to be
preferred
since that then gave
us the same behavior on all three platforms.  Also discussions back then
that the Linux platform was
perhaps the most important to as as it is more "open source".
I don't think the Audacity developers have ever subscribed to that
view, though it's true that the Linux community, despite their small
numbers, are major contributors to open source software. Quite the
opposite in fact. If an issue 'only' affects Linux, then it is treated
as less important because Linux is a minority platform (see below).

This has led to a situation for now over seven years where we have
denied
the possible dynamic
behavior of the Play-at-Speed slider to our majority Windows and Mac
users,
who combined vastly
outnumber the relative minority of Linux users.

Fixing this, at least for, Windows and Mac, would be a great benefit to
thos
users of Play-at-Speed
who suffer from RSI.  Plus, as Gale points out in the bug thread, it
would
benefit VI usrs (who are
mainly Windows users) as it would enable them to restore and reuse their
Play-at-Speed shortcuts.
That's not a fix, it's avoidance. On Linux it's a crash issue that has
been known about for years (should be P1 imo, but Linux is a minority
platform).

Steve


While we are fixing those two bugs, we really need to sort #815:
Transcription Toolbar Play button should be down after clicking it, not
Transport Play button
http://bugzilla.audacityteam.org/show_bug.cgi?id=815
This is currently listed as a P4Enh - but I believe it exhibits
erroneous,
misleading, behavior and
deserves at a least a P3 and a release note.


------------------------------------------------------------
-------------------------------------------------
There is a counter-argument that could be raised ...

Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
control, it could be
argued that we no longer need the Transcription Toolbar and could
retire it.
I do not subscribe to this view.

Cheers,
Peter.


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

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


      

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot


_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



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

Re: Transcription Toolbar

Stevethefiddle
I'm not keen on the idea of disabling things on less popular
platforms, rather than fixing them. It sounds like a very slippery
slope to me.

It's probably impossible to get accurate figures, but given that Mac
users have GarageBand installed by default, I'd guess that there's not
a big difference between the number of Audacity users on Linux and
Audacity users on Mac. Audacity development would be much easier if we
only actively supported Windows (which is the majority of our user
base by a long way).

Steve

On 5 April 2017 at 12:44, James Crook <[hidden email]> wrote:

> I've not revisited this recently, but my recollection from way back was that
> the play-at-speed code was extremely bad code, reallocating (and leaking) an
> internal time track for every movement of the slider.
>
> Paul's new code for vari-speed used by his scrubbing, in my opinion, should
> be used if we reenable varying play at speed.  That means it is a bit more
> work than just a #define, but still reasonable to request it for 2.2.0.
>
>
>
> On 4/5/2017 11:47 AM, Peter Sampson wrote:
>
> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>
> Are we talking about 276 being known for years:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>
> That was P1 towards the end of 2.1.3-alpha but then demoted
> back to P2 because James could not yet fix it by making
> monitoring always on.
>
> No I am not talking about that - unless that is what is stopping 133 and 235
> being fixed for our majority Windows and Mac users.
>
> My understanding from reading the 133 bug thread was that we had this
> working
> at least the dynamic speed change - but with the 235 "restart from" issue
> on both
> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>
> We were apparently  unable to make this work properly on Linux - and then
> took the
> decision tothereby remove it from Windows and Mac users - just so that we
> could be
> the same (with degraded behavior) on all three platforms.  Rather this
> should have
> remained open as a Linux bug to be fixed (possibly with a Linux kludge
> pro-tem
> workaround fix).
>
> So what I am appealing for here is that we restore the dynamic
> Play-at-Speed for at
> least Windows and ac - and fix the associated bug #235.  This in the name
> of making
> the Transcription toolbar prperly useful - and more usable by RSI sufferers
> and VI users.
>
> Thanks,
> Peter
>
>
>
> Although we should update PortAudio I don't think there
> is anything merged into it that would directly help 276. Or
> a developer could test the unmerged code for PortAudio's
> pulseaudio API and see if it's going to help.
>
> I am guessing to make P1 "stick" for 276 there would have
> to be a developer committed to work on it again.
>
> Would I read into James's comment on bug 133:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>
> that Paul's work on better memory management might
> have already made the Play-at-Speed slider less prone to
> lock up?
>
>
>
> Gale
>
>
> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
> wrote:
>
> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>
> wrote:
>
> Recent testing and documentation work ahs led to to put some focus on
>
> the
>
> Transcription Toolbar - something I usually overlook as I have no
>
> personal
>
> use
> for it.
>
>
> If we are to have the Transcription Toolbar we really should make sure
>
> that
>
> we
> make it work properly (and indeed as it, sort of, used to work a long
>
> while
>
> ago
> in the erlier 1.3 betas)
>
> This means that we need to fix P3 Bug #133
> Play-at-Speed slider: Change of playback speed is no longer automatic
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>
> And its closely related cousin would really need fixing too, bug #235
> Transcription Toolbar Play-at-Speed slider: Change of playback speed
> auto-restarts from cursor
> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
> Audacity 1.3.5 shows this behavior.
>
> 133, which has been open since February 2010 was kludge  "fixed" by
>
> removing
>
> the dynamic
> changing of the Play-at-Speed slider.  If my reading of the bug thread
>
> is
>
> correct then the "fix"
> to make it non-dynamic was because it couldn't be made to work on (some)
> linux platforms.
>
> There was some discussion back then that the kludge fix was to be
>
> preferred
>
> since that then gave
> us the same behavior on all three platforms.  Also discussions back then
> that the Linux platform was
> perhaps the most important to as as it is more "open source".
>
> I don't think the Audacity developers have ever subscribed to that
> view, though it's true that the Linux community, despite their small
> numbers, are major contributors to open source software. Quite the
> opposite in fact. If an issue 'only' affects Linux, then it is treated
> as less important because Linux is a minority platform (see below).
>
> This has led to a situation for now over seven years where we have
>
> denied
>
> the possible dynamic
> behavior of the Play-at-Speed slider to our majority Windows and Mac
>
> users,
>
> who combined vastly
> outnumber the relative minority of Linux users.
>
> Fixing this, at least for, Windows and Mac, would be a great benefit to
>
> thos
>
> users of Play-at-Speed
> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>
> would
>
> benefit VI usrs (who are
> mainly Windows users) as it would enable them to restore and reuse their
> Play-at-Speed shortcuts.
>
> That's not a fix, it's avoidance. On Linux it's a crash issue that has
> been known about for years (should be P1 imo, but Linux is a minority
> platform).
>
> Steve
>
>
> While we are fixing those two bugs, we really need to sort #815:
> Transcription Toolbar Play button should be down after clicking it, not
> Transport Play button
> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
> This is currently listed as a P4Enh - but I believe it exhibits
>
> erroneous,
>
> misleading, behavior and
> deserves at a least a P3 and a release note.
>
>
> ------------------------------------------------------------
>
> -------------------------------------------------
>
> There is a counter-argument that could be raised ...
>
> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
> control, it could be
> argued that we no longer need the Transcription Toolbar and could
>
> retire it.
>
> I do not subscribe to this view.
>
> Cheers,
> Peter.
>
>
> ------------------------------------------------------------
>
> ------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------
>
> ------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Transcription Toolbar

Peter Sampson-2


On Wed, Apr 5, 2017 at 2:07 PM, Steve the Fiddle <[hidden email]> wrote:
I'm not keen on the idea of disabling things on less popular
platforms, rather than fixing them. It sounds like a very slippery
slope to me.

I'm not at all keen on that either - rather what I was suggesting is that we open
up the preexisting functionality that works on Winmdows and Mac and log this
as a Linux-only bug with high priority.

But in the light of Paul's and James's comments - and given that Scrubbing works on
all three platforms woth dynamic play-at-speed control - what I'd rather see now is the
Transcription Toolbar reworke dwith some of Paul's scrubbing engine.

And I agree with James taht this would be a good aim for 2.2.0

Peter

 

It's probably impossible to get accurate figures, but given that Mac
users have GarageBand installed by default, I'd guess that there's not
a big difference between the number of Audacity users on Linux and
Audacity users on Mac. Audacity development would be much easier if we
only actively supported Windows (which is the majority of our user
base by a long way).

Steve

On 5 April 2017 at 12:44, James Crook <[hidden email]> wrote:
> I've not revisited this recently, but my recollection from way back was that
> the play-at-speed code was extremely bad code, reallocating (and leaking) an
> internal time track for every movement of the slider.
>
> Paul's new code for vari-speed used by his scrubbing, in my opinion, should
> be used if we reenable varying play at speed.  That means it is a bit more
> work than just a #define, but still reasonable to request it for 2.2.0.
>
>
>
> On 4/5/2017 11:47 AM, Peter Sampson wrote:
>
> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>
> Are we talking about 276 being known for years:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>
> That was P1 towards the end of 2.1.3-alpha but then demoted
> back to P2 because James could not yet fix it by making
> monitoring always on.
>
> No I am not talking about that - unless that is what is stopping 133 and 235
> being fixed for our majority Windows and Mac users.
>
> My understanding from reading the 133 bug thread was that we had this
> working
> at least the dynamic speed change - but with the 235 "restart from" issue
> on both
> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>
> We were apparently  unable to make this work properly on Linux - and then
> took the
> decision tothereby remove it from Windows and Mac users - just so that we
> could be
> the same (with degraded behavior) on all three platforms.  Rather this
> should have
> remained open as a Linux bug to be fixed (possibly with a Linux kludge
> pro-tem
> workaround fix).
>
> So what I am appealing for here is that we restore the dynamic
> Play-at-Speed for at
> least Windows and ac - and fix the associated bug #235.  This in the name
> of making
> the Transcription toolbar prperly useful - and more usable by RSI sufferers
> and VI users.
>
> Thanks,
> Peter
>
>
>
> Although we should update PortAudio I don't think there
> is anything merged into it that would directly help 276. Or
> a developer could test the unmerged code for PortAudio's
> pulseaudio API and see if it's going to help.
>
> I am guessing to make P1 "stick" for 276 there would have
> to be a developer committed to work on it again.
>
> Would I read into James's comment on bug 133:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>
> that Paul's work on better memory management might
> have already made the Play-at-Speed slider less prone to
> lock up?
>
>
>
> Gale
>
>
> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
> wrote:
>
> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>
> wrote:
>
> Recent testing and documentation work ahs led to to put some focus on
>
> the
>
> Transcription Toolbar - something I usually overlook as I have no
>
> personal
>
> use
> for it.
>
>
> If we are to have the Transcription Toolbar we really should make sure
>
> that
>
> we
> make it work properly (and indeed as it, sort of, used to work a long
>
> while
>
> ago
> in the erlier 1.3 betas)
>
> This means that we need to fix P3 Bug #133
> Play-at-Speed slider: Change of playback speed is no longer automatic
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>
> And its closely related cousin would really need fixing too, bug #235
> Transcription Toolbar Play-at-Speed slider: Change of playback speed
> auto-restarts from cursor
> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
> Audacity 1.3.5 shows this behavior.
>
> 133, which has been open since February 2010 was kludge  "fixed" by
>
> removing
>
> the dynamic
> changing of the Play-at-Speed slider.  If my reading of the bug thread
>
> is
>
> correct then the "fix"
> to make it non-dynamic was because it couldn't be made to work on (some)
> linux platforms.
>
> There was some discussion back then that the kludge fix was to be
>
> preferred
>
> since that then gave
> us the same behavior on all three platforms.  Also discussions back then
> that the Linux platform was
> perhaps the most important to as as it is more "open source".
>
> I don't think the Audacity developers have ever subscribed to that
> view, though it's true that the Linux community, despite their small
> numbers, are major contributors to open source software. Quite the
> opposite in fact. If an issue 'only' affects Linux, then it is treated
> as less important because Linux is a minority platform (see below).
>
> This has led to a situation for now over seven years where we have
>
> denied
>
> the possible dynamic
> behavior of the Play-at-Speed slider to our majority Windows and Mac
>
> users,
>
> who combined vastly
> outnumber the relative minority of Linux users.
>
> Fixing this, at least for, Windows and Mac, would be a great benefit to
>
> thos
>
> users of Play-at-Speed
> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>
> would
>
> benefit VI usrs (who are
> mainly Windows users) as it would enable them to restore and reuse their
> Play-at-Speed shortcuts.
>
> That's not a fix, it's avoidance. On Linux it's a crash issue that has
> been known about for years (should be P1 imo, but Linux is a minority
> platform).
>
> Steve
>
>
> While we are fixing those two bugs, we really need to sort #815:
> Transcription Toolbar Play button should be down after clicking it, not
> Transport Play button
> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
> This is currently listed as a P4Enh - but I believe it exhibits
>
> erroneous,
>
> misleading, behavior and
> deserves at a least a P3 and a release note.
>
>
> ------------------------------------------------------------
>
> -------------------------------------------------
>
> There is a counter-argument that could be raised ...
>
> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
> control, it could be
> argued that we no longer need the Transcription Toolbar and could
>
> retire it.
>
> I do not subscribe to this view.
>
> Cheers,
> Peter.
>
>
> ------------------------------------------------------------
>
> ------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------
>
> ------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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


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

Re: Transcription Toolbar

Gale
Administrator
In reply to this post by Peter Sampson-2
On 5 April 2017 at 11:47, Peter Sampson <[hidden email]> wrote:

>
>
> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Are we talking about 276 being known for years:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
>> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>>
>> That was P1 towards the end of 2.1.3-alpha but then demoted
>> back to P2 because James could not yet fix it by making
>> monitoring always on.
>
>
> No I am not talking about that - unless that is what is stopping 133 and 235
> being fixed for our majority Windows and Mac users.

Steve wrote:

"On Linux it's a crash issue that has been known about for years (should be
 P1 imo, but Linux is a minority platform)."

I don't know what Steve means if not 276. And I don't know what Linux
problem made us remove automatic playback speed change if not 276.

Perhaps one of you would enlighten me?


> My understanding from reading the 133 bug thread was that we had this
> working
> at least the dynamic speed change - but with the 235 "restart from" issue on
> both
> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>
> We were apparently  unable to make this work properly on Linux - and then
> took the
> decision tothereby remove it from Windows and Mac users - just so that we
> could be
> the same (with degraded behavior) on all three platforms.  Rather this
> should have
> remained open as a Linux bug to be fixed (possibly with a Linux kludge
> pro-tem
> workaround fix).
>
> So what I am appealing for here is that we restore the dynamic Play-at-Speed
> for at
> least Windows and ac - and fix the associated bug #235.  This in the name of
> making
> the Transcription toolbar prperly useful - and more usable by RSI sufferers
> and VI users.

Al Dimond and James would not do that, AFAIK. They wanted/want
consistent behaviour on each platform. Steve is saying the same I
think, and I am more inclined to agree with them than I was, because
a fix seems closer than it was, even if it's specific to Transcription
Toolbar and not a fix for 276.



Gale


>> Although we should update PortAudio I don't think there
>> is anything merged into it that would directly help 276. Or
>> a developer could test the unmerged code for PortAudio's
>> pulseaudio API and see if it's going to help.
>>
>> I am guessing to make P1 "stick" for 276 there would have
>> to be a developer committed to work on it again.
>>
>> Would I read into James's comment on bug 133:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>>
>> that Paul's work on better memory management might
>> have already made the Play-at-Speed slider less prone to
>> lock up?
>>
>>
>>
>> Gale
>>
>>
>> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
>> wrote:
>> > On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>> > wrote:
>> >> Recent testing and documentation work ahs led to to put some focus on
>> >> the
>> >> Transcription Toolbar - something I usually overlook as I have no
>> >> personal
>> >> use
>> >> for it.
>> >>
>> >>
>> >> If we are to have the Transcription Toolbar we really should make sure
>> >> that
>> >> we
>> >> make it work properly (and indeed as it, sort of, used to work a long
>> >> while
>> >> ago
>> >> in the erlier 1.3 betas)
>> >>
>> >> This means that we need to fix P3 Bug #133
>> >> Play-at-Speed slider: Change of playback speed is no longer automatic
>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>> >>
>> >> And its closely related cousin would really need fixing too, bug #235
>> >> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>> >> auto-restarts from cursor
>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>> >> Audacity 1.3.5 shows this behavior.
>> >>
>> >> 133, which has been open since February 2010 was kludge  "fixed" by
>> >> removing
>> >> the dynamic
>> >> changing of the Play-at-Speed slider.  If my reading of the bug thread
>> >> is
>> >> correct then the "fix"
>> >> to make it non-dynamic was because it couldn't be made to work on
>> >> (some)
>> >> linux platforms.
>> >>
>> >> There was some discussion back then that the kludge fix was to be
>> >> preferred
>> >> since that then gave
>> >> us the same behavior on all three platforms.  Also discussions back
>> >> then
>> >> that the Linux platform was
>> >> perhaps the most important to as as it is more "open source".
>> >
>> > I don't think the Audacity developers have ever subscribed to that
>> > view, though it's true that the Linux community, despite their small
>> > numbers, are major contributors to open source software. Quite the
>> > opposite in fact. If an issue 'only' affects Linux, then it is treated
>> > as less important because Linux is a minority platform (see below).
>> >
>> >>
>> >> This has led to a situation for now over seven years where we have
>> >> denied
>> >> the possible dynamic
>> >> behavior of the Play-at-Speed slider to our majority Windows and Mac
>> >> users,
>> >> who combined vastly
>> >> outnumber the relative minority of Linux users.
>> >>
>> >> Fixing this, at least for, Windows and Mac, would be a great benefit to
>> >> thos
>> >> users of Play-at-Speed
>> >> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>> >> would
>> >> benefit VI usrs (who are
>> >> mainly Windows users) as it would enable them to restore and reuse
>> >> their
>> >> Play-at-Speed shortcuts.
>> >
>> > That's not a fix, it's avoidance. On Linux it's a crash issue that has
>> > been known about for years (should be P1 imo, but Linux is a minority
>> > platform).
>> >
>> > Steve
>> >
>> >
>> >> While we are fixing those two bugs, we really need to sort #815:
>> >> Transcription Toolbar Play button should be down after clicking it, not
>> >> Transport Play button
>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>> >> This is currently listed as a P4Enh - but I believe it exhibits
>> >> erroneous,
>> >> misleading, behavior and
>> >> deserves at a least a P3 and a release note.
>> >>
>> >>
>> >>
>> >> -------------------------------------------------------------------------------------------------------------
>> >>
>> >> There is a counter-argument that could be raised ...
>> >>
>> >> Now that we have Scrubbing/Seeking which does have dynamic
>> >> play-at-speed
>> >> control, it could be
>> >> argued that we no longer need the Transcription Toolbar and could
>> >> retire it.
>> >>
>> >> I do not subscribe to this view.
>> >>
>> >> Cheers,
>> >> Peter.
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Check out the vibrant tech community on one of the world's most
>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> >> _______________________________________________
>> >> Audacity-quality mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >>
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Check out the vibrant tech community on one of the world's most
>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Transcription Toolbar

Gale
Administrator
In reply to this post by James Crook
On 5 April 2017 at 12:44, James Crook <[hidden email]> wrote:
> I've not revisited this recently, but my recollection from way back was that
> the play-at-speed code was extremely bad code, reallocating (and leaking) an
> internal time track for every movement of the slider.
>
> Paul's new code for vari-speed used by his scrubbing, in my opinion, should
> be used if we reenable varying play at speed.  That means it is a bit more
> work than just a #define, but still reasonable to request it for 2.2.0.

Do I take it this route would automatically fix
http://bugzilla.audacityteam.org/show_bug.cgi?id=235

"Transcription Toolbar Play-at-Speed slider: Change of playback speed
 auto-restarts from cursor (edit)" ?

Certainly scrubbing is very smooth on my slow Linux netbook and
does not cause Audacity to freeze up like standard playback does.


Gale

> On 4/5/2017 11:47 AM, Peter Sampson wrote:
>
> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>
> Are we talking about 276 being known for years:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>
> That was P1 towards the end of 2.1.3-alpha but then demoted
> back to P2 because James could not yet fix it by making
> monitoring always on.
>
> No I am not talking about that - unless that is what is stopping 133 and 235
> being fixed for our majority Windows and Mac users.
>
> My understanding from reading the 133 bug thread was that we had this
> working
> at least the dynamic speed change - but with the 235 "restart from" issue
> on both
> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>
> We were apparently  unable to make this work properly on Linux - and then
> took the
> decision tothereby remove it from Windows and Mac users - just so that we
> could be
> the same (with degraded behavior) on all three platforms.  Rather this
> should have
> remained open as a Linux bug to be fixed (possibly with a Linux kludge
> pro-tem
> workaround fix).
>
> So what I am appealing for here is that we restore the dynamic
> Play-at-Speed for at
> least Windows and ac - and fix the associated bug #235.  This in the name
> of making
> the Transcription toolbar prperly useful - and more usable by RSI sufferers
> and VI users.
>
> Thanks,
> Peter
>
>
>
> Although we should update PortAudio I don't think there
> is anything merged into it that would directly help 276. Or
> a developer could test the unmerged code for PortAudio's
> pulseaudio API and see if it's going to help.
>
> I am guessing to make P1 "stick" for 276 there would have
> to be a developer committed to work on it again.
>
> Would I read into James's comment on bug 133:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>
> that Paul's work on better memory management might
> have already made the Play-at-Speed slider less prone to
> lock up?
>
>
>
> Gale
>
>
> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
> wrote:
>
> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>
> wrote:
>
> Recent testing and documentation work ahs led to to put some focus on
>
> the
>
> Transcription Toolbar - something I usually overlook as I have no
>
> personal
>
> use
> for it.
>
>
> If we are to have the Transcription Toolbar we really should make sure
>
> that
>
> we
> make it work properly (and indeed as it, sort of, used to work a long
>
> while
>
> ago
> in the erlier 1.3 betas)
>
> This means that we need to fix P3 Bug #133
> Play-at-Speed slider: Change of playback speed is no longer automatic
> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>
> And its closely related cousin would really need fixing too, bug #235
> Transcription Toolbar Play-at-Speed slider: Change of playback speed
> auto-restarts from cursor
> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
> Audacity 1.3.5 shows this behavior.
>
> 133, which has been open since February 2010 was kludge  "fixed" by
>
> removing
>
> the dynamic
> changing of the Play-at-Speed slider.  If my reading of the bug thread
>
> is
>
> correct then the "fix"
> to make it non-dynamic was because it couldn't be made to work on (some)
> linux platforms.
>
> There was some discussion back then that the kludge fix was to be
>
> preferred
>
> since that then gave
> us the same behavior on all three platforms.  Also discussions back then
> that the Linux platform was
> perhaps the most important to as as it is more "open source".
>
> I don't think the Audacity developers have ever subscribed to that
> view, though it's true that the Linux community, despite their small
> numbers, are major contributors to open source software. Quite the
> opposite in fact. If an issue 'only' affects Linux, then it is treated
> as less important because Linux is a minority platform (see below).
>
> This has led to a situation for now over seven years where we have
>
> denied
>
> the possible dynamic
> behavior of the Play-at-Speed slider to our majority Windows and Mac
>
> users,
>
> who combined vastly
> outnumber the relative minority of Linux users.
>
> Fixing this, at least for, Windows and Mac, would be a great benefit to
>
> thos
>
> users of Play-at-Speed
> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>
> would
>
> benefit VI usrs (who are
> mainly Windows users) as it would enable them to restore and reuse their
> Play-at-Speed shortcuts.
>
> That's not a fix, it's avoidance. On Linux it's a crash issue that has
> been known about for years (should be P1 imo, but Linux is a minority
> platform).
>
> Steve
>
>
> While we are fixing those two bugs, we really need to sort #815:
> Transcription Toolbar Play button should be down after clicking it, not
> Transport Play button
> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
> This is currently listed as a P4Enh - but I believe it exhibits
>
> erroneous,
>
> misleading, behavior and
> deserves at a least a P3 and a release note.
>
>
> ------------------------------------------------------------
>
> -------------------------------------------------
>
> There is a counter-argument that could be raised ...
>
> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
> control, it could be
> argued that we no longer need the Transcription Toolbar and could
>
> retire it.
>
> I do not subscribe to this view.
>
> Cheers,
> Peter.
>
>
> ------------------------------------------------------------
>
> ------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------
>
> ------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

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

Re: Transcription Toolbar

Stevethefiddle
In reply to this post by Gale
On 5 April 2017 at 15:35, Gale Andrews <[hidden email]> wrote:

> On 5 April 2017 at 11:47, Peter Sampson <[hidden email]> wrote:
>>
>>
>> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> Are we talking about 276 being known for years:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
>>> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>>>
>>> That was P1 towards the end of 2.1.3-alpha but then demoted
>>> back to P2 because James could not yet fix it by making
>>> monitoring always on.
>>
>>
>> No I am not talking about that - unless that is what is stopping 133 and 235
>> being fixed for our majority Windows and Mac users.
>
> Steve wrote:
>
> "On Linux it's a crash issue that has been known about for years (should be
>  P1 imo, but Linux is a minority platform)."
>
> I don't know what Steve means if not 276.

Yes I'm referring to bug 276.

> And I don't know what Linux
> problem made us remove automatic playback speed change if not 276.
>
> Perhaps one of you would enlighten me?
>
>
>> My understanding from reading the 133 bug thread was that we had this
>> working
>> at least the dynamic speed change - but with the 235 "restart from" issue on
>> both
>> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>>
>> We were apparently  unable to make this work properly on Linux - and then
>> took the
>> decision tothereby remove it from Windows and Mac users - just so that we
>> could be
>> the same (with degraded behavior) on all three platforms.  Rather this
>> should have
>> remained open as a Linux bug to be fixed (possibly with a Linux kludge
>> pro-tem
>> workaround fix).
>>
>> So what I am appealing for here is that we restore the dynamic Play-at-Speed
>> for at
>> least Windows and ac - and fix the associated bug #235.  This in the name of
>> making
>> the Transcription toolbar prperly useful - and more usable by RSI sufferers
>> and VI users.
>
> Al Dimond and James would not do that, AFAIK. They wanted/want
> consistent behaviour on each platform. Steve is saying the same I
> think, and I am more inclined to agree with them than I was, because
> a fix seems closer than it was, even if it's specific to Transcription
> Toolbar and not a fix for 276.
>
>
>
> Gale
>
>
>>> Although we should update PortAudio I don't think there
>>> is anything merged into it that would directly help 276. Or
>>> a developer could test the unmerged code for PortAudio's
>>> pulseaudio API and see if it's going to help.
>>>
>>> I am guessing to make P1 "stick" for 276 there would have
>>> to be a developer committed to work on it again.
>>>
>>> Would I read into James's comment on bug 133:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>>>
>>> that Paul's work on better memory management might
>>> have already made the Play-at-Speed slider less prone to
>>> lock up?
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>> > On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>>> > wrote:
>>> >> Recent testing and documentation work ahs led to to put some focus on
>>> >> the
>>> >> Transcription Toolbar - something I usually overlook as I have no
>>> >> personal
>>> >> use
>>> >> for it.
>>> >>
>>> >>
>>> >> If we are to have the Transcription Toolbar we really should make sure
>>> >> that
>>> >> we
>>> >> make it work properly (and indeed as it, sort of, used to work a long
>>> >> while
>>> >> ago
>>> >> in the erlier 1.3 betas)
>>> >>
>>> >> This means that we need to fix P3 Bug #133
>>> >> Play-at-Speed slider: Change of playback speed is no longer automatic
>>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>>> >>
>>> >> And its closely related cousin would really need fixing too, bug #235
>>> >> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>>> >> auto-restarts from cursor
>>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>>> >> Audacity 1.3.5 shows this behavior.
>>> >>
>>> >> 133, which has been open since February 2010 was kludge  "fixed" by
>>> >> removing
>>> >> the dynamic
>>> >> changing of the Play-at-Speed slider.  If my reading of the bug thread
>>> >> is
>>> >> correct then the "fix"
>>> >> to make it non-dynamic was because it couldn't be made to work on
>>> >> (some)
>>> >> linux platforms.
>>> >>
>>> >> There was some discussion back then that the kludge fix was to be
>>> >> preferred
>>> >> since that then gave
>>> >> us the same behavior on all three platforms.  Also discussions back
>>> >> then
>>> >> that the Linux platform was
>>> >> perhaps the most important to as as it is more "open source".
>>> >
>>> > I don't think the Audacity developers have ever subscribed to that
>>> > view, though it's true that the Linux community, despite their small
>>> > numbers, are major contributors to open source software. Quite the
>>> > opposite in fact. If an issue 'only' affects Linux, then it is treated
>>> > as less important because Linux is a minority platform (see below).
>>> >
>>> >>
>>> >> This has led to a situation for now over seven years where we have
>>> >> denied
>>> >> the possible dynamic
>>> >> behavior of the Play-at-Speed slider to our majority Windows and Mac
>>> >> users,
>>> >> who combined vastly
>>> >> outnumber the relative minority of Linux users.
>>> >>
>>> >> Fixing this, at least for, Windows and Mac, would be a great benefit to
>>> >> thos
>>> >> users of Play-at-Speed
>>> >> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>>> >> would
>>> >> benefit VI usrs (who are
>>> >> mainly Windows users) as it would enable them to restore and reuse
>>> >> their
>>> >> Play-at-Speed shortcuts.
>>> >
>>> > That's not a fix, it's avoidance. On Linux it's a crash issue that has
>>> > been known about for years (should be P1 imo, but Linux is a minority
>>> > platform).
>>> >
>>> > Steve
>>> >
>>> >
>>> >> While we are fixing those two bugs, we really need to sort #815:
>>> >> Transcription Toolbar Play button should be down after clicking it, not
>>> >> Transport Play button
>>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>>> >> This is currently listed as a P4Enh - but I believe it exhibits
>>> >> erroneous,
>>> >> misleading, behavior and
>>> >> deserves at a least a P3 and a release note.
>>> >>
>>> >>
>>> >>
>>> >> -------------------------------------------------------------------------------------------------------------
>>> >>
>>> >> There is a counter-argument that could be raised ...
>>> >>
>>> >> Now that we have Scrubbing/Seeking which does have dynamic
>>> >> play-at-speed
>>> >> control, it could be
>>> >> argued that we no longer need the Transcription Toolbar and could
>>> >> retire it.
>>> >>
>>> >> I do not subscribe to this view.
>>> >>
>>> >> Cheers,
>>> >> Peter.
>>> >>
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> Check out the vibrant tech community on one of the world's most
>>> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> >> _______________________________________________
>>> >> Audacity-quality mailing list
>>> >> [hidden email]
>>> >> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>> >>
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Check out the vibrant tech community on one of the world's most
>>> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> > _______________________________________________
>>> > Audacity-quality mailing list
>>> > [hidden email]
>>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

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

Re: Transcription Toolbar

Peter Sampson-2
In reply to this post by Gale
Gale wrote:
>Al Dimond and James would not do that, AFAIK. They wanted/want
>consistent behaviour on each platform. Steve is saying the same I
>think, and I am more inclined to agree with them than I was, because
>a fix seems closer than it was, even if it's specific to Transcription
>Toolbar and not a fix for 276.

I think we're getting close to vehement agrrement i if we're not there already ;-))

I also don't want to fix up 133/235 with old creaky technology.

But I do want to see the Transcription Toolbar working properly with;
a) dynamic speed contrlol
b) no move back to cursor/play position whe changing speed
c) and working thus on all three platforms
d) The Play-at-Speed button depressed and not the Play button when Transcription
toolbar is in use.


Paul's engine technology in Scrubbing would seem an emminently sensible
tool for this (a, b and c at least) as it seems to work well and smoothly on all
three platforms.

All we need is to find a developer willing to commit some time and effort
to implement this ...


BTW we have always tolerated minor platform differences - mainly down to
Apple's insistence on ploughing its own furrow and doing things differently.

Peter

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

Re: Transcription Toolbar

Stevethefiddle
In reply to this post by Gale
On 5 April 2017 at 15:44, Gale Andrews <[hidden email]> wrote:

> On 5 April 2017 at 12:44, James Crook <[hidden email]> wrote:
>> I've not revisited this recently, but my recollection from way back was that
>> the play-at-speed code was extremely bad code, reallocating (and leaking) an
>> internal time track for every movement of the slider.
>>
>> Paul's new code for vari-speed used by his scrubbing, in my opinion, should
>> be used if we reenable varying play at speed.  That means it is a bit more
>> work than just a #define, but still reasonable to request it for 2.2.0.
>
> Do I take it this route would automatically fix
> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>
> "Transcription Toolbar Play-at-Speed slider: Change of playback speed
>  auto-restarts from cursor (edit)" ?
>
> Certainly scrubbing is very smooth on my slow Linux netbook and
> does not cause Audacity to freeze up like standard playback does.

I'm rarely getting freezes, but scrubbing is not at all smooth on my
new super-fast Ubuntu laptop.

Steve

>
>
> Gale
>
>> On 4/5/2017 11:47 AM, Peter Sampson wrote:
>>
>> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>>
>> Are we talking about 276 being known for years:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
>> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>>
>> That was P1 towards the end of 2.1.3-alpha but then demoted
>> back to P2 because James could not yet fix it by making
>> monitoring always on.
>>
>> No I am not talking about that - unless that is what is stopping 133 and 235
>> being fixed for our majority Windows and Mac users.
>>
>> My understanding from reading the 133 bug thread was that we had this
>> working
>> at least the dynamic speed change - but with the 235 "restart from" issue
>> on both
>> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>>
>> We were apparently  unable to make this work properly on Linux - and then
>> took the
>> decision tothereby remove it from Windows and Mac users - just so that we
>> could be
>> the same (with degraded behavior) on all three platforms.  Rather this
>> should have
>> remained open as a Linux bug to be fixed (possibly with a Linux kludge
>> pro-tem
>> workaround fix).
>>
>> So what I am appealing for here is that we restore the dynamic
>> Play-at-Speed for at
>> least Windows and ac - and fix the associated bug #235.  This in the name
>> of making
>> the Transcription toolbar prperly useful - and more usable by RSI sufferers
>> and VI users.
>>
>> Thanks,
>> Peter
>>
>>
>>
>> Although we should update PortAudio I don't think there
>> is anything merged into it that would directly help 276. Or
>> a developer could test the unmerged code for PortAudio's
>> pulseaudio API and see if it's going to help.
>>
>> I am guessing to make P1 "stick" for 276 there would have
>> to be a developer committed to work on it again.
>>
>> Would I read into James's comment on bug 133:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>>
>> that Paul's work on better memory management might
>> have already made the Play-at-Speed slider less prone to
>> lock up?
>>
>>
>>
>> Gale
>>
>>
>> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
>> wrote:
>>
>> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>>
>> wrote:
>>
>> Recent testing and documentation work ahs led to to put some focus on
>>
>> the
>>
>> Transcription Toolbar - something I usually overlook as I have no
>>
>> personal
>>
>> use
>> for it.
>>
>>
>> If we are to have the Transcription Toolbar we really should make sure
>>
>> that
>>
>> we
>> make it work properly (and indeed as it, sort of, used to work a long
>>
>> while
>>
>> ago
>> in the erlier 1.3 betas)
>>
>> This means that we need to fix P3 Bug #133
>> Play-at-Speed slider: Change of playback speed is no longer automatic
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>>
>> And its closely related cousin would really need fixing too, bug #235
>> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>> auto-restarts from cursor
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>> Audacity 1.3.5 shows this behavior.
>>
>> 133, which has been open since February 2010 was kludge  "fixed" by
>>
>> removing
>>
>> the dynamic
>> changing of the Play-at-Speed slider.  If my reading of the bug thread
>>
>> is
>>
>> correct then the "fix"
>> to make it non-dynamic was because it couldn't be made to work on (some)
>> linux platforms.
>>
>> There was some discussion back then that the kludge fix was to be
>>
>> preferred
>>
>> since that then gave
>> us the same behavior on all three platforms.  Also discussions back then
>> that the Linux platform was
>> perhaps the most important to as as it is more "open source".
>>
>> I don't think the Audacity developers have ever subscribed to that
>> view, though it's true that the Linux community, despite their small
>> numbers, are major contributors to open source software. Quite the
>> opposite in fact. If an issue 'only' affects Linux, then it is treated
>> as less important because Linux is a minority platform (see below).
>>
>> This has led to a situation for now over seven years where we have
>>
>> denied
>>
>> the possible dynamic
>> behavior of the Play-at-Speed slider to our majority Windows and Mac
>>
>> users,
>>
>> who combined vastly
>> outnumber the relative minority of Linux users.
>>
>> Fixing this, at least for, Windows and Mac, would be a great benefit to
>>
>> thos
>>
>> users of Play-at-Speed
>> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>>
>> would
>>
>> benefit VI usrs (who are
>> mainly Windows users) as it would enable them to restore and reuse their
>> Play-at-Speed shortcuts.
>>
>> That's not a fix, it's avoidance. On Linux it's a crash issue that has
>> been known about for years (should be P1 imo, but Linux is a minority
>> platform).
>>
>> Steve
>>
>>
>> While we are fixing those two bugs, we really need to sort #815:
>> Transcription Toolbar Play button should be down after clicking it, not
>> Transport Play button
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>> This is currently listed as a P4Enh - but I believe it exhibits
>>
>> erroneous,
>>
>> misleading, behavior and
>> deserves at a least a P3 and a release note.
>>
>>
>> ------------------------------------------------------------
>>
>> -------------------------------------------------
>>
>> There is a counter-argument that could be raised ...
>>
>> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
>> control, it could be
>> argued that we no longer need the Transcription Toolbar and could
>>
>> retire it.
>>
>> I do not subscribe to this view.
>>
>> Cheers,
>> Peter.
>>
>>
>> ------------------------------------------------------------
>>
>> ------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------
>>
>> ------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

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

Re: Transcription Toolbar

Gale
Administrator
On 5 April 2017 at 16:04, Steve the Fiddle <[hidden email]> wrote:

> On 5 April 2017 at 15:44, Gale Andrews <[hidden email]> wrote:
>> On 5 April 2017 at 12:44, James Crook <[hidden email]> wrote:
>>> I've not revisited this recently, but my recollection from way back was that
>>> the play-at-speed code was extremely bad code, reallocating (and leaking) an
>>> internal time track for every movement of the slider.
>>>
>>> Paul's new code for vari-speed used by his scrubbing, in my opinion, should
>>> be used if we reenable varying play at speed.  That means it is a bit more
>>> work than just a #define, but still reasonable to request it for 2.2.0.
>>
>> Do I take it this route would automatically fix
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>>
>> "Transcription Toolbar Play-at-Speed slider: Change of playback speed
>>  auto-restarts from cursor (edit)" ?
>>
>> Certainly scrubbing is very smooth on my slow Linux netbook and
>> does not cause Audacity to freeze up like standard playback does.
>
> I'm rarely getting freezes, but scrubbing is not at all smooth on my
> new super-fast Ubuntu laptop.
>
> Steve

Nor is it smooth on my Mac mini (about 2 GHz, 4 GB RAM). It's
OK on Ubuntu 16.04 and on Windows 10, both of those on my
laptop (2.4 GHz, 6 GB RAM).

I don't think my Mac was like that immediately after Paul implemented
the scrubbing engine.



Gale


>>> On 4/5/2017 11:47 AM, Peter Sampson wrote:
>>>
>>> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> Are we talking about 276 being known for years:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
>>> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>>>
>>> That was P1 towards the end of 2.1.3-alpha but then demoted
>>> back to P2 because James could not yet fix it by making
>>> monitoring always on.
>>>
>>> No I am not talking about that - unless that is what is stopping 133 and 235
>>> being fixed for our majority Windows and Mac users.
>>>
>>> My understanding from reading the 133 bug thread was that we had this
>>> working
>>> at least the dynamic speed change - but with the 235 "restart from" issue
>>> on both
>>> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>>>
>>> We were apparently  unable to make this work properly on Linux - and then
>>> took the
>>> decision tothereby remove it from Windows and Mac users - just so that we
>>> could be
>>> the same (with degraded behavior) on all three platforms.  Rather this
>>> should have
>>> remained open as a Linux bug to be fixed (possibly with a Linux kludge
>>> pro-tem
>>> workaround fix).
>>>
>>> So what I am appealing for here is that we restore the dynamic
>>> Play-at-Speed for at
>>> least Windows and ac - and fix the associated bug #235.  This in the name
>>> of making
>>> the Transcription toolbar prperly useful - and more usable by RSI sufferers
>>> and VI users.
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>>
>>> Although we should update PortAudio I don't think there
>>> is anything merged into it that would directly help 276. Or
>>> a developer could test the unmerged code for PortAudio's
>>> pulseaudio API and see if it's going to help.
>>>
>>> I am guessing to make P1 "stick" for 276 there would have
>>> to be a developer committed to work on it again.
>>>
>>> Would I read into James's comment on bug 133:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>>>
>>> that Paul's work on better memory management might
>>> have already made the Play-at-Speed slider less prone to
>>> lock up?
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>>>
>>> wrote:
>>>
>>> Recent testing and documentation work ahs led to to put some focus on
>>>
>>> the
>>>
>>> Transcription Toolbar - something I usually overlook as I have no
>>>
>>> personal
>>>
>>> use
>>> for it.
>>>
>>>
>>> If we are to have the Transcription Toolbar we really should make sure
>>>
>>> that
>>>
>>> we
>>> make it work properly (and indeed as it, sort of, used to work a long
>>>
>>> while
>>>
>>> ago
>>> in the erlier 1.3 betas)
>>>
>>> This means that we need to fix P3 Bug #133
>>> Play-at-Speed slider: Change of playback speed is no longer automatic
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>>>
>>> And its closely related cousin would really need fixing too, bug #235
>>> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>>> auto-restarts from cursor
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>>> Audacity 1.3.5 shows this behavior.
>>>
>>> 133, which has been open since February 2010 was kludge  "fixed" by
>>>
>>> removing
>>>
>>> the dynamic
>>> changing of the Play-at-Speed slider.  If my reading of the bug thread
>>>
>>> is
>>>
>>> correct then the "fix"
>>> to make it non-dynamic was because it couldn't be made to work on (some)
>>> linux platforms.
>>>
>>> There was some discussion back then that the kludge fix was to be
>>>
>>> preferred
>>>
>>> since that then gave
>>> us the same behavior on all three platforms.  Also discussions back then
>>> that the Linux platform was
>>> perhaps the most important to as as it is more "open source".
>>>
>>> I don't think the Audacity developers have ever subscribed to that
>>> view, though it's true that the Linux community, despite their small
>>> numbers, are major contributors to open source software. Quite the
>>> opposite in fact. If an issue 'only' affects Linux, then it is treated
>>> as less important because Linux is a minority platform (see below).
>>>
>>> This has led to a situation for now over seven years where we have
>>>
>>> denied
>>>
>>> the possible dynamic
>>> behavior of the Play-at-Speed slider to our majority Windows and Mac
>>>
>>> users,
>>>
>>> who combined vastly
>>> outnumber the relative minority of Linux users.
>>>
>>> Fixing this, at least for, Windows and Mac, would be a great benefit to
>>>
>>> thos
>>>
>>> users of Play-at-Speed
>>> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>>>
>>> would
>>>
>>> benefit VI usrs (who are
>>> mainly Windows users) as it would enable them to restore and reuse their
>>> Play-at-Speed shortcuts.
>>>
>>> That's not a fix, it's avoidance. On Linux it's a crash issue that has
>>> been known about for years (should be P1 imo, but Linux is a minority
>>> platform).
>>>
>>> Steve
>>>
>>>
>>> While we are fixing those two bugs, we really need to sort #815:
>>> Transcription Toolbar Play button should be down after clicking it, not
>>> Transport Play button
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>>> This is currently listed as a P4Enh - but I believe it exhibits
>>>
>>> erroneous,
>>>
>>> misleading, behavior and
>>> deserves at a least a P3 and a release note.
>>>
>>>
>>> ------------------------------------------------------------
>>>
>>> -------------------------------------------------
>>>
>>> There is a counter-argument that could be raised ...
>>>
>>> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
>>> control, it could be
>>> argued that we no longer need the Transcription Toolbar and could
>>>
>>> retire it.
>>>
>>> I do not subscribe to this view.
>>>
>>> Cheers,
>>> Peter.
>>>
>>>
>>> ------------------------------------------------------------
>>>
>>> ------------------
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------
>>>
>>> ------------------
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

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

Request for 2.2.0

Cliff Scott
In reply to this post by Stevethefiddle
Not sure where to lodge this request. It may already be part of an existing enh item, but I've not seen it.

Request: Audacity at present does not have any visible means that I know of, to show that the current project has unsaved changes. It seems to me as if this would be a useful enhancement for all platforms. Most software I use, and have used, have some means of indicating such. Mac apps have for quite a while just put a dot in the red button at the top left of the app's window. Once saved the button returns to the no dot version, but as soon as a change is made the dot appears. Some software put the word "edited" in the title bar. Others put something at the bottom of the window. Does anyone else think this is useful? It seems to me that it should be a simple thing to do since Audacity already knows it has unsaved changes.

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

Re: Transcription Toolbar

Peter Sampson-2
In reply to this post by Gale
Scrubbing is smooth at varying speeds on both of my laptops
W10 and Sierra - Seeking is not smooth, but is is not intended
to be smooth.

Peter.


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

Re: Request for 2.2.0

Peter Sampson-2
In reply to this post by Cliff Scott
Sounds like a nice idea to me

Peter

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

Re: Request for 2.2.0

Gale
Administrator
In reply to this post by Cliff Scott
I see some pitfalls. I am sure Cliff asked before.

I am guessing the typical behaviour on Windows and Linux would be to
put an asterisk in the Title Bar.

But do you propose we see this indication just for already saved projects
or also for the first action that makes an empty workspace dirty?

If the indication did not match with "dirty" I think it could be
confusing in its
own right.

And if it was only used for already saved projects, it could confuse those
who think that we "open" audio files and so would expect the indication
when importing audio.

If it is not agreed as an enh for Bugzilla then you could still put it on Wiki
Feature Requests, as long as the request is clear.



Gale


On 5 April 2017 at 16:32, Cliff Scott <[hidden email]> wrote:

> Not sure where to lodge this request. It may already be part of an existing enh item, but I've not seen it.
>
> Request: Audacity at present does not have any visible means that I know of, to show that the current project has unsaved changes. It seems to me as if this would be a useful enhancement for all platforms. Most software I use, and have used, have some means of indicating such. Mac apps have for quite a while just put a dot in the red button at the top left of the app's window. Once saved the button returns to the no dot version, but as soon as a change is made the dot appears. Some software put the word "edited" in the title bar. Others put something at the bottom of the window. Does anyone else think this is useful? It seems to me that it should be a simple thing to do since Audacity already knows it has unsaved changes.
>
> Cliff
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

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

Re: Transcription Toolbar

Cliff Scott
In reply to this post by Stevethefiddle
Seems to sound smooth here on my pretty fast Mac, but the cursor movement is quite jumpy if at "Zoom Normal". More like the cursor used to be during record until that was fixed. Does this need the same fix?

Noticed an interesting thing that's not a big deal I suppose, but I was trying the scrub on a voice track then opened a now window with a music track and when starting scrub in the music window there was about a second of the voice track then the music started. Like there was some of the voice track left in a buffer.

Cliff

> On Apr 5, 2017, at 10:04 AM, Steve the Fiddle <[hidden email]> wrote:
>
> On 5 April 2017 at 15:44, Gale Andrews <[hidden email]> wrote:
>> On 5 April 2017 at 12:44, James Crook <[hidden email]> wrote:
>>> I've not revisited this recently, but my recollection from way back was that
>>> the play-at-speed code was extremely bad code, reallocating (and leaking) an
>>> internal time track for every movement of the slider.
>>>
>>> Paul's new code for vari-speed used by his scrubbing, in my opinion, should
>>> be used if we reenable varying play at speed.  That means it is a bit more
>>> work than just a #define, but still reasonable to request it for 2.2.0.
>>
>> Do I take it this route would automatically fix
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>>
>> "Transcription Toolbar Play-at-Speed slider: Change of playback speed
>> auto-restarts from cursor (edit)" ?
>>
>> Certainly scrubbing is very smooth on my slow Linux netbook and
>> does not cause Audacity to freeze up like standard playback does.
>
> I'm rarely getting freezes, but scrubbing is not at all smooth on my
> new super-fast Ubuntu laptop.
>
> Steve
>
>>
>>
>> Gale
>>
>>> On 4/5/2017 11:47 AM, Peter Sampson wrote:
>>>
>>> On Tue, Apr 4, 2017 at 7:48 PM, Gale Andrews <[hidden email]> wrote:
>>>
>>> Are we talking about 276 being known for years:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=276
>>> "PULSE-AUDIO issues. Freeze repeatedly starting/stopping streams"?
>>>
>>> That was P1 towards the end of 2.1.3-alpha but then demoted
>>> back to P2 because James could not yet fix it by making
>>> monitoring always on.
>>>
>>> No I am not talking about that - unless that is what is stopping 133 and 235
>>> being fixed for our majority Windows and Mac users.
>>>
>>> My understanding from reading the 133 bug thread was that we had this
>>> working
>>> at least the dynamic speed change - but with the 235 "restart from" issue
>>> on both
>>> Windows and Mac - and testing on 1.3.5 shows that to be the case.
>>>
>>> We were apparently  unable to make this work properly on Linux - and then
>>> took the
>>> decision tothereby remove it from Windows and Mac users - just so that we
>>> could be
>>> the same (with degraded behavior) on all three platforms.  Rather this
>>> should have
>>> remained open as a Linux bug to be fixed (possibly with a Linux kludge
>>> pro-tem
>>> workaround fix).
>>>
>>> So what I am appealing for here is that we restore the dynamic
>>> Play-at-Speed for at
>>> least Windows and ac - and fix the associated bug #235.  This in the name
>>> of making
>>> the Transcription toolbar prperly useful - and more usable by RSI sufferers
>>> and VI users.
>>>
>>> Thanks,
>>> Peter
>>>
>>>
>>>
>>> Although we should update PortAudio I don't think there
>>> is anything merged into it that would directly help 276. Or
>>> a developer could test the unmerged code for PortAudio's
>>> pulseaudio API and see if it's going to help.
>>>
>>> I am guessing to make P1 "stick" for 276 there would have
>>> to be a developer committed to work on it again.
>>>
>>> Would I read into James's comment on bug 133:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133#c8
>>>
>>> that Paul's work on better memory management might
>>> have already made the Play-at-Speed slider less prone to
>>> lock up?
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4 April 2017 at 15:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>> On 4 April 2017 at 14:12, Peter Sampson <[hidden email]>
>>>
>>> wrote:
>>>
>>> Recent testing and documentation work ahs led to to put some focus on
>>>
>>> the
>>>
>>> Transcription Toolbar - something I usually overlook as I have no
>>>
>>> personal
>>>
>>> use
>>> for it.
>>>
>>>
>>> If we are to have the Transcription Toolbar we really should make sure
>>>
>>> that
>>>
>>> we
>>> make it work properly (and indeed as it, sort of, used to work a long
>>>
>>> while
>>>
>>> ago
>>> in the erlier 1.3 betas)
>>>
>>> This means that we need to fix P3 Bug #133
>>> Play-at-Speed slider: Change of playback speed is no longer automatic
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=133
>>>
>>> And its closely related cousin would really need fixing too, bug #235
>>> Transcription Toolbar Play-at-Speed slider: Change of playback speed
>>> auto-restarts from cursor
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=235
>>> Audacity 1.3.5 shows this behavior.
>>>
>>> 133, which has been open since February 2010 was kludge  "fixed" by
>>>
>>> removing
>>>
>>> the dynamic
>>> changing of the Play-at-Speed slider.  If my reading of the bug thread
>>>
>>> is
>>>
>>> correct then the "fix"
>>> to make it non-dynamic was because it couldn't be made to work on (some)
>>> linux platforms.
>>>
>>> There was some discussion back then that the kludge fix was to be
>>>
>>> preferred
>>>
>>> since that then gave
>>> us the same behavior on all three platforms.  Also discussions back then
>>> that the Linux platform was
>>> perhaps the most important to as as it is more "open source".
>>>
>>> I don't think the Audacity developers have ever subscribed to that
>>> view, though it's true that the Linux community, despite their small
>>> numbers, are major contributors to open source software. Quite the
>>> opposite in fact. If an issue 'only' affects Linux, then it is treated
>>> as less important because Linux is a minority platform (see below).
>>>
>>> This has led to a situation for now over seven years where we have
>>>
>>> denied
>>>
>>> the possible dynamic
>>> behavior of the Play-at-Speed slider to our majority Windows and Mac
>>>
>>> users,
>>>
>>> who combined vastly
>>> outnumber the relative minority of Linux users.
>>>
>>> Fixing this, at least for, Windows and Mac, would be a great benefit to
>>>
>>> thos
>>>
>>> users of Play-at-Speed
>>> who suffer from RSI.  Plus, as Gale points out in the bug thread, it
>>>
>>> would
>>>
>>> benefit VI usrs (who are
>>> mainly Windows users) as it would enable them to restore and reuse their
>>> Play-at-Speed shortcuts.
>>>
>>> That's not a fix, it's avoidance. On Linux it's a crash issue that has
>>> been known about for years (should be P1 imo, but Linux is a minority
>>> platform).
>>>
>>> Steve
>>>
>>>
>>> While we are fixing those two bugs, we really need to sort #815:
>>> Transcription Toolbar Play button should be down after clicking it, not
>>> Transport Play button
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=815
>>> This is currently listed as a P4Enh - but I believe it exhibits
>>>
>>> erroneous,
>>>
>>> misleading, behavior and
>>> deserves at a least a P3 and a release note.
>>>
>>>
>>> ------------------------------------------------------------
>>>
>>> -------------------------------------------------
>>>
>>> There is a counter-argument that could be raised ...
>>>
>>> Now that we have Scrubbing/Seeking which does have dynamic play-at-speed
>>> control, it could be
>>> argued that we no longer need the Transcription Toolbar and could
>>>
>>> retire it.
>>>
>>> I do not subscribe to this view.
>>>
>>> Cheers,
>>> Peter.
>>>
>>>
>>> ------------------------------------------------------------
>>>
>>> ------------------
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------
>>>
>>> ------------------
>>>
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------
>>> ------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


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

Re: Request for 2.2.0

Cliff Scott
In reply to this post by Gale

> On Apr 5, 2017, at 11:23 AM, Gale Andrews <[hidden email]> wrote:
>
> I see some pitfalls. I am sure Cliff asked before.

My proposal is:

Only put up the indications if Audacity, as it is now, would popup up its "save/cancel/don't save" dialog if the Audacity active window was requested to be closed or an Audacity Quit was requested.

>
> I am guessing the typical behaviour on Windows and Linux would be to
> put an asterisk in the Title Bar.
>
> But do you propose we see this indication just for already saved projects
> or also for the first action that makes an empty workspace dirty?

I believe that the normal for most software is to put up the indication as soon as anything is done that would be lost if the program was quit which would mean that opening an already saved project would not put up the indication. Playing the project would not cause the indication. Importing an mp3 file would cause the indication because the import would be lost if closed without saving. Of course any editing, recording, etc.  would cause the indication. This is exactly how Audacity handles its save/don't save/cancel dialog.

>
> If the indication did not match with "dirty" I think it could be
> confusing in its
> own right.

Correct. "Dirty" in Audacity would mean that it would popup the dialog to Save etc. on quit, correct?

>
> And if it was only used for already saved projects, it could confuse those
> who think that we "open" audio files and so would expect the indication
> when importing audio.

No, it would come up as soon as a new recording started or a file was imported since quitting Audacity at that point without saving would lose what the user had just done. Just opening an already saved project would not by itself bring up the indication. Of course the indication would by per open window so with several windows open only those with unsaved changes would have the indication.

>
> If it is not agreed as an enh for Bugzilla then you could still put it on Wiki
> Feature Requests, as long as the request is clear.

Ok, I'm hoping for a discussion to arrive at a clear definition so it can be entered as an enh or a Feature Request. Since this, in my experience on the Mac, is in most if not all apps it seems to me to be more than just a "nice to have" thing, but of course Audacity has existed for quite a while without it.

To my thinking it is extremely simple, just key off (basically display) the Audacity "dirty" flag so it's warning the user that there are unsaved changes to whatever is going on in that window that would be lost on quitting without a save.

Cliff

>
>
>
> Gale
>
>
> On 5 April 2017 at 16:32, Cliff Scott <[hidden email]> wrote:
>> Not sure where to lodge this request. It may already be part of an existing enh item, but I've not seen it.
>>
>> Request: Audacity at present does not have any visible means that I know of, to show that the current project has unsaved changes. It seems to me as if this would be a useful enhancement for all platforms. Most software I use, and have used, have some means of indicating such. Mac apps have for quite a while just put a dot in the red button at the top left of the app's window. Once saved the button returns to the no dot version, but as soon as a change is made the dot appears. Some software put the word "edited" in the title bar. Others put something at the bottom of the window. Does anyone else think this is useful? It seems to me that it should be a simple thing to do since Audacity already knows it has unsaved changes.
>>
>> Cliff
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


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