Build: 1347
- Fixed initialization bug for tempo 125
- Recalculated the complete Paula period to OPL4 OCT/FNUM lookup table
- Fixed the samplename / effect display
- Command line support drive/directory
- Reimplemented command line parameters /REP:[0/1] and /PAN:[0-7]
The 9xx command is important for Amiga MODs. It can be supported ... sort of, by creating a separate sample/wave header entry for each unique (sample-number, 9xXX) combination found in the MOD, up to 128-31 = 97 such combinations, or more if the MOD doesn't use all 31 samples. When a sample/note with 9xx command is triggered, you play the corresponding special sample instead of the one that starts from offset 0.
Another big problem for playing MODs on the OPL4 is that you cannot completely mute a playing sample without stopping it. Even the quietest possible volume setting is not quiet at all, so what do you do when the MOD changes volume to zero? You either play it completely wrong by not having silence, OR you play it completely wrong by playing the wrong sample data when the volume comes back on again. If you stop the playback, you can have the channel silent, but then the sample playback offset stops advancing, and you can't get it back without restarting the whole sample. It might be possible to approximate the re-opening a silent channel by simulating the playback of the whole MOD before starting OPL4 playback, and on every occurrence of such re-opening, generate a new sample/wave header entry for that particular sample offset. But the 97 free custom sample slots aren't that many when you start doing things like this.
Both of these problems are caused by the fact that you can't change wave attributes without stopping the sound of the entire OPL4! This chip, just like the whole MSX system, is the opposite extreme of design philosophy compared to the C64 or Amiga where the programmer has total control and total responsibility. Poke and change any parameter any time, something interesting might happen, or maybe not.
If you make MoonSound tunes that are originally written for MoonSound, then it at least sounds right.
Yes I know. Thanks for your input.
Another big problem for playing MODs on the OPL4 is that you cannot completely mute a playing sample without stopping it.
Not even if you set the corresponding panpot register to 8? This value should theoretically mute both stereo channels.
Build: 1386
- Channel mute by pressing 1-4 (easymute by Parn)
- Repeat shortcut [R]
- Paula period bug fixed in both slidedown (2xx) and slideup (1xx)
- Fixed a lookup bug in the Paula period table
- Fixed the pattern skip function
- All notes pitch are verified by tuning devices
Build: 1482
- Added check on DOS version
- Colors get restored when leaving the player
- Keyboard buffer is reset when leaving the player
- Added help [F1]
- Fixed mouse pointer issue while loading (non im 2 mode)
- Deoderized my car with Airclean 5G-WL
- Drank some Merlot
Build: 1507
- Fixed issue where the repeat button was not updated when you exit from help
- Implemented command line parameter /CMD8:[0/1] to enable command 8 (channel panning)
I guess it is now "released".
Awesome work, NOP! Thx
You guys already wrote an 8channel MODplayer back in the days. Is this new MOD Player also going to support 8channel MOD?
I did not write the 8 channel mod player. Somebody just modified the code to enable it. The source is available for anyone.
I am personally not interested in 8 channel mods. I have an history on the Amiga which only supported 4 channels and do not know of any good 8 channel mods.
Also 8 channels mods are not XM/S3M mods. The XM/S3M mods have new complicated commands for which I do not have an player in (assembly) code and would require lots of reverse engineering and work. I am not willing to put in that work right now. I could only support the basic commands but that results in bad player experience. And I don't even mention the additional memory requirements in both pattern and sample data (even 16 bits samples).
It would also mean the interface will degrade in framerate, since more channels will also cause more CPU time in both UI and player code. That is one of the reasons nobody does any fancy UI for their players (and I guess they want to look at some static DOS screens some more).
I basically wanted the improve the player code for our upcoming projects. This means fast code, small memory footprint and easy implementation. Since WLCracks wanted the player to work on MSX1 (he got himself a Sony HB75P) to test mods on, I got a little distracted and produced the v2.0 version.