I have, and I imagine quite a lot of other users also, Renoise set to display line numbers in Hex. Works well for 4/4 and isn’t even too bad for working with 12s (triplets etc.) Thing is, even if you have your pattern set to Hex mode, all the DSP and sync options still display in Decimal. (Or is there another tick-box I haven’t noticed?)
If you have pattern set to Hex notation then I feel LPB, Sample Sync, LFO Frequency, Delay values etc etc should also be displayed in Hexadecimal.
Or would that just confuse other people too much? Especially with a sudden change from one to the other…
That’d possibly be confusing… There’s a lot of precedent for this mixed-mode numerical display - most older synthtrackers with sequence lists used decimal for track numbers. AHX even mixes modes in the sequence list, with decimal for the sequence number and hex for the transpose modifier.
Anyway, that’s a bit of a tangent. I find having decimal and hex alongside one another is a bit like namespacing - it’s a good distinction between two separate conceptual domains. Hex means I’m up to my nuts in patterndata guts. Decimal means I’ve got my hand on the mouse, my pinkie finger sticking out and I’m faffing around all lah-di-dah with newschool DSP. Rare moments of practical clarity and existential confidence ensue!
True but I’d like to be able to go I have a noise and would like the first repeat of the delay to be on, say line 36h, not have to go right that’s 3 times 16 is 48 plus 6 is 54 to get the value. Admittedly not that hard but you know. And if you don’t overly like Hex you can always set the pattern numbers to be decimal and then everything would. I just think it’s weird telling it to display the numbers by the side of the pattern in hexadecimal then every single box/numerical value that corresponds to this is entered in decimal.
Offering hex for things like sample sync shouldn’t be too much of an issue, since it is already based on whole number values, but there are many other parameters such as LFO frequency which depend heavily on fractional amounts like “4.5 LPC” or “33.33 LPC”, etc. I’m curious to hear your thoughts on how those kinds of values would be handled if the method of setting them was purely based on hex, rather than being able to input a decimal value.
Even now, it’s true that if we set the LFO frequency via pattern commands, we are limited to the fairly crude range x500 to x5FF. Due to the slightly odd extremes of the frequency parameter (60000000 LPC to 1.000 LPC) it’s actually impossible to set a perfect value such as 2.000 LPC via pattern commands, since the command x57F maps to 2.008 LPC, while x580 maps to 1.992 LPC. Currently, we can of course input a decimal value directly into the device (or via automation curves) in order to gain the extra precision needed, but how would it work if both the pattern commands and the direct input methods were both represented as hex 00-FF?
Or, hmm… perhaps you simply meant to keep it as a fractional value, but display it as some kind of pseudo-hex? For example, instead of 10.5 LPC it would display 0A.8 ? Hehe… kind of interesting
Don’t forget that the pattern effect command is more or less a deprecated feature from the tracker past and automation is the placeholder for these kind of issues right there.
So i should not attempt to involve pattern effect commands in this relationship. One should not necessarily need to know hex to be able to use Renoise.
Yep. It’s something that Sunjammer and I were discussing the other night actually. We came to the agreement that pattern commands should really be context-sensitive, in more or less the same way that the automation envelopes are handled now, allowing the user to interact with device parameters in a more meaningful way by setting values in their native format.
Have to admit I rarely use fractional values so hadn’t overly thought about the radix point but yes, it would have to work as you say with 0.5dec = 0.8h and 0.333dec = 0.555h (if I have that right.)
Of course it’s not something that would be forced as compulsory to everybody using the hexadecimal Position Number Format but maybe a ticket box for having all pattern-position/lines based values follow the setting used for the above.
If this was made available I’d probably find I’d try it then confuse myself but I do at times already and it just seems weird to offer to display the pattern line numbers in one number system but then have every value that corresponds with them elsewhere in a different one.
Maybe I should petition for Duodecimal (base 12) so we can get nice workings on thirds as well as halves (Joke)
While checking the name of base12 I did see Wikipedia has a lot of fractional hexadecimal values tabled in the hex entry. Could turn out useful if this was introduced.
(Joke)