I don’t think it is as much that as that it’s an inheritance of older trackers that had 8 bit values. From 1987 with the first Amiga tracker (soundtracker) they used 8 bit columns because while the computers were 16 bit the samples and pretty much everything else still had 8 bits of resolution, and usually you had to limit sample sizes to 1 megabyte or less.
MIDI also only has 7 bits of resolution. It’s not just a problem with Renoise. Roli is trying to rectify this with MIDI 2.0 and we’ll see how far they get. Honestly, OSC is better supported and has a wide ecosystem around it already. Pd, Max, CSound, Monomes, Expert Sleepers’ Silent Way, etc have already adopted it.
I really highly doubt “saving screen space” was high on the list. It’s more like old traditions die hard.
As I said before, I think there are only 2 compelling reasons why Renoise continues with 2 digits: maintain easy compatibility with previous software (such as the Impulse Tracker format, for example) and take up less screen space.
We can talk about older software of the 90s. But Renoise has had a lot of time to evolve, and he still uses the hexadecimal system to represent it on the screen (2 digits). There must be a reason.
In the past, it was also a great advantage to use only 2 digits, precisely because the screen resolution was small. You could see more information in less space. Increasing the number of values in less space were two advantages. Not only is the programming (numbers) but the way to represent it for a human to see.
Obviously, Renoise is another tracker that inherits this notation, precisely based on NoiseTrekker, has an origin. The question is simple. Why is it maintained? I know that compatibility with old things has a lot of weight. Renoise is tied to the past. Breaking this union will be expensive, because the software base is already done.
It seems silly but changing the range from 000 to 999 for the instrument box means changing many things. Above all that has to do with optimization and performance. Perhaps in other things under the hood it is not so complicated. After all, we are just talking about numbers.
maintain easy compatibility with previous software (such as the Impulse Tracker format, for example) and take up less screen space.
You could theoretically still keep compatible for playback with 16 bits. Even easier than what you propose. For example, 0x0080 becomes 0x8000. On a computer science level, it’s a clean conversion and in a lot of cases a relatively small code change. You can also drop the high bits if you want.
Obviously, Renoise is another tracker that inherits this notation, precisely based on NoiseTrekker, has an origin. The question is simple. Why is it maintained? I know that compatibility with old things has a lot of weight.
When NoiseTrekker was made (and other trackers) we barely was able to do 16 bit audio in computers at all, and the control chips (ie like for volume) were in many cases still 8 bit. 16 bit ADDA conversion and memory was stupid expensive. It wasn’t until the last decade have we seen the drift away from 8 bit for good because 16 bits hardware is now cheap and practically the standard for all control and playback systems from the EE level industrial systems to digital audio… And good riddance.
This is literally what was happening when Noisetrekker was around. Your run of the mill 16 bit soundblaster live cost 99 dollars… 24 bit anything was coming out in pro audio and cost thousands of dollars for eight channels…
I believe it’s maintained mostly because MIDI. Even some plugins don’t take advantage of anything past MIDI and don’t use the full 32 bits floating point automation. They should, you really really hurt the sound and accuracy of your music (a 20hz-20khz filter sweep is impossible with MIDI without hacks and the filters as a result will always be an inaccurate interpolated mess) but they don’t.
How about banks of up to 256 instruments assignable to tracks. Nothing in the patter editor would change aside from the track name (Drums:Track 1). This would also provide the benefit of grouping similar instruments.
I think the best way is to classify the instruments into groups without affecting their use.
The logical step would be to increase the 00-FE range to the new 000-999 (decimal) range. Increase to 3 digits, and that each instrument can be used on any track. This only implies two things:
Increase capacity (number). This does not affect performance, but performance (more indexes, more data to update if the list is moved).
To be able to classify them by groups in the instrument box (by folders or labels of a level, at least). In the sequence there is something similar. This should not affect the index of the instrument, and should allow you to select several and drag and drop.
But compatibility with the old format is broken. It should be 3 digits in hexadecimal.
The index is the way to “call the instrument”. It must be possible to work on all tracks.
The operation would be very simple. You select several instruments, right click, create group. Magically a folder appears above or a label. All instruments will retain the same index. Even the labels could be colored. In this way it is even possible to relate them to the tracks indirectly. It is the easiest to add.
All this in case you would like to implement, which I doubt very much, and it is not precisely for using 2 or 3 digits. Here, the MIDI theme has nothing to do with it either.
For that, Renoise’s main programmer should take time and implement it seriously. At least the classification of instruments. If he hasn’t done it yet with 254 instruments, it may be due to a performance problem. Imagine with 1000 instruments.
More related details … An instrument can have more than 1000 samples in hexadecimal. That is more than 4096 samples in decimal. Here, hexadecimal notation is also used, probably to occupy fewer digits, although it doesn’t matter here.
It seems logical to think that the most suitable solution for instruments box is to change to 3 digits in hexadecimal, following the coherence. There is no more history here.
However, there is a contradiction or inconsistency with hexadecimal notation. In the MIDI Mapping window, the instruments are numbered in decimal. This is confusing and incoherent:
Instr. 01
Instr. 02
…
Instr. 09
Instr. 10
…
If the indexes of each instrument are called in hexadecimal inside the instruments box, do not change them to decimal. This is probably an oversight or forgetfulness.
On the other hand, the tracks use decimal notation. It doesn’t matter if the name takes up more space.
Again, it’s far more simple and effective to use 4 digits instead of 3. Computers are much, much faster at power of twos (hexadecimal and binary) than they are at all the dividing and multiplying you’ll have to do. Additionally, you’d have to completely rewrite Renoise do do this, when my way would simply be changing uint8s to uint16s or uint32s. There is no such thing as a data type that goes from 1-1000. Sorry.
Surely you are thinking about something else, not this thread. Maybe in the sub-column of effects or things related to MIDI, to have more resolution, but not in the instrument slots. It is not really a matter of numbers, but what limit you put for each thing to make it governable.
For the instrument box and the instrument sub-column of the pattern editor (and elsewhere), that the index is 4 digits is barbaric and unnecessary. This should only be added where necessary. Here is not the case.
Nobody is going to use more than 1000 instruments, not even more than 500, because that ecosystem is practically uncontrollable by the composer. With 3 digits in hexadecimal 4096 values would be reached (they are still 3 digits). It is practically without limits. But changing this does not depend on the index itself, but on the design of how that index is used to relate data between the patterns and each instrument.
If you refer to the sub-column of effects, Renoise actually already exceeds the MIDI capability of the range of 0 to 127 values of the knobs or knobs of limited travel (with upper and lower limit). Renoise uses the range of 0 to 255 in many things, twice the MIDI capacity, that is, it will ignore half of the values in limited-path controls.
If you also increase the MIDI ability to be able to change a greater range in limited-path controls, it is the command itself that does not have sufficient resolution. That is, I would jump. Here the only really interesting are the infinite spin knobs (without limits). It’s not just the MIDI standard and how it works. The hardware also has its limitations. For example, for a knob to have a higher resolution, it would be necessary to increase its physical size. All the knobs you see in the market are very very small wheels.
To use 4 digits there would be no choice but to do it 2 + 2, and control 2 columns of 2 + 2 digits. For live recording it would be an odyssey.
Not only would you have to use a 16 bit or 32 bit value in the background code to represent 1000 instruments, you’re holding yourself back from simply providing the full amount.
The Renoise code probably uses uint8s for everything (in fact I’m almost sure it does cuz I remember seeing some noisetrekker code at some point I think) and this is where the limitation lies.
Renoise uses what is necessary or what the programmer has estimated as sufficient. For example, for the effect parameters it is possible to use uint16s, with their range from 0 to 65535 values.
Renoise can use a much higher range and be limited to a much lower range if you need a limit on something concrete.
What I have tried to comment in previous comments (apart from the limitations of the hardware itself and standards such as MIDI) is that using more quantity can be a performance problem, as it is designed now, I suppose that by the way of accessing the data tables to manipulate them. With 254 instruments and 1000 Renoise patterns it goes very fair. Start filling the patterns with data (notes with the instrument index) and then continue adding more instruments. You will see that you will resent each time you have to update the pattern data by adding a new index in the instrument table. This is probably the reason for which the instrument box is not improved, because it would probably involve changing the way this is handled.
