Why there won't be more effect columns in the forseeable future

[Saga Musix]

This question has been asked numerous times in the past, and I've been asked the same thing twice in the last week, so I thought I should maybe write up a quick FAQ about why OpenMPT still doesn't have more than one effect column in the pattern editor.

In essence, several factors play into it. Try answering the following questions:

1. What should happen if the same effect is encountered in two different columns of the same cell?
2. What should happen if two contradicting effects are encountered?

To give a good example where this will fail, imagine the retrigger (Qxy / Rxy) effect: It has a counter that, when reaching zero, retriggers the note. Now what happens if you put two retrigger effects in the same cell?
1. Execute them both, using just one state variable as before. This would lead to hard to understand and random behaviour.
2. Execute them both, having one state variable per column. This would be confusing if you switch between columns.
3. Execute only one of them. But which one? Why should it be the leftmost one? Why should it be the rightmost one? Both choices are arbitrary.

Now I hear you saying "but you can already put exx in the volume column and Fxx in the effect column and they contradict each other", and in a sense you are right. But:
1. The behaviour for this contradiction is well-defined. I don't want to and cannot make up and verify well-defined behaviour for each possible effect combination (there are too many).
2. The effects don't contradict each other when actually processing them: They have no internal state or counter like the retrigger effect. Putting several slide effects on different columns is not a big problem.

This is just one example, but there are many other problematic situations, and I really don't want to consider an exponentially growing number of potentially conflicting commands and hardcode their behaviour if they are encountered together. As an example, note delay + retrigger would need to be hardcoded at the very least: Should the retrigger command do something before the first delayed tick is encountered? If so, should this only affect an already playing note? If yes, what should happen if there was an already playing note but it reached its sample end? What about VSTis in this case?

To propose some actual solutions that could be implemented in the far future:
1. Have dedicated effect columns for specific effects, like in Renoise: e.g. volume, panning, delay, other. Would always take more space in the pattern if you need them all, but is very tidy and simple to implement. Or maybe, to mimic the existing system a bit more: volume + slides, volume + slides, delay, other.
2. Have only one column into which problematic effects like retrigger can be entered. I imagine this to be confusing, though, since it would be hard to distinguish where you can enter what. Right now, the volume and effect column are very distinct from each other, but having two identical-looking columns with different effect sets would be confusing.

Maintaining support for legacy formats will also complicate this even further.

[LPChip]

Is it possible to display an error when a contradicting effect is entered and simply not allow it? The error can have a checkbox: don't show this again, and an explaination in laymans terms why it can't work.

[Saga Musix]

No, because that's bad UX.

[Harbinger]

I have thought about this very problem when designing my own tracker (still in the Idea phase), and it seems the problems encountered would only be worth solving if MPT was primarily designed to offer its own way of tracking music. But MPT has always been first and foremost a 'universal editor,' able to open and edit many different track formats, allowing it to convert them too, as long as the user understands what will and won't be converted, and how. As it happens, the ModPlug Tracker's own MPTM format is an afterthought as an extension of the IT format, and if any extra command columns were to be added, it would only be under the MPTM format, and only after, i'm sure, it's been decided what will happen when conflicting commands must be processed on one row or in one tick.
I applaud our devs' desire to keep MPT simple, and it's one of the primary reasons I never jumped to Renoise, which does have multiple command columns. When i'm composing or producing music, I don't need my mind boggled with so many rules of 'what will happen if I do this?'. It should be pretty straightforward and intuitive when I put in a  note or command.

As a side-thought: if we should ever undertake a multiple-command channel display, i'm thinking it'll be better if conflicting commands be dynamically restricted based on already-existing commands. That is, once you enter one volume command, another volume command can't be entered, as an example. But that's for another discussion in the future...

[Exhale]

How about restricting the new column, it isnt a traditional effect column, but a "secondary effect" column ie it will only allow you to put in commands which will not conflict with others... so if you have an effect in the volume column which will conflict it is greyed out on the modplug double click and cannot be entered at all on our "extra effect column" and the column is only available in the mptm format or other formats exclusive to modplug - that way it will still load old files which wouldnt have that extra data anyways, and after a conversion from an old format to mptm or others you guys might decide to use too we can have the extra functionality.

[Saga Musix]

As said, not allowing the user to enter certain command combinations is just frustrating for the users. I'd rather go with an approach that "always works", like delay and pan columns.
You can leave formats other than MPTM out of the picture anyway as there will always be a backward-compatible way to edit those.

[Exhale]

well just throwing the idea out there that the new column could be restricted in some way - not exactly the same as the effect column, and still be extremely useful.

[PRAYTHEPO]

Yes, it is too late (8 years), but the easiest solution is to not allow to put the same type of effect into second column. Just to do some check if there is already this type of FX.

If you raised your right leg, then you can't lift it again. Defend fools from themselves.

[Saga Musix]

Working backwards from what currently exists and projecting how the future should look isn't a very constructive approach, it's filled with trouble in fact. If we just take the existing set of commands (of which there are about 50), we'd have to evaluate for every combination of two such effects if they are in conflict with each other. It's not just putting the same effect into two different columns which can cause such a conflict, but also just two different effects belonging to the same category (e.g. portamento up and down) that may or may not be troublesome. If this matrix of incompatible effects isn't 100% correct when the feature is introduced, people will be able to use quirky effect combinations and suddenly those quirks must be supported forever, because someone might have already used them (like combining volume column and effect column vibrato in XM files, of course it's a terrible idea to do that and yet there are some modules using this quirk, so it has to be emulated correctly).

For the MPTM format, I'd rather try to start fresh at some point and try to avoid this problem from existing in the first place. If it's physically impossible to enter a conflicting effect combination, e.g. because different effects must go into different columns (like in Renoise), this helps both the users and maintainers of playback code because the question of how conflicting effects should be dealt with doesn't even arise.

[n0cturn]

Doesn't OMPT already deal with similar conflicts, like note volume opposed to channel and global volume? I'm guessing that works on which has the highest priority

[Saga Musix]

No, those volumes are by design multiplied with each other, that is not a conflict.

[Exhale]

For the MPTM format, I'd rather try to start fresh at some point and try to avoid this problem from existing in the first place. If it's physically impossible to enter a conflicting effect combination, e.g. because different effects must go into different columns (like in Renoise), this helps both the users and maintainers of playback code because the question of how conflicting effects should be dealt with doesn't even arise.

I like that option immensely... the way I picture it being handled is the first column is a master column and works exactly like the effect column we already have, but anything put into the second column is a slave to the first and if it conflicts with the first column people can put it in - it will be highlighted in a bright red background with black text and will not save if you save the file. That way you only have to check the second column for conflicts with the first if someone puts anything in it and it basically flat out refuses to even process conflicting commands put into it.
And with things that dont conflict but are similar to the way we have things in the volume column as it is right now, you can keep your multiplication system (I didnt even know it did that, I thought it added/subtracted, learn something new every day )
And this could be another way of adding to the functionality of the volume column, make all the new additions a slave to both effect columns... which could actually be something we do instead of adding the new column right away, add more functionality to the volume column, as many effects as you can in a similar way to the way we have been doing it, but make the new effects slaves to the effects column, and any conflict would show up as an obvious error and not save when the file is saved.