“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?
Yeah, most probably, but I personally think it would be neater to keep a two digit code for parameter rather than adding more columns. And it wouldn’t break the current system as all old codes would remain the same.
That was the reason I suggested using banks. By default all existing codes would be bank 00, which would be the default if no bank were specified. That way existing patterns shouldn’t be affected. It would also mean that new codes could use a different bank but an existing code if they worked in a similar way to an existing effect, such as the 09xx example above.
[EDIT]
As another example, you could have variations of the pitch and volume slide commands controlling a low-pass filter using bank 01 or a high-pass filter using bank 02. It would also mean you could switch filter type just by changing the bank number.
But that does add extra columns, you even say so in your post about it, which is what would be avoided with alphanumerical and thus why I think it’s a neater solution.
I’d rather have an extra 2-digit column (which could probably be hidden when required) than break the current hex system.
Just because you’ve compressed numbers down to two columns does not really make it too much neater. We used to have screens with super limited resolution, and in the old times they needed to save space. It’s a different story now.
Columns you can hide is better than being limited, and two hex columns is hard to deal with calculating let alone six.
The way the command/argument don’t have to change, since a command and a hexadecimal number is the same as a command and regular numbers. the current effects don’t have to change, they can stay the same and benefit wholly from better resolution while also leaving previous renoise songs unaltered.
Maybe YOU don’t need it, but lots of us do. Many like linking Renoise and Max/PD and/or having more precise control over the samples. They are also prominent members of the Renoise community so it’s probably going to get done anyways.
But you can’t do proper OSC implementation without floating point. When the scripting language comes, it may be faster overall.
You can’t do any of the complex sampling stuff everyone is discussing about linked to the pattern editor without floating point.
Renoise is the ONLY professional program that LETS you program deep this way by the way it works with samples.