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.
Floating point is a completely different matter all together and anything that helps Renoise communicate with OSC is obviously a good thing.
At the end of the day we all agree we would like to see it expanded in some way in the future. Hopefully the board occasionally helps give the developers the insight into how to make something work.
???
effect id’s are entirely separate from values…
LOL! we used to store modules in binary files, so the effect numbers were limited to 0-F… now we’re storing modules in .xml files 
what are you talking about???
xxxx yyyy
x = effect id
y = value
you never add or subtract effect id’s, so the whole talk about breaking hex or anything being harder to calculate confuses me to be honest… again: effect id’s are entirely separate from values…
instead of
00 9xx (normal offset command)
01 9xx (sample markers)
I’d rather have
9xx (normal offset command)
Mxx (sample markers)
there’s actually trackers that have this, you know. and guess what, they haven’t broken the hex, nowhere near haha. wtf…
that you can hide the column is… uhhh… not a good argument… then you might as well hide the effect colum because without the “bank” column you have no idea what the effects actually are… uhm…
That’s what I was saying. Whether it is in hex, or regular numbers it don’t matter since it’s only the values that would change at all at any time. You could switch between the two by a checkbox if you wanted to. Of course hex can be notated in floating point as well. It would be preferable to work in numbers past 1500. 99999999 max (8 numerical columns) would be way preferable… That would take many columns, which is why you would need to hide them and to calculate hex values in that notation could take twice as long as the song being written…
Anything anyone else says to hate on it is really just being a douchebag and saying “hex is better because it’s harder and I want to be better than ___ because I take two more minutes to calculate a value” or “I want it to keep limited to two value columns because timestretching/beatslicing is for idiots who can’t write music and I like to keep my samples all down to less than 128 kilobytes.”
Amongst other things that though may not be said, really are what is thought. Out of my experience, I’ve seen this multiple times. It’s usually for a decent reason, but it’s totally misguided. At the same time you don’t want to have the “kiddies” get your software and be able to use it in droves to make crap music (since crap tracker music isn’t even worth listening to over say crap fruityloops music) you’re putting ideas in peoples heads to limit things.
Sometimes the limitations are fun, for anything serious you don’t want built in limitations. I would never try to use a NES tracker to create a commercial album, but I don’t mind using NES trackers. I don’t mind using two column hex, but there’s much much more you can do with extended resolution and with coming technology that renoise is going to see it’s going to be needed anyways for the REAL values a scripting language or better timestretching or anything else that needs tons of values for represenation.
Have you ever tried to remove some space from a 09xx command-applied sample while trying to preserve the audible offsets in the song? result: It is horribly tedious! You will have to check ALL 09xx commands 
that are applied to that sample.
This could be solved by referring to markers instead. Resulting in a central point where the offsets are defined, namely the sample editor. It is way more subtle…
Man, I love the original post. Thanks!
A simple ‘find replace / masked edit’ feature would have solved the above too, but I’ll stop harping on about that 
I would really like the ‘Mxx’ idea to be implemented, simple and easier to remember (particularly if you’re coming back to an old, unfinished tune). I’m guessing that the next logical step would be to improve the RNI structure and allow for layering and lots more, probably more wishfulthinking. 
I think it would be great if people would see what this is (and should be leading to) is an engine that has all the similar features of a Beatslicer.
I know that is what makes one called a heretic on these forums if that word is said out aloud, since some people actually think that is not an innovative feature - but the fact is that it is, and it could be incorporated pretty easily with the 09XX concept. They would work well side by side and all users of Renoise would benefit.
Those wishing for a more accurate 09XX algorithm / approach to the concept, and those making beats the traditional way using multiple samples that are sliced (aswell as those using drumkits inside instruments)
…so why not simply approach this from a Beatslicer viewpoint?
To benefit us all 
All trackerers just need to get abit out of their [“tracker=I do all with sinewavesounds”] egos first and think of the practicality.
I wouldn’t be surprised if with 2.6 and scripting, some kind of beatslicer will be present / possible.
Plusplus. This would be dreamy… to just move those markers back and forth…even automate them. Wow. Together with higher effect resolution would be even dreamier.
I thought I would quote this here
just checked out slicex (never heard about it before) and that is a really good approximation of what I imagined it would be like in Renoise. When I think if it had AHDSR envelope, sample start, and routing/processing for each individual slice… and they were all automatable…