The Mixing problem

[potul]

Hi All,

I'm working on a digital looper, and I have the basic skeleton working, so I can record, play and overdub. I still have some digital noise issues I need to solve... but the functionality seems to work.
The problem I have is the following:

The easiest way to mix 2 signals digitally is simply average them instead of adding them, in order to avoid clipping. But.... when you do this and one of the signals is in fact silent, ... you basically reduce the output of the only remaining signal.
When doing this over and over (in my case mixing the recorded signal with the dry signal, and recording it again), I end up with a loop that fades out, because each time the loop plays/record simultaneously, it gets divided by 2...

So I was wondering if there is any other approach to mix that can preserve most of the volume without going into clippling. Some kind of compression maybe?

I've been taking  a look at this page with a proposed algorithm, and it looks promising but I haven't had the time to try it yet.

http://www.vttoth.com/digimix.htm

Mat

[MoltenVoltage]

It seems like a looper would need to continually normalize the output level or the fadeout is certain to happen.  In fact if you didn't normalize and just started playing more quietly (as opposed to stopping) it would still fade or go down in volume.

The question is whether you want what you play to continually loop or fade into the background.

The problem would be if your incoming signal is noisy, you would want to put some kind of gate on the input so you didn't mix in the noise when you weren't playing.

[potul]

I need the loop to endlesly repeat and mix with whatever signal we add... I guess some kind of normalization should be applied. I wonder how commercial loopers do that... because in these units you don't feel like any fading out is happening, and every new layer you add seem to sound at the same level....

[cloudscapes]

I bet a number of loopers do it by making sure there's extra headroom.

if I try hard enough, I can get my 2880 and smm/h to clip after several dozen overdubs of loud drones.   the 2880 is too easy to clip! the rang III seems to do a good job, though. maybe 24bit vs 16bit helps? I'm just guessing.

[potul]

As my ADC is anyway only 12bits, I can try to keep the incoming signal to 12bits without losing any resolution, and recording and playing at 16 bits. This will give me 4 bits of headroom... I guess it will give me about 5/6 overdubs without clipping. I will give it a try and see if it's enough.

[derevaun]

Seems like you could make a crude sidechain for each signal, and use a microcontroller to watch them and change the mix, resolving the various unanticipated problems that come up, with code. A tricky part would be programming the micro to respond "musically" to one signal without using delays that get in the way of watching the other signal(s). Maybe increasing compression along with reducing the signal would conceal the effects a little. In any case, please let us know what eventually works!

[potul]

Some alternatives I have in mind right now are:

-Have more headroom. Keep input at 12bits while recording at 16 bits. This will give me 4 bits of extra headroom even if I simply add the signals to be mixed
-Monitor the envelope of each signal and have an adaptative mixing, trying to maximize the usage of all available headroom without clipping
-Investigate the formula here  http://www.vttoth.com/digimix.htm . The idea is to dynamically adapt the mix so that clipping never occurs, but I guess some distortion will happen. (I'll try it tonight and see how it sounds).

I'll keep you updated. As soon as I can I'll record a small demo video.

Regards,

Mat

[Processaurus]

The Line 6 green looper is interesting how it handles it, if you listen close while overdubbing it reduces the volume of the existing loop by a little every time there is an overdub.  I wonder what their magic ratio is?

[potul]

In theory, you could use a divide factor of srt(n), being n the number of signals to be mixed... and you would be more or less OK (statistically speaking...)

[derevaun]

I wonder if there's some ducker science that applies?

[potul]

After doing some trials yesterday I couldn't find a solution other than having more headroom.
What I did is apply a reduction to the guitar signal that gets recorded but keep the recorded playback at full range (as in fact, it was already reduced when recorded). This way there is no fading out of the loop, but there is some risk of clipping when recording multiple layers. I will have to add anyway a noise gate because when overdubbing the noise gets added over and over even if you are not playing...

You can see it in action here:

http://www.diystompboxes.com/smfforum/index.php?topic=91695.0

Later this week I will try other approaches, and see if I can find a better solution.

[MoltenVoltage]

I think you will want to reduce the existing track proportionally to the incoming track.

Is the write speed on the SD card fast enough for 16 bit processing?  I was under the impression that you couldn't write that quickly to SD cards since you need to write large chunks of data at a time rather than streaming it in.

[potul]

I think you will want to reduce the existing track proportionally to the incoming track.

What I do is reduce the guitar track, mix it with the recorded track at unity gain and record the mix again. This way, the recorded track is in fact reduced as well. This way both tracks keep the same level and there is no attenuation when re-recording. But of course this does not avoid clipping after a big number of overdubs. I need to investigate a little more on this.

Is the write speed on the SD card fast enough for 16 bit processing?  I was under the impression that you couldn't write that quickly to SD cards since you need to write large chunks of data at a time rather than streaming it in.

This was the main intention of the proof of concept, test if the read/write speed is enough, and so far it's been positive. I'm recording at 16 bits and 25Khz (unless my math is wrong with the ADC configuration), and in chunks of 512 Bytes (this is the minimum block size). I can't hear any artifact due to lost samples, so I guess the speed is enough.
You have to read and write 512+512 Byes in the time you need to play 256 samples (around 10.4 ms), so you need an overall transfer rate of around 20KB/s, which seems achievable (I've seen some people in the net having much higher write transfer rates)
And you have to consider that most of the read/write time is wasted when accessing (the access time is usually bad), so by working with bigger buffers I could probably achieve higher rates (and some more latency). Probably the fastest setup would be to use DMA and write around 8 blocks at a time. If you just need to record (and not play), you can continuously "stream" data to the card as well.

BTW, in order to get the maximum speed I'm accessing the SD card sectors directly, without any filesystem (I'm not using the FAT library from Microchip).

Mat

[MoltenVoltage]

you have to consider that most of the read/write time is wasted when accessing (the access time is usually bad)

I assume you mean the bottleneck is the access time from the card.  Have you tried the newer high speed SD cards?

[potul]

Yes, this is what I meant. I think that if you access the card in continuous read mode you can get the maximum speed.
I haven't tried Hgih speed ones, the only one I've tested is a rather old 512Mb card I had around. It's true though that according to what people report, there are huge speed differences depending on the card you use... so it could be that another card would not be fast enough.

Mat