Samples Overlapping Slightly

Hi,

Sometimes when I export a loop from Renoise and reimport it to a new song it does not loop properly. What I mean is that the final part of the loop ends ever so slightly late, so when it retriggers I get an unnecessary peak in audio when the start and end play at the same time. The same thing also happens if I try to retrigger my loop early.

Can I prevent this?

Cheers Renoisers :)

Hey, thanks for the reply and going into so much detail!

The thing is though mate, the problem isn’t the loop being in the right tempo… I’ve chopped, rearranged, eqd and distorted my break then exported it out of Renoise. Next I’ve rechopped it and done some more eqing (it’s in perfect time at this point). This is where the problem comes in… When I reimport the beat back into Renoise (at the same tempo) it overlaps with itself when it comes to retriggering. I can’t see why it would do that when it was looping perfectly when I rendered it :blink:

Is it a bug?

I believe the problem you are experiencing here could be related to plugin delay compensation, or in Renoise’s case, the lack of plugin delay compensation. Certain effects such as compressors, reverbs, filters, even EQs, can introduce a small delay into the audio chain. Typically speaking, the more intensive the effect is, the larger the amount of delay it introduces. You can see this happening easily when using FFT based effects, or with big convolution based reverbs, etc.

Without going into too much detail, the reason for the delay is usually because the effect algorithm itself needs access to a large group of samples to do its processing. In many cases it will need access to samples which are “in the future” which is of course impossible to do, so to get around this limitation the audio must be buffered for X samples and the rest is simply filled up with silence, then the algorithm is adjusted to work with this delayed buffer. And the result is a small bit of silence at the beginning of everything, which offsets the rest of the audio, resulting in the end being slightly chopped off.

Until Renoise gets full delay compensation (if it ever does, since from what I’ve read it’s apparently a really shitty problem to try and solve) a very simple thing you can do is simply export 2 loops, or 3, or whatever number you need + 1. Then you will have to cut this export down to the correct size to remove the silence from the beginning and fix the premature ending. A bit of extra work, but worth it in the end.

.

crytek: Cheers, I’m making dnb by the way. I don’t understand why my beat would suddenly become out of time when I export it :huh: I don’t understand why adding harmonics through distortion would change the timing of my loop either -can you enlighten me please? It’s weird, the problem doesn’t always occur. I would have thought that even if my beat was completely out of time (or much longer than the pattern) it would still cut before it was retriggered and not overlap! If I enable the beat sync feature the problem is even more likely to occur!

dblue: Thanks too. I did think about plugin delays, but I only use plugs that don’t cause any (as much as that can be true). The only plugs I used on my beat were Gliss EQ and CamelCrusher. I have tested to see if these plugs cause delay (by checking for phasing by the same sample on effected and non-effected channels) but they don’t. Like I said above, even if my beat were delayed surely it would be cut before it was retriggered?

Here is an example of what I mean:

http://www.fileden.com/files/2007/1/1/580287/problem.xrns

I had to carefully watch the peak meter several times before I finally noticed what the hell you were talking about :D But yes, I definitely see the little peak now and I know what is causing it.

Let’s say you have a sample with no instrument envelope. The sample is playing and then you have a note-off command to stop it. The sample doesn’t immediately go from full volume to dead silence - this would cause a horrible click in almost every instance. So instead there is a very quick volume fade out to give a cleaner note-off.

To demonstrate things, I’m using a pulse sample which goes immediately from dead silence to 50% volume and then stays at 50% volume (basically creating pure DC offset which is very useful for highlighting strange behaviour, or to see the exact effects of a volume envelope, etc).

A note-on followed by a note-off looks something like this:

You can see very clearly that the sample started correctly, with no volume ramping occuring, but at the note-off there was some volume ramping down to silence.


Now let’s look at turning the sample on and off using volume commands:

Here we can see that Renoise is now ramping the volume up as well as down. Again, this is simply to avoid nasty clicks that would normally occur from instant volume changes.


Finally let’s look at a note-on, followed by a 2nd note-on, then a note-off:

This one is quite interesting. I’ve highlighted in dark red where the first note-off is fading out to silence. We can clearly see that while this first note is fading out, the tail is actually mixing back into the beginning of the 2nd note and causing a brief spike due to their combined volume. This is what seems to be happening to your breakbeat sample.


So… what can you do about it? Well, unfortunately I don’t think you can really do much to stop this since it is simply a part of the audio engine. And to be honest, the benefits from this behaviour are probably far more important than the side-effects. Quick volume changes and note-off’s without this feature would sound a lot more noisy and nasty.

Something you could try is to add a volume envelope with sustain to the breakbeat, and immediately before you play a new note (with sample offset or something) add a note-off command. Of course this might affect the sound of the break too much, giving it a more stuttering feeling with all the little fade outs from the envelopes, and you might need to double the resolution of your song to get enough accuracy with the note-off positions… :unsure:

However… looking into this problem gave me an idea which could possibly be useful in a future update to Renoise. Maybe it would be possible to enable/disable this volume ramping per instrument or sample, if the user is absolutely certain that they don’t need it?

Taktik… any thoughts?

.

Wow, that’s a really great explanation mate, thanks a lot!

What you’ve said makes perfect sense. I just assumed that note-off meant literally ‘note off’, but I can see why the fade is added.

I think a solution might be having a fade in and out setting for each note on and off command which would be calculated in ms and not ticks. I realise that Renoise works in ticks, but I think this could prove very useful.

I think the best solution to my problem at the moment seems to be rechopping my break. Not the end of the world :)

I don’t think you should ever have to limit yourself… but if you understand what is going on behind the scenes, then you can at least work around it hopefully.

.

:)

This is really interesting. And indeed: I would love to have a feature where I can decide per sample how it should cut. And if it smoothes, it would be nice to set the ‘smootheness’. The ramps are now hardcoded, so there’s nothing we can do about it.

Anyways, thanks for the (graphical) explanation.
Really nice to see this kind of subjects here.

by the way: this really isn’t a beginners question i think :)
this is going into high tech details about the audio engine.

maybe use a plugin like ggclip to limit those peaks on each track where this happens. it uses nearly no cpu and would be very useful for those things.

http://www.gvst.co.uk/

apart from that I think that you really just have bad luck with the problem there, normally a sample starts with an attack from the zero-line, so even if the other sample that is faded out is somewhere in the peak area they should not both “clip” or peak like this. except you just chop into there with the 09xx ommand oofcourse.

Whoo thanks for that link, great stuff there!

yeah, he has some great basic butter&bread effects that are very low on the cpu.