prezzodaman / pymod Goto Github PK

The test modules added in the repo are great. It could be useful to check in renders of those modules and build unit tests that check that these remain correct after changes are made to the code.

I can provide a PR for this.

Render the test module "filter.mod" to a mixed file, then render it to individual channels. After mixing the channels together and comparing against the file mixed in Pymod, there's a handful of bytes in the filtered section which are off.

When rendering in hard-panned stereo, the bytes are only off by one, but in mono, the bytes are off significantly more (likely because all the bytes are mixed together before the "filter" is applied). This is causing the unit tests to fail.

The issue is likely in the "filtering" code, where the difference between the current and last bytes is calculated:

channel_sum_left = (channel_sum_left + channel_sum_left_last) // 2
channel_sum_right = (channel_sum_right + channel_sum_right_last) // 2

A potential solution could be to implement a proper filter that's much more accurate.

The code separates into two when dealing with rendering a single channel and rendering a mix of all channels.

That's probably a bit error-prone, especially ones that could only take place in one codepath and not the other.

Any issue with changing this and making code always act like it's a mix of channels but just mute other channels when rendering only one?

I can provide a PR for this.

I'd like to make the lib into something that can be posted on pypi and that can be used both as a command line tool and a module.

Anything I should be aware of before embarking on this?

I use hatch to build my pypi packages, let me know if that works for you too.

I can provide a PR for this.

The code looks like it's changing between the two in a lot of place, as in:

mod_channel_pan = [0] * mod_channels_adjusted

which makes an array of mod_channels_adjusted values, but then:

for a in range(0, mod_channels):
    ...
    mod_channel_pan[a] = 0.5

which only goes over mod_channels values.

Technically, if the code is not distributed with a license attached then it can't legally be used by other people.

You should probably pick a license that works for you and add it to a LICENSE file and in the file headers too.

For some reason, when rendering "ode2ptk.mod" to individual channels, channels 2-4 render slightly later, even though it's using the exact same code as rendering to a mixed file. In the picture below, the black line shows where the other channels should start:

The resulting tracks seem all maxed to volume-wise.

In ProTracker, if the current sample number is empty (e.g. no sample data and no loop), and the sample number is changed to one with a loop, that sample should begin playing immediately from the start. If a sample is playing currently and the sample number is changed to an empty one, the current sample should first play all the way through before stopping entirely. That doesn't happen right now...

(this is the only behaviour that I'm aware of that isn't implemented yet - most of the other sample swapping quirks have been added)

See OpenMPT test module https://resources.openmpt.org/player_tests/mod/PTSwapEmpty.mod

A lot of people consider Protracker 2.3 to be the one true version of protracker and a lot of modules rely on the replay routine abiding by 2.3 quirks and standards.

One example are the pan commands 0x80 and 0xE8. On 2.3, and on Amigas for that matter, those commands don't exists because channel panning is hardwired (1 & 4 to the left, 2 & 3 to the right).

We could add a --legacy command line option that implements this (ignoring the pan commands in this case) and any other quirks we find down the road.

I'm opening this as a note/reminder but I'll submit a PR for it later on if this is ok with you in principle.