Well, for one it is impossible to use both. Though yeah - on those cases where you really NEEEEED markers (long samples), you wouldn’t use 9xx anyway - unless it would be possible to apply it to a slice, as mentioned above!
But more importantly (for me): 980 always means 50% of the sample. M80 however could mean anything… as could 980 when implement that way, because it depends on wether sample markers are turned on and where they’re at.
Isn’t there some crazy volume column/effect column combo for controlling MIDI pitchbend parameter? Couldn’t we have some crazy volume/panning & effect column combo for doing UDO + sample offset automation?
However, this would mean that the 09xx offset would need to be recalculated based on how long each individual slice is. Just something to take into consideration.
Some more incentive for sample markers is that we could align the markers to zero crossings as opposed to working semi-blind with 09xx commands.
I thought we decided UDO and 09xx could be used together? 
00M001 000980 = start playing sample halfway though the first user defined offset
of course we’re keeping hex, so it wouldn’t be M
NO, please!! No more of that hybrid stuff. It doesn’t solve anything, it just shifts the problem: “what if I want to use volume,panning,slices AND offsets?”
If I had my way there would be a column for EVERY possible effect, but I’m not even going to propose that, I know better…
That’s what I meant with “subtraction and division”. That takes less time than drawing a single pixel*.
I thought the issue was that there are no more hex values available for new effect commands. So we do want to add an extra digit or two to the pattern effect column?
Then it would be 010901 or something like that, yeah? Seems much less confusing than 0M01.
Someone complained that we’re delaying the inevitable by adding the alphabet, but is it really any more practical to continually widen the effect command columns? Eventually they’re going to get a bit unwieldy, and how much feature creep do we really want in Renoise? I’d think an extra 20 effect commands ought to be more than enough.
“I have to say that in 1981, making those decisions, I felt like I was providing enough freedom for 10 years. That is, a move from 64k to 640k felt like something that would last a great deal of time. Well, it didn’t - it took about only 6 years before people started to see that as a real problem.” - Bill Gates, in a 1989 speech on the history of the microcomputer industry
… often misattributed as something to the effect of “640k ought to be more than enough memory for anything”
We need both.
I can appreciate what you’re saying, but did you ignore the rest of my post? Adding more pattern effect command digit columns is going to encroach on screen real-estate, which makes that suggestion just as practical as adding support for 20 more characters. In that case, wouldn’t it make even more sense to do both?
I suppose that we could prepare for the future by allowing users to specify the width in digits of each pattern effect column. That way we’ll never run out of hexadecimal combinations. (This clearly would not work.)
Yes, if we added the extra spaces for another character, like BYTE suggested (xxxyyy as apposed to xxyy), that’ll open up the possibility for 256 different effects (two hex=16 x 16=256, plus the one hex for dsp commands). So there would be no need for the rest of the alphabet for a VERY LONG time.
But even then, we could just add another hex character to jump it up to 4096 possibilities with one hex for dsp command (xxxxyyyy). But lets not get ahead of ourselves.
I really like BYTE’s idea, simple solve.
Lets continue this pattern command extension discussion in other thread, shall we? It is becoming totally off topic in here.
So lets assume we get the pattern command id extension since it is really neccessary and continue from there. Otherwise this whole discussion is pretty pointless, because then only implementation would be altering 9xx behaviour if marker mode is on.
Do we want to automate playback behaviour at marker positions (notecut, noteoff, continue, loops) or keep it fixed? If former, needeth is two commands or dual command and restricted amount of marker points (not with extended command precision), even though I doubt more than 16 would be needed especially if we have 9xx offset coupled with Mxy. Unless they would be used for some bizzarre workaround for some even more bizzarre problem (got any?). If latter, it would be best imho to offset 9xx inside marker range if coupled with M-command, M0 in pan/vol or M00 in command colum for last used. Otherwise 9xx would behave as normal. Just as Johann said.
Your post in that thread focuses too much on your scripting idea for my liking… so I’ve started another thread to discuss the direct implications of the idea I’ve proposed here… but I’ve expanded it to 8 hex chars:
https://forum.renoise.com/t/extend-pattern-effect-to-xxxxyyyy/25127
Not my intention. You are free to drive that into off topic as well. 
Well the first 26 commands still will have a “shortcut” related to the old values and then ofcourse 11 new ones (since G to Z were not defined previous) anything above will then either be a shift+ or control+ combination, but will go at the cost of some existing key shortcuts.
I would not go for a click-select model but rather fastsearch like we have for the plugins. type in the first few letters and have the command in a shorter time than click, list, scroll and select.
Just once more:
Originally nammed as PARENTING, but now renamed as 09XX RENOISE INSTRUMENT
(…this would “combine” all the ways of beat-tracking with the flexibility of [all methods, and] using hitpoints…)
Supported methods including, 1. using drums inside one instrument, 2. using hits via 09XX and 3. the most popular for those interested in sharp editing: Using samples in multiple instruments.
(…Clips can overlap, therefor they can be individually edited…)
(…Clips have their own loop-points, and envelopes…)
(…All hitpoints can have assignable 09XX controls…)
I think it would be simpler to use floating point numbers. You could have the first column be the effect number with a different color and then 4958.556 or something by adding an add button per column, thereby not only providing more resolution but also fairly easy to understand. It would also be useful down the line with OSC and scripting since OSC is all floating point and perhaps we can move into a PD/max like modular environment to make use of the upcoming scripting features. It could also be possible with the minus button for each effect column to “hide” the numbers if it’s large. The point could just be typed in, and would highlight the point on the column instead of it being grey.
You can also kill this bird (amongst many) with this solution since it would provide not only more resolution for timestretching, but also a way to read precicely where you are in the sample. More resolution in hexadecimal just makes your head hurt, and it’s not a n00b thing. We’re simply working FAR beyond the numerical limitations now of why hex was chosen in the first place for the simplest of modern digital audio technique, and that is just the facts.
For nastalgia or simplified notation purposes you could enable it via a easy to find check box in the pattern editor.
Or possibly have an extra column so that effects can be split into “banks” with all of the standard effects in bank 00 and banks 01-FF for future expansion.
eg:
00 09xx gives you the normal Renoise 09xx command
01 09xx gives you the old-school 09xx command
02 09xx could be used for user-defined markers
Or am I just talking crap?
I’d say first get rid of the fake “hexadecimal” restriction because it makes NO sense… not 0-F or 00-FF, 0-Z and 00-ZZ… !
Hex makes perfect sense for data entry (the argument/value) but 0-Z (alphanumeric) would be nice for effect types to open up for future expansion.
Wouldn’t the 255 banks of effect commands in my suggestion be more than enough for future expansion rather than breaking the current system?