[Ardour-Users] Ardour 3 - export bugs

[Paul Davis]

On Wed, Jul 2, 2014 at 9:05 PM, Thomas Vecchione <seablaede at gmail.com>
wrote:

>
>
>
> On Wed, Jul 2, 2014 at 8:17 PM, Paul Davis <paul at linuxaudiosystems.com>
> wrote:
>
>>
>> As I said, I'm entirely in favor of reinstating "make xfades as long as
>> the overlap when the overlap is created". I'm not in favor of "make the
>> xfade track the overlap" because that fundamentally conflicts with our
>> model of what fades really are, now.
>>
>>
> I suspect there is a terminology issue here in describing this.  When I
> think of this, I think of modifying the region ends of the lower and upper
> layer to modify the crossfade, but what you are I _think_ describing is
> modifying the fade start and end point regardless of where the audio region
> starts and ends for the upper and lower layers?  The end result is
> effectively the same if I am correct, it is just easier to visualize for
> myself, and I suspect others in the form of modifying the region start and
> end points, but the issue here being what if one region is completely
> contained within another, where your solution is obviously the better one.
>
> If I am understanding you correctly and described it correctly above, then
> I don't think there is much issue I have with this.  If however I am
> misunderstanding would love a bit of clarification.
>
>
What happens/ed in Ardour 2 is that whenever 2 regions overlap a crossfade
*OBJECT* was created corresponding to precisely the overlap between those
two regions. As the regions were moved or trimmed, the crossfade object was
adjusted to reflect that.

I have no plans to bring back this model. There is no crossfade object
anymore, and there is no notion of a fade between two particular regions,
only between a region and whatever else is below it (which could be 10
regions or could be silence).

Changing things so that when you first overlap two regions, the xfade of
the uppermost region is adjusted so that its length matches the length of
the overlap is ... feasible.
Tracking changes to the overlap caused by motion or trimming ... not
feasible (at least not for me)

--p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ardour.org/pipermail/ardour-users-ardour.org/attachments/20140702/f4fddbe8/attachment.htm>