Hi all,
After a long delay (my fault), dev build 1.17.02.46 has been released (http://sourceforge.net/project/platformdownload.php?group_id=100385).
The important news is that Relabsoluness' work (aka the 1.17.3.00a branch, or the '3.00 alpha' preview) has been merged into the main builds. In particular, this includes the experimental MPTm format which, implementation-wise, is still very close to the hacked IT format, but represents a stepping stone towards further changes and improvement in the future.
From now on, development builds will be made available through Sourceforge's formal release process. This means they will be visible from the project page and will be easier to get at. In the name of simplicity, the processor specific builds have been ditched in favour of a single executable (there was no evidence that they were providing performance gains anyway).
This update requires more than just the .exe. Installation notes:
. If you have an existing installation of OpenMPT and wish to re-use its settings, you have 2 options:
. Overlay the .exe and new files from this directory onto your existing installation.
. OR: copy mptrack.ini and plugin.cache from your existing installation into this directory.
. If not, you're done: just launch mptrack.exe.
Here's what's new:
v1.17.02.46
+ <Relabsoluness> Experimental MPTm format:
--> Internally, it is still very close to the IT-based format.
--> Order&pattern limit increased to 65000; whole range not tested :) (Note that modeffects such as position jump doesn't cover the whole range unless the #-extension can be used(haven't tested))
+ <Relabsoluness> User definable tuning modes for instruments:
--> Only available for MPTm
--> Ratio value as well as note name for every key can be assigned invidually; gives rather free hands for experiments.
--> Every instrument can have it's own tuning
--> Tunings can be saved to file and loaded from file.
--> IMPORTANT: When using tunings, behavior of various modcommands such as portamento have been changed, and new behaviors are still to be decided.
+ <Relabsoluness> In song properties, option to increase playback compatibility with original Impulse Tracker behavior. Is in no way complete; currently affects only a couple of differences. Many differences are still there.
+ <Relabsoluness> Ability to load multiple mods/samples/instruments from corresponding load dialogs.
--> Known issue: Intermittent failures.
+ <Relabsoluness> 32-bit float wav import
. <Relabsoluness> 24/32-bit PCM wav sample import fixed
+ <Relabsoluness> Playback control additions: 'Solo on transition' & 'Mute on transition'. Available from pattern view context menu(right click).
+ <Relabsoluness> Envelope points can be scaled by a factor through context menu on envelopeview(right click)
+ <Relabsoluness> Calculator of playback time (measured from start) at the beginning of any row of any pattern (uses existing modlength calculator).
--> Known limitation: When the row is within pattern loop, doesn't give all possible times.
+ <rewbs> SCx now sends note-off to VSTis at tick x.
+ <rewbs> New mixmode (called 1.17RC3): bypass global preamp, force soft panning, provide explicit dB value for sample attenuation. WARNING: this mixmode is subject to change.
+ <rewbs> Check for updates on startup. To disable, set CheckForUpdates=0 in mptrack.ini.
. <rewbs> Plugin list window remembers its position/size even on cancel.
. <rewbs> Fix odd window position on very first startup (before mptrack.ini is created).
. <Relabsoluness> When opening instruments, load dialog didn't remember its previous path.
. <Relabsoluness> In general tab, it was possible to give longer modname than the fileformat could save.
. <Relabsoluness> Instruments associates with VSTis no longer also need to be associated to a sample in order to play.
. <Relabsoluness> Trash characters to empty ITP comments should no longer appear.
. <Relabsoluness> Channel state should now be updated correctly when e.g. moving channels through channel manager.
. <Relabsoluness> It should no longer be possible to remove all channels from channel manager.
/ <Relabsoluness> Channel states resetting when jumping between orders from orderlist.
--> NOTE: While this fixes a bug (behavior change) introduced in the tuning branch(?), it also changes quite prominent behavior so can annoy people - might need to be modified at some point.
/ <Relabsoluness> Added version number to the mainframe title.
/ <Relabsoluness> Changed the 'order message' at the bottom bar of the screen "Position x of y" to "Position x of y (x in hex of y in hex)".
/ <Relabsoluness> Lots of smaller (internal) changes.
By the way, because of the change in release process, the RSS feed that drives the normal release page (http://modplug.sourceforge.net/builds/#dev) hasn't been updated yet. Will fix soon.
Huge thank you to our programmers that worked on it. Big thanks too, to all involved in what ever way. I'm looking forward to trying it out.
This is indeed great news!!! :D
Heil to Rewbs and Relabsoluness! :D
Great news, yay!
Thanks a lot for the good work.
It says 'Order&pattern limit increased to 65000'. Is this really 65000, or in fact 65536 ?
Quote from: "Sam_Zen"It says 'Order&pattern limit increased to 65000'. Is this really 65000, or in fact 65536 ?
65000 is correct, but indeed figure 65536 is closely related to that.
Quote from: "Relabsoluness"Quote from: "Sam_Zen"It says 'Order&pattern limit increased to 65000'. Is this really 65000, or in fact 65536 ?
65000 is correct, but indeed figure 65536 is closely related to that.
I'm curious to why it's not 65536. It would seem that 65000 is wasting 536 other numbers that is possible with a 16 bit unsigned integer, despite not conserving even a single bit. I have no qualms with it though, as I'm probably never going to reach that many patterns, but rather, I'm wondering about the practicality of 65000 over the programming canon of 65536.
list of improvements/fixes sounds promising ^_^
will start testing this evening... lalalalalla
woohoo! fantastic effort, nice fixes + improvements. i got confused by the tunings until i realised that they can only be changed in mpt format (duh!) so if anyone else has the same problem...
is it possible to send vstis different tunings or will this be a sample only thing? ace addition regardless, plenty of things to do with samples alone!
more than 238 or whatever the limit was for patterns is brilliant - i'll probably not max it out ever again now.
i've not delved deeply yet but ran some old tracks which all worked perfectly.
Quote from: "CrazyAznGamer"I'm curious to why it's not 65536.
Wouldn't that get problematic if one would need to have somekind of 'reserved' indeces in addition? And why it's 65000 and not for example 65154 or 65527, is pretty much just an arbitrary choice.
Quote from: "anboi"is it possible to send vstis different tunings or will this be a sample only thing?
Only for samples at least for now; I reckon that this kind of scheme can't be used for VSTs.
IMPORTANT: When using tunings, behavior of various modcommands such as portamento have been changed, and new behaviors are still to be decided.Many tuning related matters are still quite crude and are subject to change, which is good to keep in mind if intending to 'seriously' use them.
But anyway, below is some explanation about the current modeffect behaviors when using new tuning modes; I'm certainly not an expert in this field so many of the concepts and terms might be misused.
-Many pitch affecting commands such as 'portamento up' increases 'finesteps' instead of the frequency itself - that is, the note goes towards the next note with little steps and the pitch changes accordingly. As a consequence, the effect of certain modeffects is dependent on the tuning and on the tuning specific finestep count; one can for example create arpeggio style effects with this. Also it can be that portamento up actually lowers the pitch instead of increasing if choosing certain kind of tuning. Between notes, the tuning changes geometrically: in build .49, the change was specisialised for all available tuning types, before that the same implementation was used for all types(might behave weirdly for types other than "tet").
Modeffect behaviors with new tuning modes:
-Portamento up Fxx (changed): Increase finesteps by given amount of steps on every tick. For example: With Ticks/row == 6, F01 increases finesteps by 1 on every tick, which makes 6 finesteps up per row.
-Portamento down Exx (changed): Like portamento up with decreasing finestepcount.
-Fineportamento FFx, EFx (changed): Increases/decreases finesteps by x finesteps per row dividing the total effect to every tick.
-Extra fineportamento (changed): Doesn't exist - the command is interpreted like regular portamento.
-Tone portamento (changed): Uses finestep approach and sample is not changed if new sample is part of a same instrument as the old sample.
-Glissando (not changed): When enabled, tone portamento changes whole steps instead of finesteps.
-Vibrato (changed): Speed parameter is interpreted like before, but depth defines deviation from 'reference' so that pitch may be within [0.95; 1.05] from the reference.
-Sample AutoVibrato (changed): Acts like vibrato, but sweep parameter is neglected.
just a little question: I didn't change anything, but after installing .46, some modules sound really loud. why that? They tend to overdrive, but PreAmp is at 30% (i don't really get that RC3 message, maybe that's the fault?) and Sample Volume is also at ~60, so both are still "normal" - but the songs overdrive like hell!
EDIT: Hm, okay, those old modules sound better with mix level set to RC2 - but now i have to reset mix level for EVERY SINGLE module i want to listen to...?!
How come the new OMPT wants to connect to soal.org (65.254.250.109)?
My Firewall says so.
The old Modplugs never did.
???
Quote
+ <rewbs> Check for updates on startup. To disable, set CheckForUpdates=0 in mptrack.ini.
Quote from: "Jojo"EDIT: Hm, okay, those old modules sound better with mix level set to RC2 - but now i have to reset mix level for EVERY SINGLE module i want to listen to...?!
Based on quick look it seems that mods not made with OMPT are set to use RC3 mode by default, with which mods tend to sound louder - sounds like a bug.
Quote from: "KrazyKatz"the new OMPT wants to connect to soal.org
Got a warning by my firewall as well, and I wonder too. I was rather unpleasantly surprised by this.
Quote from: "Relabsoluness"Quote from: "Jojo"EDIT: Hm, okay, those old modules sound better with mix level set to RC2 - but now i have to reset mix level for EVERY SINGLE module i want to listen to...?!
Based on quick look it seems that mods not made with OMPT are set to use RC3 mode by default, with which mods tend to sound louder - sounds like a bug.
Bug confirmed, fixing..
Quote from: "Sam_Zen"Quote from: "KrazyKatz"the new OMPT wants to connect to soal.org
Got a warning by my firewall as well, and I wonder too. I was rather unpleasantly surprised by this.
As stated by Jojo this is an update check and can be disabled by reading the release notes. :)
:oops:
jap, i opened that thread in the bug report forum some time after stuffing around with the different sound outputs.
edit: didn't see that there is another page of replies - that was an anwser on the last post on the previous page.
I use my ole laptop with W98 for realtime playing modules, so I was very eager to update to .46, because of the new 'transition' options.
(BTW a nice achievement of the makers to create one compatible executable. Before that I always had to get both versions, generic and P3)
To be safe I placed .46 in a new dir, parallel to the previous version. When started, I got an error message saying that "winhttp.dll" was missing, did ok and then OMPT was shutdown. Quite disappointing.
Considering the filename I could imagine what the problem could be. The laptop is a stand-alone unit with no network drivers or such apps at all. I copied the DLL from my 2K machine, and placed it in the system32 dir of W98. Problem solved.
So then the comment came in mind of this thread about OMPT trying to connect to soal.org.
Rewbs explained the reason : "Check for updates on startup. To disable, set CheckForUpdates=0 in mptrack.ini.".
But there is no "CheckForUpdates" line in the ini-file of the previous generic version.
Anyway, suppose there is no previous version on such a non-network system. Running the executable is then impossible, because it get stuck with the update-check. And its first ini-file can't be generated after a proper closing, so nothing to edit.
So at least a warning about this would be a good thing.
This is reason for me to nag about this new internet-function inside the program. I don't like it and I don't need it.
It makes the program more dependent of external resources, as proved here, and the real MPT freak doesn't need an automatic function to check for the new version. This is maybe an imitation of the mainstream popular software which likes to please the lazy customer.
Quote from: "rewbs"
+ <Relabsoluness> 32-bit float wav import
. <Relabsoluness> 24/32-bit PCM wav sample import fixed
guys, what about 16bit mono 11,025khz?
it's still not possible to import those files
::)
and yeah, i will keep requesting this for another 3 years if necessary
Quote from: "BooT-SectoR-ViruZ"Quote from: "rewbs"
+ <Relabsoluness> 32-bit float wav import
. <Relabsoluness> 24/32-bit PCM wav sample import fixed
guys, what about 16bit mono 11,025khz?
it's still not possible to import those files
11025
KHZ? wow, that would be an insane quality file O_o
anyway tho, mpt imports 11khz 16bit mono file perfectly... at least 1.17.2.46 does...
mine doesn't... i think i posted more detailed format information somewhere in the past
searched for that but can't find it... probably due to data loss on some forum crash
i never had problems with 11khz 16bit mono wav files - but I have a guess: Your WAV file is not RAW data but compressed - you have to change the format to RAW then ;) So basically a CODEC was used to save that file (you can even use mp3 in wav files ;) ) and modplug only can handle RAW data.
Quote from: "BooT-SectoR-ViruZ"guys, what about 16bit mono 11,025khz?
it's still not possible to import those files
::)
and yeah, i will keep requesting this for another 3 years if necessary
If you wish to improve the changes that you don't have to wait 3 years, it indeed might be useful if you could specify the format of the file.
Quote from: "Jojo"i never had problems with 11khz 16bit mono wav files - but I have a guess: Your WAV file is not RAW data but compressed - you have to change the format to RAW then ;) So basically a CODEC was used to save that file (you can even use mp3 in wav files ;) ) and modplug only can handle RAW data.
well that might be.... when i open the files in wavelab for conversion it sais "decoded"
okay, thanks for that information. indeed this means that modplug does not support this file. however, you can convert it using "save as..." in WaveLab.
Quote from: "Jojo"okay, thanks for that information. indeed this means that modplug does not support this file. however, you can convert it using "save as..." in WaveLab.
sure, but it's sort of bugging me
That means modplug authors would have to include decoders / wrappers, and that's a hard job, i guess.
Great to see this. Modplug still rules supreme in my book. :D
Quote from: "maleek"Great to see this. Modplug still rules supreme in my book. :D
If you're talking about the fact that .46 is out, then maybe try .47 and .48 too? :P
LPChip:
I should probably come here more often, obviously :lol:
My hat is off to you guys
Quote from: "maleek"LPChip:
I should probably come here more often, obviously :lol:
That, or we shouldn't release 3 builds in about 1,5 week or so, after having not given out a build for a few months? :nuts:
But thanks for the compliments. I'm sure the Dev's are pleased to hear that their hard work is greatly being appreciated. :) (also by me ofcource)
Quote from: "LPChip"That, or we shouldn't release 3 builds in about 1,5 week or so, after having not given out a build for a few months? :nuts:
In fact, i rather like the option to just fix a few bugs and release a "weekly build" instead of releasing one release per half year and everyone has to wait till 100 bugs are fixed :D
Quote from: "Jojo"Quote from: "LPChip"That, or we shouldn't release 3 builds in about 1,5 week or so, after having not given out a build for a few months? :nuts:
In fact, i rather like the option to just fix a few bugs and release a "weekly build" instead of releasing one release per half year and everyone has to wait till 100 bugs are fixed :D
This was not due to lazyness of wanting to put many bugfixes together.
It was merelly because Rewbs, who maintain the releases, was too busy to get all the bugfixes from Relabs and Pelya into the build to release a newer version.
Don't forget: they also have their own life, and they do this as a hobby!
well, if i had VS05, i'd really like to join the team - i already know php and a bit of java, so it shouldn't be tooooooo hard :) but well, no VS05, no fun i suppose... damn, why don't you write this in VC98 or VB98? :nuts:
Quote from: "Jojo"well, if i had VS05, i'd really like to join the team - i already know php and a bit of java, so it shouldn't be tooooooo hard :) but well, no VS05, no fun i suppose... damn, why don't you write this in VC98 or VB98? :nuts:
I think you should know a lot of Java actually to understand C++ code. On the other hand PHP has the same level of weirdness as C++ does.
The developers (except me) actually use VS2003, but I think MPT source can be compiled with VC98 with not so many changes (there are still some old VC98 project files in repository - if you manage to compile MPT with VC98, you're definitely in!).
The best thing IMHO would be modifying source to be compiled with WineLib in Linux or even in Windows using Cygwin and g++ using f.e. Eclipse IDE. All following programs (except Windows :lol:) can be downloaded for free. And g++ is arguably better than Visual C++, 'cause it has operator typeof() :) , can compile for exotica platforms 8) and has better expression parser.
Pelya, will you be offended if I didn't understood your last post? :nuts:
Okay, correction, I did understood the word PHP, but thats as far as it went :P
well, "knowing a bit of java" does not refer to my "skillz" but rather to that i didn't do anything with it yet - i know the syntax and everything, but i never did a project in java ;) i did a lot stuff in PHP already...
Quote from: "LPChip"Pelya, will you be offended if I didn't understood your last post? :nuts:
Okay, correction, I did understood the word PHP, but thats as far as it went :P
Ehm. Sorry for bad english :oops: .
I mean we can tweak MPT code to be compiled on Linux (and run on Linux, hopefully) using Winelib (the Windows emulator). Then we install Cygwin (the Linux emulation for Windows) and voila - we're compiling MPT code with totally freeware tools (if you don't mind running Windows emulator on Linux emulator which is definitely perversion). That will require some effort however. The first part (making MPT run on Linux) should be done anyway I think.
Quote from: "pelya"I mean we can tweak MPT code to be compiled on Linux
Might take quite a 'tweak' :)
Um Pelya,
I kind of made a joke about not being able to understand you. But not because of poor english language, but because of the usage of all kinds of technical terms that I never heard of :P
Great! Thank you, guys!