That's true, all audio clips are slightly faded-in and out at their edges, allegedly to avoid glitches as much as possible. This "artifact" can be indeed very noticeable if you happen to run jackd with large buffer sizes and slower sample rates (=> higher latencies). As first try, reduce the buffer size, for instance to 128 frames which is one good compromise all around. You'll see the slight just becomes slighter, or else. :)
But now that you ask, there's one hack of an idea I got this very moment: audio clips with zero-offsets, that is, their start frame equals the first frame of the audio file which they represent, should not be targets to that anti-glitch fade-in or so. That obviously assumes the audio file is well cut from the start. Nice eh?
Be prepared to play catch up with svn trunk ;) a fix will be cooking in no time ;)
Cheers
[UPDATE:] faster than lightning: qtractor 0.4.3.1452+ (svn trunk) already does the hack!
That's true, all audio clips are slightly faded-in and out at their edges, allegedly to avoid glitches as much as possible. This "artifact" can be indeed very noticeable if you happen to run jackd with large buffer sizes and slower sample rates (=> higher latencies). As first try, reduce the buffer size, for instance to 128 frames which is one good compromise all around. You'll see the slight just becomes slighter, or else. :)
But now that you ask, there's one hack of an idea I got this very moment: audio clips with zero-offsets, that is, their start frame equals the first frame of the audio file which they represent, should not be targets to that anti-glitch fade-in or so. That obviously assumes the audio file is well cut from the start. Nice eh?
Be prepared to play catch up with svn trunk ;) a fix will be cooking in no time ;)
Cheers
[UPDATE:] faster than lightning: qtractor 0.4.3.1452+ (svn trunk) already does the hack!