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.

j7n says:

I think standard Windows UI looks good, has high performance, and responds consistently across application, for example, when I push a button but not release the mouse on it (I changed my mind), the command doesn't get run, or when I drag the mouse across a set of cascading menus, there is a short delay before the child menu disappears, so it is possible to move the mouse in a diagonal fashion straight onto the desired option on the child menu. I noticed that I can't do that in many QT programs (which are also on the larger side with the whole GUI stuff duplicated for every program).

Windows 10 does of course look ugly and is often difficult to read, but that is a problem with the OS, and the trending Flat Design™. No such problem exists in Windows versions older than that.

REAPER actually is very much Windows based, apart from the main window where the tracks and mixer are. I like this very much. The Preferences, the batch converter, and the properties of an audio item to me look like normal Windows dialogs with some custom controls embedded (faders). Also the sheer amount of cascading menus that REAPER has would be hard to navigate if they used a custom framework.

Saga Musix says:

Note that a native look&feel is the default with Qt, and you can get it wrong with Qt (things behaving differently than you are used to) just like you can get it wrong with MFC or pure WinAPI.

j7n says:

VideoLAN, SMPlayer and MkvMerge don't look native. These applications use thick 3D and boldface where Windows would have Office 97 look instead; the controls are also spread out and use a lot of screen real estate. I guess the authors of Qt never got to polishing their Windows classic GUI emulation because it was out of common use already. The new MkvMerge now looks like a cross between Windows 3.11 and Vista, and takes ages to open. The old WxWidgets builds however were completely native. I couldn't find any visual flaw in them. Reaper also looks great with the 2.x theme. Its windows have high information density.

Saga Musix says:

"VideoLAN, SMPlayer and MkvMerge don't look native."

You are taking three examples and conclude from that how all Qt applications look like, without ever having dealt with Qt yourself apparently. It is perfectly possible to write native-looking Qt apps if you just let Qt do its job.