How does software mixing work in OpenMPT?

[FreezeFlame(Alchemy)]

How can it produce those monophonic voices?

An interested in making something like this in the future, but better optimized once i learned how to assembly code from middle school.
https://www.youtube.com/watch?v=b_QbBE_fXZs&list=FLXMpSr8eQgWqyUCOl4ev1cA

[FreezeFlame(Alchemy)]

Mind if this topic gets moved to Help and Questions?

[Saga Musix]

Mixing is as simple as adding two values together. Depending on the volume, you can also scale the values that are being added (multiply with e.g. 0.5 to make it half as loud). To make a sample play slower or faster, you have to increment the sample play position by lower or higher values. That's the basics. There is really no black magic behind it, and OpenMPT does it the same way as other applications do it. If you are intersted in how OpenMPT does things specifically, look at MixerInterface.h, IntMixer.h, and Fastmix.cpp.

[FreezeFlame(Alchemy)]

Ok, thanks.

[Rakib]

If c++ is hard for you, you can always try a programming language like Chuck, which is a audio programming languagehttp://en.m.wikipedia.org/wiki/ChucK

[FreezeFlame(Alchemy)]

Mixing is as simple as adding two values together. Depending on the volume, you can also scale the values that are being added (multiply with e.g. 0.5 to make it half as loud).

So, its something like that:

1/mixed channels=divined volumen per channel.

And then adding the divined volumen values per channel together for the master output. But, doesn't that causes more noise to appear?

[Saga Musix]

Hell no, you never ever divide by the number of mixed channels or anything! Doing so would cause complete havoc since the number of mixed voices changes all the time. That paragraph explained how to adjust the volume of a single channel like you would do it when e.g. processing volume commands or volume envelopes.

[FreezeFlame(Alchemy)]

Thanks for the advice. I experimented abit and tried your method adding the values (channels) together, and it works great, if the end result does not overflow from the maximum value of the sampling resolution (in my case 8bit, which can go from 0-255). How can i eliminate this?

[Saga Musix]

If your architecture does not provide saturated arithmetic you have to do it yourself, which is of course costly. One way to avoid it is to reduce the mixing precision (e.g. treat the mix buffer as 7 bit + 1 bit of headroom), which is what OpenMPT does (32 bit mix buffer, 28 bit  = 0dB, so 4 bits of headroom). Mixing in 8 bit precision is a really bad idea, even DOS trackers like IT and FT2 didn't do this. You will get an extremely noisy output not only because of 8 bit in general but also because of the needed headroom. If you absolutely must output 8 bit audio in the end, it makes more sense to mix in a 32 bit buffer and then dither the output to 8 bit instead. Or if you don't have any restrictions to the output format, do the mixing in floating point precision right away so that no wraparounds can occur anyway.

[FreezeFlame(Alchemy)]

If your architecture does not provide saturated arithmetic you have to do it yourself, which is of course costly.

The microcontroller (MSP430G2553) does not support this AFAIK. I guess making an string, in which the value of the result is checked if it is bigger then 255 would be of use.
If it is >255, then it discards the result and replaces the value with 255 as the result. If it is <255, then it goes on without trouble.

One way to avoid it is to reduce the mixing precision

Doesn't that make the problem worse?

Mixing in 8 bit precision is a really bad idea, even DOS trackers like IT and FT2 didn't do this.

The DAC i use for this project is sadly 8bit fixed. I will try your suggestion about mixing it in an higher resolution and then dithering it to 8bit.

[Saga Musix]

One way to avoid it is to reduce the mixing precision

Doesn't that make the problem worse?

I should probably clarify what I mean: You could reduce the mixing precision by dividing the sample data by 2 before adding it, so that two samples added together cannot overflow. Then you need to saturate the result after every addition. But as said, that's way too noisy for 8 bit mixing, so I'd rather go with a higher-precision mixing buffer and then dithering the output to 8 bit.