<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 9:05 PM, Thomas Vecchione <span dir="ltr"><<a href="mailto:seablaede@gmail.com" target="_blank">seablaede@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class=""><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 2, 2014 at 8:17 PM, Paul Davis <span dir="ltr"><<a href="mailto:paul@linuxaudiosystems.com" target="_blank">paul@linuxaudiosystems.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div></div><div>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.<br>


</div><br></div></div></div>
</blockquote></div><br></div></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div></div></blockquote><div><br></div><div>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.<br>
<br></div><div>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).<br>
<br></div><div>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.<br></div><div>Tracking changes to the overlap caused by motion or trimming ... not feasible (at least not for me)<br>
<br>--p<br> <br></div></div></div></div>