My duplicate issue contains some ideas. Here is a copy:

There should be a new file format, that can be customized. For example, consider the volume of notes. In mptm file format, it's always in a scale out of 64. However you may want greater precision so you customize the file format to use a scale out of 256; the information about the file format customization is in header. Or the opposite; you may want to directly use fades like 16-12-9-7-5-4-3-2-1 (requires proper settings to seamlessly play consecutive notes) without multiplying the numbers by 4. Also, the custom file format should provide lots of flexibility, like allowing long pattern length (I don't like the idea of splitting songs). Oh, guess what? This custom file format can also have potential to provide a feature mptm doesn't: different time resolutions on different channels!

So, this custom file format simply should bypass limitations:

1. of always having volume out of 64; there may be an option to freely select a fractional value from scale out of 1, or an option of having volume scale out of different integers
2. of having only 1024 pattern length; people like me don't like the idea of splitting songs
3. of having equal time resolution on every channel
4. of only having 120 different pitches (finetuning doesn't fix the range problem)¹
   and some more you can think of.

¹For unusual type of tunings, like Hz-based (16, 32, 48, etc. Hz) or period (inverse Hz) based (8000, 4000, 2666.7, etc. Hz), you may run out of range quicker than octave based ones, also tunings like these have no generator built in so they are hard to create

Note that time resolution is what you call "tempo". It's called time resolution because it determines the time resolution (precision) of the song.

The varying time resolution interface could be something along the lines of this (note the empty rows):

https://i.imgur.com/el1Cvl9.png

Channel 1 and 2 is 1/16 time resolution, channel 3 is 1/8 time resolution, channel 4 is 1/32 time resolution. On 4 ticks/row, these would be tempo 240, 120 and 480.

Do you like my ideas?

In one word: No.
1 and 2 are already covered by other requests, and the rest is simply unnecessary and impractical.

I don't think you make much music; You seem to be mainly a programmer. All four are important and necessary to produce good music. You can't easily make good music with volume stuck on a scale out of 64, with only 1024 pattern length, with equal time resolution on every channel or with only 120 pitches. Very important to make music.

So implementing these four will make making music tons easier. Instead of wasting an hour where to split patterns, simply extend the pattern length! Want higher volume resolution, or directly using fades like 16-12-9-7-5-4-3-2-1? Change volume scale! Want a great selection of pitches? Just add more pitches! Want some channels to be half or double time resolution? Simply use that feature!

Yes, I too think that 120+ pieces of music is indeed not a lot. Maybe I should make at least 10,000 pieces of music before I can have an opinion about producing music.
Piotr, you keep insulting the developers that you want to do something for you for free. Do you really think this will get you anywhere? Do you realize that virtually all music software out there is bound to the MIDI standard, which cannot address more than 128 notes? Do you think the developers of all these audio programs have no clue about music? If patterns longer than 1024 rows were required to write good music, how comes that there are tens of thousands of great-sounding modules out in the wild?

MIDI isn't a modern sound format.

Your musicmaking would be much easier with these 4 features implemented. Also, OpenMPT is a free program, so any feature request should be also free.

"If patterns longer than 1024 rows were required to write good music, how comes that there are tens of thousands of great-sounding modules out in the wild?"

That's because with the extended pattern length feature musicmaking would take less work.

MIDI isn't a modern sound format.

I am not talking about the MIDI file format. Internally, every big audio software uses MIDI commands for triggering notes and parameter changes. There is no way to send more than the 128 notes supported by MIDI to a VST plugin, for instance. Even if OpenMPT wanted to support 500 different notes, it would be impossible to send them to a VST plugin.

Also, OpenMPT is a free program, so any feature request should be also free.

And I am free to say no to any feature request, but if you do not respect that and keep posting how "simple" it would be to add them and how important they are, I have all the rights to restrict your access to our issue tracker and forum. Your insistence on minor details that absolutely noone else has ever wanted is costing everyone here a lot of nerves and time.

I think OpenMPT is simply not the right tool for you if all of these features are so important. Please switch to a different tool.

"I think OpenMPT is simply not the right tool for you if all of these features are so important. Please switch to a different tool."

What in the world makes you think someone makes a tool that is exactly like OpenMPT but also with this custom file format?

"Your insistence on minor details that absolutely noone else has ever wanted is costing everyone here a lot of nerves and time."

No. That would be hilarious. It's actually the other way around; even if people didn't notice it, musicmaking would be a lot easier.

"Internally, every big audio software uses MIDI commands for triggering notes and parameter changes. There is no way to send more than the 128 notes supported by MIDI to a VST plugin, for instance. Even if OpenMPT wanted to support 500 different notes, it would be impossible to send them to a VST plugin."

You don't need to hack MIDI to support over 2^7 pitches. While making the GUI a lot easier by allowing unlimited pitches, code OpenMPT to internally use extra instruments with the samples that do not fit in the root instrument, to have the "effect" of more than 2^7 pitches.

Nice that you are actually spending time implementing instead of counter-exampling!

Alright. We've had it. We've had enough of your insults and needless sarcasm steered towarads the developers and other forum members. You have received several warnings that we will not tolerate this behaviour, and you have now reached your limits. Both your issue tracker and forum account will be locked, and you are no longer welcome in this community. Ban evasion will not be tolerated.
Have a nice day and maybe write your own tracker if all of these things are so important to you. If you see other developers like the Audacity developers say no to your requests, maybe it's time for you to think about your own behaviour and if you really are right when everyone else tells you that you are in fact wrong.

Wow, that was quite the read, um... Could I suggest a chord effect for the format something like this:
c#4 01 v64 <1A - or maybe [1A or another unused character - if not in the effect column I am sure we could fit the lot in a volume effect.

The idea is that it would work in a range, (for demo I will use < symbol)
<00 would be a major chord ascending from the base note, <01 could be the major 7th <02 maj sus <03 maj 2nd <04 - <07 would be the minors. some of the options for the chords could be plucked at regular intervals like a stringed instrument with some note off variation. An example of the plucking could be :
c#4 02 v32 <3f - could translate as: (c# sus with 2 tick note off)

C#4 02 v32 . . . | . . . . . . . . . . . | . . . . . . . . . . . | . . . . . . . . . . . |
. . . . . . . . . . . | F-4 02 v32 . . . | . . . . . . . . . . . | . . . . . . . . . . . |
=== . . . . . . . . | . . . . . . . . . . . | G#4 02 v32 . . .| . . . . . . . . . . . |
. . . . . . . . . . . | === . . . . . . . . | . . . . . . . . . . . | A#4 02 v32 . . . |
. . . . . . . . . . . | . . . . . . . . . . . | === . . . . . . . . | . . . . . . . . . . . |
. . . . . . . . . . . | . . . . . . . . . . . | . . . . . . . . . . . | === . . . . . . . . |
What something like this could do is save a lot of song programming time for everyone - even limited. But if we have a lot more room and are not limited too much it would be nice to get as many variations as possible, so plucked descending chord centred on the provided note so cmaj notes = g-3, c-4, e-4.

That would be an extremely specific case of templates/macros that have been suggested before, so: no, not in this form. too specific.

A nifty feature would be Envelope Key-Scaling parameter, that makes envelopes play faster the higher notes you play or vice versa, similar to pan separation, that makes sound play more left or right depending on higher or lower notes.

Yes I know it's possible to use samples of instrument with decay, but what if sample-size is a matter in a certain scenario to somebody?
Dxx is also a way, but even if the future may bring multiple effect-columns, that way is complex - all from that you have to fill the patterns with them, clean up after easily made and missed mistakes, to calculate rates if you're not using DFx, and in the long run, again, size-issues for the one who wants to keep things small yet get much out things as possible.

Nonetheless, it makes creation of realistic-sounding instrument possible, like piano, where higher notes sustains shorter than lower note. It can also be used for cool envelopes that changes rate depending on note.