[s]Started in the discussion “Markers”. Please read to get a hang on what is going on.
(Discussing about stretching xxyy pattern commands to xxxyyy and breaking the hex limit of pattern command id’s (=Fh=16 opposed to 1-Z=36))
Why don’t we just stretch the value part of command to 4-digit at once. I would do that even if we lost one extended commandId character. That would allow pretty precise control of parameters and thus would improve the upcoming(?) correlation between accurate automation envelopes and inaccurate 256-step pattern commands.
If the id range is to be radically extended, and yet if not that radically but just extended, we could have some kind of programmable macro commands, like IT had MIDI macros, but not limited to MIDI. For example if 1-9 were macro commands, I could write that macro 1 would be (note, just examples)
range(0000-ffff)
{
distortion2.Drive(lin(0.5-1)); //linear response curve from half to way up
filter3.Resonance(log1(0.7-0.3)); //logx, where x is form of logarithmic curve, inverse response. Of course actual slider values could be used here too, like db for volume.
}
or
pitchSlideUp/command id;
vibrato/command id;
or
Ec v 00; //would send pitch bend message to associated instruments MIDI channel and out, values taken from v=velocity variable, c=channel variable, 00=constant (no fine tuning)
or
pitchBend(instr1.pitchEnv); //would trigger sending pitcbend values according to instrument pitch envelope to associated instruments MIDI channel and MIDI out, dunno if would be possible, but would keep this unimplemented until XRNIv2 unless compatibility could be providen.
or any specific MIDI command or command sequence.
Then we would need variables like channel, instrument velocity, volume, panning and maybe envelopes and input value from other macro for example, if present. Then you had any imaginable pattern command available any time. You could trigger envelopes for MIDI and such. Very flexible. Just a sketch, feel free to improve the idea.
Only thing that would keep me from adding more detail into pattern commands is the clumsyness in horizontal moving across the column. I would really like to see digit input changing into “start from right and push left” method, then one digit field would be one arrow-keypress. For four-digit commands we could have shift-numbers or so to alter between high and low order numbers, there are tons of commands that neccessarily wouldn’t need such precision when entering by hand. Also, if 4 symbols would be entered in a row without modifier, first two goes to high and latter two into low order part. Heck, low order numbers could even be hidden in most of times until key is pressed, and then hidden back when released, or they could be displayed in smaller font or so (customizable?). Also separating them would allow handling them as separate input variables in macro commands.
And how about separating internal sampler/core program controls and Fx automation commands into different columns?[/s]
…okay, apparently the whole thing was a joke and I got a bit too excited. We don’t really need that extended command range and macros even if it would allow recording NRPN, RPN and pitchbend commands directly into pattern. We got devices already. Too hard, too weird.
Some day I’ll make my own tracker and show you all! 
It’ll be so good that you can write the song directly into source code!