OpenMPT 1.26.06.00 released

Posted on 22 October, 2016 - 15:17 by Saga Musix

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?

18 November, 2016 - 13:55

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.

20 November, 2016 - 19:31

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?

5 December, 2016 - 23:27

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.

6 December, 2016 - 00:40

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!

18 December, 2016 - 04:35

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.

18 December, 2016 - 15:53

James thrillington says:

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

28 December, 2016 - 07:58

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.

27 January, 2017 - 19:45

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.

27 January, 2017 - 22:47

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.

10 February, 2017 - 20:53

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.

12 February, 2017 - 13:45

Diamond says:

I am still somewhat concerned about what QT will do for accessibility. While it is possible to make QT applications somewhat accessible, you cannot use the mouse navigation equivalent functions of any screen reader in a QT based interface. This means that it would be impossible to access parts of the interface which are normally not accessible/reachable using only keyboard navigation. I should emphasize that while OpenMPT is currently usable because of the standard Windows UI, it is only considered so by more advanced/determined blind users. And part of what makes it usable at all is the ability to use a screen reader's mouse functionality to access parts of the program which are not reachable using keyboard navigation. I'm not sure that I would be too heartbroken since the current versions of OpenMPT can already do most of what I want, but I might not like missing out on any really cool new features due to lack of accessibility.

20 March, 2017 - 11:22

Saga Musix says:

I don't think there is any reason to be concerned about Qt regarding accessbility. I have tested my own Qt-based applications with Windows' screen reader and it works just like it work for any other Windows application, simply because Qt draws standard Windows controls. Switching to Qt would not get rid of the standard Windows (or other OS) UI, and I know the Qt project also cares about accessibility. In fact, Qt would make it much easier to e.g. add accessbility features to the pattern editor (like reading out cell contents), because Qt would take care of the tedious OS-specific code.

20 March, 2017 - 12:38

manx says:

In any case, switching to QT will neither happen anytime in the near future, nor will it happen over night, nor will it completely remove the current MFC at all in the first place.
The switch will, whenever it will actually be attacked at all, almost certainly be a parallel reimplementation of the GUI in QT, without modifying the existing GUI code at all (or only in order to facilitate code sharing between the 2 GUIs).

20 March, 2017 - 13:40

Diamond says:

Thanks. This is good to know.

20 March, 2017 - 14:12

Diamond says:

I don't know. It might require further testing, but in my experience which is reasonably extensive, no QT based interface has ever been accessible to the mouse functionality of any screen reader. This could theoretically be worked around, but it would definitely require implementing improved keyboard navigation. For example, currently, there is no way using just the keyboard to switch between the lower and upper sections of the "General" tab. Similarly, on the "Sample" and "Instrument" tabs, there is no way to switch between the note input and parameter sections using just the keyboard. These are just the obvious examples which occur to me at the moment, but there may be others. Although there might in fact be some advantages such as reading out cell contents, the mouse navigation issue is a known problem with QT. You can test this for yourself by installing the demo of JAWS
http://www.freedomscientific.com/Downloads/JAWS
and trying to navigate the interface of any QT based application using the JAWS cursor. The JAWS cursor is a feature which simulates mouse functionality. It is activated by pressing NumPad - while NumLock is turned off. In an interface based on the standard Windows UI, you can then use the cursor keys to navigate the entire window. Specifically, parts of the window which would normally only be accessible using the mouse. However, in a QT based interface, this screen reader functionality does not work.

20 March, 2017 - 14:08

Saga Musix says:

Either way, the release notes for OpenMPT 1.26 are the completely wrong place to discuss this. As manx says, when / if this happens, it will still take a while, and related discussion will happen on the forum and/or issue tracker. We do not want to cut off suppport for visually impaired users, but at the same time we do want to improve support for non-Windows users, which becomes more and more important these days, and MFC is simply a large obstacle for this goal.

20 March, 2017 - 16:44