Exx and Fxx portamento commands does not sound like the old MPT

[Saga Musix]

No, I deliberately decided against keeping the old code here because it only makes a difference in some extreme edge cases. Like this one. Which, as I have said now multiple times before, is not even up for discussion because the module was not made with ModPlug Tracker, so ModPlug's inaccuracies have no place in this module in the first place.
End of discussion.

[Jedinhopy]

OpenMPT is louder than modplugtracker.

[Saga Musix]

Yes, because you chose a different sample pre-amp volume in the mixer settings than you did in MPT 1.16. The joy of old ModPlug Tracker legacy settings.

[Jedinhopy]

My (The new MPT song.it) has portamento effects that sounds different in OpenMPT 1.24.04.00 than ModPlug Tracker version 1.16.0203.

[Saga Musix]

I said End of discussion.
It's still an SPC to IT conversion at the core, no matter if you resaved it in MPT or not.

[Jedinhopy]

I said End of discussion.
It's still an SPC to IT conversion at the core, no matter if you resaved it in MPT or not.

So now i can't copy and paste super mario world instruments properly the way i want thanks to you because i can't start creating a new modplug tracker song because it will not retain it's portamento characteristics between Modplug Tracker version 1.16.0203 and OpenMPT 1.24.04.00.

And since the super mario world instruments relies heavily on pattern data at a tempo of 250 with speed 1. The vibrato portmanto pitchbend effects is only available in the pattern rows so OpenMPT does not play them like the classic modplug tracker program.

Combining both old modplug tracker portamento behaviors with that portamento interpretations of OpenMPT.

THANK YOU for not implementing old modplug tracker portamento behaviours. :angry-smile: :sad-smile: :disappointed-smile:



Failed discussion.

[manx]

Let me restate the whole debate from a somewhat different angle and hopefully clear up some misunderstandings.

Let me list some of the facts first:

• OpenSPC is really old software. The version i spotted from a quick search is from about 1999. There are some newer variants around also. I cannot judge their relevance though.
• OpenSPC can generate IT files.
• In 1999, there was exactly 1 authorative source on how to correctly play IT files, namely the way Impulse Tracker itself actually played them.
• For plain IT files in general (unless made with one of the other major IT ttrackers available nowadays), Impulse Tracker is still the only valid reference playback engine.
• MPT 1.16 played things differently and inaccurately, in certain corner cases.
• These corner cases are not excercised by IT files made with MPT 1.16 in any significant number of files available in the wild to warrant keeping playback compatibility.
• OpenMPT has since been fixed to correctly mimic Impulse Trackers behaviour, because the previous behaviour of OpenMPT had acutally been a bug which had just existed for way too long time.

So, iff OpenSPC actually relied on the way MPT 1.16 played back portamento in IT files (I'm not sure whether it does or whether it in fact assumes Impulse Tracker behaviour), this would have been a bug in OpenSPC from the start.

Thus, if you really want to get this working again for you, I suggest finding someone who maintains or wants to maintain OpenSPC and actually fix their assumptions on how portamento works in IT files.

Some further remarks:

OpenMPT in fact does mimic a lot of strange playback bugs and other problems to be compatible with the playback engines of the older trackers, at least the significant ones. However, as far as I understand, any SPC to IT conversion would be greatly lossy with regards to pitch precision and other problems anyway, thus, there is really little use in trying to mimic the exact portamento behaviour that had been possibly be assumed by OpenSPC.

The only relevant point with regards to how OpenMPT plays back any specific IT file generated with OpenSPC is, how great old Impulse Tracker actually plays it.

If we would keep all assumptions valid that any old conversion software could have possibly been making on how to play back IT files, this would completely prohibit any playback related bug fixing and progress in OpenMPT. Keeping all kinds of different playback modes around would increase the maintanance burden. Handling all the formats OpenMPT and libopenmpt actually can handle is already really complicated even without even more compatibility modes. Whether some specific feature/bug warrants a compatibility mode is always a tradeoff between the amount of code required and how widespread the specific feature/bug is actually used in the wild. It's just not feasable in each and every case.
As already noted by Saga Musix, a compatibilty mode for OpenSPC is out of question anyway as OpenSPC should actually have assumed Impulse Tracker behaviour in the first place and would then be handled just fine with OpenMPT's default Impulse Tracker style playback mode.

I'm sorry that this change causes trouble for you, but, as outlined, the problem does not lie in the change in OpenMPT itself, but possibly in the assumptions some ancient software made.

[Jedinhopy]

OpenMPT has since been fixed to correctly mimic Impulse Trackers behaviour, because the previous behaviour of OpenMPT had acutally been a bug which had just existed for way too long time.

Which version of OpenMPT lost old modplug tracker portamento behavior?

[Saga Musix]

1.24 was the first with the correct behaviour, but you will do yourself and everyone else a favor if you don't cling to the old behaviour. The problem here is that extra-fine slides up and down (EEx / FEx commands) are not symmetric (i.e. EEF followed by FEF will not go back precisely to the original note), however the asymmetry is the wrong way around in the old MPT. Since OpenSPC most likely didn't even consider this inaccuracy, notes in OpenSPC conversions will typically diverge after a lot of portamento effects, and in MPT 1.16 they will diverge into the opposite direction than in OpenMPT or any other player.

So now i can't copy and paste super mario world instruments properly

Err, portamento has nothing to do with instruments? You can copy the samples just like before and use them in your own songs and remixes. The patterns output by OpenSPC are not really suitable for anything but listening to a (bad) SPC conversion anyway, no sane human being would try make a remix based on those patterns and write music at such insane tempos (except for Venetian Snares I guess). If you want to make your own remixes of this song, you can easily do it at a lower tempo and by using actual vibrato (Hxx) commands instead of OpenSPC's insanely fast Exx/Fxx effect combinations. I still don't see your problem.

[Jedinhopy]

So now i can't copy and paste super mario world instruments properly

Err, portamento has nothing to do with instruments? You can copy the samples just like before and use them in your own songs and remixes. The patterns output by OpenSPC are not really suitable for anything but listening to a (bad) SPC conversion anyway, no sane human being would try make a remix based on those patterns and write music at such insane tempos (except for Venetian Snares I guess). If you want to make your own remixes of this song, you can easily do it at a lower tempo and by using actual vibrato (Hxx) commands instead of OpenSPC's insanely fast Exx/Fxx effect combinations. I still don't see your problem.

I mean that one single waveform sample is using multiple envelopes in a multiple channels at the same time to create ADSR effects on volumes and pitches and panning + using these instrument articulation effects:
1. Tremolos.
2. Fade ins.
3. Fade outs.
4. Pannings.
5. Pitchbends.
6. Vibratos.
7. Glidings.
8. Delays / Echoes.
9. Chorus.

None of these can be converted into a .XI file because some of them use more than one channel to create chorus effects and so on like delay effects that require 2 channels or more.

[Saga Musix]

None of them depend on the insane pattern speed used by OpenSPC and can easily be replicated at lower speeds. And certainly none of them depend on MPT's buggy portamento interpretation. You do not require this bug to be emulated for writing remixes. Unless you copy the original pattern data and are too lazy to fix the detuned parts (which, as already pointed out in my first post, is detuned compared to the original in both playback modes anyway), in which case it can hardly be called a remix.
Anyway, I am tired of reiterating the same facts again and again. Case closed.

[Saga Musix]

You can be happy, as OpenMPT is in need of more fine-grained legacy playback settings, OpenMPT 1.26 will most likely be able to use the "old" portamento code independently of all other IT compatbility settings.