Re: [Audacity-quality] Time track copy-paste and aup3 import

[James C. <jam...@gm...>]

I've given this new code a try out and it looks to be working fine.  Thanks
for fixing the extra envelope points.

We're going into string freeze today and from here to release we have to
avoid risky changes or it 'resets' how long until release.  So the further
simplification isn't appropriate for 3.0.0.  At some point quite soon we
will be P2 fixes only.

--James.


On Wed, 3 Feb 2021 at 02:59, Paul Licameli <pau...@gm...> wrote:

> The rewrite of .aup3 import was something I had ready months ago because I
> identified the special time track code as an obstacle to modularization.
> So I sought an alternative.  Now that we merge it we also lose #include
> “TimeTrack.h” in EditMenus.
>
> Other obstacles to modularizing TimeTrack remain.  I also want to rewrite
> the import of .aup without including TimeTrack and also eliminating
> duplicated code interpreting XML tags for that and other classes.
>
> That’s all to the good and won’t add translatable strings but won’t
> eliminate any sqlite3 calls.
>
> Is a month to release enough time to hazard this simplification too?  I
> suppose not.  But I hope I will submit more dependency breaking moves that
> enable some of the more than fifty modules to be pulled out, next release.
>
> PRL
>
> On Tuesday, February 2, 2021, James Crook <jam...@gm...> wrote:
>
>> Thank you.  I will have a proper look at it tomorrow.
>>
>> On Tue, 2 Feb 2021 at 20:29, Paul Licameli <pau...@gm...>
>> wrote:
>>
>>> I have done it at commit eb888bb03b0a557aab0b9ae7ac07ae61eee720ba
>>>
>>> Time to review and test, then:  Time tracks never cut or copy; import of
>>> .aup3 with TimeTrack works; and if TimeTrack was already present, it is
>>> (quietly) replaced, not pasted into, by the import.
>>>
>>> PRL
>>>
>>>
>>> On Mon, Feb 1, 2021 at 2:23 PM James Crook <jam...@gm...>
>>> wrote:
>>>
>>>> Paul can you apply your update, with the small fix for those envelope
>>>> points?
>>>> I'd like this to be in in time for string freeze, so that it goes
>>>> through to release.
>>>>
>>>> --James.
>>>>
>>>> On Sat, 30 Jan 2021 at 19:49, Steve Fiddle <ste...@gm...>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, 30 Jan 2021 at 17:47, Paul Licameli <pau...@gm...>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 30, 2021 at 12:31 PM Peter Sampson <
>>>>>> pet...@gm...> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 30, 2021 at 5:25 PM Robert Hänggi <
>>>>>>> aar...@gm...> wrote:
>>>>>>>
>>>>>>>> Just to inform you about the Reaper behaviour:
>>>>>>>> It asks you on import if the tempo should be imported as well. This
>>>>>>>> applies mainly to MIDI tracks.
>>>>>>>> However, it is the nearest to time tracks (apart from the master
>>>>>>>> play
>>>>>>>> rate envelope which is treated like all other envelopes like volume,
>>>>>>>> pan, width, pitch).
>>>>>>>> In essence, if you want that the user can decide, ask him directly
>>>>>>>> and
>>>>>>>> don't presume that he knows that he has first to exclude the other
>>>>>>>> time track from the project to be imported in order to keep the new
>>>>>>>> one.
>>>>>>>> Common sense and more user friendly imho.
>>>>>>>>
>>>>>>>
>>>>>>> I like Robert;s thinking here - asking the user, in the situation
>>>>>>> where they have a Time Track
>>>>>>> on both projects, which one they want to keep sounds eminently
>>>>>>> sensible ad as Robert
>>>>>>> says user-friendly (also more "discoverable" - removing the chance
>>>>>>> of nasty surprises
>>>>>>> when the wrong one gets used).
>>>>>>>
>>>>>>> Peter.
>>>>>>>
>>>>>>
>>>>>> I'd say no for right now and I think RM agrees.
>>>>>>
>>>>>
>>>>> I agree. I think it's a good idea, but we should be close to string
>>>>> freeze and I don't think this is urgent.
>>>>> Steve
>>>>>
>>>>>
>>>>>>
>>>>>> Remember this is incidental to the more important white-box review of
>>>>>> Unitary.
>>>>>>
>>>>>> PRL
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Robert
>>>>>>>>
>>>>>>>> On 30/01/2021, Peter Sampson <pet...@gm...>
>>>>>>>> wrote:
>>>>>>>> > Looking at this page:
>>>>>>>> > https://alphamanual.audacityteam.org/man/Time_Tracks
>>>>>>>> >
>>>>>>>> > I see nothing there about the ability (or expectation) to
>>>>>>>> Cut&Paste the
>>>>>>>> > Time Track or sections of it.
>>>>>>>> >
>>>>>>>> > So the ability to do so is either a cunning and tricksy Easter
>>>>>>>> Egg - or
>>>>>>>> > it's a bug, I'm thinking.
>>>>>>>> >
>>>>>>>> > And note that this is different from the ability to import a Time
>>>>>>>> Track as
>>>>>>>> > part of an imported project
>>>>>>>> > which is to be allowed.
>>>>>>>> >
>>>>>>>> > Peter.
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > Peter.
>>>>>>>> >
>>>>>>>> > On Sat, Jan 30, 2021 at 4:56 PM Peter Sampson <
>>>>>>>> > pet...@gm...> wrote:
>>>>>>>> >
>>>>>>>> >> BTW although one can edit the Time Track with Cut&Paste, albeit
>>>>>>>> only
>>>>>>>> >> through associated audio
>>>>>>>> >> we do have an inconsistency as the Time Track does nor
>>>>>>>> expand/contract
>>>>>>>> >> when the associated
>>>>>>>> >> audio is modified with the Change Speed effect.
>>>>>>>> >>
>>>>>>>> >> Peter.
>>>>>>>> >>
>>>>>>>> >> On Sat, Jan 30, 2021 at 4:54 PM Peter Sampson <
>>>>>>>> >> pet...@gm...> wrote:
>>>>>>>> >>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>> On Sat, Jan 30, 2021 at 4:47 PM Steve Fiddle <
>>>>>>>> ste...@gm...>
>>>>>>>> >>> wrote:
>>>>>>>> >>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> On Sat, 30 Jan 2021 at 16:32, Peter Sampson <
>>>>>>>> >>>> pet...@gm...> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>> On Sat, Jan 30, 2021 at 4:21 PM Steve Fiddle
>>>>>>>> >>>>> <ste...@gm...>
>>>>>>>> >>>>> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>>> Copy and Paste for time  tracks sounds to me like a major
>>>>>>>> can of
>>>>>>>> >>>>>> worms. Also, we have recorded precisely zero requests for
>>>>>>>> this
>>>>>>>> >>>>>> feature.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>> I am strongly of the opinion that we should not implement
>>>>>>>> copy /
>>>>>>>> >>>>>> paste
>>>>>>>> >>>>>> for time tracks until we have a much better implementation
>>>>>>>> of time
>>>>>>>> >>>>>> tracks.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>> It's not a question of whether we implement or not - you can
>>>>>>>> already
>>>>>>>> >>>>> do
>>>>>>>> >>>>> it  - but you need to select in the audio
>>>>>>>> >>>>> I only tried this with a single audio track and a time
>>>>>>>> track.  I've no
>>>>>>>> >>>>> idea how it works
>>>>>>>> >>>>> a) in a multi-track project - with all or just some tracks
>>>>>>>> with
>>>>>>>> >>>>> selected audio
>>>>>>>> >>>>> b) when some tracks are above and some below the Time track
>>>>>>>> >>>>> c) what the interaction is with Sync-Lock (or other settings)
>>>>>>>> >>>>> d) other use cases I haven't thought of yet.
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>> Regarding  importing a project, I think that if both the
>>>>>>>> current
>>>>>>>> >>>>>> project and the imported project have time tracks, the
>>>>>>>> imported time
>>>>>>>> >>>>>> track
>>>>>>>> >>>>>> should replace  the current time track. (If the user prefers
>>>>>>>> to retain
>>>>>>>> >>>>>> the
>>>>>>>> >>>>>> current time track, then they need to remove the time track
>>>>>>>> from the
>>>>>>>> >>>>>> project  that they intend to import.)
>>>>>>>> >>>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>> I think it should be the other way around.
>>>>>>>> >>>>>
>>>>>>>> >>>>
>>>>>>>> >>>> If it is the other way round, then either it is impossible to
>>>>>>>> import a
>>>>>>>> >>>> time track, or we have some cases where a time track can be
>>>>>>>> imported
>>>>>>>> >>>> and
>>>>>>>> >>>> some cases where it cannot.
>>>>>>>> >>>>
>>>>>>>> >>>> On the other hand, if an imported time track overwrites the
>>>>>>>> current
>>>>>>>> >>>> time
>>>>>>>> >>>> track (if present), then the user has control to either import
>>>>>>>> a time
>>>>>>>> >>>> track
>>>>>>>> >>>> or not. I'm in favour of allowing the user to make this
>>>>>>>> decision rather
>>>>>>>> >>>> than prohibiting the import of time tracks or introducing
>>>>>>>> "special
>>>>>>>> >>>> case"
>>>>>>>> >>>> inconsistencies.
>>>>>>>> >>>>
>>>>>>>> >>>
>>>>>>>> >>> Good point,  I concede, I think you're right about this.
>>>>>>>> >>>
>>>>>>>> >>> Peter.
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>
>>>>>>>> >>>> Steve
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>> If you are importing into a project that already has aTime
>>>>>>>> Track then
>>>>>>>> >>>>> I
>>>>>>>> >>>>> think that Time Track should be retained.
>>>>>>>> >>>>>
>>>>>>>> >>>>> If the user wants the imported Time Track to be used then
>>>>>>>> they should
>>>>>>>> >>>>> first delete the Time Track in the primary project.
>>>>>>>> >>>>>
>>>>>>>> >>>>> [image: image.png]
>>>>>>>> >>>>> Peter.
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>>> Steve
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> On Sat, 30 Jan 2021 at 15:52, Paul Licameli <
>>>>>>>> pau...@gm...>
>>>>>>>> >>>>>> wrote:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>>> James, please review these details.  Peter, maybe generate
>>>>>>>> some bug
>>>>>>>> >>>>>>> issues.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> How does copy and paste of time track work, and how should
>>>>>>>> it?
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Short answer:  you can copy and paste time track points,
>>>>>>>> even into a
>>>>>>>> >>>>>>> project with an existing time track, though not all the
>>>>>>>> behavior is
>>>>>>>> >>>>>>> intuitive.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Question:  If you import an .aup3 project with a time
>>>>>>>> track, should
>>>>>>>> >>>>>>> that do the same as paste (pasting at time 0 and shifting
>>>>>>>> other
>>>>>>>> >>>>>>> control
>>>>>>>> >>>>>>> points right), or should it replace the old time track with
>>>>>>>> a new one
>>>>>>>> >>>>>>> (but
>>>>>>>> >>>>>>> maybe losing some of your data)?  James argues for the
>>>>>>>> second
>>>>>>>> >>>>>>> solution, I'm
>>>>>>>> >>>>>>> not sure I agree.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> We need agreement on that to commit simplified code for
>>>>>>>> aup3 import,
>>>>>>>> >>>>>>> reducing the amount of sqlite3 calls we need to maintain.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Details.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>    1. Make new project with a time track and some control
>>>>>>>> points,
>>>>>>>> >>>>>>>    and some generated sound
>>>>>>>> >>>>>>>    2. Select all Ctrl + A
>>>>>>>> >>>>>>>    3. Select time track and deselect wave track with Ctrl +
>>>>>>>> click
>>>>>>>> >>>>>>>    4. Try to copy - dialog box tells you to select some
>>>>>>>> audio
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> That has been so at least since 2.3.1:  You can't copy if
>>>>>>>> only time
>>>>>>>> >>>>>>> track is selected.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> But, if time track is selected and another track -- then is
>>>>>>>> it
>>>>>>>> >>>>>>> copied
>>>>>>>> >>>>>>> to clipboard?  Since at least 2.3.1, yes, because then
>>>>>>>> pasting into
>>>>>>>> >>>>>>> another
>>>>>>>> >>>>>>> project makes a time track.  So a time track IS copyable.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> But in 2.3.1, the time track points were lost.  2.3.2
>>>>>>>> changed that.
>>>>>>>> >>>>>>> Time track points may be inserted into a time track that
>>>>>>>> already
>>>>>>>> >>>>>>> exists and
>>>>>>>> >>>>>>> has other points.  There may be discontinuities at the
>>>>>>>> edges of the
>>>>>>>> >>>>>>> paste,
>>>>>>>> >>>>>>> arguably correct or not.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> I also notice that if you have cut time & wave tracks, then
>>>>>>>> paste
>>>>>>>> >>>>>>> into a new project with only a time track -- then, whether
>>>>>>>> the wave
>>>>>>>> >>>>>>> track
>>>>>>>> >>>>>>> pastes or not, depends whether the time track is selected
>>>>>>>> or not.  If
>>>>>>>> >>>>>>> it
>>>>>>>> >>>>>>> was, I only paste time track.  Undo, click background,
>>>>>>>> paste -- then
>>>>>>>> >>>>>>> both
>>>>>>>> >>>>>>> paste.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Audacity-quality mailing list
>>>>>>>> Aud...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Audacity-quality mailing list
>>>>>>> Aud...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> Aud...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> Aud...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> Aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> Aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>