Full Version:
OpenMPT v1.17.02.50
Has the bug occured in previous versions? If yes, please specify version(s): (This option is optional, and doesn't need research. But in case you know...)
All versions
Description of the bug:
The original S3M format did not have Zxx effects, but you can actually use them in MPT. This may result in wrongly played modules which used extensions of old players like PixPlay which interpreted Zxx as panning.
Example Tune (http://modarchive.org/data/downloads.php?moduleid=34641#CRAWLING.S3M)
I guess that (almost) nobody used Zxx in S3M tunes (as it really should not be possible!), so it's probably safer to remove this feature from the S3M playback engine.
Fixed in OpenMPT 1.17.02.53
Zxx indeed is not in the list of S3M effects.
Listening to this example tune, I got the impression that the playback suffers a strong lowpassfilter.
Of course it does since Zxx is a low-pass filter :P
Replacing those commands by S8x works remedies the situation.
nah, in this case Zxx is a high-cut filter :lol:
I'm afraid some readers will wonder here : - what's the difference ?
lol, it was a joke :lol:, the 2 terms are completely same =)
letting only the low-frequency signals pass, or cutting of the high ones gives exactly the same resoult ^_^
it probably doesn't, depending on the quality of the filter. however, the filter MPT uses doesn't seem to be the same the original IT uses, so Modules with resonant filters sound different (mostly sharper) in IT.
I think you're both right here. But psishock in a theoretical way, and Jojo in a practical way.
Electronic circuits, analog or digital, always will have some slope, or curve, between the pass and the cut area.
Btw: A resonant filter is not the same as a plain LPF or HPF. Then the 'Q-factor' also is a variable.
As the Zxx macro editor is disabled anyway for Zxx files, I'm going to try to remove the Zxx standard macro (cutoff) for S3M files. I guess nobody has something against this..? :P
How about simply interpreting Zxx as S8x for S3M?
I haven't looked at many S3M files or players, but there aren't many which use Zxx for anything indeed. but as this isn't a standard behavious it's maybe better to ignore it. I'm not really sure...
I thought of an option in the Module settings (there's enough empty space anyway): A dropdown list how to handle Zxx: Compatible (No interpretation), PixPlay (Emulate S8x), MPT (Cutoff/Resonance)
Quote from: "Jojo"I thought of an option in the Module settings (there's enough empty space anyway): A dropdown list how to handle Zxx: Compatible (No interpretation), PixPlay (Emulate S8x), MPT (Cutoff/Resonance)
The list seems reasonable -- my previous idea of simply interpreting Zxx as S8x isn't good.
I think this is worth discussing in the forums so we can hear other opinions as well...
If a Zxx effect is detected in a S3M module while being loaded, this message will appear:
(http://sagagames.de/ithumb/thumbs/question-zxx5164fj49.jpg) (http://sagagames.de/ithumb/show/question-zxx5164fj49.png)
I'll quickly c&p my mail to relabs concerning the action assigned to the "no" button:
QuoteI don't know if *removing* the effects is really that good. If the user clicks "no", they could be kept instead and the macro configuration could be deleted as I suggested it in the beginning. But I guess there are arguments for both sides:
- You can remove the Zxx effects from the patterns (which would contradict the way it's done at the moment)
- You can remove Macros by yourself (which would contradict my new suggestion)
Is it perhaps possible to relabel the buttons? That'd be a lot more intuitive, IMHO...
without looking at the sourcecode, i'd say it's a common windows messagebox and you can't change labels there. but i thought about moving this into the Module Properties (like the IT-related stuff) anyway.
Indeed. I see this happening alot is software. Ofcource you could create your own dialog and the problem would be fixed, but it happens in other software too, so its not a big deal, really.
I agree that the dialog is crappy, but it deals with a rare situation among S3M files which themselves are rather rare compared to it and xm -- not worth the effort in my opinion.
Although this is already closed, I think something can still be optimized here. Maybe we could check for MPT-made s3ms (like this: http://schismtracker.org/hg/rev/8c3d4b21b8c4) and then only interpret Zxx as cutoff stuff when MPT is detected