[Audacity-quality] Sync-lock icons in Note tracks and spectrograms (Bug 1671)

[Paul Licameli <paul.licameli@gm...>]

I was asked for an opinion about the new sync-lock wallpaper in Midi and
Spectrogram -- a problem on which I had been inclined to doer-decides
neutrality, and willing to leave unfixed in 2.2.0.

Short verdict:  I say let it all stand.

First, Note tracks.  It looks disctinct enough to me, in all themes, at
certain (time) zoom levels.  I do notice that it is possible to zoom out
enough that the verical bars become so dense that the clocks are not
distinguishable. But then I think this might only call for an enhancement
of Note track drawing code in future.  Perhaps the vertical bars should be
decimated depending on zoom level, somewhat as the interval of ticks on the
time ruler is adaptive to zoom level too.

The other zooming (using vertical ruler) -- If the time zoom leaves the
clocks noticeable, then I find no problem even at extreme vertical
zoom-out: clocks remain visible.

Secondly, spectrograms.  If I view white noise, which makes a red
snowstorm, then the clocks are almost impossible to see.  If I view a
rising chirp with square no-alias waveform, the clocks are very clear.

If I try something more realistic, the recording of some voice, and zooming
in on the bottom 2 kHz, then the clocks look good enough to me, except in
Light theme, where they are rather faint.

The commit comment at 3d5a4e8a45c66bf78356b8d79f12f72c67656cbb says the
EXPERIMENTAL could turn it off "In case we decide too much detail is lost
in low intensity spectrogram."

This was not the difficulty I was considering.  I think this intersection
of two intermediate-to-advanced Audacity features is very unlikely to
inconvenience anyone in practice.  If I really wanted to study that low
intensity spectrogram, I would unselect all anyway.

I see sync-lock clocks rather as just a warning and reminder that what you
are about to do to this track, might also affect that track.  So for this
purpose, I see improvement, although as others have noted it isn't ideal
and a visual redesign may be in the future as part of bigger things.

James speaks of tree-structuring of the track list, though I am not sure I
follow all of that.

PRL

[Audacity-quality] New Flags

[James Crook <crookj@in...>]

1. I've created a new Bugzilla flag  "Must-Test-All-OS"

You can see it in use on 
http://bugzilla.audacityteam.org/show_bug.cgi?id=1664

I think the assumption should be that the majority of bugs need to be 
tested only on a single OS.  RepeatableAll bugs, mostly if it works on 
one platform it will work on the others too.  For Bugs that are platform 
specific, the bug title will indicate the problematic OS, and usually a 
fix will not disrupt the feature on the unaffected OS'es.

This flag can be put on bugs to clarify.  If a bug is Must-Test-All-OS+ 
then someone who placed the flag thinks the bug fix must be tested on 
other platforms.


2. I've created a new Bugzilla flag "Vote-To-Keep" which is about 
keeping a bug that at least one person thinks is a WONTFIX or INVALID, 
but where they want opinions from others too, rather than just closing 
it on the spot.  That was in my previous email.


3. Finally Test-OK-Win+ etc now can be placed by more than one person, 
so if two testers do both confirm that a bug is tested on windows, both 
testings and both flags can be shown in the bug.

Re: [Audacity-quality] Fwd: [Bug 1165] Enh: Keyboard preference columns are not resizeable

[James Crook <crookj@in...>]

On 8/18/2017 5:32 PM, Steve the Fiddle wrote:
> What does "Vote-To-Keep" flag mean?
Hover over the flag name for a description...

I'd like to close bug 1165 as WONTFIX, as I don't think it makes a lot 
of difference whether we have resizable columns (a grid) or use a 
scrollbar as now. http://bugzilla.audacityteam.org/show_bug.cgi?id=1165
Even for very very very long effects paths, right now can just use the 
scroll bar to read the full name and see the bindings. Resizable columns 
would entail truncating the paths, or wrapping the text to fit (leading 
to very tall boxes).

However I don't think I have a God given right to just close the bug, 
simply because I don't agree.  I guess, Steve, you could also put a 
Vote-To-Keep flag, but give it a + rather than a -.
I don't think we will actually close bugs on a simple count.  E.g, even 
if the count is -3 +1.  If however the count is +3 -1, then that might 
spark some discussion on quality and lead to a better solution than any 
suggested so far.
Equally there may be some bugs that rapidly gather -4, and go on to be 
marked INVALID.

--James.






>
> Steve
>
>
> ---------- Forwarded message ----------
> From: <bugzilla-daemon@...>
> Date: 18 August 2017 at 17:19
> Subject: [Bug 1165] Enh: Keyboard preference columns are not resizeable
> To: stevethefiddle@...
>
>
> James Crook <james.k.crook@...> changed bug 1165
> <http://bugzilla.audacityteam.org/show_bug.cgi?id=1165>;
> What Removed Added
> Flags   Vote-To-Keep-
>
> ------------------------------
> You are receiving this mail because:
>
>     - You are on the CC list for the bug.
>     - You reported the bug.
>
>
>
> ------------------------------------------------------------------------------
> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

[Audacity-quality] Fwd: [Bug 1165] Enh: Keyboard preference columns are not resizeable

[Steve the Fiddle <stevethefiddle@gm...>]

What does "Vote-To-Keep" flag mean?

Steve


---------- Forwarded message ----------
From: <bugzilla-daemon@...>
Date: 18 August 2017 at 17:19
Subject: [Bug 1165] Enh: Keyboard preference columns are not resizeable
To: stevethefiddle@...


James Crook <james.k.crook@...> changed bug 1165
<http://bugzilla.audacityteam.org/show_bug.cgi?id=1165>;
What Removed Added
Flags   Vote-To-Keep-

------------------------------
You are receiving this mail because:

   - You are on the CC list for the bug.
   - You reported the bug.

Re: [Audacity-quality] Apologies... https on bugzilla.

[Arturo 'Buanzo' Busleiman <buanzo@bu...>]

Done. Cache flushed.

On Fri, Aug 18, 2017 at 12:37 PM, Arturo 'Buanzo' Busleiman <
buanzo@...> wrote:

> On it.
>
>
> On Fri, Aug 18, 2017 at 12:34 PM, James Crook <crookj@...> wrote:
>
>> I just tested that bugzilla worked on https, (it did) and then set
>> bugzilla to redirect to https.
>>
>> I must have done something wrong, as we now get infinite redirects.
>> Sorry for that.  Unfortunately I can't sort it out as I don't now have
>> access to bugzilla....
>>
>> Buanzo, can you edit the data/params file, and change ssl_redirect back
>> to 0?  Thanks.
>>
>> --James.
>>
>>
>

Re: [Audacity-quality] Apologies... https on bugzilla.

[Arturo 'Buanzo' Busleiman <buanzo@bu...>]

On it.


On Fri, Aug 18, 2017 at 12:34 PM, James Crook <crookj@...> wrote:

> I just tested that bugzilla worked on https, (it did) and then set
> bugzilla to redirect to https.
>
> I must have done something wrong, as we now get infinite redirects.  Sorry
> for that.  Unfortunately I can't sort it out as I don't now have access to
> bugzilla....
>
> Buanzo, can you edit the data/params file, and change ssl_redirect back to
> 0?  Thanks.
>
> --James.
>
>

Re: [Audacity-quality] Apologies... https on bugzilla.

[Arturo 'Buanzo' Busleiman <buanzo@bu...>]

Yes, that is a great feature.

Thank you James.


On Fri, Aug 18, 2017 at 12:47 PM, James Crook <crookj@...> wrote:

> Great.  Back in business, and it is redirecting to https now too :-)
>
> Thanks Buanzo!  And I noticed cloudflare gave us a cached version whilst
> we were offline, so that is working well too.
>
> --James.
>
>
> On 8/18/2017 4:38 PM, Arturo 'Buanzo' Busleiman wrote:
>
>> Done. Cache flushed.
>>
>> On Fri, Aug 18, 2017 at 12:37 PM, Arturo 'Buanzo' Busleiman <
>> buanzo@...> wrote:
>>
>> On it.
>>>
>>>
>>> On Fri, Aug 18, 2017 at 12:34 PM, James Crook <crookj@...> wrote:
>>>
>>> I just tested that bugzilla worked on https, (it did) and then set
>>>> bugzilla to redirect to https.
>>>>
>>>> I must have done something wrong, as we now get infinite redirects.
>>>> Sorry for that.  Unfortunately I can't sort it out as I don't now have
>>>> access to bugzilla....
>>>>
>>>> Buanzo, can you edit the data/params file, and change ssl_redirect back
>>>> to 0?  Thanks.
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>

Re: [Audacity-quality] Apologies... https on bugzilla.

[James Crook <crookj@in...>]

Great.  Back in business, and it is redirecting to https now too :-)

Thanks Buanzo!  And I noticed cloudflare gave us a cached version whilst 
we were offline, so that is working well too.

--James.

On 8/18/2017 4:38 PM, Arturo 'Buanzo' Busleiman wrote:
> Done. Cache flushed.
>
> On Fri, Aug 18, 2017 at 12:37 PM, Arturo 'Buanzo' Busleiman <
> buanzo@...> wrote:
>
>> On it.
>>
>>
>> On Fri, Aug 18, 2017 at 12:34 PM, James Crook <crookj@...> wrote:
>>
>>> I just tested that bugzilla worked on https, (it did) and then set
>>> bugzilla to redirect to https.
>>>
>>> I must have done something wrong, as we now get infinite redirects.
>>> Sorry for that.  Unfortunately I can't sort it out as I don't now have
>>> access to bugzilla....
>>>
>>> Buanzo, can you edit the data/params file, and change ssl_redirect back
>>> to 0?  Thanks.
>>>
>>> --James.
>>>
>>>

[Audacity-quality] Apologies... https on bugzilla.

[James Crook <crookj@in...>]

I just tested that bugzilla worked on https, (it did) and then set 
bugzilla to redirect to https.

I must have done something wrong, as we now get infinite redirects.  
Sorry for that.  Unfortunately I can't sort it out as I don't now have 
access to bugzilla....

Buanzo, can you edit the data/params file, and change ssl_redirect back 
to 0?  Thanks.

--James.

Re: [Audacity-quality] More about bugs and release notes

[James Crook <crookj@in...>]

Bill, there is a quicker easier way!

http://bugzilla.audacityteam.org/buglist.cgi?bug_status=DEVEL%20-%20FIX%20MADE&list_id=11348&order=priority%2Cbug_id&priority=P1&priority=P2&priority=P3&product=Audacity&query_based_on=&query_format=advanced&resolution=---

So accordingly I see 19 bugs that need to be tested and possibly marked 
RESOLVED that would otherwise generate release notes.  1661 has been 
reopened (Peter found that the fix did not work), and 1623 is fixed (I 
marked it as test_single_OS) , so are not in that list.

--James.


On 8/17/2017 8:58 PM, Bill Wharrie wrote:
> I’ve spent a while trolling through the commits with “Bug” in the title (back to June 28) and relating them to bugzilla. In the process I’ve identified some work it seems needs to be done.
>
> I hope this is not a duplication of someone else’s efforts!
>
> Bug 1608 should be set to RESOLVED to suppress release note, if indeed resolved
>
> Bug 1702 should be set to RESOLVED or a release note should be entered
>
> Bug 1567 should be set to RESOLVED or a release note should be entered
>
> Bug 290 should be set to RESOLVED to suppress release note, if indeed resolved; release note should be updated with latest advice
>
> Bug 1227 should be set to RESOLVED to suppress release note, if indeed resolved; release note should be updated with latest advice
>
> Bug 1404 should be set to RESOLVED or a release note should be entered
>
> Bug 1502 should be set to RESOLVED to suppress release note, if indeed resolved
>
> Bug 1623 needs Linux test to RESOLVE
>
> Bug 1661 - could failure to confirm fix be due to lack of language files in the nightly?
>
> I updated the release note in bug 665 (AUNBandEQ causes crash) since 1603 is RESOLVED
>
> — Bill

[Audacity-quality] More about bugs and release notes

[Bill Wharrie <billwh@go...>]

I’ve spent a while trolling through the commits with “Bug” in the title (back to June 28) and relating them to bugzilla. In the process I’ve identified some work it seems needs to be done.

I hope this is not a duplication of someone else’s efforts!

Bug 1608 should be set to RESOLVED to suppress release note, if indeed resolved

Bug 1702 should be set to RESOLVED or a release note should be entered

Bug 1567 should be set to RESOLVED or a release note should be entered

Bug 290 should be set to RESOLVED to suppress release note, if indeed resolved; release note should be updated with latest advice

Bug 1227 should be set to RESOLVED to suppress release note, if indeed resolved; release note should be updated with latest advice

Bug 1404 should be set to RESOLVED or a release note should be entered

Bug 1502 should be set to RESOLVED to suppress release note, if indeed resolved 

Bug 1623 needs Linux test to RESOLVE

Bug 1661 - could failure to confirm fix be due to lack of language files in the nightly?

I updated the release note in bug 665 (AUNBandEQ causes crash) since 1603 is RESOLVED

— Bill

Re: [Audacity-quality] Bug 33 release note - themes

[Bill Wharrie <billwh@go...>]

Thanks. I removed the reference to the invisible editing cursor in High Contrast. 

Perhaps now the release notes field for bug 33 is complete.

— Bill

> On 2017/08/17, at 5:35 AM, Peter Sampson <petersampsonaudacity@...> wrote:
> 
> 
> 
> On Thu, Aug 17, 2017 at 8:43 AM, James Crook <crookj@... <mailto:crookj@...>> wrote:
> Yes.  I fixed it.  That would be early days of the Selection toolbar.  That text can be removed.
> 
> I removed that text from the Release Note field in Bug #33
> 
> Peter.
> 
>  
> 
> 
> On 8/17/2017 2:23 AM, Bill Wharrie wrote:
> It says, in part:
> “Some interface text or markings remain in black when using High Contrast light-on-dark themes, so cannot be viewed properly. However you can now choose a light-on-dark "Hi Contrast" theme for Audacity in Interface Preferences”
> 
> I can’t find the bug this relates to. There is no “Hi Contrast” theme. I think this has been fixed.
> 
> — Bill
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>;
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@... <mailto:Audacity-quality@...>
> https://lists.sourceforge.net/lists/listinfo/audacity-quality <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://slashdot.org/>;! http://sdm.link/slashdot_______________________________________________ <http://sdm.link/slashdot_______________________________________________>;
> Audacity-quality mailing list
> Audacity-quality@... <mailto:Audacity-quality@...>
> https://lists.sourceforge.net/lists/listinfo/audacity-quality <https://lists.sourceforge.net/lists/listinfo/audacity-quality>;

Re: [Audacity-quality] Bug 33 release note - themes

[Peter Sampson <petersampsonaudacity@gm...>]

On Thu, Aug 17, 2017 at 8:43 AM, James Crook <crookj@...> wrote:

> Yes.  I fixed it.  That would be early days of the Selection toolbar.
> That text can be removed.


I removed that text from the Release Note field in Bug #33

Peter.



>
>
> On 8/17/2017 2:23 AM, Bill Wharrie wrote:
>
>> It says, in part:
>> “Some interface text or markings remain in black when using High Contrast
>> light-on-dark themes, so cannot be viewed properly. However you can now
>> choose a light-on-dark "Hi Contrast" theme for Audacity in Interface
>> Preferences”
>>
>> I can’t find the bug this relates to. There is no “Hi Contrast” theme. I
>> think this has been fixed.
>>
>> — Bill
>>
>
>
> ------------------------------------------------------------
> ------------------
> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

Re: [Audacity-quality] Bug 33 release note - themes

[James Crook <crookj@in...>]

Yes.  I fixed it.  That would be early days of the Selection toolbar.  
That text can be removed.

On 8/17/2017 2:23 AM, Bill Wharrie wrote:
> It says, in part:
> “Some interface text or markings remain in black when using High Contrast light-on-dark themes, so cannot be viewed properly. However you can now choose a light-on-dark "Hi Contrast" theme for Audacity in Interface Preferences”
>
> I can’t find the bug this relates to. There is no “Hi Contrast” theme. I think this has been fixed.
>
> — Bill

Re: [Audacity-quality] Run Benchmark - can we retain this for the 2.2.0 release build

[Vaughan Johnson <v.audacity@gm...>]

"Carefully" is just about using flags, e.g., IS_BETA, so totally automated.

But I'm +1 on including it. :-)

Thanks,
Vaughan


On Wed, Aug 16, 2017 at 4:50 AM, Peter Sampson <
petersampsonaudacity@...> wrote:

> As part of a trawl of the P1s in the Manual today, I responded to a P1
> from Bill
> on this page (you need to be logged in to see the ednote):
> http://alphamanual.audacityteam.org/man/Help_Menu:_Tools#run_benchmark
>
> AFAIK we always "carefully" remove Run Benchmark from the release versions
> and
> only have it available in alpha and beta versions.
>
> I've never been sure why we bother to do this - it lookks like a useful
> little tool to me
> and it would do no harm having it there.  It does give users an ide of the
> maximum
> number of tracks they could consider using.
>
> So - can I please lobby for having this command retained in the 2.2.0
> release version.
> This must be an easy fix.
>
> ELSE we will need to update that Manual page - menu image and the text.
>
> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>

[Audacity-quality] Bug 33 release note - themes

[Bill Wharrie <billwh@go...>]

It says, in part:
“Some interface text or markings remain in black when using High Contrast light-on-dark themes, so cannot be viewed properly. However you can now choose a light-on-dark "Hi Contrast" theme for Audacity in Interface Preferences”

I can’t find the bug this relates to. There is no “Hi Contrast” theme. I think this has been fixed.

— Bill

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Peter Sampson <petersampsonaudacity@gm...>]

On Wed, Aug 16, 2017 at 7:04 PM, Paul Licameli <paul.licameli@...>
wrote:

> I stated some opinions about what Sync-lock should and should not do in
> Bugzilla and I repeat here.
>
>
> "I disagree with this interpretation of what sync-lock should do.
>
> When a track is sync-lock adjusted for other reasons in Audacity, all that
> ever happens is this:  Some selected track has an editing operation that
> replaces the selected region with other contents of different length.  The
> corresponding portion of the sync-locked tracks is correspondingly
> lengthened or shortened with insertion of silence or deletion.
>
> That's it.  And I implemented that much for the Stretch operation too.
> And this can happen only when doing the left and right stretches.
>
> If you think center stretch should affect more than one note track at
> once, then I say,  we should make it happen in all selected note tracks at
> once and make it not dependent on sync-lock state.
>

And I said in Bugzilla that yes I agree with that IF that is we retain
stretching for Note tracks.

But I (along with James and Bill) would like to see Note track stretching
removed for 2.2.0


> I do not want to stretch audio too.  That is an expensive thing to
> calculate.  The more so if you interpret that to mean changing tempo rather
> than pitch.  Even if you just change pitch it entails resampling.
>

Nor do I want to stretch audio either - but as I explained in the Bugzila
thread , if we retain it for
Note tracks - then it copuld arouse interest and desire in users for
stretchable audio tracks.

So this is another key reason for withdrawing stretching for Note tracks in
2.2.0.


>
> This said, I have also been thinking that all the places in the code where
> sync-lock does happen need reexamining."
>

Sync-lock itself and the way we created/define SLTGs needs careful
re-examining IMVHO.

Peter.



>
> PRL
>
>
> On Wed, Aug 16, 2017 at 11:22 AM, Paul Licameli <paul.licameli@...>
> wrote:
>
>>
>>
>> On Tue, Aug 15, 2017 at 11:17 AM, Peter Sampson <
>> petersampsonaudacity@...> wrote:
>>
>>>
>>>
>>> On Tue, Aug 15, 2017 at 3:55 PM, Bill Wharrie <billwh@...> wrote:
>>>
>>>>
>>>> > On 2017/08/15, at 10:28 AM, James Crook <crookj@...> wrote:
>>>> >
>>>> > +1 for disabling stretching for 2.2.0.
>>>>
>>>> +1 for disabling stretching for 2.2.0 from me as well.
>>>>
>>>> Moving forward, perhaps a look from James’ “helicopter” would be
>>>> useful, for example: What MIDI functionality is useful within Audacity
>>>> (syncing, stretching, mixing, editing, creating, etc)? Or put another way:
>>>> What do users need?
>>>>
>>>
>>> It also begs the question (my "mystery-shopper" asked this straight
>>> away):
>>> "So why can't I similarly stretch the audio track(s)?"
>>>
>>>
>>> Plus imo the GUI for the stretching with the cross-hairs cursor
>>> appearing in the
>>> zone near the ceter line (replacing the I-beam cursor in a selected
>>> track or
>>> selection) is not really ideal.
>>>
>>> There is no explanation to the user as to why the cursor has
>>> mysteriously changed
>>> nor any indication of waht it will do in this new mode.
>>>
>>
>> Isn't there at least a status bar message change?
>>
>>
>>>
>>> I would much prefer a UI where the user made a command or/and button
>>> choice to
>>> switch in and out of stretch mode (like we switch into Scrubbing say).
>>>
>>
>> NO!!!  We need fewer modes toolbar buttons, not more.  I am with James on
>> that.  We need the whole of Audacity to be more like Multi tool.  Your
>> mouse hovers over various targets, and you get a cursor change.  And also
>> Esc key helps to disambiguate targets close together.
>>
>> I am hoping some day to shrink the tools toolbar to just the Zoom and
>> Select tools, and the Select actually behaving like the Multi.
>>
>>
>>>
>>> But given that James, Bill and muself are in favour of turning off Note
>>> track stretching
>>> as it is for 2.2.0 (and gien that, as yet, there are no naysayers) - who
>>> has the techy
>>> wherewithawl to make this happen?
>>>
>>
>> It can be very simply disabled in the hit-testing routine peculiar to
>> Note tracks.
>>
>> PRL
>>
>>
>>
>>>
>>> Do we need to log is as a bug ? certainly we would need to log the
>>> Use-case 4 crash
>>> and turning off stretching would be a strightforward solution.
>>>
>>> Peter.
>>>
>>>
>>>
>>>
>>>>
>>>> — Bill
>>>>
>>>> >
>>>> > Aside from the crash on Mac it does not work (yet) on Linux
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>>> > The user interface design is also more proof of concept than ready to
>>>> use.
>>>> > We're close to release, and it could hold us up a lot.
>>>> >
>>>> > --James.
>>>> >
>>>> >
>>>> >
>>>> > On 8/15/2017 2:44 PM, Peter Sampson wrote:
>>>> >> *Management summary:*
>>>> >>
>>>> >> NoteTracks do not behave nicely altogether when you have multiple
>>>> instances
>>>> >> and selections
>>>> >> or particularly when you house them in Sync Locked Track Groups.
>>>> >>
>>>> >> 1) we should seriously consider inhibiting the use of Stretch
>>>> functionality
>>>> >> in Note tracks
>>>> >> that form part of of sync-locked track group - or
>>>> >>
>>>> >> 2) We should turn off Note track stretching untill we resolve the
>>>> >> bugs/design issues
>>>> >> highlighted here.
>>>> >> And note there may be others that I have not uncovered yet
>>>> >>
>>>> >> Use-case 4 with its consistent crash, although an unlikely fringe
>>>> case, is
>>>> >> nonetheless serious.
>>>> >>
>>>> >>
>>>> >> *TL;DR*
>>>> >>
>>>> >> Part 2 of the steps of Bug #1646 has some bearing on this:
>>>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>>> >>
>>>> >> I have not logged any of these on Bugzilla yet - at this stage I am
>>>> just
>>>> >> seeking feedback on
>>>> >> these behaviours.
>>>> >>
>>>> >> For the basic scenario get yourseld a project with two MIDI Note
>>>> tracks one
>>>> >> longer, make Track-1
>>>> >> the shorter of the two. Zoom out ine level so thay half-fill the
>>>> window
>>>> >>
>>>> >> 1) select all scenario
>>>> >> 1.1 Select All
>>>> >> 1.2 now hover in track-1 in the middle to get the square cross-hairs
>>>> >> stretch cursor
>>>> >> 1.3 stretch in either direction
>>>> >> 1.4 Note that the stretch only takes place in track-1 and nothing
>>>> happens
>>>> >> to track-2
>>>> >> Is this expected behaviour when both tracks are selected - I am
>>>> unsure
>>>> >> about this.
>>>> >>
>>>> >> 2) SLTG and one track selected
>>>> >> 2.1 Turn on Sync-locked tracks
>>>> >> 2.2 select just track-1
>>>> >> 2.3 now hover in track-1 in the middle to get the square cross-hairs
>>>> >> stretch cursor
>>>> >> 2.4 stretch in either direction
>>>> >> 2.5 Note that the stretch only takes place in track-1 and nothing
>>>> happens
>>>> >> to track-2
>>>> >> 2.6 Same happens if both tracks are selected
>>>> >> Now because we have the tracks in an SLTG I would expect the stretch
>>>> to
>>>> >> happen in both
>>>> >> maintaining the syncronization
>>>> >>
>>>> >> 3) SLTG and right stretch of shorter track
>>>> >> 3.1 Turn on Sync-locked tracks
>>>> >> 3.2 select just track-1
>>>> >> 3.3 now hover in track-1 iat the extreme right of the notes for the
>>>> right
>>>> >> stretch cursor
>>>> >> 3.4 stretch to the right beyond the length of track-2
>>>> >> 3.5 release the cursor (display of synching doesn;t show until you
>>>> do this,
>>>> >> it's not dynamic)
>>>> >> 3.6 Note that the synchronization of the tracks is maintained by
>>>> cutting
>>>> >> track-2 at the point
>>>> >> where track-1 used to end and the part beyond that is slid to the
>>>> right -
>>>> >> starting again
>>>> >> where track-1 now ends after the right stretch.
>>>> >>
>>>> >> Similar odd-looking synchronization occurs if you substitute Note
>>>> track-2
>>>> >> with an audio track
>>>> >>
>>>> >>
>>>> >> 4) SLTG and right stretch of shorter track
>>>> >> 4.1 Turn on Sync-locked tracks
>>>> >> 4,2 Slide both tracks to the right with Time Shift Tool
>>>> >> 4.3 select just track-1
>>>> >> 4.4 now hover in track-1 iat the extreme left of the notes for the
>>>> left
>>>> >> stretch cursor
>>>> >> 4.5 stretch to the left beyond the length of track-2
>>>> >> 4.6 visual stretch of track-1 occurs with sync clocks in track-2
>>>> >> 4.7 release the cursor
>>>> >> 4.8 CRASH !  - consistent
>>>> >> Crash also happens if you similarly left stretch track-2 left of
>>>> track-1
>>>> >>
>>>> >> This crash is consistent in use-case 4 here - but I occasionally
>>>> moonphase
>>>> >> get it with use-case-3
>>>> >>
>>>> >> The crash does not occur if you substitute track-1 (or track-2) with
>>>> an
>>>> >> audo track.
>>>> >>
>>>> >> 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
>>>> > Audacity-quality@...
>>>> > 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
>>>> Audacity-quality@...
>>>> 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
>>> Audacity-quality@...
>>> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Paul Licameli <paul.licameli@gm...>]

I stated some opinions about what Sync-lock should and should not do in
Bugzilla and I repeat here.


"I disagree with this interpretation of what sync-lock should do.

When a track is sync-lock adjusted for other reasons in Audacity, all that
ever happens is this:  Some selected track has an editing operation that
replaces the selected region with other contents of different length.  The
corresponding portion of the sync-locked tracks is correspondingly
lengthened or shortened with insertion of silence or deletion.

That's it.  And I implemented that much for the Stretch operation too.  And
this can happen only when doing the left and right stretches.

If you think center stretch should affect more than one note track at once,
then I say,  we should make it happen in all selected note tracks at once
and make it not dependent on sync-lock state.

I do not want to stretch audio too.  That is an expensive thing to
calculate.  The more so if you interpret that to mean changing tempo rather
than pitch.  Even if you just change pitch it entails resampling.

This said, I have also been thinking that all the places in the code where
sync-lock does happen need reexamining."

PRL


On Wed, Aug 16, 2017 at 11:22 AM, Paul Licameli <paul.licameli@...>
wrote:

>
>
> On Tue, Aug 15, 2017 at 11:17 AM, Peter Sampson <
> petersampsonaudacity@...> wrote:
>
>>
>>
>> On Tue, Aug 15, 2017 at 3:55 PM, Bill Wharrie <billwh@...> wrote:
>>
>>>
>>> > On 2017/08/15, at 10:28 AM, James Crook <crookj@...> wrote:
>>> >
>>> > +1 for disabling stretching for 2.2.0.
>>>
>>> +1 for disabling stretching for 2.2.0 from me as well.
>>>
>>> Moving forward, perhaps a look from James’ “helicopter” would be useful,
>>> for example: What MIDI functionality is useful within Audacity (syncing,
>>> stretching, mixing, editing, creating, etc)? Or put another way: What do
>>> users need?
>>>
>>
>> It also begs the question (my "mystery-shopper" asked this straight away):
>> "So why can't I similarly stretch the audio track(s)?"
>>
>>
>> Plus imo the GUI for the stretching with the cross-hairs cursor appearing
>> in the
>> zone near the ceter line (replacing the I-beam cursor in a selected track
>> or
>> selection) is not really ideal.
>>
>> There is no explanation to the user as to why the cursor has mysteriously
>> changed
>> nor any indication of waht it will do in this new mode.
>>
>
> Isn't there at least a status bar message change?
>
>
>>
>> I would much prefer a UI where the user made a command or/and button
>> choice to
>> switch in and out of stretch mode (like we switch into Scrubbing say).
>>
>
> NO!!!  We need fewer modes toolbar buttons, not more.  I am with James on
> that.  We need the whole of Audacity to be more like Multi tool.  Your
> mouse hovers over various targets, and you get a cursor change.  And also
> Esc key helps to disambiguate targets close together.
>
> I am hoping some day to shrink the tools toolbar to just the Zoom and
> Select tools, and the Select actually behaving like the Multi.
>
>
>>
>> But given that James, Bill and muself are in favour of turning off Note
>> track stretching
>> as it is for 2.2.0 (and gien that, as yet, there are no naysayers) - who
>> has the techy
>> wherewithawl to make this happen?
>>
>
> It can be very simply disabled in the hit-testing routine peculiar to Note
> tracks.
>
> PRL
>
>
>
>>
>> Do we need to log is as a bug ? certainly we would need to log the
>> Use-case 4 crash
>> and turning off stretching would be a strightforward solution.
>>
>> Peter.
>>
>>
>>
>>
>>>
>>> — Bill
>>>
>>> >
>>> > Aside from the crash on Mac it does not work (yet) on Linux
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>> > The user interface design is also more proof of concept than ready to
>>> use.
>>> > We're close to release, and it could hold us up a lot.
>>> >
>>> > --James.
>>> >
>>> >
>>> >
>>> > On 8/15/2017 2:44 PM, Peter Sampson wrote:
>>> >> *Management summary:*
>>> >>
>>> >> NoteTracks do not behave nicely altogether when you have multiple
>>> instances
>>> >> and selections
>>> >> or particularly when you house them in Sync Locked Track Groups.
>>> >>
>>> >> 1) we should seriously consider inhibiting the use of Stretch
>>> functionality
>>> >> in Note tracks
>>> >> that form part of of sync-locked track group - or
>>> >>
>>> >> 2) We should turn off Note track stretching untill we resolve the
>>> >> bugs/design issues
>>> >> highlighted here.
>>> >> And note there may be others that I have not uncovered yet
>>> >>
>>> >> Use-case 4 with its consistent crash, although an unlikely fringe
>>> case, is
>>> >> nonetheless serious.
>>> >>
>>> >>
>>> >> *TL;DR*
>>> >>
>>> >> Part 2 of the steps of Bug #1646 has some bearing on this:
>>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>> >>
>>> >> I have not logged any of these on Bugzilla yet - at this stage I am
>>> just
>>> >> seeking feedback on
>>> >> these behaviours.
>>> >>
>>> >> For the basic scenario get yourseld a project with two MIDI Note
>>> tracks one
>>> >> longer, make Track-1
>>> >> the shorter of the two. Zoom out ine level so thay half-fill the
>>> window
>>> >>
>>> >> 1) select all scenario
>>> >> 1.1 Select All
>>> >> 1.2 now hover in track-1 in the middle to get the square cross-hairs
>>> >> stretch cursor
>>> >> 1.3 stretch in either direction
>>> >> 1.4 Note that the stretch only takes place in track-1 and nothing
>>> happens
>>> >> to track-2
>>> >> Is this expected behaviour when both tracks are selected - I am unsure
>>> >> about this.
>>> >>
>>> >> 2) SLTG and one track selected
>>> >> 2.1 Turn on Sync-locked tracks
>>> >> 2.2 select just track-1
>>> >> 2.3 now hover in track-1 in the middle to get the square cross-hairs
>>> >> stretch cursor
>>> >> 2.4 stretch in either direction
>>> >> 2.5 Note that the stretch only takes place in track-1 and nothing
>>> happens
>>> >> to track-2
>>> >> 2.6 Same happens if both tracks are selected
>>> >> Now because we have the tracks in an SLTG I would expect the stretch
>>> to
>>> >> happen in both
>>> >> maintaining the syncronization
>>> >>
>>> >> 3) SLTG and right stretch of shorter track
>>> >> 3.1 Turn on Sync-locked tracks
>>> >> 3.2 select just track-1
>>> >> 3.3 now hover in track-1 iat the extreme right of the notes for the
>>> right
>>> >> stretch cursor
>>> >> 3.4 stretch to the right beyond the length of track-2
>>> >> 3.5 release the cursor (display of synching doesn;t show until you do
>>> this,
>>> >> it's not dynamic)
>>> >> 3.6 Note that the synchronization of the tracks is maintained by
>>> cutting
>>> >> track-2 at the point
>>> >> where track-1 used to end and the part beyond that is slid to the
>>> right -
>>> >> starting again
>>> >> where track-1 now ends after the right stretch.
>>> >>
>>> >> Similar odd-looking synchronization occurs if you substitute Note
>>> track-2
>>> >> with an audio track
>>> >>
>>> >>
>>> >> 4) SLTG and right stretch of shorter track
>>> >> 4.1 Turn on Sync-locked tracks
>>> >> 4,2 Slide both tracks to the right with Time Shift Tool
>>> >> 4.3 select just track-1
>>> >> 4.4 now hover in track-1 iat the extreme left of the notes for the
>>> left
>>> >> stretch cursor
>>> >> 4.5 stretch to the left beyond the length of track-2
>>> >> 4.6 visual stretch of track-1 occurs with sync clocks in track-2
>>> >> 4.7 release the cursor
>>> >> 4.8 CRASH !  - consistent
>>> >> Crash also happens if you similarly left stretch track-2 left of
>>> track-1
>>> >>
>>> >> This crash is consistent in use-case 4 here - but I occasionally
>>> moonphase
>>> >> get it with use-case-3
>>> >>
>>> >> The crash does not occur if you substitute track-1 (or track-2) with
>>> an
>>> >> audo track.
>>> >>
>>> >> 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
>>> > Audacity-quality@...
>>> > 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
>>> Audacity-quality@...
>>> 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
>> Audacity-quality@...
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Peter Sampson <petersampsonaudacity@gm...>]

On Wed, Aug 16, 2017 at 4:22 PM, Paul Licameli <paul.licameli@...>
wrote:

>
>
> On Tue, Aug 15, 2017 at 11:17 AM, Peter Sampson <
> petersampsonaudacity@...> wrote:
>
>>
>>
>> On Tue, Aug 15, 2017 at 3:55 PM, Bill Wharrie <billwh@...> wrote:
>>
>>>
>>> > On 2017/08/15, at 10:28 AM, James Crook <crookj@...> wrote:
>>> >
>>> > +1 for disabling stretching for 2.2.0.
>>>
>>> +1 for disabling stretching for 2.2.0 from me as well.
>>>
>>> Moving forward, perhaps a look from James’ “helicopter” would be useful,
>>> for example: What MIDI functionality is useful within Audacity (syncing,
>>> stretching, mixing, editing, creating, etc)? Or put another way: What do
>>> users need?
>>>
>>
>> It also begs the question (my "mystery-shopper" asked this straight away):
>> "So why can't I similarly stretch the audio track(s)?"
>>
>>
>> Plus imo the GUI for the stretching with the cross-hairs cursor appearing
>> in the
>> zone near the ceter line (replacing the I-beam cursor in a selected track
>> or
>> selection) is not really ideal.
>>
>> There is no explanation to the user as to why the cursor has mysteriously
>> changed
>> nor any indication of waht it will do in this new mode.
>>
>
> Isn't there at least a status bar message change?
>

Yes but as I and Steve have explained before - very few people look at the
Status Bar
especially when their hand/eye is focussed on the cursor and the track and
the operation
they are trying to preform.

The Status BAr is at its most usful when making a recording or doing other
time consuming
things that require no input fromn the user - so that gives them tim tosit
back and appraise
the screen more fully.




>
>
>>
>> I would much prefer a UI where the user made a command or/and button
>> choice to
>> switch in and out of stretch mode (like we switch into Scrubbing say).
>>
>
> NO!!!  We need fewer modes toolbar buttons, not more.  I am with James on
> that.  We need the whole of Audacity to be more like Multi tool.  Your
> mouse hovers over various targets, and you get a cursor change.  And also
> Esc key helps to disambiguate targets close together.
>
> I am hoping some day to shrink the tools toolbar to just the Zoom and
> Select tools, and the Select actually behaving like the Multi.
>
>
>>
>> But given that James, Bill and muself are in favour of turning off Note
>> track stretching
>> as it is for 2.2.0 (and gien that, as yet, there are no naysayers) - who
>> has the techy
>> wherewithawl to make this happen?
>>
>
> It can be very simply disabled in the hit-testing routine peculiar to Note
> tracks.
>

Can you do that then please - or at least make it experimental and exclude
it :-))

And then I can update the Manual accordingly.

Thanks,
Peter.


>
> PRL
>
>
>
>>
>> Do we need to log is as a bug ? certainly we would need to log the
>> Use-case 4 crash
>> and turning off stretching would be a strightforward solution.
>>
>> Peter.
>>
>>
>>
>>
>>>
>>> — Bill
>>>
>>> >
>>> > Aside from the crash on Mac it does not work (yet) on Linux
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>> > The user interface design is also more proof of concept than ready to
>>> use.
>>> > We're close to release, and it could hold us up a lot.
>>> >
>>> > --James.
>>> >
>>> >
>>> >
>>> > On 8/15/2017 2:44 PM, Peter Sampson wrote:
>>> >> *Management summary:*
>>> >>
>>> >> NoteTracks do not behave nicely altogether when you have multiple
>>> instances
>>> >> and selections
>>> >> or particularly when you house them in Sync Locked Track Groups.
>>> >>
>>> >> 1) we should seriously consider inhibiting the use of Stretch
>>> functionality
>>> >> in Note tracks
>>> >> that form part of of sync-locked track group - or
>>> >>
>>> >> 2) We should turn off Note track stretching untill we resolve the
>>> >> bugs/design issues
>>> >> highlighted here.
>>> >> And note there may be others that I have not uncovered yet
>>> >>
>>> >> Use-case 4 with its consistent crash, although an unlikely fringe
>>> case, is
>>> >> nonetheless serious.
>>> >>
>>> >>
>>> >> *TL;DR*
>>> >>
>>> >> Part 2 of the steps of Bug #1646 has some bearing on this:
>>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>> >>
>>> >> I have not logged any of these on Bugzilla yet - at this stage I am
>>> just
>>> >> seeking feedback on
>>> >> these behaviours.
>>> >>
>>> >> For the basic scenario get yourseld a project with two MIDI Note
>>> tracks one
>>> >> longer, make Track-1
>>> >> the shorter of the two. Zoom out ine level so thay half-fill the
>>> window
>>> >>
>>> >> 1) select all scenario
>>> >> 1.1 Select All
>>> >> 1.2 now hover in track-1 in the middle to get the square cross-hairs
>>> >> stretch cursor
>>> >> 1.3 stretch in either direction
>>> >> 1.4 Note that the stretch only takes place in track-1 and nothing
>>> happens
>>> >> to track-2
>>> >> Is this expected behaviour when both tracks are selected - I am unsure
>>> >> about this.
>>> >>
>>> >> 2) SLTG and one track selected
>>> >> 2.1 Turn on Sync-locked tracks
>>> >> 2.2 select just track-1
>>> >> 2.3 now hover in track-1 in the middle to get the square cross-hairs
>>> >> stretch cursor
>>> >> 2.4 stretch in either direction
>>> >> 2.5 Note that the stretch only takes place in track-1 and nothing
>>> happens
>>> >> to track-2
>>> >> 2.6 Same happens if both tracks are selected
>>> >> Now because we have the tracks in an SLTG I would expect the stretch
>>> to
>>> >> happen in both
>>> >> maintaining the syncronization
>>> >>
>>> >> 3) SLTG and right stretch of shorter track
>>> >> 3.1 Turn on Sync-locked tracks
>>> >> 3.2 select just track-1
>>> >> 3.3 now hover in track-1 iat the extreme right of the notes for the
>>> right
>>> >> stretch cursor
>>> >> 3.4 stretch to the right beyond the length of track-2
>>> >> 3.5 release the cursor (display of synching doesn;t show until you do
>>> this,
>>> >> it's not dynamic)
>>> >> 3.6 Note that the synchronization of the tracks is maintained by
>>> cutting
>>> >> track-2 at the point
>>> >> where track-1 used to end and the part beyond that is slid to the
>>> right -
>>> >> starting again
>>> >> where track-1 now ends after the right stretch.
>>> >>
>>> >> Similar odd-looking synchronization occurs if you substitute Note
>>> track-2
>>> >> with an audio track
>>> >>
>>> >>
>>> >> 4) SLTG and right stretch of shorter track
>>> >> 4.1 Turn on Sync-locked tracks
>>> >> 4,2 Slide both tracks to the right with Time Shift Tool
>>> >> 4.3 select just track-1
>>> >> 4.4 now hover in track-1 iat the extreme left of the notes for the
>>> left
>>> >> stretch cursor
>>> >> 4.5 stretch to the left beyond the length of track-2
>>> >> 4.6 visual stretch of track-1 occurs with sync clocks in track-2
>>> >> 4.7 release the cursor
>>> >> 4.8 CRASH !  - consistent
>>> >> Crash also happens if you similarly left stretch track-2 left of
>>> track-1
>>> >>
>>> >> This crash is consistent in use-case 4 here - but I occasionally
>>> moonphase
>>> >> get it with use-case-3
>>> >>
>>> >> The crash does not occur if you substitute track-1 (or track-2) with
>>> an
>>> >> audo track.
>>> >>
>>> >> 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
>>> > Audacity-quality@...
>>> > 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
>>> Audacity-quality@...
>>> 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
>> Audacity-quality@...
>> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Peter Sampson <petersampsonaudacity@gm...>]

On Wed, Aug 16, 2017 at 4:14 PM, Paul Licameli <paul.licameli@...>
wrote:

>
>
> On Tue, Aug 15, 2017 at 9:48 AM, Peter Sampson <
> petersampsonaudacity@...> wrote:
>
>> *Corollary:*
>>
>> I'm not at all sure why we bother with Note track stretching at all  -
>> there are far
>> better MIDI editors available.
>>
>> For my money we'd be far better off adding rendering of MIDI track(s) to
>> audio -
>> but probably not for 2.2.0 (work-arounds using loopback recording do
>> exist).
>>
>> Just my 2c worth here.
>>
>> Peter
>>
>
> I bothered because it has been an existing, though undocumented, feature
> in 2.1.3 and earlier, but it behaved really horribly.  I made it less
> horrible.
>
> Now it's getting attention.
>

It's getting attention because:
a) we have been testing the new playback ( Inever had a Note trcak ever
before)
b) Gale had a P1 in the Manual for the cross-hairs cursor (which I never
previously understood).

And the attention it's getting with the availabilty of playback is why
we're finally spotting
the bugs and shortcomings ;-))

Peter.


>
> The allegro API for manipulating MIDI sequences included a stretch
> operation, and it looks like a user interface was written to access this,
> because it was there.  Roger may say more.
>
> PRL
>
>
>
>>
>> ------------------------------------------------------------
>> ------------------
>> 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
>> Audacity-quality@...
>> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Paul Licameli <paul.licameli@gm...>]

On Tue, Aug 15, 2017 at 11:17 AM, Peter Sampson <
petersampsonaudacity@...> wrote:

>
>
> On Tue, Aug 15, 2017 at 3:55 PM, Bill Wharrie <billwh@...> wrote:
>
>>
>> > On 2017/08/15, at 10:28 AM, James Crook <crookj@...> wrote:
>> >
>> > +1 for disabling stretching for 2.2.0.
>>
>> +1 for disabling stretching for 2.2.0 from me as well.
>>
>> Moving forward, perhaps a look from James’ “helicopter” would be useful,
>> for example: What MIDI functionality is useful within Audacity (syncing,
>> stretching, mixing, editing, creating, etc)? Or put another way: What do
>> users need?
>>
>
> It also begs the question (my "mystery-shopper" asked this straight away):
> "So why can't I similarly stretch the audio track(s)?"
>
>
> Plus imo the GUI for the stretching with the cross-hairs cursor appearing
> in the
> zone near the ceter line (replacing the I-beam cursor in a selected track
> or
> selection) is not really ideal.
>
> There is no explanation to the user as to why the cursor has mysteriously
> changed
> nor any indication of waht it will do in this new mode.
>

Isn't there at least a status bar message change?


>
> I would much prefer a UI where the user made a command or/and button
> choice to
> switch in and out of stretch mode (like we switch into Scrubbing say).
>

NO!!!  We need fewer modes toolbar buttons, not more.  I am with James on
that.  We need the whole of Audacity to be more like Multi tool.  Your
mouse hovers over various targets, and you get a cursor change.  And also
Esc key helps to disambiguate targets close together.

I am hoping some day to shrink the tools toolbar to just the Zoom and
Select tools, and the Select actually behaving like the Multi.


>
> But given that James, Bill and muself are in favour of turning off Note
> track stretching
> as it is for 2.2.0 (and gien that, as yet, there are no naysayers) - who
> has the techy
> wherewithawl to make this happen?
>

It can be very simply disabled in the hit-testing routine peculiar to Note
tracks.

PRL



>
> Do we need to log is as a bug ? certainly we would need to log the
> Use-case 4 crash
> and turning off stretching would be a strightforward solution.
>
> Peter.
>
>
>
>
>>
>> — Bill
>>
>> >
>> > Aside from the crash on Mac it does not work (yet) on Linux
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>> > The user interface design is also more proof of concept than ready to
>> use.
>> > We're close to release, and it could hold us up a lot.
>> >
>> > --James.
>> >
>> >
>> >
>> > On 8/15/2017 2:44 PM, Peter Sampson wrote:
>> >> *Management summary:*
>> >>
>> >> NoteTracks do not behave nicely altogether when you have multiple
>> instances
>> >> and selections
>> >> or particularly when you house them in Sync Locked Track Groups.
>> >>
>> >> 1) we should seriously consider inhibiting the use of Stretch
>> functionality
>> >> in Note tracks
>> >> that form part of of sync-locked track group - or
>> >>
>> >> 2) We should turn off Note track stretching untill we resolve the
>> >> bugs/design issues
>> >> highlighted here.
>> >> And note there may be others that I have not uncovered yet
>> >>
>> >> Use-case 4 with its consistent crash, although an unlikely fringe
>> case, is
>> >> nonetheless serious.
>> >>
>> >>
>> >> *TL;DR*
>> >>
>> >> Part 2 of the steps of Bug #1646 has some bearing on this:
>> >> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>> >>
>> >> I have not logged any of these on Bugzilla yet - at this stage I am
>> just
>> >> seeking feedback on
>> >> these behaviours.
>> >>
>> >> For the basic scenario get yourseld a project with two MIDI Note
>> tracks one
>> >> longer, make Track-1
>> >> the shorter of the two. Zoom out ine level so thay half-fill the window
>> >>
>> >> 1) select all scenario
>> >> 1.1 Select All
>> >> 1.2 now hover in track-1 in the middle to get the square cross-hairs
>> >> stretch cursor
>> >> 1.3 stretch in either direction
>> >> 1.4 Note that the stretch only takes place in track-1 and nothing
>> happens
>> >> to track-2
>> >> Is this expected behaviour when both tracks are selected - I am unsure
>> >> about this.
>> >>
>> >> 2) SLTG and one track selected
>> >> 2.1 Turn on Sync-locked tracks
>> >> 2.2 select just track-1
>> >> 2.3 now hover in track-1 in the middle to get the square cross-hairs
>> >> stretch cursor
>> >> 2.4 stretch in either direction
>> >> 2.5 Note that the stretch only takes place in track-1 and nothing
>> happens
>> >> to track-2
>> >> 2.6 Same happens if both tracks are selected
>> >> Now because we have the tracks in an SLTG I would expect the stretch to
>> >> happen in both
>> >> maintaining the syncronization
>> >>
>> >> 3) SLTG and right stretch of shorter track
>> >> 3.1 Turn on Sync-locked tracks
>> >> 3.2 select just track-1
>> >> 3.3 now hover in track-1 iat the extreme right of the notes for the
>> right
>> >> stretch cursor
>> >> 3.4 stretch to the right beyond the length of track-2
>> >> 3.5 release the cursor (display of synching doesn;t show until you do
>> this,
>> >> it's not dynamic)
>> >> 3.6 Note that the synchronization of the tracks is maintained by
>> cutting
>> >> track-2 at the point
>> >> where track-1 used to end and the part beyond that is slid to the
>> right -
>> >> starting again
>> >> where track-1 now ends after the right stretch.
>> >>
>> >> Similar odd-looking synchronization occurs if you substitute Note
>> track-2
>> >> with an audio track
>> >>
>> >>
>> >> 4) SLTG and right stretch of shorter track
>> >> 4.1 Turn on Sync-locked tracks
>> >> 4,2 Slide both tracks to the right with Time Shift Tool
>> >> 4.3 select just track-1
>> >> 4.4 now hover in track-1 iat the extreme left of the notes for the left
>> >> stretch cursor
>> >> 4.5 stretch to the left beyond the length of track-2
>> >> 4.6 visual stretch of track-1 occurs with sync clocks in track-2
>> >> 4.7 release the cursor
>> >> 4.8 CRASH !  - consistent
>> >> Crash also happens if you similarly left stretch track-2 left of
>> track-1
>> >>
>> >> This crash is consistent in use-case 4 here - but I occasionally
>> moonphase
>> >> get it with use-case-3
>> >>
>> >> The crash does not occur if you substitute track-1 (or track-2) with an
>> >> audo track.
>> >>
>> >> 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
>> > Audacity-quality@...
>> > 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
>> Audacity-quality@...
>> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Paul Licameli <paul.licameli@gm...>]

On Tue, Aug 15, 2017 at 10:28 AM, James Crook <crookj@...> wrote:

> +1 for disabling stretching for 2.2.0.
>
> Aside from the crash on Mac it does not work (yet) on Linux
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
> The user interface design is also more proof of concept than ready to use.
> We're close to release, and it could hold us up a lot.
>
> --James.
>

I am inclined to agree, just because I don't want to deal with a third big
development emergency now.  (1 was the library loading problem that
disappeared with the consts removed, 2 is the business of Midi play on
Linux.)

PRL



>
>
>
> On 8/15/2017 2:44 PM, Peter Sampson wrote:
>
>> *Management summary:*
>>
>> NoteTracks do not behave nicely altogether when you have multiple
>> instances
>> and selections
>> or particularly when you house them in Sync Locked Track Groups.
>>
>> 1) we should seriously consider inhibiting the use of Stretch
>> functionality
>> in Note tracks
>> that form part of of sync-locked track group - or
>>
>> 2) We should turn off Note track stretching untill we resolve the
>> bugs/design issues
>> highlighted here.
>> And note there may be others that I have not uncovered yet
>>
>> Use-case 4 with its consistent crash, although an unlikely fringe case, is
>> nonetheless serious.
>>
>>
>> *TL;DR*
>>
>>
>> Part 2 of the steps of Bug #1646 has some bearing on this:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1646
>>
>> I have not logged any of these on Bugzilla yet - at this stage I am just
>> seeking feedback on
>> these behaviours.
>>
>> For the basic scenario get yourseld a project with two MIDI Note tracks
>> one
>> longer, make Track-1
>> the shorter of the two. Zoom out ine level so thay half-fill the window
>>
>> 1) select all scenario
>> 1.1 Select All
>> 1.2 now hover in track-1 in the middle to get the square cross-hairs
>> stretch cursor
>> 1.3 stretch in either direction
>> 1.4 Note that the stretch only takes place in track-1 and nothing happens
>> to track-2
>> Is this expected behaviour when both tracks are selected - I am unsure
>> about this.
>>
>> 2) SLTG and one track selected
>> 2.1 Turn on Sync-locked tracks
>> 2.2 select just track-1
>> 2.3 now hover in track-1 in the middle to get the square cross-hairs
>> stretch cursor
>> 2.4 stretch in either direction
>> 2.5 Note that the stretch only takes place in track-1 and nothing happens
>> to track-2
>> 2.6 Same happens if both tracks are selected
>> Now because we have the tracks in an SLTG I would expect the stretch to
>> happen in both
>> maintaining the syncronization
>>
>> 3) SLTG and right stretch of shorter track
>> 3.1 Turn on Sync-locked tracks
>> 3.2 select just track-1
>> 3.3 now hover in track-1 iat the extreme right of the notes for the right
>> stretch cursor
>> 3.4 stretch to the right beyond the length of track-2
>> 3.5 release the cursor (display of synching doesn;t show until you do
>> this,
>> it's not dynamic)
>> 3.6 Note that the synchronization of the tracks is maintained by cutting
>> track-2 at the point
>> where track-1 used to end and the part beyond that is slid to the right -
>> starting again
>> where track-1 now ends after the right stretch.
>>
>> Similar odd-looking synchronization occurs if you substitute Note track-2
>> with an audio track
>>
>>
>> 4) SLTG and right stretch of shorter track
>> 4.1 Turn on Sync-locked tracks
>> 4,2 Slide both tracks to the right with Time Shift Tool
>> 4.3 select just track-1
>> 4.4 now hover in track-1 iat the extreme left of the notes for the left
>> stretch cursor
>> 4.5 stretch to the left beyond the length of track-2
>> 4.6 visual stretch of track-1 occurs with sync clocks in track-2
>> 4.7 release the cursor
>> 4.8 CRASH !  - consistent
>> Crash also happens if you similarly left stretch track-2 left of track-1
>>
>> This crash is consistent in use-case 4 here - but I occasionally moonphase
>> get it with use-case-3
>>
>> The crash does not occur if you substitute track-1 (or track-2) with an
>> audo track.
>>
>> 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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

Re: [Audacity-quality] Note Track odd behaviours when sync-locked

[Paul Licameli <paul.licameli@gm...>]

On Tue, Aug 15, 2017 at 9:48 AM, Peter Sampson <
petersampsonaudacity@...> wrote:

> *Corollary:*
>
> I'm not at all sure why we bother with Note track stretching at all  -
> there are far
> better MIDI editors available.
>
> For my money we'd be far better off adding rendering of MIDI track(s) to
> audio -
> but probably not for 2.2.0 (work-arounds using loopback recording do
> exist).
>
> Just my 2c worth here.
>
> Peter
>

I bothered because it has been an existing, though undocumented, feature in
2.1.3 and earlier, but it behaved really horribly.  I made it less horrible.

Now it's getting attention.

The allegro API for manipulating MIDI sequences included a stretch
operation, and it looks like a user interface was written to access this,
because it was there.  Roger may say more.

PRL



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

[Audacity-quality] Inaccuracy Nyq sliders

[Robert Hänggi <aarjay.robert@gm...>]

Hi
I've been working on the NVDA-addon for 2.2.0 and changed the
behaviour of the Nyquist effect sliders such that they speak the
absolute value instead of the position (in percent).
Well, this doesn't matter but I've seen that using the arrow keys is
not properly implemented.

Steps to reproduce:
Open "Vocal Reduction and Isolation".
Go to lo frequency cut and press home. --> 1.0.
Now, move to the right by using right arrow.
I get the sequence:
1.0 25.0 25.0 73.0 73.0 121.0 121.0...
And now go back by using the left arrow key:
121.0 97.0 73.0 49.0 25.0

The issue should be quite obvious.
Note also that the last digit is always 0--Try it in other Nyq effects.

I think that the logic in Nyquist.cpp is faulty.
See especially lines 2345ff.
It helps for me to increase the precision values by one, however, this
doesn't correct the rounding error entirely.

IMO, the goal should be to have arrow key movements that always change
the value (exception might be the change to the max value, which could
be equal to its predecessor).
I don't propose to change the number of ticks (1000) for 2.2.0 in
order to achieve the above mentioned goal but the rounding should
certainly be taken care of or logged as a bug (presumably existing
since the introduction of validation).
The only satisfactory control is currently type "int" if its range is
under 1000.

Cheers
Robert

Re: [Audacity-quality] Mac install.txt is inside the bundle

[Cliff Scott <flyer185@gm...>]

I agree they should be visible in the install DMG window. Without that the user will not likely know they exist as most won't go drilling down into the app contents to see what is there.

Cliff

> On Aug 16, 2017, at 6:25 AM, Peter Sampson <petersampsonaudacity@...> wrote:
> 
> This was true for 2.1.3 too (I've just reinstalled it for testing SLTG/Note tracks)
> 
> As far as I recall no-one has yet complained about this.
> 
> Is this perceived as a problem?
> 
> Peter
> 
> On Tue, Aug 15, 2017 at 3:41 AM, Bill Wharrie <billwh@... <mailto:billwh@...>> wrote:
> As is LICENCE.txt and README.txt. Shouldn’t those three files be visible in the DMG window outside the application? In particular, install.txt contains important information about duplicated effects, generators and analyzers.
> 
> — Bill
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot <http://sdm.link/slashdot>;
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@... <mailto:Audacity-quality@...>
> https://lists.sourceforge.net/lists/listinfo/audacity-quality <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
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality