Author
Topic: [DUPE] OpenMPT Project (.mptp) (Read 2427 times)

Quite simply: this would be like .mptm - with the exception that the samples are not saved with the file, but dynamically linked to .wavs (or proprietary sample format) on the hard drive in a specified (relative path) location.

This way, you could save a large number of versions / version history of your song project without filling the HDD space by saving multiple copies of the sample data with the patterns.

I know there is already the Impulse Tracker Project (.itp), but it doesn't work properly if the same sample is used in multiple instruments, which I tend to do a lot to get more different uses out of a single sample. Also, it doesn't support the other advanced .mptm features, like custom pattern timesigs or multiple sequences.

Is this technically feasible? I know at least that .wavs cannot store all metadata required by OpenMPT in their header (such as, whether the loop is ping pong or not) so that data would have to be retained in the .mptp. Loop points may also have been modified inside .mptp to get ping pong working, so the loop point data in the .wav would have to be ignored when loading the song, if this has been done.

An OpenMPT project which would merge ITP-functionality in MPTM and further improve it is an idea that has been around for some time, but it's still hanging on the TODO-list. Some of this has already been discussed in (S=O) [REQ] Revised IT Project (.ITP) functionality.

While waiting this to become reality, have you tested any version control software whether they would be suitable for you for keeping version history and saving HD space?

Yeah... my suggestion was more along the lines of actually stripping the .ITI, because it complicates matters due to the way .iti handles samples (ie a sample cannot be shared between instruments).

Is there (free, open source) version control software out there, that can actually pack the similar data within a file to create a more compact version history? I haven't looked into that option at all, actually. Any good tips?

Is there (free, open source) version control software out there, that can actually pack the similar data within a file to create a more compact version history? I haven't looked into that option at all, actually. Any good tips?

Subversion(for Windows see TortoiseSVN), the revision control system used for example for OpenMPT source code, compacts version history. I don't know, though, how well it is suited for keeping version history of module files, but based on what I've used it so far I wouldn't be surprised if it suits fine.