OpenMPT > Technical Documents

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

(1/2) > >>

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.

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.

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...

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.


[0] Message Index

[#] Next page

Go to full version