Yes there is, then again there was. Mudlord once assembled a plugin based on the ModPlug sources which includes support for the MT2 format, though he didn't pursue this idea any further and the plugin vanished......so they thought. <- hidden link?

It is inconvenient to use third-party players (modplug a player). I thought if it is possible...

QUOTE (deus-ex @ Jan 14 2013, 03:16)

QUOTE (kode54 @ Jan 14 2013, 08:49)

Isn't there already a replayer for the format?

Yes there is, then again there was. Mudlord once assembled a plugin based on the ModPlug sources which includes support for the MT2 format, though he didn't pursue this idea any further and the plugin vanished......so they thought. <- hidden link?

That doesn't sound like it supports the full feature set of the MT2 format. That sounds like it just supports the feature set which is compatible with an Impulse Tracker 2 player.

QUOTE (LordOfOrder @ Jan 14 2013, 01:09)

Whether there will be an opportunity to return record of tags to the file?

You do know that I wasn't actually modifying the original modules' info fields, but simply appending an APEv2 tag with the changes, right?

Yes, I know. Now I form and I sort a collection of the chiptunes of music, and it was very convenient earlier - wrote down the APEv2 tag, and on other computer, at other person, when playing through foobar2000 tags will be visible, and now at me tags constantly vanish, especially if to reinstall foobar2000, and also already it is impossible to archive a collection and to transfer to other computer - tags are lost: (I liked an old method therefore I ask a tick that it was possible to switch over to old option .

Fixed. Several of the instruments have envelope nodes which have values greater than the limit of 64. I now mimic the behavior of Fast Tracker 2, which is to clamp them to 64, rather than throwing an error.

Fixed. Several of the instruments have envelope nodes which have values greater than the limit of 64. I now mimic the behavior of Fast Tracker 2, which is to clamp them to 64, rather than throwing an error.

Woah, fast fix. However,

QUOTE

Unrecoverable playback error: Not enough storage is available to complete this operation. (0x8007000E)

My component would not be throwing Win32 error codes. Try reconfiguring your output device, or if you're playing the files from a Windows share, try verifying that you can still read the files elsewhere.

I posted a workaround in my playptmod fork, which is unlikely to fix that module, and probably has nothing to do with what that module was doing. It works around another suspicious module, which even acts strangely in the original playptmod, but due to how my version is different, this issue would cause a complete lockup in the mixer loop.

Aha, apparently, it's related to using a high base pitch, and there being no period clamping on the vibrato code. Verified that original Protracker has no clamping on the vibrato either. I'm leaving this workaround in, as muting notes which have the equivalent of INF pitch is better than the player locking up completely.

Also, this issue didn't exist in the original playptmod, because it mixed samples differently, and INF pitch (effective period of 0 or less, which causes it to set the channel rate to 0) would likely only cause it to emit the same sample over and over for that channel, instead of locking up trying to write an infinite number of sinc pulses to the mixer buffer.

Hmm, original author has decided to add clamping, so I'll just duplicate that. Likely fixes it, but workaround stays just in case funny things happen in the future.

EDIT: Okay, the workaround didn't fix a further attempt to make it crash, but the current version fixes it now with clamping.

I posted a workaround in my playptmod fork, which is unlikely to fix that module, and probably has nothing to do with what that module was doing.

Yes, latest release of foo_dumb didn't fix playback for orange.mod (8 chn), so I disabled playptmod as per your suggestion and the issue is gone.

Here's something I found to be disturbing for quite a while but never came around to mention it. I find the playback of .psm modules to be inaccurate regarding the volume in certain cases. This is most noticable at the beginning of below listed modules where the volume of certain channels appear to be too low, almost silent.

Seems to have something to do with the use of surround for channels. Would you suggest I reimplement surround altogether to apply a little phase offset to the phase inversion, or even implement it to output an actual rear channel so users can downmix their modules themselves?

Seems to have something to do with the use of surround for channels. Would you suggest I reimplement surround altogether to apply a little phase offset to the phase inversion, or even implement it to output an actual rear channel so users can downmix their modules themselves?

Tracker modules utilizing surround channel configuration are rather uncommon. At least actually I can't name any making use of it (more so any which does require surround channel playback for accurate recreation). Having said that you understand I hardly can give you a profound suggestion on which of the both options you offer to pursue. I didn't know that .psm modules support and actually make use of a surround channel setup.

They make use of the surround effect, which is commonly implemented in stereo module players by playing the sample exactly centered, but one channel phase inverted. This kills the bass signal fed to a subwoofer if phase inversion isn't accounted for somehow, as the two channels will cancel each other out if they are simply added together.