OpenMPT 1.20 releases

[Saga Musix]

Hi all,
it has been far too long since the last major update of OpenMPT, so I plan to not delay the release of OpenMPT 1.20 any longer. So here's the current test version available for some last tests. If everything goes well, no further changes will be made and this will be the release version of OpenMPT 1.20.

Download: http://openmpt.org/openmpt-1-20-01-00-released
Changelog: http://openmpt.org/release_notes/History.txt

[Rakib]

Crazy big changelog. Thanks and will be tested as soon as possible.

[Saga Musix]

Crazy big changelog.

Not necessarily a good thing - if I still was to implement everything I wanted to have in OpenMPT 1.20, I'd have to delay it even more, but the list of changes is already too damn long. The following releases will have smaller changelogs again.

[Rakib]

I have been testing and compiling new version almost as fast as they, I am currently on version 1.20.00.77 and have not encountered any problems. But I only use mptm-format and with vst's.

[Harbinger]

   WOW! That's alot!!
 
Fortunately, i have some time right now as i've finished a couple of projects, so i can review the build and the changes, and complete the OHM for this version, which i haven't worked on a for quite a few months. This should inspire me to finish the CHM file as well...
 
I'll post questions later if i run into difficulty.
 
Thanks, dev(s)!

[Saga Musix]

FYI, most (if not all) changes in OpenMPT 1.20 have of course been written up in the wiki already, ready to be compiled into a PDF manual.

[Saga Musix]

OpenMPT 1.20.01.00 is now officially available.

[Harbinger]

Notes as i'm wandering:
 
The MIDI Macro help is better than nothing, but somewhere there should be more centralized help on HOW to set these macros up. I saw all the possibilities, but i had no idea what you could do or how to set it up. I could definitely use more knowledge on this subject for the CHM.
 
The tooltips and other changes in the Res and Cutoff sliders in the Instruments page is GENIUS.
 
The draggable mouse across the keys of the Sample Map is also a welcome change, but i would like to see the drag across the black keys separate from the white keys (possibly by separating by halves). It would also help if you had a "Reset" button to cancel out changes but allow the user to keep editing. (I'll make a FR.)
 
I also like the option of selecting a channel by double-clicking a field in the channel. Now to just click and drag to select more columns...
 
I do have a few questions:
 

[Imp]  When trying to paste but no pattern data was found in the system clipboard, previously copied pattern data is now regained from an internal clipboard.

I don't understand. If the clipboard does not have valid pattern data and a paste is attempted into the PE, is Modplug storing a backup clipboard of PREVIOUSLY copied pattern data? That means MPT has 3 clipboards -- the OS clipboard, this backup clipboard, and Modplug's "Quick-Paste" clipboard?
 

[New]  Added "mapped" MIDI channels (like in Impulse Tracker). If a plugin's MIDI Channel is set to "mapped" in the instrument editor, note data is transmitted on a triggered note's pattern channel modulo 16.

Could not find how to set a MIDI channel to "mapped" on the Instrument page or the plugin's GUI window. How do you activate this?

UPDATE: Never mind, i found it. Now my question is, is only MIDI data being transmitted for any instrument set to Mapped (any associated samples are ignored/not played)? I'm guessing that the channel in the pattern editor where the instruiment is called defines which MIDI channel to send; "modulo 16" means the PE channels are divided into groups of 16, so that a MIDI-Mapped instrument whose note is played in PE channel 16 will transmit on MIDI Ch. 16, and for PE channel 17, it's MIDI Ch. 1, and so on? Can you fill us in on how we can best use this feature, and what you initially intended with it? Is it designed mostly for calling external MIDI hardware?
 

[New]  Experimental feature: A Sample Tuner which tunes the sample to a specified note.

If you read my description of the different possible frequencies in the OHM (Reference-Audio Processing:Pitch:Frequency Calculation), i describe (admittedly with some verbal trudgery) of 3 frequency settings of a given sample in ModPlug -- the "apparent" frequency (the actual pitch of the sound when played back at the same speed it was recorded), the "declared" frequency (the value that appears in the sample's header, which doesn't have to do anything with the actual pitch that was recorded), and the "playback" frequency (which is the transposition that takes place according to the note that you're playing the sample at). I'm wondering which frequency the new Sample Tuner is modifying and its relationship to the Freq field in the Samples page. Does the Sample Tuner change the internal 'recorded' frequency (the actual waveform pitch) or is it changing the value that was in the sample header, or some other program variable that is neither?
 

[Imp]  OpenMPT also checks for the new VST DLL entry point ("VSTPluginMain") when loading plugins now, so plugins that only export "VSTPluginMain" and not "main" will now also load (if there are any).

Not sure what this means for the average user. Can you clarify this new capability?...
 

[Mod]  Knob mode is set to linear (instead of circular) mouse actions for VST plugins that support it.

Does this means that round knob elements in plugin GUIs can now be changed with a click-and-drag that moves forward or backward, instead of trying to emulate a knob "turn" while dragging the mouse?
 

[Fix]  When finishing a sustain loop that is behind a normal sample loop, sample playback is not simply stopped anymore.

Not sure what this means. The Sustain loop of a sample or an Instrument? "Behind" a normal sample loop; what do you mean by "behind"? Can you give an example of what triggered the playback to stop?
 

[Fix]  Multiple fine pattern delays on the same row are now added up.

Wait a minute. If you put pattern delay commands on the same row but in different channels, Modplug now ADDs them all together so that you can delay playback more than the number of ticks in a row?!? 
 

[Imp]  Saving: Samples that are not associated to any instrument are now tried to be written to XM files anyway.

This means that normally ModPlug would not normally save a sample that wasn't called in any pattern? You say it "tries;" what does that mean if it fails? The save is not completed, or the XM file has a missing sample slot?
 

[Imp]  PixPlay panning heuristics only apply to modules made with versions of ScreamTracker older than 3.20.

Never heard of PixPlay. Does this have something to do with more recent S3M tracks made in ScreamTracker? Some background and "overknowledge" is necessary to understand what this means for ModPlug users who track, edit, or play in S3M format.
 

[Imp]  UMX Loader: Instead of "scanning" Unreal files for modules, they are actually parsed correctly now. As a nice side effect, it is now also possible to load UAX files (collections of samples) from older Unreal Engine games as modules.

Excellent! As you may or may not know or remember, i got into MPT because i wanted to compose UMX tracks. Now i can unlock the UAX files too?! Incidentally i tried this out, and i couldn't Import any UAX sounds in the Samples page, but UAX files do open in the Folder Tree, and it will show all the sounds in the package. However, the preview playback (double-clicking on the sample icon in the Folder Tree) leaves something to be desired, and the only way i could hear the sounds correctly was to drag it into the sample window and play it back. Perhaps a contextual menu with different playback rates for previewing so you don't have to touch the module...
 

[New]  Template modules can now be loaded and saved through the "File" menu.

Please provide a link on how to set up and use templates, for newcomers and the lazy...

[Mod]  Compatibility export hints are now hideable.

Can't seen to find the option or toggle. Is it an INI setting?
 
Seems like one thing you forgot to mention in the changelog was access to the Help file...
I've been waiting with anticipation to see how you'd implement the Help manual call, and it seems that Modplug looks for the properly named PDF in the root directory of the application. You sure that's the best way?
For those who don't know, stick the latest PDF in the same folder as the Modplug EXE and make sure it's named "OpenMPT manual.pdf" -- just like that (it's apparently hard-coded).
I would also think we should have two Help menu items, one for an offline Help manual, and one for the wiki manual.
 
I also noticed that our skinny little application is now nearly twice as bulky. What did you insert that nearly doubled its size? I'm going to guess this is partly refactoring, partly backward compatibility retention, and partly MIDI enhancements, no?...
 
Most all of these changes will affect the text of the Reference section in the OHM, but not so much the upcoming Windows Help File for MPT.
 
All in all, an excellent set of fixes and new capabilities. Now hopefully with all these bug features, you can invest some serious time in requested features. (Yeah, i know... you just found time to catch your breath and we're already asking for 10 more laps!!  I think we'll understand if you take some time off to pursue other projects.  )

[Saga Musix]

[Imp]  When trying to paste but no pattern data was found in the system clipboard, previously copied pattern data is now regained from an internal clipboard.

I don't understand. If the clipboard does not have valid pattern data and a paste is attempted into the PE, is Modplug storing a backup clipboard of PREVIOUSLY copied pattern data? That means MPT has 3 clipboards -- the OS clipboard, this backup clipboard, and Modplug's "Quick-Paste" clipboard?

Exactly. The backup clipboard is a foreshadowing of an upcoming feature: Multiple patterns clipboards, or a "clipboard history", if you will.
 

[New]  Added "mapped" MIDI channels (like in Impulse Tracker). If a plugin's MIDI Channel is set to "mapped" in the instrument editor, note data is transmitted on a triggered note's pattern channel modulo 16.

[...]Never mind, i found it. Now my question is, is only MIDI data being transmitted for any instrument set to Mapped (any associated samples are ignored/not played)? I'm guessing that the channel in the pattern editor where the instruiment is called defines which MIDI channel to send; "modulo 16" means the PE channels are divided into groups of 16, so that a MIDI-Mapped instrument whose note is played in PE channel 16 will transmit on MIDI Ch. 16, and for PE channel 17, it's MIDI Ch. 1, and so on? Can you fill us in on how we can best use this feature, and what you initially intended with it? Is it designed mostly for calling external MIDI hardware?

To be honest I have no idea what it could be useful for, I just implemented this because it's also there in Impulse Tracker (and thus the IT format). I guess you could use it for controlling a multitimbral plugin using a single mod instrument.
 

[New]  Experimental feature: A Sample Tuner which tunes the sample to a specified note.

Does the Sample Tuner change the internal 'recorded' frequency (the actual waveform pitch) or is it changing the value that was in the sample header, or some other program variable that is neither?

The sample tuner calculates a new C-5 frequency so that the sample sounds like the desired note. It does not apply pitch-shifting or whatever. So if you for example have a sample recorded at 44100 Hz playing a C#, and you tell the sample tuner to make it sound like a D#, it will set the C-5 frequency to 49492 Hz (theoretically; practically autocorrelation is not that exact; it will set the C-5 frequency to something close to that value).

 

[Imp]  OpenMPT also checks for the new VST DLL entry point ("VSTPluginMain") when loading plugins now, so plugins that only export "VSTPluginMain" and not "main" will now also load (if there are any).

Not sure what this means for the average user. Can you clarify this new capability?...

It means nothing. A program (or plugin in this case) needs an "entry point" that the operating system (or the plugin host) uses to start the program / plugin, and by convention this entry point is normally called "main". However, Steinberg decided at one point that the entry point for VST plugins should be called "VSTPluginMain" instead, so they recommend plugin authors to use that entry point instead of "main". However, practically speaking you can of course not simply remove the old entry point because many old hosts still rely on it, so it is a safe bet that all plugins that are still being published have both entry points enabled.
 

[Mod]  Knob mode is set to linear (instead of circular) mouse actions for VST plugins that support it.

Does this means that round knob elements in plugin GUIs can now be changed with a click-and-drag that moves forward or backward, instead of trying to emulate a knob "turn" while dragging the mouse?

Exactly. Keep in mind that many plugins don't support this opcode, though, so they will still use circular movement.
 

[Fix]  When finishing a sustain loop that is behind a normal sample loop, sample playback is not simply stopped anymore.

Not sure what this means. The Sustain loop of a sample or an Instrument? "Behind" a normal sample loop; what do you mean by "behind"? Can you give an example of what triggered the playback to stop?

First off, don't mix instrument loops with sample loops, they don't have anything to do with each other (I think trying to find a link between them has confused you already in the past, so simply see them as two completely different things). Of course I'm talking about sample loops only here. And I literally mean sustain loops that are "behind" sample loops. Imagine a sample with a sustain loop from 10000 to 20000 and a normal loop from 5000 to 8000. In old versions, if a note-off (==) was triggered, the sample was stopped after reaching the end of the sustain loop. Now the sample continues playing in the normal loop (so the sample cursor jumps backwards if you will).
 

[Fix]  Multiple fine pattern delays on the same row are now added up.

Wait a minute. If you put pattern delay commands on the same row but in different channels, Modplug now ADDs them all together so that you can delay playback more than the number of ticks in a row?!? 

Well, that's exactly what was done before. Previously the line was just repeated as often as the last pattern delay command in a row dictated, so if there was a S64 command and right next to it a S62 command, the row was extended by 2 ticks - now it extended by 4 + 2 = 6 ticks.
 

[Imp]  Saving: Samples that are not associated to any instrument are now tried to be written to XM files anyway.

This means that normally ModPlug would not normally save a sample that wasn't called in any pattern? You say it "tries;" what does that mean if it fails? The save is not completed, or the XM file has a missing sample slot?

No, this does not have anything to do with samples being referenced in patterns or not. This fix prevents samples that are linked to an instrument in an XM file, but not found in that instrument's sample map to be lost when re-saving the XM file. For this, OpenMPT tries to associate samples that are not associated with any instrument yet to some instrument. If this fails (because the instrument already has 16 or 32 sample associations), the sample is simply not stored in the file. As said, this is only important for samples that were linked to an instrument but not referenced by its sample map, so if this mechanism fails to associate such samples, the module will not sound different or anything. This mechanism is mostly there to preserve sample texts in existing XM files. See this thread for details.
 

[Imp]  PixPlay panning heuristics only apply to modules made with versions of ScreamTracker older than 3.20.

Never heard of PixPlay. Does this have something to do with more recent S3M tracks made in ScreamTracker? Some background and "overknowledge" is necessary to understand what this means for ModPlug users who track, edit, or play in S3M format.

PixPlay was apparently a rarely used S3M player back in the days. It used commands Z00 to Z0F as panning commands. So OpenMPT looks if a S3M module contains those commands (it won't do anything if higher Zxx commands are found, as then they are clearly not indended to be PixPlay panning commands) and if thinks they are panning commands, it converts them to real panning commands (S80 to S8F) instead. As I know exactly one module which makes use of "PixPlay panning" and this module was composed with an old version of ScreamTracker, I have changed the heuristic to ignore S3M files made with ST3.20 or newer ST3.20 has its own panning commands). For OpenMPT users, this means nothing because OpenMPT does not claim to be ST3.00. So this fix only changed the heuristic to generate less false positives.
 

[Imp]  UMX Loader: Instead of "scanning" Unreal files for modules, they are actually parsed correctly now. As a nice side effect, it is now also possible to load UAX files (collections of samples) from older Unreal Engine games as modules.

Excellent! As you may or may not know or remember, i got into MPT because i wanted to compose UMX tracks. Now i can unlock the UAX files too?! Incidentally i tried this out, and i couldn't Import any UAX sounds in the Samples page, but UAX files do open in the Folder Tree, and it will show all the sounds in the package.

That's why it says that you can load them as modules, not samples. How would you imagine OpenMPT to pick one sample out of hundreds if you load the UAX file into a sample slot?

However, the preview playback (double-clicking on the sample icon in the Folder Tree) leaves something to be desired, and the only way i could hear the sounds correctly was to drag it into the sample window and play it back. Perhaps a contextual menu with different playback rates for previewing so you don't have to touch the module...

You can use the pattern/sample/instrument editor note keys in the treeview to trigger samples, I think that's much better than a context menu...
 

[New]  Template modules can now be loaded and saved through the "File" menu.

Please provide a link on how to set up and use templates, for newcomers and the lazy...

There's not much to say because templates are simply saved modules. They cannot be "set up". You simply save an existing module as a template and then re-use it later.

[Mod]  Compatibility export hints are now hideable.

Can't seen to find the option or toggle. Is it an INI setting?

This is not a hidden setting, it simply adds a "Don't show this message again" checkbox to the compatibility export hint that is shown when trying to compatibility-export a file.
 

I've been waiting with anticipation to see how you'd implement the Help manual call, and it seems that Modplug looks for the properly named PDF in the root directory of the application. You sure that's the best way?

Why should it not be a good way?

For those who don't know, stick the latest PDF in the same folder as the Modplug EXE and make sure it's named "OpenMPT manual.pdf" -- just like that (it's apparently hard-coded).

There is no need to replace the manual or anything - I do not plan to do "in-between" releases of the manual. The latest version will always be included with the appropriate version of OpenMPT.

I would also think we should have two Help menu items, one for an offline Help manual, and one for the wiki manual.

The online help is available through the "Web Resources" menu item, but it might indeed be a good idea to add it as a separate link again.
 

I also noticed that our skinny little application is now nearly twice as bulky. What did you insert that nearly doubled its size? I'm going to guess this is partly refactoring, partly backward compatibility retention, and partly MIDI enhancements, no?...

mptrack.exe OpenMPT 1.19.04.00: 2.38 MB
mptrack.exe OpenMPT 1.20.01.00: 2.72 MB
That's not really twice the size. I guess you mean the installer package, which has indeed been doubled in size - have you already forgotten that OpenMPT now comes with a 2 MB big manual?

[Relabsoluness]

The release looks very good with help manuals and all and I don't think that the whopping 3.53 MB is too big an installer for an application like this

Great work.

[Rakib]

Absolutely,  Jojo has really outdone himself. OpenMPT is really moving fast forward with all these new features.

[Diamond]

Good work and thanks for all the updates.  This is pretty minor so it's probably not worth having it's own thread,but I have F1 mapped to the "General" tab and in the latest version it does not work since it seems to have been hard coded to open the help file.

[Diamond]

Actually, after a bit more testing it seems that the action is performed, but I first receive an error about not being able to find the help file.  I downloaded the ZIP package and did not copy over the help file which explains the error so it seems the problem is more that the check to see if the help file exists is still performed even if the key is assigned to something else.

[Saga Musix]

I will have to check if the F1 key is really hardcoded - If that's the case, it's MFC's fault and I will have to change some stuff. Of course this behaviour is not intended.

Edit: OK, tracked down what caused F1 to trigger the help. This will be fixed in the next release.

[Diamond]

OK, tracked down what caused F1 to trigger the help. This will be fixed in the next release.

Thanks.