Author Topic: XMPlay, S3Ms, and Channel Volume Slide  (Read 487 times)

Joseph Collins

  • Posts: 14
XMPlay, S3Ms, and Channel Volume Slide
« on: 18 Feb '18 - 16:07 »
I'm back, again.  Hooray…

Something interesting has come to my attention, lately.  Apparently, XMPlay doesn't support the Channel Volume Slide command (Nxy), on Scream Tracker 3 modules.  How I found this out was, I've been making files in Schism Tracker (basically, a port of Impulse Tracker for modern systems), which have "if not looping" patterns that fade, using the Channel Volume Slide feature, and exporting them as Scream Tracker 3 modules.
What's so interesting, about this?  Well… Scream Tracker 3 doesn't actually have such a command, in it.  Oh, it has a Volume Slide command (Dxy)…but, that doesn't change the volume of the channel.  Just the sample that's currently playing.  But, the thing of it is… Scream Tracker 3 also doesn't prevent you from using this non-existent command.  What's even more interesting is that, if you do use the command, it does save, to the file, and even works perfectly, in certain software, such as Impulse/Schism Tracker and ModPlug/Tracker.

So, again… why is any of this interesting, in the slightest?  Because… this means that XMPlay is the only all-format module player (to my knowledge) that actually reads and plays S3Ms exactly as they were in designed to be played; without all the extra features that that Jeffery Lim introduced into Scream Tracker-based modules.

It's seemingly-simple things, like this, that both fascinate and impress me.  Kudos, un4seen developments!
Now, I have some S3M files to fix.  Heelllp meee.

saga

  • Posts: 2242
Re: XMPlay, S3Ms, and Channel Volume Slide
« Reply #1 on: 18 Feb '18 - 17:44 »
Quote
So, again… why is any of this interesting, in the slightest?  Because… this means that XMPlay is the only all-format module player (to my knowledge) that actually reads and plays S3Ms exactly as they were in designed to be played; without all the extra features that that Jeffery Lim introduced into Scream Tracker-based modules.
That's not entirely true. For example, XMPlay supports 16-bit and stereo samples, as well as command X panning, all not supported by the original ST3. Not that this fact would be relevant for anything... except for impressing people, apparently. :)
For what it's worth, it's trivial to support these extended commands depending on which tracker was used to save the file. However, in case of command X you cannot really do that because many people tracked in ST3 with other players in mind that supported this command (I think DMP introduced command X in S3M files), so ignoring it in S3M files saved with ST3 would be a bad idea - even if that's closer to what they sounded in ScreamTracker 3.

Quote
this means that XMPlay is the only all-format module player (to my knowledge) that actually reads and plays S3Ms exactly as they were in designed to be played
The last thing I want to do is a player flamewar (as I love XMPlay, too), but OpenMPT handles some obscure and rarely-used ST3 quirks more accurately, while at the same time supporting all those evil Impulse Tracker extensions. ;)

Joseph Collins

  • Posts: 14
Re: XMPlay, S3Ms, and Channel Volume Slide
« Reply #2 on: 19 Feb '18 - 04:05 »
Aww, saga…  Why'd you have to go and tell me that XMPlay isn't too-perfect-for-its-own-good?  ;)

I do find it interesting that XMPlay plays some IT-based functions, in S3Ms, when it technically shouldn't.  I mean, as I said… other players just kind of read files as, "if it says to do this, then do it," even if the original tracker program didn't have that functionality.  Disallowing channel volume shifting while not disallowing channel panning (which, I also use, in my S3Ms…  Thanks, Jeffery) seems like an oversight… though, I suppose it could be a design choice, too.  I think only one person could say which it is, but I don't expect them to do so, since it's such a trivial (read: non-critical) thing.  The program works, as it does, for the reasons it does.  And, so long as it plays my modules beautifully and precisely (and, shuffles them adequately… nyuk-nyuk), I'm a happy dude!

Quote
The last thing I want to do is a player flamewar (as I love XMPlay, too), but OpenMPT handles some obscure and rarely-used ST3 quirks more accurately, while at the same time supporting all those evil Impulse Tracker extensions. ;)
And, yet… OpenMPT still doesn't support AdLib instruments.  Then again, XMPlay doesn't seem able to play mixed-mode modules (like Zone 66 Stargunner Zone 66's dang it "Sound Blaster" variants of tunes), so…
(And, no, I'm not trying to start a "player flamewar," either!  There is no "one perfect player," but we all have our preferences!)
« Last Edit: 22 Feb '18 - 16:00 by Joseph Collins »

saga

  • Posts: 2242
Re: XMPlay, S3Ms, and Channel Volume Slide
« Reply #3 on: 19 Feb '18 - 11:49 »
Quote
There is no "one perfect player"
And that exactly was my point too. ;) In particular it's pretty much impossible to have one perfect multi-format player that handles all formats perfectly, while also allowing to customize playback settings (interpolation, pan separation, etc) for all of them AND offering a pattern view on top of that. It's just not going to happen, ever. ;)

Quote
OpenMPT still doesn't support AdLib instruments.
Adding AdLib emulation is pretty much out of scope for both OpenMPT and BASS/XMPlay I guess (if you hear any AdLib S3Ms being played in your XMPlay, it's most likely AdPlug taking care of them). One other big problem for both OpenMPT and XMPlay would be licensing of various available OPL emulators. Even though e.g. the majority of the MAME project was re-licensed to BSD recently, their OPL emulator is still licensed under the GPL. Some others are LGPL, but there is no OPL emulator with a permissive license as far as I'm aware.

Joseph Collins

  • Posts: 14
Re: XMPlay, S3Ms, and Channel Volume Slide
« Reply #4 on: 22 Feb '18 - 11:35 »
(if you hear any AdLib S3Ms being played in your XMPlay, it's most likely AdPlug taking care of them).
Uhh… huh.  I… forgot that I had AdPlug in my installation of XMPlay.  That would definitely explain why the AdLib versions of the music from Stargunner Zone 66 (not Zone 66, whoops) play correctly, while the Sound Blaster versions – which have both AdLib instruments and recorded samples – only plays the samples.  I hadn't even thought about that.  Thank you!

Quote
One other big problem for both OpenMPT and XMPlay would be licensing of various available OPL emulators. Even though e.g. the majority of the MAME project was re-licensed to BSD recently, their OPL emulator is still licensed under the GPL. Some others are LGPL, but there is no OPL emulator with a permissive license as far as I'm aware.
That's… odd.  There's emulation for a ton of different audio hardware, these days, so… you'd think that there would be a free (or, at least, "free with included TXT file") OPL emulation core, out there.  Well, I would, I mean.  I just dabble in NES/Famicom music, module formats, and MIDI, so…

Anyway, this is some pretty interesting insight and definitely more than I'd expected, after posting this topic.  Thank you, very much!
« Last Edit: 22 Feb '18 - 16:01 by Joseph Collins »

saga

  • Posts: 2242
Re: XMPlay, S3Ms, and Channel Volume Slide
« Reply #5 on: 22 Feb '18 - 12:23 »
Quote
so… you'd think that there would be a free (or, at least, "free with included TXT file") OPL emulation core
The "problem" with the GPL is that it practically enforces the user to publish their software that uses the library under the GPL as well. This makes it practically impossible to use GPL-ed libraries e.g. in closed-source products - which is the whole point of the GPL, of course. Using an OPL emulator that is licensed under the GPL would not be possible with BASS/XMPlay.
The LPGL is more permissive, but it brings similar restrictions if you link LGPL-ed code statically into your own program (think of the emulator being part of xmplay.exe). The only way around that is to link LGPL-ed libraries dynamically (think of an opl.dll next to xmplay.exe), which can have its own sets of problems.
OpenMPT (and in turn, libopenmpt and xmp-openmpt) is licensed under the more permissive BSD license, which allows pretty much any usage that wouldn't be allowed under the GPL. If we were to incorporate a GPL-ed library into OpenMPT, it would effectively enforce it (and much more importantly, libopenmpt and all its users) to be GPL software.

Free software is complicated. :)