Re: [Audacity-quality] Sync lock and "editing a clip can move other clips" preference

[Chrysophylax <chr...@ya...>]

I think Steve misunderstands.

The preference checkbox, when on, permits editing one clip to move other clips.  When off, not.

My suggestion was that when the checkbox is off, Sync Lock is also turned off and cannot be turned on.  That is the simplest way perhaps to solve the conflict between requirements of Sync Lock and the restrictions of turning the box off.

I did not suggest removing the Sync Lock feature entirely, and I do not think Gale understood me as saying that.


The alternative to what I propose would be Sync Lock that sometimes applies, but sometimes is prohibited, when the checkbox is also off, depending whether the right edge of selection before the edit falls in or after the last clip of the track to adjusted, or does not so fall.  When Sync Lock is blocked, the edit must be aborted and an error message displayed.  This solution would be more difficult to implement as the code is now organized.




On Wednesday, January 21, 2015 7:42 PM, Steve the Fiddle <ste...@gm...> wrote:
On 21 January 2015 at 03:48, Gale <ga...@au...> wrote:
> I'm still with Paul on this. To me, Sync-Locked tracks are incompatible
> with the pref to prevent other clips being moved, even though you
> might sometimes have the space to move them and you might
> sometimes get a complete Sync-Lock.

I disagree.
Sync-Lock not only maintains synchronisation horizontally (along the
timeline) but also vertically (clips that are "stacked" across
multiple tracks).

Probably easiest if I give an example:

The task: To create a sound effect track for a video, film or stage production.

Frequently sound effects at specific time positions will be "stacked"
vertically. For example, in a "car crash scene", there may be sound
effects for screeching tires, a loud bang and breaking glass. Each of
these are likely to be separate sound clips, stacked on separate
tracks (thus allowing the precise timing to be tweaked as necessary.

Either side of this stacked collection of clips, there will probably
be a large amount of empty space.

Further along the timeline there will be other stacks of audio clips
that are synchronised to specific timed events.
It is essential that editing one stack of clips does not cause other
stacks to move, therefore "Editing clips can move other clips" should
be disabled.

However, if the time position of one stack of clips needs to be
adjusted, it is essential that the entire stack is moved together. The
simplest, safest, quickest and most convenient way to do this is to
temporarily enable Sync-Lock. Then when one clip in the stack is
moved, the entire stack moves together.

Managing large projects like this and maintaining correct
synchronisation is not easy, but fortunately Audacity includes the
necessary features to be able to handle the task. Features that you
propose to remove.

Steve


>
> Allowing the two to co-exist is exposing bugs at the moment, regardless.

If we disabled features that have bugs, how much of Audacity would be left?

Steve

>
>
>
> Gale
>
>
> Chrysophylax wrote
>> Here's what I am thinking.
>>
>> To adjust a sync-locked track, when the edited selection changes length,
>> one or two things happen:
>>
>> 1) If the right edge of the selection, before the edit, was inside a clip
>> of the sync-locked track -- then change that clip, either deleting from it
>> (and possibly earlier clips too), or inserting silence; and --
>>
>> 2) If other clips are (completely) to the right of that time, then move
>> them all either left or right.
>>
>> Now the preference disallows (2).  So if (2) would be required, should the
>> program do nothing and fail the entire edit?  That would enforce the
>> preference.  Or should it quietly ignore that and let the edit proceed
>> with no effect on the sync locked track?  That is not honoring the
>> preference.  Or should it do only part (1) and quietly skip part (2)?  But
>> that's not really doing a complete sync-lock.
>>
>> What if part (2) is not required?  Should it do part (1) as needed?  Then
>> that might be a complete sync-lock in that case, but then, sync lock would
>> sometimes be completed and sometimes not.
>>
>>
>> What does Audacity actually do now?  I think it is not a consistent
>> implementation of any of those choices, as documented in bug 825.
>>
>> So I think it may be simplest to sidestep this messy question and just
>> say, no sync-locked allowed, when the preference does not allow moving of
>> clips.
>>
>>
>>
>>
>>
>> On Friday, January 16, 2015 11:08 AM, Chrysophylax &lt;
>
>> chrysophylaxdives@
>
>> &gt; wrote:
>> See but 825, one of several I recently added after my own review of
>> WaveTrack.cpp for my own education.
>>
>> When the "editing a clip can move other clips" check box is off, Sync Lock
>> causes strange things to happen.  How should correct behavior be defined?
>>
>> Perhaps Sync Lock should just be disabled when that preference is off.
>>
>> ------------------------------------------------------------------------------
>> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
>> GigeNET is offering a free month of service with a new server in Ashburn.
>> Choose from 2 high performing configs, both with 100TB of bandwidth.
>> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>> http://p.sf.net/sfu/gigenet
>> _______________________________________________
>> Audacity-quality mailing list
>
>> Audacity-quality@.sourceforge
>
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
>
>
> --
> View this message in context: http://audacity.238276.n2.nabble.com/Sync-lock-and-editing-a-clip-can-move-other-clips-preference-tp7566981p7567073.html
> Sent from the audacity-quality mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> GigeNET is offering a free month of service with a new server in Ashburn.
> Choose from 2 high performing configs, both with 100TB of bandwidth.
> Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> http://p.sf.net/sfu/gigenet
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
Audacity-quality mailing list
Aud...@li...
https://lists.sourceforge.net/lists/listinfo/audacity-quality