OpenMPT development build 1.17.02.49 is available for testing from
modplug.svn.sourceforge.net/viewvc/*checkout*/modplug/trunk/OpenMPT/mptrack/bin/mptrack.exe?revision=194
Note that for the time being this isn't available in sourceforge download page and the update check doesn't 'know' about this build(and thus won't inform of it). Changes in this build:
[New] Windows keys can be used as modifiers in the keyboard configuration(disables Windows start menu pop-up if used in the active keyboard configuration)."
[New] Name filter in plugin selection dialog.
[Imp] (http://forum.openmpt.org/index.php?topic=1972.0) Improved preset navigation in VST window.
[Imp] Improvements in IT compatible play.
[Imp] Improvements in user defined tuning modes.
[Fix] (http://forum.openmpt.org/index.php?topic=1813.0) Fixed possible unnotified file overwriting when saving unsaved file.
[Fix] (http://forum.openmpt.org/index.php?topic=1723.0) Fixed wrong version number in IT files saved with compatibility save.
[Fix] (http://forum.openmpt.org/index.php?topic=1996.0) Fixed broken note preview for certain type of instruments in instrument tab.
[Fix] (http://forum.openmpt.org/index.php?topic=2005.0) Fixed possible crash when exporting wav in channel mode with long channel name.
[Fix] (http://forum.openmpt.org/index.php?topic=2014.0) Fixed channel position jump when clicking VST box in channel header.
[Fix] (http://forum.openmpt.org/index.php?topic=1799.0) Fixed possible searching of wrong parameter in pattern search
[Misc] Update check disabled and miscellaneous other changes.
Some things that have to be improved in this build:
This msgbox appears twice when i try to start the build:
(http://sagagames.de/ithumb/show/tuning8230ow94.png)
It does not occur if i rename the tuning folder.
The VST window is too small if the VST has no GUI:
(http://sagagames.de/ithumb/show/effectswindow8159cv73.png)
Good to see that things are moving forward. Very positive. I have not encountererd Jojo's problem, but I've only started it so far and have not tested it much.
2 Jojo
The messagebox is due to unrecognised tuning files. You can for example copy the tuning folder from release package of .48, or if don't use the tuning things, simply renaming/deleting the tuning folder might fix it without any additional problems.
The second problems seems to be direct consequence of the 'vst preset navigation improvement'-thing; to be fixed.
I can't recall changing any tuning settings (i don't use them), so they should be the original .48 ones... I'll try downloading the old files.
Quote from: "Jojo"
The VST window is too small if the VST has no GUI:
(http://sagagames.de/ithumb/show/effectswindow8159cv73.png)
it also happens with VSt that have GUI.
Besides I experienced several VSTi crashes with some specific functions, ompt closes itself without a message... see ya in the bug report sections!
But I'm glad the development is still active, thanks you guys! the filter in vst load menu is rather interesting...
Quote from: "Jojo"I can't recall changing any tuning settings (i don't use them), so they should be the original .48 ones... I'll try downloading the old files.
Can you confirm this? I've tested this with more than one machine with .48 files and it has worked fine. My guess would be that the files are from the 'RC3'-build.
Quote from: "le_parasite"Quote from: "Jojo"
The VST window is too small if the VST has no GUI:
it also happens with VSt that have GUI.
I looked all VSTs I have, and couldn't notice one VST with GUI in which the window was too small.
Quote from: "le_parasite"Besides I experienced several VSTi crashes with some specific functions, ompt closes itself without a message... see ya in the bug report sections!
'Specific functions'? Does the crashes crashes occur only in this build?
Anyway, thanks for the reports - pity there's is so much to report about.
Confirmed.
ModPlug is now able to start again with the original .48 files. ;)
testing it for the first time just now and it seems like performance has been improved.
looks and sounds nice so far :)
Quote from: "BooT-SectoR-ViruZ"testing it for the first time just now and it seems like performance has been improved.
Interesting. Is there some specific aspect where the performance seems improved?
For eager testers, there is new build(1.17.02.50) available in SVN repository. List of changes is below. The long list doesn't mean massive new features, I'm just being detailed here :)
NOTE: A major bug has been found in .50 (bug report (http://forum.openmpt.org/index.php?topic=2154.0)).
[New] Ability to control plug params with MIDI controllers
-Very basic model with limited and annoying GUI and usability.
-For the time being, only for 'live'-controlling; no ability to insert pattern commands with it.
-No pitch bender mapping
[New] Ability to pass MIDI to plugin.
-Enable from setup->midi
[Imp] Ability to take MIDI volume into account when playing notes with MIDI keyboard.
-Enabled from setup->midi
[New] Ability to start/continue/stop play with certain MIDI messages (0xFA, 0xFB, 0xFC)
-Untested. If you can test this, results would be appreciated.
-If this works, it should work only in pattern tab.
[Fix/Imp] (http://forum.openmpt.org/index.php?topic=1973.0) Fix for volume command behavior for plugins; in addition now there are options how to interpret it.
-Note: By default, the old buggy behavior is emulated for existing files - emulation can be disable from song properties.
-In effect: VST volume control may now be possible simply with the familiar volume commands without any macros.
Note, though, a significant difference in volume handling: plug volume is plug specific, not channel specific. So for example in
|C-501......|D-501......
|.....v64...|...........
|.....v32...|...........
|.....v00...|...........
If instrument 01 has VSTi plug, the volume fade affects the VSTi volume thus affecting both channels, while when using ordinary samples, only the note in the first channel fades out.
[Imp] Keyshortcut for preset navigation jumps in VST editor.
[Mod] .bak files won't be shown anymore in load dialog with 'All modules' filter.
[Mod] MPTm files saved with this version should open as IT-files in previous versions
[Fix/Mod] (http://forum.openmpt.org/index.php?topic=2074.0) Instrument random variation fix/behavior change.
-Note: By default, old behavior is used for existing files. New behavior can be enabled from song properties.
[Fix] (http://forum.openmpt.org/index.php?topic=1747.0) Fix for pattern duplicate for small patterns
[Fix] (http://forum.openmpt.org/index.php?topic=2033.0) Fix for ini-settings related crash.
[Fix] (http://forum.openmpt.org/index.php?topic=2044.0) Show row playtime didn't on certain cases work on first pattern row.
[Fix] (http://forum.openmpt.org/index.php?topic=2080.0) Fix for faulty play on "noteless notes" in IT compatible playmode
[Fix] (http://forum.openmpt.org/index.php?topic=2073.0) Pattern number box didn't open pattern properties when using MPTm.
[Fix] Fixed wrong MIDI CC names in macro editor.
[Fix] Possible crash when loading/saving MPTm with more than 64 channels.
And various other changes/fixes. Please note that this is a development build not thoroughly tested.
The exe-hashes
MD5 : 0fa4239eaf13893dc45b8ebdf6bff221 mptrack.exe
SHA-1: 141d3df60be235d453e37c7082575d3c0f95d714 mptrack.exe
Where can I download the new build?
I don't know how to accesse the SVN Repository. :)
Quote from: "LPChip"Where can I download the new build?
See first post. Replace 194 with 198 in the link.
http://modplug.svn.sourceforge.net/viewvc/modplug/trunk/OpenMPT/mptrack/bin/
voilà! :D going to test it now!
Got it.
I don't use VST or MIDI, so I can't be a help of any testing there, so I concentrated first on playback.
I think BSV got a point. It's vague of course, but I got the impression, that somehow the sound-quality
has improved. In the fields of dynamics and clarity. More 'body' one could say.
I only have one beta running, so can't compare with the previous ones. But I can with the regular RC2 one,
and the ole MPPlayer.
I did this testing with a track of Louigi Verona : "At ModPlug Central", an IT file to be found at
http://forum.openmpt.org/index.php?topic=911.0
Maybe it's a good idea for a beta-testing, that, next to specific personal issues and use,
there are some 'standard' files, in consensus, to be used in some areas of the performance testing process.
I vote for this one.
I don't have time to download it right now... (gotta go fix my Fedora 8 installation! :)), but just to clarify this point:
Quote[Fix/Imp] Fix for volume command behavior for plugins; in addition now there are options how to interpret it.
-Note: By default, the old buggy behavior is emulated for existing files - emulation can be disable from song properties.
-In effect: VST volume control may now be possible simply with the familiar volume commands without any macros.
Note, though, a significant difference in volume handling: plug volume is plug specific, not channel specific. So for example in
|C-501......|D-501......
|.....v64...|...........
|.....v32...|...........
|.....v00...|...........
If instrument 01 has VSTi plug, the volume fade affects the VSTi volume thus affecting both channels, while when using ordinary samples, only the note in the first channel fades out.
If a plug
does interpret volume messages correctly, will this be overridden? That is, can you enable MIDI/MPT volume controlling per plugin, or is it only per song? 'Cos I use a mixture of plugs, some of which
do handle it correctly (like Kontakt), and some of which don't (like FabFilterOne).
Thanks!
I honestly didn't hear any difference, but ...
Quote[Fix] Fix for ini-settings related crash.
maybe this changed your bass boost, reverb or whatever settings? :)
Quote from: "bvanoudtshoorn"If a plug does interpret volume messages correctly, will this be overridden?
Volume commands used with note have worked correctly and that behavior should have remained the same; problem has been in volume commands without note.
Quote from: "bvanoudtshoorn"
That is, can you enable MIDI/MPT volume controlling per plugin, or is it only per song?
Per plugin.
edit: Corrected per instrument to per plugin
Quote from: "Relabsoluness"Quote from: "bvanoudtshoorn"If a plug does interpret volume messages correctly, will this be overridden?
Volume commands used with note have worked correctly and that behavior should have remained the same; problem has been in volume commands without note.
Quote from: "bvanoudtshoorn"
That is, can you enable MIDI/MPT volume controlling per plugin, or is it only per song?
Per instrument.
OK... So that now means that volume messages will be sent to the plug even when there's no note? Awesome!
Quote from: "bvanoudtshoorn"OK... So that now means that volume messages will be sent to the plug even when there's no note? Awesome!
Note, though, the difference in the volume command when used with note and without note. When used with note, it only sends velocity message, which doesn't affect the 'volume'-parameter. I see this somewhat analogous to electric piano with a volume slider: volume corresponds to the setting in the volume slider and velocity to the force used to press to key. One can't make the actual 'audible volume' higher just by using more force. So in practice with the default settings with VSTi
|C-501v64...
|.....v32...
|.....v00...
|C-501v64...
note on 4th row will not make any sound because on row 3 volume(actually dry/wet ratio) is set to zero, and the v64 on row 4 only sets max velocity, not volume. Also the v32 on second row doesn't necessarily make 'audible volume' weaker - depends on the volume setting with which first note is played with. I admit this is confusing behavior, and I think this needs improvement.
Isn't it better to not set the velocity at all, but instead use the dry/wet slider?
Quote from: "LPChip"Isn't it better to not set the velocity at all, but instead use the dry/wet slider?
If it's better, you can use this behavior by setting "note velocity" to "process as volume" and "Volume command effect" to "Dry/wet ratio". But there's a reason why this is not the default: the problem is that dry/wet is set for the whole plugin. So for example when using this behavior, in
|C-501v64...|...........
|...........|...........
|...........|D-501v32...
D-5 01 v32 sets the dry/wet slider of the whole plugin to half thus affecting the audible volume also for the note C-5.
OK, I've got it now. Here are my thoughts.
[Imp] Ability to take MIDI volume into account when playing notes.
I didn't see the options in the instruments first time round. :) Now I see how it works. Good stuff for buggy plugs which don't handle volume properly.
Request: Can you change the default from Dry/Wet to MIDI, or give the option to? The plugs I use most already work properly, so I'll be using MIDI a lot more. :)
[Mod] .bak files won't be shown anymore in load dialog with 'All modules' filter.
Wonderful. :D
[Fix] Pattern number box didn't open pattern properties when using MPTm.
I might start using MPTm again, now.
[Fix] Fixed wrong MIDI CC names in macro editor.
Very nice. Now everything makes sense. :)
All in all, thanks for the work guys. Just that one little request... :D
Quote from: "Relabsoluness"Quote from: "BooT-SectoR-ViruZ"testing it for the first time just now and it seems like performance has been improved.
Interesting. Is there some specific aspect where the performance seems improved?
well mainly that theory was based on my impression that playback went more smoothly. no lag to be seen in pattern editor and stuff. also i believe to hear a better mixing-quality as sam said before.
Quote from: "Relabsoluness"
[New] Ability to control plug params with MIDI controllers
-Very basic model with limited and annoying GUI and usability.
-For the time being, only for 'live'-controlling; no ability to insert pattern commands with it.
-No pitch bender mapping
[...]
[Fix/Imp] (http://forum.openmpt.org/index.php?topic=1973.0) Fix for volume command behavior for plugins; in addition now there are options how to interpret it.
-Note: By default, the old buggy behavior is emulated for existing files - emulation can be disable from song properties.
-In effect: VST volume control may now be possible simply with the familiar volume commands without any macros.
Note, though, a significant difference in volume handling: plug volume is plug specific, not channel specific. So for example in
|C-501......|D-501......
|.....v64...|...........
|.....v32...|...........
|.....v00...|...........
If instrument 01 has VSTi plug, the volume fade affects the VSTi volume thus affecting both channels, while when using ordinary samples, only the note in the first channel fades out.
looking forward to .50 testing!!!! :D
Progressing nicely guys,some really good improvements. :)
But i wonder,is someone still planning on adding more midi macro's?
I wonder what kind of midi macros you would need inside OpenMPT except those that send messages to plugins and the filters?
Quote from: "bvanoudtshoorn"[Imp] Ability to take MIDI volume into account when playing notes.
The description was quite vague so it was changed to "Ability to take MIDI volume into account when playing notes with MIDI keyboard."
Quote from: "bvanoudtshoorn"Request: Can you change the default from Dry/Wet to MIDI, or give the option to? The plugs I use most already work properly, so I'll be using MIDI a lot more. :)
Yes, it might be useful to be able to define the default. But the default propably won't be changed to MIDI simply because not all plugs respond to MIDI volume message, but dry/wet works for all.
Quote from: "Jojo"I wonder what kind of midi macros you would need inside OpenMPT except those that send messages to plugins and the filters?
I was talking about the amount of macro's you can use.
Right now we can only use 16 macro's and when automating synths and effects 16 just isn't that much.
So a while back i made a request to increase the amount and now wondered if someone is still working on it.
ah yeah, i remember, i second that :) although i hardly need macros...
Quote from: "seventhson"But i wonder,is someone still planning on adding more midi macro's?
In a way I hope not; I would rather see better plug parameter control altogether.
Quote from: "Jojo"maybe this changed your bass boost, reverb or whatever settings?
If I perform a test, I do it 'flat', so no bass boost, etc. or EQ active.
Quote from: "Relabsoluness"Quote from: "bvanoudtshoorn"Request: Can you change the default from Dry/Wet to MIDI, or give the option to? The plugs I use most already work properly, so I'll be using MIDI a lot more. :)
Yes, it might be useful to be able to define the default. But the default propably won't be changed to MIDI simply because not all plugs respond to MIDI volume message, but dry/wet works for all.
Yeah... The problem with dry/wet is that it affects the
whole volume of the instrument, not just that note... :) But being able to change the default would be fine with me, as long as it was a tracker-setting, not a song-setting. :)
Quote from: "Sam_Zen"If I perform a test, I do it 'flat', so no bass boost, etc. or EQ active.
well i just indicated that those settings could have been changed for whatever reason... :)
Quote from: "bvanoudtshoorn"Yeah... The problem with dry/wet is that it affects the whole volume of the instrument, not just that note... :)
The same problem is with "MIDI volume"-setting. But when "Note velocity" is set to "Use channelvolume"(default), Dry/wet ratio or MIDI volume is not set when volume command is used with note. So the dry/wet setting and MIDI volume setting are similar in this sense: both affect the whole plugin.
Quote from: "Relabsoluness"Quote from: "seventhson"But i wonder,is someone still planning on adding more midi macro's?
In a way I hope not; I would rather see better plug parameter control altogether.
I agree. Direct control of VST parameters from the pattern view is something we've been waiting a long time for. Better to improve this than simply adding more MIDI macros.
Quote from: "Diamond"Quote from: "Relabsoluness"Quote from: "seventhson"But i wonder,is someone still planning on adding more midi macro's?
In a way I hope not; I would rather see better plug parameter control altogether.
I agree. Direct control of VST parameters from the pattern view is something we've been waiting a long time for. Better to improve this than simply adding more MIDI macros.
Direct control would be better i guess,however i don't really mind how automation works right now.
Somehow i think that adding more macro's would be alot easier to implement (and would also be a nice short term solution) then to implement a whole new system for automation which will probably take a lot of time to develop,test and implement,not to mention that there is no real concensus on how this new automation system should look and function.
Quote from: "seventhson"Somehow i think that adding more macro's would be alot easier to implement (and would also be a nice short term solution) then to implement a whole new system for automation which will probably take a lot of time to develop,test and implement,not to mention that there is no real concensus on how this new automation system should look and function.
Some discussion about the automation matters(*) can be found found from "More midi macros" (http://forum.openmpt.org/index.php?topic=1757.0)-request. Personally I find the way outlined by Pelya quite nice(introducing special "notes" for controlling parameters), and it doesn't seem particularly hard to implement either (although that's just an (un)educated guess).
(*) In this context, does "automation" really mean simply "controlling VST params from pattern"?
I know i started that thread (although it is quite old now) :lol:
I'd still like it to resemble the way it is working now,we have quite a bit of control over automating vst parameters with using Z00 to Z7f or with the /00 to /7f.
About the (*),what else is there to automate ?
Quote from: "seventhson"About the (*),what else is there to automate ?
I just wanted to confirm it because for me automation gave an impression of something else than simply controlling params from pattern. But indeed it can be seen as sort of automation.
Quote from: "Sam_Zen"Got it.
Yep, Daisy likes to say that when it is her turn! As for a couple of updates, that is interesting because I do not recall Modplug Tracker asking me to update when I opened it like it used to, so I did not know anything about them until I saw the topic about new builds (or whatever it is called)!
Quote from: "Relabsoluness"I just wanted to confirm it because for me automation gave an impression of something else than simply controlling params from pattern. But indeed it can be seen as sort of automation.
My definition also involves recording parameter changes from plugin and using LFO's to control plugin parameters.
Quote from: "Relabsoluness"Quote from: "seventhson"About the (*),what else is there to automate ?
I just wanted to confirm it because for me automation gave an impression of something else than simply controlling params from pattern. But indeed it can be seen as sort of automation.
Yeah i understand. :)
I'm so used to the whole vst thing that i just wasn't able to come up with anything else that would fit the automation description except maybe stuff like volume or panning which we allready have commands for,which is why it's good to have other people thinking about this stuff too.
midi-mapping seems to work awesomely good, but i just seem to have found a bug:
when i assign the modwheel of my keyboard to some vst (channel doesn't matter) it will also affect other plugins' parameters if those are assigned to other midi-controllers....
i tested this aswell when BSV told me about it and i have to second this report, the mod wheel seems to pass the values to all plugs while other knobs don't...
EDIT: Modwheel affects assigned params even without being assigned itself
edit: made a bug report
A major bug has been found in .50 (see the bug report (http://forum.openmpt.org/index.php?topic=2154.0) for details) which can cause data loss.
I must admit that I've switched back to 0.49, following the 0.50 release. There are a couple of reasons for this. The first (and most important) is that the "fixed" VST volume handling has seriously borked my plugins which already handled the volume correctly. Volume commands aren't sent reliably, regardless of what settings I choose in the instrument. It's possible to get it to work by editing the song settings every time, but that's just a pain. Also, there's that major bug to do with all the song properties, which is very annoying.
Is it possible to achieve the "normal" plugin volume handling (per channel, *not* per instrument) in 0.50?
Quote from: "bvanoudtshoorn"Is it possible to achieve the "normal" plugin volume handling (per channel, *not* per instrument) in 0.50?
I think, its safe to say that this is nearly impossible, because its always possible to have one effect on several channels, and setting the volume on one will make it affective on all the channels. Do note that if you talk about the channel volume itself, that the VST effects are being called AFTER the channel volume.
Basically it goes like this:
Sample/instrument -> Channel -> Channel settings -> plugin -> master
That means if you use a VSTi, it will skip channel, and channel settings. Well skip, the sound isn't being altered because there's no sound at that stage to alter.
Sorry - I meant MIDI channel. :D
But thanks LP - that explains it a bit better for me.
My problem, though, is that I use multi-channel plugs, which are velocity-sensitive. So with the "standard" settings, I both lose the velocity sensitivity (a note played piano is just a quieter version of a forte note, *not* a different sound), and what I get is blanketed across. So I can't, for example, have two notes (in the same plug, let alone the same midi channel), playing at different velocities.
So basically, I want the old behaviour, where each note is sent with an accompanying velocity message to the plug, without *any* volume handling whatsoever on MPT's part. Just a straight pass-through.
Hope that explains it a bit better. :P
Quote from: "bvanoudtshoorn"So basically, I want the old behaviour, where each note is sent with an accompanying velocity message to the plug, without *any* volume handling whatsoever on MPT's part. Just a straight pass-through.
Could you provide a test case where the new behavior fails: in all tests I've tried the old velocity behavior seems working. For example playing notes with different velocity with the same plugin works fine. If there is something buggy with this (too), it would be good to have it fixed in the next test build, which is to be a bug fix build.
A new test build(1.17.02.51) is available in SVN. Mostly bug fixes.
NOTE: Use with care.
Long, detailed list of changes again - some important ones are bolded:
VST related:
------------
[Fix] Fix to crash when loading Olga-VST(and some other plugs as well?).
[Fix] Miscellaneous memory handling fixes. Although it's not likely, checking whether the Kontakt2 related bugs (Bug726 (http://forum.openmpt.org/index.php?topic=726.0)) and (Bug1786 (http://forum.openmpt.org/index.php?topic=1786.0)) are solved would be appreciated.
[Mod] (http://forum.openmpt.org/index.php?topic=1367.0) When loading plug information at startup, checking whether files of cached plugs exists, and inform if not.
MIDI related:
-------------
[Fix] (http://forum.openmpt.org/index.php?topic=2153.0) Fix to MIDI mapping not checking MIDI event, which could cause events like pitch bend to trigger some mapping item.
[Fix] (http://forum.openmpt.org/index.php?topic=2024.0) Fix to wrong notes on MIDI drum export.
[Fix] Possible crash when exporting module with more than 64 channels to MIDI.
[Fix] (http://forum.openmpt.org/index.php?topic=2017.0) Muted channels should now be excluded in MIDI export.
Changes in 'IT-style' playflag:
--------------------------
[Fix] (http://forum.openmpt.org/index.php?topic=1869.0) Tentative fix for envelope resetting on new instrument.
[Fix] (http://forum.openmpt.org/index.php?topic=788.0) Tentative fix for bidi loop resetting.
[Fix] (http://forum.openmpt.org/index.php?topic=2080.0) Tentative fix for plain instrument triggering note after note cut.
GUI/usability:
--------------
[New] Unmute all(on transition) shortcutkeys should now work in orderlist context
[New] Half/double pattern rownumber buttons to pattern properties dialog.
[New] Channel status in status bar now show channel volume info.
[Mod] (http://forum.openmpt.org/index.php?topic=2124.0) Modified flag is not set when sliding tempo/global volume slider for MOD file.
[Mod] (http://forum.openmpt.org/index.php?topic=913.0) When setting instrument pan, checking whether instrument samples have set pan enabled and optionally disabling them.
[Mod] Disabled Set Pan in sample tab for XM
[Mod] (http://forum.openmpt.org/index.php?topic=1958.0) Show prev/next pattern now shows pattern over +++ orderlist items
[Mod] Disabled setting channel pan for MOD/XM in general view.
[Fix] (http://forum.openmpt.org/index.php?topic=1938.0) Paste for pattern effectdata was broken for MOD. Broken probably since .46
[Fix] Fix to severe memory leak in tree view occuring when browsing module samples/instruments.
[Fix] Fix to mptm-files not showing in tree view file browser.
[Fix] (http://forum.openmpt.org/index.php?topic=2222.0) Fix to possible crash when browsing modules in treeview.
[Fix] (http://forum.openmpt.org/index.php?topic=1998.0) Non existent channels existed in channel control in general tab.
[Fix] (http://forum.openmpt.org/index.php?topic=1614.0) Fix for faulty tabs when switching between modtypes with and without instrumenttab.
[Fix] (http://forum.openmpt.org/index.php?topic=2176.0) Mixmode-tooltip in general tab was shown with unrelated controls
[Fix] (http://forum.openmpt.org/index.php?topic=1960.0), [Fix] (http://forum.openmpt.org/index.php?topic=1959.0) Continuous pattern navigation fixes.
[Fix] (http://forum.openmpt.org/index.php?topic=1887.0) Keyboard split related fix.
[Fix] (http://forum.openmpt.org/index.php?topic=1324.0) Pixel garbage bug might now appear less frequently.
Misc:
-----
[Fix] (http://forum.openmpt.org/index.php?msg=16335.0) Extended song/instrument properties were not always loaded correctly for IT in version .50.
[Fix] (http://forum.openmpt.org/index.php?topic=1823.0) Pitch/tempo lock was lost on first instrument when opening instrument tab for the first time.
[Fix] (http://forum.openmpt.org/index.php?topic=992.0) Validating buffer length setting read from INI-file to prevent the impression that it can be set < 10.
[Fix] (http://forum.openmpt.org/index.php?topic=1706.0) Finetune setting was ignored when converting MOD->IT.
[Reg] (http://forum.openmpt.org/index.php?topic=2148.0) Buggy rearrange samples is no longer available.
Executable hashes:
MD5 : ed60357307bed34dd5c5d08067a6349f
SHA-1: 1c3813fd8464d5571d195eaa8fc91fe28e5bfaa2
That's one big update! Thank you very very much!
In case someone is wondering where this can be obtained:
http://modplug.svn.sourceforge.net/viewvc/modplug/trunk/OpenMPT/mptrack/bin/
Thanks indeed. Nice job!
thanks for the job, I hope I'll can use fuly this version as I did with releases before .50!
great! thanks for the update, i had to downgrade back to .48 after .50 had some big issues :\
small bug, the vst plugin scan doesnt work right with plugins that have more than one '.' in the file name (ie, it claims its unable to find 'dominion v1.2.dll', but the plugin loads up fine). also, the buffer issue isnt quite fixed, but i posted in that thread.
is there any reason these builds arent on sourceforge download page? too unstable?
Snu, good discovery. Look at this thread (http://forum.openmpt.org/index.php?topic=2255.0), i had similar issues with VSTs :)
Wow, thanks devs! Great work. This is a milestone build for me, 'cos it's the first time that my plugs seem to all work nicely. :)
Great stuff.
Quote from: "Snu"is there any reason these builds arent on sourceforge download page? too unstable?
Too unstable? :) Won't go into details, but there are various reasons. But it's definitely intention to get new build in sourceforge at some point.
Quote from: "bvanoudtshoorn"Wow, thanks devs!
I wasn't quite informative in the build description, so it's worth noting that plural form is indeed encouraged ;)
THX!
Quick mention for next release... This build (.51) wouldn't start as it needed "winhttp.dll". I will guess this is for accessing the internet sites, and i assume that my setup does not have this .dll (win98SE), especially since i've not connected this computer to the internet.
When there is a "big enough" release in the future, please remove this requirement. If i remember correctly, someone made a special .48 build without this requirement, and it turned out to be VERY helpful. Right now, .48 is fine and relatively stable for my purposes, so there's no big rush....
http://forum.openmpt.org/index.php?topic=1778.0&highlight=winhttp
you have asked that before :P
Quote from: "changelog"To disable, set CheckForUpdates=0 in mptrack.ini.
Does the update check even work?
Quote from: "älskling"Does the update check even work?
As far as I know, it works in .48(but doesn't recognise newer builds on purpose), but in builds 49-51 update check is disabled.
In the thread Jojo mentioned, MisterX wondered about further supporting of W98.
Next to my main machine I use two laptops, with W98, very frequently, for live and educational purposes.
Afaik every version upto .51 runs fine on them, except the .dll issue at the start. But that's the only hinder so far.
So I don't see any special supporting or compatibility demands in the development so far.
In case any member needs it, I have made the DLL available here (http://www.louigiverona.com/webarchive/samzen/modz/winhttp.7z).
well, there's still an issue on win98 in the instrument tab when you have the time indication lines turned on.
I checked my .ini and CheckforUpdates was indeed set to 0.
Thanks, Zen, for making that .dll available. I'm sure i'll never use it, but if it keeps me with the current version of open MPT, and it's otherwise harmless, i'm all for it.
Quote from: "Jojo"well, there's still an issue on win98 in the instrument tab when you have the time indication lines turned on.
You too? :? I thought it was just my machine, since i'm running Win98SE on emulation with Mac. I hope that gets addressed, either by defaulting OFF or fixing the graphics glitch (altho i don't what i'd ever use it for).
It simply doesn't work on any win98 installation. and since i only use win98 for oldskool games, i don't really care.
i'm not quite sure if this can be called a bug and it'll need further testing, but:
i get the impression that in some certain cases .51 handles sample/vst volume differently than older version do. experienced much lower sample-volumes than it should be while playing some older modules live last weekend.
Quote from: "BooT-SectoR-ViruZ"i'm not quite sure if this can be called a bug and it'll need further testing, but:
i get the impression that in some certain cases .51 handles sample/vst volume differently than older version do. experienced much lower sample-volumes than it should be while playing some older modules live last weekend.
If you ask me, certainly a bug if true - and a major one as well. To be investigated - I've also noticed something similar with older mods.
Edit: Results of investigations: For me, the likely cause for the difference was the value of pre-amp setting in sound card setup. The pre-amp value affects only samples, so playing a mod with different pre-amp value can make the VST/sample volume ratio to be wrong. To think of it, this is rather horrible behavior. The RC3 mixmode ignores the setting, however. Please report whether this is the cause in your case as well.
---------------------------------------
Quick bug fix build(1.17.02.52) is available:
[Fix] Shouldn't need winhttp anymore.
[Fix] (http://forum.openmpt.org/index.php?topic=2255.0) Fix to faulty plug file existence check.
[Fix] (http://forum.openmpt.org/index.php?topic=992.0) Sound card-options buffer length value validation.
[Fix] (http://forum.openmpt.org/index.php?topic=2080.0) Yet another IT style-playback fix.
Executable hashes:
MD5 : 8f719b62f323c4d407e1703e590e239d
SHA-1: b16bf498f80b5f0833016f7571069b50a1201f53
thanks for the update, will test it now :)
edit: nice improvements, no dissapointments :)
edit: i also bumped some of the threads with issues fixed in .51 so they can be set to "closed" status.
Quote from: "Jojo"edit: nice improvements, no dissapointments :)
Yet :)
I feel confident in trying out build .52, so I downloaded it.
When I start OpenMPT I get the following error:
Title: Tuning readmessages
Type: Info
Message: Error: ID 1073741840; FrameworkID mismatch
Buttons: Ok only
OpenMPT does start after that, but I get this errormessage each time.
Do I need to change something in my settings?
Quote from: "LPChip"Do I need to change something in my settings?
Copy tuning folder from .48 package(or destroy the folder).
Quote from: "Relabsoluness"Quote from: "LPChip"Do I need to change something in my settings?
Copy tuning folder from .48 package(or destroy the folder).
Ah okay.
I did just moved the new mptrack.exe in my old .48 install build after renaming the mptrack.exe to mptrack.48.exe (yes I have about every release in that directory! :D) and then started. I now renamed the tunings directory to tunings.dnu and it works now.
Opening .52 was ok.
Also replaced .48 by it on the W98 sys, after removing winhttp. No probs.
Quote from: "Relabsoluness"Quote from: "BooT-SectoR-ViruZ"i'm not quite sure if this can be called a bug and it'll need further testing, but:
i get the impression that in some certain cases .51 handles sample/vst volume differently than older version do. experienced much lower sample-volumes than it should be while playing some older modules live last weekend.
If you ask me, certainly a bug if true - and a major one as well. To be investigated - I've also noticed something similar with older mods.
Edit: Results of investigations: For me, the likely cause for the difference was the value of pre-amp setting in sound card setup. The pre-amp value affects only samples, so playing a mod with different pre-amp value can make the VST/sample volume ratio to be wrong. To think of it, this is rather horrible behavior. The RC3 mixmode ignores the setting, however. Please report whether this is the cause in your case as well.
didn't test it but sounds very much like the reason...
will check when i come home from work...
(btw: i've been using the same pre-amp value for years now)
I would imagine that it is also located on SourceForge.
Quote from: "Really Weird Person"I would imagine that it is also located on SourceForge.
Yes, as always (http://modplug.svn.sourceforge.net/viewvc/modplug/trunk/OpenMPT/mptrack/bin/mptrack.exe?view=log).
It would be nice if the OpenMPT Development Builds (http://modplug.sourceforge.net/builds/) page went back into service, I can't imagine I was the only one subscribing to the RSS.