Unleashing Modplug.

[Relabsoluness]

I think our common interest is that MPT is growing in a balanced way, not bending to the direction of the hype of the day, nor bending to the direction of a 'purist' kind of view.

Nicely put.

Indeed

[Sam_Zen]

So you base your opinion on Reason 4 on a ten year old TB-303 emulator?

LOL. Yes, probably.

[MisterX]

Modplug is more of a composing tool. Sort of like pen and music paper to write out your music.

Agreed - I always viewed MPT as an instrument and not a studio mixing/mastering software suite.

One of the pet peeves of the original author of the MODPlug software (Olivier Lapique) was requests to make the software "all-in_one", i.e. MP3 support for the MODPlug Player.  He believed, and I agree, that it was not the intention to make the software support every file format, videos, plugins, etc. but to focus on module music specifically.

Of course I think that there can be many improvements made to MPT that will help composers to create music, which as some have posted here already should be the main focus of MPT.  When VST support was added it just expanded the possibilities for composers, and I think that there are other options that could also add to the abilities of MPT.

Let's make MPT the best "instrument" that it can be, and leave the other things to the software that specializes in the mixing/mastering end of things.  It doesn't need to be an "all-in-one" production environment, especially when there are plenty of other tools out there already.

[Sam_Zen]

Right on, Kim.
Olivier's spirit still should be maintained in the growing of MPT.

[maleek]

I don't think anyone here wishes for Modplug to do their math or cook nice pasta. But really, there is no reason why not to want Modplug to move forward while maintaining the core of what the program is and means to people. I mean, there are apparantly several things that can get better. It seems most people agree on that point.

[Sam_Zen]

Sure, that's why we're here on this forum. Getting it better, That's why we post the bugreports, requests, suggestions, etc.
Afaik a program is never really finished. Even if it's functioning perfectly, a new OS comes along, or a new fileformat.
New graphic environments, etc. So new demands coming up, and the choice how to deal with them.
It's the same reason why the message on a website "under construction" is quite silly.
So often a pronounced 'standard' had to make place for 'the new standard'. And so on.

In this light the choice of Olivier, not to add MP3 import as a sample, is a crucial one.
I see that as a long-term policy.
I happen to be a fan of the OGG format as compression instead of MP3.
So now I could request the capability of this format as well. Does this mean any progression? I don't think so.
I just accept the fact that I have to offer the basic material in the WAV format.
Also because technically, MP3 or OGG would mean a rather useless extra decompression routine in the process.

MPT does have the ability to export as MP3. That's a bonus. But that's the right position to decide to add it or not.
At the output.
Do you want a quick MP3 to be used instantly, or do you want to use the WAV(s) for a next proces of final production?

[älskling]

In this light the choice of Olivier, not to add MP3 import as a sample, is a crucial one.

IIRC, Olivier said something along the lines of that since MP3 compression removes some frequencies, the sound quality will sufferwhen previously compressed samples are resampled. That's a valid point, but I would like to be able to make the choice myself. Compressed samples can be extremely pracical if one wishes to distribute a mod that contains e.g. vocals or other non-sequenced sounds.

I also think that speculating in "what would Olivier do" is more of a curiosity than a sign of which direction OpenMPT should be developed. Then again, I see no reason for the developers to implement anything they have no personal interest in, all we can say is "pretty please".

[Saga Musix]

IIRC, Olivier said something along the lines of that since MP3 compression removes some frequencies, the sound quality will sufferwhen previously compressed samples are resampled. That's a valid point, but I would like to be able to make the choice myself. Compressed samples can be extremely pracical if one wishes to distribute a mod that contains e.g. vocals or other non-sequenced sounds.

In this case, the MO3 format comes in pretty handy :lol:

[maleek]

Älskling wrote:

I also think that speculating in "what would Olivier do" is more of a curiosity than a sign of which direction OpenMPT should be developed. Then again, I see no reason for the developers to implement anything they have no personal interest in, all we can say is "pretty please".

I wholeheartedly agree. Since I cannot contribute with coding I, as well as everyone else, can only ask and suggest. Not demand anything really. I am quite humble in face of everyones personal lifes, especially sine we are talking about freeware.

[Sam_Zen]

I would like to be able to make the choice myself. Compressed samples can be extremely practical if one wishes to distribute a mod that contains e.g. vocals or other non-sequenced sounds.

Valid points too. But it would be my last choice, only when the mod itself would become very huge.

Things have drastically changed in that perspective concerning filesize.
In the pre-VST time, with only lo-res samples, and only short vocal samples, size of a module tracker was independent of duration of the output.
Like a WAV or MP3 is. The longer, the bigger.

A mod could have about 600 KB of samples, and could result in a WAV output of 2 min. or one with a duration of 10 min.
Maybe the 2nd one added a couple of KB's to the 600 KB, because of some extra patterns in the row.

Lately, I've met posts in the Download section, where people saying :
- I will post a link to a simplified version of this mod of 3:20, because the original is 1.5 GB..

[MisterX]

I also think that speculating in "what would Olivier do" is more of a curiosity than a sign of which direction OpenMPT should be developed.

Certainly - the only reason that I brought his name into the conversation was due to his interest in keeping the software focused on making and playing back module files, something that I also believe should be the focus of the software.

As it is now open source, any developer can add whatever feature(s) they feel are worthy of their time.  I am just hoping that new features will help to make MPT a better instrument, and not start to go off in the direction of making MPT a complete production environment, since it seems that would be a bit of "reinventing the wheel".  But as you mentioned, all we can do is say "pretty please" unless we have the time and the knowledge to modify the source code on our own.

VST support, while not in the arena of "oldskool" tracking, was IMHO one of the best new features for making MPT a better instrument to work with.  (The *.ITI format comes in a close second - no more 120MB files!!)  Improvements like these (and the fact that it is free) are what keeps MPT a viable option for anyone wishing to make music on their computer.

[mrvegas]

Maybe this should be in feature requests, but I'm just curious if it would be possible to add a "crossfade loop points" function in the samples editor.  This would be great, particularly for stereo samples.  Also, the ability to select the area for fade in and fade out, and resampling for changing the sample rate would be nice.

Just some thoughts.  Actually, I'm very, very happy with Modplug and I'm not even using the most recent beta build.  I will probably wind up buying Renoise at some point, but one of the reasons I have held off is simply that I enjoy the openness of the format and the flexibility of the program.  While it would be nice to see less buggy VST handling and better VST mixing abilities, I am frankly amazed that this program exists for free.  There is a collection of features available that doesn't exist even in some commercial programs -- the combination of the ability to use a wide array of formats, VST support, midi export, solid wav renderer, built in sample editor, good (and flexible) sample ramping, etc.

Thank you developers!  If you want a list of things I'd like to see, I'm sure I could keep you busy, but I think the most important thing is to keep a stable program that works well with samples and the known module formats.  As I said, a few additions to the sample editor would be most helpful.

I can't tell you how much I've enjoyed working with Modplug.

[KrazyKatz]

Thank you for all your votes and comments fellow craftsmen. We've all come to realize quite a bit from this. Modplug must remain firm in its traditional roots and improve by all means without becoming a generic DAW.

I'm personally going to be looking for options to start implementing the features, so stay posted for future threads where YOU can make a difference to Modplug.

Keep on tracking.

[bvanoudtshoorn]

Scripting. If MPT had a scripting engine, with access to all of its internal variables, small features could be added in really quickly... Pascal Script, Javascript, whatever. (I'd prefer not VBScript, but I'd handle it! ) Only problem is that, AFAIK, it'd be a bit of a nightmare to implement.

[Sam_Zen]

'Keep on tracking' it is. (my signature on the old forum)
As known, I barely use VST, but I think as it's implemented in MPT now, there is an obligation to finetune the function of it.
I'm a bit afraid that it would be a continuous process, because VST's are an external factor with its own developments.
So MPT can only react to those devs afterwards.
I agree with mrvegas about some sample handling improvements. But that's for the Request department.

EDIT: Missed Barry's post while writing the previous.
Being able to use some kind of script has been my wish from a long time ago.
For the output, it could be a means to perform the same composition in different ways, while the original module can stay the same.

Examples :
~ For a short version skipping stanza 3 and refrain 3, by making a jump in the patternrow.
~ Enable the effect-settings in the player-tab after pattern n.
As for an input to create a script, there are fancy possibilities too, like recording a macro-file, while the song is being played,
and some values are changed, or a channel is muted, and could be saved.
This can be reversed-engineering of course. Not depending of complicated realtime recording, but composing a script on forehand,
how the composition should be performed.

If it's about the format of such a script, I prefer to start with basic options. Like e.g. a .BAT or an .INI file ascii.
All kinds of script-languages possible, but first question is : Which script-formats already can be read by MPT?
Before adaptation to a new format.
I can imagine a file 'song.ini' next to 'song.it' being loaded first, to define the actual performance of the song.

So each song can/will be a set of 2 files.
If this is the case, one can't expect to ask from other module-players, like XMPlay, to read this properly.
But the counterpoint to compatibility is exclusiveness. Only MPT can do it.