View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000671||ardour||bugs||public||2004-08-08 20:23||2009-11-09 09:21|
|Summary||0000671: Clicks at splits.|
|Description||When you split a track, the fades either side of the split are the same as the start/end fades of the original region.|
This causes a click at the split point, as there is a tiny fade in/out if fades are enabled for the region, which is the default behavour.
|Additional Information||There should never be an automatic fade at a split.|
|Tags||No tags attached.|
|Users sponsoring this issue|
Total Sponsorship = US$ 30
2008-08-01 20:19: philicordas (US$ 30)
||Bit me as well with Ardour/GTK 0.529.3 libardour 0.827.4 although I'm not sure that the short default length of the inherited fades is the cause for this. I tried different lengths for the fades, [de]activated envelopes, trimmed the concerned regions etc. but couldn't get rid of the clicks.|
I would like there to be an option to disable the automatic fades.
A test for this would be...
Disable 'auto fades'.
Randomly split a long piece of audio.
There should be no clicks or glitches at the split points.
Lazy people like me use splits like markers. Splitting should not be a destructive audible operation.
a) i agree entirely that the fades should not be there initially
b) what happens when you move one or other side of the split away from the location of the split? to avoid clicks then, you may want or even need the fade
c) this is not destructive
i have thought about this for quite a long time, and i am not sure how to handle (b)
In the case of (b), yes most of the time you'd get a click.
For me, splitting a track logically, and doing a little fade in/out are two separate things. It's almost always useful to have a fade, but not always.
Here is some rambling as to why it would be useful to be able to disable automatic fade in/out....
Where I don't want it is when...
Comping parts that are spread over a few tracks. For example vocal parts, I might split four tracks into many regions, then mute and unmute parts to see which bits sound good. If there are little fade in/outs at each split, I'd have to clean up all the edits when there are contiguous unmuted parts on the same track. I might not want to clean up the edits yet anyway, so I can keep the 'logical' splits and try changing bits of vocal later.
When editing continuous sounds, sometimes lining up the waveforms or a zero crossing works better than a crossfade or fade in/out.
Compiling audio for a CD or archiving. It's good to know that if all faders are at zero, you will get the same bits that are in the original files when you export. If there are little fades at the start and ends of any imported file, it's not the same bits.
Using loops that already loop perfectly. With a fade in/out at their ends, they don't loop perfectly any more.
While the default fadein is about 2ms, this is still enough to change the sound of some drum samples.
||i think one way to approach this is that the fades get created when two regions are *not* lined up exactly next to each other. that way if a split is made, then there is no automatic fade unless they are pulled apart. if two regions are pushed together, then the fades should also be removed, as usually the two regions should be intended to be used like that, otherwise you would probably do a tiny overlap (which would once again create the auto cross fade anyway). of course this is not always the case, hence the ability to create the fades manually or turn off the auto fade behaviour.|
"if two regions are pushed together, then the fades should also be removed, as usually the two regions should be intended to be used like that,..."
This would also cause a click if the waveforms don't fit together at the cut. You would need a feature like "snap to zero crossings" or have to fiddle around to fit the waveforms together by hand, wich IMHO would not be very parctical.
"i think one way to approach this is that the fades get created when two regions are *not* lined up exactly next to each other. that way if a split is made, then there is no automatic fade unless they are pulled apart"
This is a cool idea, but a 'dumb' implementation is all I personally need.
The feature I need is to turn off automatic creation of fades on new regions.
If I create a situation where there should be a click, and I hear one, fine. It was my choice, my edit!
I keep auto fades turned off in every sequencer I use, and never have problems. I find the default fades are rarely right, or get in the way when editing.
It seems there is definitely work to be done here. Perhaps regions should either be set to have "the default fades", in which case they use a fade which is set up as a session option (and which changes depending on the value of that option), or "user specified fades", in which case fades (once set) are never changed.
Whatever the solution is, it may well be too invasive to put in 2.0.
||just a quick note as i re-read this. philicordas - 2.X has had a "Use Region Fades" toggle for 18 months or so now, which simply turns off all Region Fades entirely. this is NOT a fix for this issue, but it might help you out.|
Hello paul. I had found the "use region fades" toggle before, but as you say, it's not quite the same thing.
In practice I've found the automatic fades cause very few problems anyway, and are generally the 'right thing' to do. Of course, if anyone wants to implement this feature, my sponsorship remains available.
|2004-08-08 20:23||philicordas||New Issue|
|2004-08-08 20:23||philicordas||=> firstname.lastname@example.org|
|2004-08-08 20:23||philicordas||Name||=> philicorda|
|2004-08-12 00:51||tito||Note Added: 0001403|
|2008-08-01 20:19||philicordas||Note Added: 0005126|
|2008-08-01 20:19||philicordas||Sponsorship Added||philicordas: US$ 30|
|2008-08-01 20:19||philicordas||Sponsorship Total||0 => 30|
|2008-09-22 11:51||paul||Note Added: 0005145|
|2008-09-23 00:02||philicordas||Note Added: 0005147|
|2008-09-23 00:04||philicordas||Note Edited: 0005147|
|2008-10-26 02:49||porl||Note Added: 0005209|
|2008-10-26 15:44||the_CLA||Note Added: 0005211|
|2008-11-18 22:38||philicordas||Note Added: 0005242|
|2009-10-29 00:38||cth103||Note Added: 0006931|
|2009-10-29 00:38||cth103||Status||new => confirmed|
|2009-10-31 12:45||paul||Note Added: 0007012|
|2009-11-03 23:36||philicordas||Note Added: 0007071|
|2009-11-05 12:49||cth103||Relationship added||related to 0002896|