OPL questions

[Graf Zahl]

I am currently trying to remove the GPL-incompatible OPL MusLib code from ZDoom, using Chocolate Doom as reference for an alternative.

 

I just discovered that the volume is handled a bit differently between both, the two differences I noticed are:

 

1. This comment:

        // If we are using non-modulated feedback mode, we must set the
        // volume for both voices.
        // Note that the same register volume value is written for
        // both voices, always calculated from the carrier's level
        // value.

 

Muslib doesn't do that, it uses each voice's own settings, not the one from the second  voice for both as Chocolate Doom.

 

2. Chocolate Doom is calculating the full volume like this:

    full_volume = (volume_mapping_table[voice->note_volume]
                   * volume_mapping_table[voice->channel->volume]
                   * volume_mapping_table[current_music_volume]) / (127 * 127);

 

MusLib is doing it differently:

 

    noteVolume = ((uint64_t)channelVolume * channelExpression * noteVolume) / (127*127);
    if (noteVolume > 127)
        return 127;
    else
        return volumetable[noteVolume];

 

Now I wonder which one is correct? I'd put my bets on Chocolate Doom because the code is far more recent but I'd still like to know for sure.

 

 

 

[nukeykt]

You are looking at the older version of the Chocolate Doom code. Latest version is nearly perfect(if not perfect) compared to Vanilla Doom.

[Michael92]

I have a question that is a bit off-topic: Will this rewrite affect the quality of OPL? I really love the Mame OPL2 in ZDoom that is vastly superior to other source ports' OPL output.

[Graf Zahl]

The plan has been to do an in-place substitution of the code as much as possible, using Chocolate Doom's OPL player as a source.

The only major change this involved was to replace the channel eviction logic if all are filled, but so far I haven't found anything where it matters.

 

Keep in mind that the only thing that needed replacement was the middle layer which connected ZDoom's high level MIDI player with the OPL cores, i.e. the code that transforms MIDI messages into OPL commands. Most of what this code needs to do is dictated by strict technical specifications, the problem was just that the existing code was under an unacceptable license, so I had to make sure that all non-trivial functions of it can be shown to use code that does not derive from the old one. All things combined it was roughly 10kb of source that needed to be rewritten,half of which was trivialities.

 

In case you ask what constitutes a triviality, here's an example:

 

    case ctrlPan:            /* change pan (balance) */
>        driverdata.channelPan[channel] = value -= 64;
        for(i = 0; i < io->OPLchannels; i++)
        {
            struct channelEntry *ch = &channels[i];
            if (ch->channel == id)
            {
                ch->time = MLtime;
>                io->OPLwritePan(i, ch->instr, value);
            }
        }
        break;

 

The problem with that fragment is that there's really only two relevant lines of code in there, marked with a '>'.

In addition, the code that calls this is under a non-problematic license, and the function being called also.

So not surprisingly, even after renaming stuff to more suit my personal likes, it still looks like:

 

void musicBlock::changePanning(uint32_t id, int value)
{
    oplchannels[id].Panning = value;
    for(uint32_t i = 0; i < io->NumChannels; i++)
    {
        auto &ch = voices[i];
        if (ch.index == id)
        {
            io->WritePan(i, ch.current_instr_voice, value);
        }
    }
}

 

Not much that can be done, there's really no way to implement this differently. And there are several functions that are virtual copies of this one.