OpenMPT 1.26.06.00 released

The latest version of OpenMPT has been released today.
This is another bugfix update for OpenMPT 1.26, addressing old bugs and improving existing functionality without adding any new features:

  • Pasting partial PC events could result in invalid parameter numbers or values in patterns.
  • "Change plugin parameter" only worked if the selection started in the first channel.
  • When reading ITI / XI instruments as samples, prefer reading the sample at middle-C rather than the first sample in the file.
  • Crossfading did not work if a sample only had a sustain loop, and adding silence at the beginning of the sample did not move the sustain loop points.
  • Allow ITI files saved with Schism Tracker to be loaded.
  • Do not cycle through treeview items when keeping keys pressed while a playable item is focussed.
  • In IT files, MIDI program and bank instrument properties are now written in a way that is also read correctly by other IT-compatible applications.
  • Avoid enabling some ProTracker quirks for MOD files most likely created with ScreamTracker 3.
  • Tremolo effect only had half the intended strength in MOD files.
  • Dragging the mouse over buttons in the Channel Manager now applies the same action to all hovered buttons rather than toggling the action everytime the mouse moves a bit.
  • SF2 region coarse tuning is now imported.
  • Embedded soundfonts in RMI files could not be read in some cases.
  • Several crashes with malformed module files.

For a complete list of changes, have a look at the release notes and the full version history.
libopenmpt has been updated as well with the same module loader fixes.

Comments

Londro Andersen says:

Is the software always going to be this ugly visually? Not that it needs to imitate other trackers or anything... But why not at least give it a facelift, maybe looking, in terms of colors, like a standard DAW, maybe like Reaper, for example?

Saga Musix says:

You just argued that your operating system looks ugly and needs a facelift, not OpenMPT itself. If you think that OpenMPT must look like Reaper, then change the colour scheme of your operating system to look like Reaper.

opla says:

I think what he meant was that one do not need to change ones operative system to look like Reaper just in order for Reaper to look like Reaper.

Maybe someone would LIKE to have a ugly OS, but a pretty Reaper, and also a non-ugly OpenMPT? That would right now be technically impossible wouldnt it?

Saga Musix says:

Yes, that is impossible, and it will stay impossible, because I am not going to pour resources (time) into a skinning engine that would be more useful when spent on more important features, and since I strongly believe that applications should follow the operating system style.

opla says:

By the sound of it I guess that this then is never going to be a poll-kind-of-matter? Even if someone wanted to do the coding, taking the time that is needed? No, everything? Since the code is open, not even if it was a externalized complementary add-on thingy for OpenMPT? Nevermind. It is too easy to complain. I take my hat of for all the absolutely incredible amount of work you have been putting into OpenMPT Sagamusix!

Saga Musix says:

Simply put, nobody wants (or should want) to add skining support to the current code, it would be a lot of wasted development power. Once we change to a new window toolkit, which we have to do to become truly cross-platform, skinning support may arrive automatically since many modern toolkits offer more easy ways of skinning than classic Win32 applications do.

James thrillington says:

what he meant was the looks only. the windows blocky style.