Possibly improve Nearest Neighbor filter

[PiotrGrochowski]

Currently, OpenMPT takes a magic number. In case of 2 samples to 14 samples, it's 0.142857142857142857. The mistake? Sample 7 incorrectly is done as 7 times this magic number, or 0.999999999999999999. Instead, directly the division 7/7 should be used instead.

[Saga Musix]

For everyone missing the context of this cryptic post, you can find it here, including the explanation why this is not going to change: https://bugs.openmpt.org/view.php?id=1007

Instead, directly the division 7/7 should be used instead.

This is simply not possible. What you want OpenMPT to be is a symbolic calculator, i.e. a calculator that does not immediately calculate the result of a "lossy" operation, but there is no reason in the world why a sampler should do such expensive operations. Upsampling or downsampling by 7 octaves at great precision is way out of the intended resampling range of OpenMPT. If you really insist on having such perfect resampling of a square wave, you will have to draw the square wave yourself.

[PiotrGrochowski]

Then I blame you for telling me to use the forum.

[PiotrGrochowski]

Wouldn't it possible to give users the option to use fast version or accurate version, like in the pitch and tempo change in Audacity?

[Saga Musix]

If you start by taking e.g. a square wave sample that is 256 points long instead of a combination of 2-point, 4-point, 8-point, etc. samples, you won't have any of these problems. We won't add another analytically "correct" (the current one is not any less correct) resampling mode just for this use case. Please re-read and understand manx' comment on this matter, it also applies to this issue.

[PiotrGrochowski]

I want a real solution, not a workaround. Please add a Symbolic Calculator resampling, which is like No Interpolation but correct. Your method (use a magic number and multiply it) simply fails. It's twice the issue than normally because there is no generator of any type, in this case, square wave type of generator is needed.

Also, note that if you make a 2x2 image in Paint and resize it to 14x2, it's correct. Magic? I think not.

[Saga Musix]

It's not a workaround if it produces the correct solution. What you want to be done is simply beyond anything that's remotely sensible. We do not use any magic numbers, we simply use 64-bit fractional integers which is already very high precision. OpenMPT is not suitable for your wish of analytical perfection, please use another piece of software for such things.

[PiotrGrochowski]

I'm sure 256 samples square wave instead of 2 is a workaround. I'm sure it will still fail for some astronomic size.

Audacity told me to use another program for 8-bit PCM
OpenMPT told me to use another program for correct nearest neighbor
What's next? I don't like lazy developers.

There IS a magic number. In case of that 2 to 14 resampling, it's 0.1428571428571429. Isn't it a magic number that's multiplied (or added) each time?

[Saga Musix]

If you call developers lazy, do not expect to get any help from them. We are not your coding slaves. We decide what's reasonable to implement and what you propose is absolutely unreasonable in the context of OpenMPT.
If both programs are not suitable for your needs, you will need to find another program, or write your own. Maybe then you will realize how difficult the things you want to be implemented are, and why pretty much everyone else is happy enough with almost-perfect solutions.

[PiotrGrochowski]

If they ask people to use another program instead of implementing it themselves, they are by definition lazy. Why in the world would anyone think there is another program with same features?

Roses are red
Violets are blue
Paint does it right
And so should you

[Saga Musix]

Neither OpenMPT nor Audacity are meant to be "Swiss Army Knives" of audio processing. They both can do a lot but there is also a lot they cannot do (intentionally). Generally you can assume that both projects implement features they consider to be worthwhile for the majority of users. If they implemented every single feature that was ever requested (and if they actually had the time to, which they don't!), they would be unusable bloatware because their menus would be filled with options and features that only a single person ever needs. OpenMPT also cannot import Cubase project files. Does that mean that its developers are lazy? No, absolutely not. It's reasonable that such a feature doesn't exist.

If you call me or any other open-source developer lazy, then you have zero understanding that I have a live too that is not only about implementing your wishes about OpenMPT. OpenMPT is a spare time project, not my job, and while I already invest more time than is probably healthy, the last thing I need is being called lazy. You have no demands from me unless you pay me for implementing features (and believe me, you cannot afford that).

And before you call the developers anything else in addition to "lazy", I would recommend you to the read the forum rules.

[PiotrGrochowski]

Not being able to import Cubase project files is not lazy because it wasn't requested. But an actually good nearest neighbor filter is requested, and you told me to use another program, which is being lazy.

[Rakib]

Saga Musix I envy your patience.

[PiotrGrochowski]

8-bit PCM is a legacy feature, and so is Nearest Neighbor that works. So it would make OpenMPT consistent.

[Alice (Midori)]

What's next? I don't like lazy developers.

Considering the amount of work Saga and manx are putting into MPT's development, and how many smaller or bigger improvements are being made every iteration of it "lazy" is the last thing that comes into mind, especially given the fact that they do this in their damned spare time.

I'm genuinely curious at this point tho; Why do you insist on this feature so much? Is it stopping you from making quality music with OpenMPT anyhow, or you want it just for the sake of unnecessary perfection?