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