Raul (ulneiz)Raul Not change but override. For ex: c-4 10 M9 (note, instrument, pan) could send note to midi channel 9 with new pan command ‘M’ regardless of channel assignment in the instrument editor. Without the command, instrument would behave the same way it does now. This way you can trigger notes on all 16 midi channels of a plugin that occupies only one instrument slot.
Raul (ulneiz)Raul I’m not familiar with vst development. I think vst instrument plugins behave like any other midi instrument. There is no assignment of midi channels, you simply send each note with midi channel.
Ok, this behavior could also be resolved by changing the MIDI channel through the command and retrieving the original channel, through a tool. At least I think I’ve understood you.
I am sure that this can be done reliably with a tool with not very fast reproduction, perhaps below BPM 200, LPB8, 37ms per line (that the reading of each line does not exceed 10ms approx.).
However, like any tool of this type, this would be better if it were under the hood of Renoise. It remains to be known if the movement of the MIDI channels influences the real-time reproduction of the notes, probably not.
Raul (ulneiz)Raul I am talking about instruments, not plugins. One Kontakt plugin port can hold 16 midi accessible instruments. Renoise instruments are the 256 instrument slots. Plugins can hold way more instruments than can be assigned with Renoise. That’s the problem.
Raul (ulneiz)Raul There is no such thing as midi channel assignment in the midi world. Note on and note off is send with midi channel. Assigning Renoise instruments to midi channels is simply there to organize your instruments.
When sending notes to a device or a plugin, there is no assigning or changing of midi channel. ALL midi messages go out or in with midi channel information. In other words, you can send any combination of notes and midi channels to a plugin. That is what happens when you use instrument aliases.
The exact direction of the signal is this:
[instrument, index 0 to FE, 254 instruments] --> [plugin properties, kontakt] --> [channel midi 1 to 16]
You would have exactly one instance of kontakt for each instrument. That’s 254 instances of Kontakt. For each instance of Kontakt, you would have 16 assignable midi channels. That’s 4064 assignments, controllable with an effect parameter that changes the MIDI channel in the instrument properties from the pattern editor.
Technically, there seems to be no problem for several notes to sound, including the same repeated note for several MIDI assignments of the same instrument.
Although I have not built it, I know that it works using a tool. And as this is possible, it is easily feasible under the hood of Reniose. And it is true, it would not be difficult to implement it.
You get however many vst instrument plugins Renosie can load * 16. I never reached the limit of plugins. I’ve reach the limit of midi instruments.
If you think so, we can write the tool code, just to try.
If this works correctly with slow reproduction, we could formally contact @taktik to he study it. I think it is an excellent idea that should be implemented.
Related documentation
-- Valid for loaded and unloaded plugins.
renoise.song().instruments[].plugin_properties.channel, _observable --> [number, 1-16]
renoise.song().patterns[].tracks[].lines[].note_columns[].effect_number_string --> [string, '00' - 'ZZ']
renoise.song().patterns[].tracks[].lines[].note_columns[].effect_amount_value --> [int, 0-255]A feasible option CH01 to CH16:
- .effect_number_string = “CH”
- .effect_amount_value = 01 – to 16
It seems that with a tool, it is only possible to assign a MIDI channel per note. That is, you cannot change the MIDI channel between two notes of the same instrument at exactly the same time:
On the other hand, the difficulty would be in analyzing the parameter in each line of all the tracks. This would be very slow.
At least it can be quickly tested by analyzing a single track.
For this to work properly under the hood, it is necessary that each note can be assigned to any midi channel, even if the note is played exactly on the same line repeatedly, and that note is assigned to different MIDI channels, something that is not possible with a tool It is not as simple as changing the MIDI channel in the “on the fly” instrument properties.
This scenario should be possible:
…
For a tool, perhaps the simplest is to link the “properties.chanel” property to the macro 1 of the instrument, using the _observable of macro 1 (range: 1 to 16). Then use the “Instr. Macros” Meta to use native parameters in the pattern editor. This would allow changing the MIDI channel of the instrument in each line, at least. Just to try.
I found a workaround. Programs in Kontakt banks of 128 instruments can be switched using the M2 fx command. However, having more instrument slots in Renoise would be more straightforward.
There are many VSTi not compatible with the Renoise program change, including Kontakt content.
The idea of changing the MIDI channel for each note is great.
Sure. That kind of command should be there.
Kontakt banks are great. You can categorize your instruments into banks and load instruments with midi program change from the pattern editor without clogging up memory. It’s too bad that the plugin’s tab in Renoise doesn’t have program change setting.
Yes, you’re right, nothing in Renoise is focused to use more than 2 digits in hexadecimal. But if integrated (two colors), it would not be a bad option, because it would allow keeping the 2 digits in hexadecimal. In fact, as Renoise is conceived, it would be far fetched to add 3 digits, since nothing in Renoise goes with 3 digits of number in the pattern editor. If this is possible, the following would be to add 3 digits in the amount of the sub-column of effects, and so on.
I’ve said it before and I’ll say it again. The BIGGEST limitation in Renoise right now is the lack of 16 bit (at minimum) control schema. When you start to get into OSC messages and vsts with 32 bit automation you begin to have lots of problems and you can’t do accurate automation in the pattern editor. You have to use automation curves in the automation window to get around those limitations… At least 16 bits of resolution is only a couple more digits in the columns, doing that they’d get rid of 50% of the gripes people have I think.
Rather it is the effort to use the hexadecimal system to represent numbers, specifically 2 characters, to occupy very little space, following the vices of the old trackers, when the image monitors had a very low resolution, and it was easier to control that amount of data, it was a good idea to keep the compacted data on the screen to be able to display more information at the same time.
It has always been a design problem that has to do with space. When I have made this comment, I always think about the same. Renoise “is tied” to a code base, whose mentality today is obsolete. Currently, if a serious programmer wanted to build a new tracker, he should not use the hexadecimal system. He would have to break that “two-digit” barrier.
But this contains many backward compatibility (of other software) problems that are not mentioned here. Renoise is compatible with “antigos” formats, because it maintains the hexadecimal system. Changing all that is a step that you have to think very well. But it is clear that here exist the evolution of the program. Probably, this could also be solved, with data conversion when loading a song format, for example. But it is another existing issue.
In other words, if Renoise stays 20 more years, one day he must leave the hexadecimal system and jump to more digits, to have more capacity, and thus go along with modern hardware, and not rely on the past.
To see it with perspective. With 8 bits you can represent 2^8 = 256 characters. Only with 16 bits you have 2^16 = 65536 characters. The limits would be set by the programmer, not the number of bits.
The only thing that proves impact on the user is that the information would take up more screen space, nothing more. The rest is programming.
Currently, Renoise has evolved with HIDPI compatibility, which is a hardware obligation. The same could happen with the abandonment of the hexadecimal system.
If someone knows a tracker that does not use the hexadecimal system, that is, that is based on the decimal system, put a link here, please.
I don’t know of such a tracker, other than the option of showing lines in decimal which is possible in several.
Having to hit the arrow keys too much is a big nuisance to me. One of the main points of trackers is that it’s quick to navigate and enter values. Already, the four digits of the effect column kind of annoys me, motorically.
Maybe if it was optional…
Well the hexadecimal system is NOT limited to 8 bits.
There are plenty of buzz modules that support 16 bit values in their pattern editors.
65536 is a nice number, it allows you enough resolution for sample accuracy, ie moving through a sample offset or changing an efx paramater, and I don’t think anyone will ever use anything past 65536 instruments.
In addition, like I said it will only take two more digits in the fx column.
But it is used to keep 2 digits and get more quantity, not limited to only 100 (from 00 to 99), but from 00 to FF (255).
Yes, the hexadecimal system with 3 characters could be used, for example. But would this really be necessary, when you already reach a range of 000 to 999? The amount of 1000 seems sufficient for most things. If in some cases a greater range is needed, then there are the 3 digits in hexadecimal.
For this thread, I think 1000 instruments would be much more than enough. But a successful classification system of the instruments would be necessary to be able to group them and classify them by types. With a lot of instruments, it would be difficult to manage if there is no decent classification system, and I think this would not work very fine at the moment, for another matter that I have already mentioned before.
Can you imagine being able to select several instruments and drag them into a folder to classify them, all from the instrument box? Why doesn’t this work like this?
But it is used to keep 2 digits and get more quantity, not limited to only 100 (from 00 to 99), but from 00 to FF
Nonsense. 16 bit hexadecimal was commonplace even before the first Amiga trackers. There is even 32 bits and 64 bits hexadecimal but it’s more rarely used cuz C became commonplace by then and while that does support hex, it’ll do decimal fine…
In Renoise hexadecimal numbering is used “to keep the 2 digits” and get 155 more values. Does this seem nonsense to you?
It does not seem a problem of quantity, or of using more bits or less, or what was done in the past or now. If it was decided to choose hexadecimal numbering, it is because of the “nonsense” of maintaining 2 digits, which take up less space on the screen (less millimeters), and as Joule says, it is even faster to handle / change than 3 digits, considering that 255 Values is enough for software like this, for most things. 255 is much greater than 100.
It is a matter of representation. In fact, under the hood of Renoise the decimal numbering is used as the basis for practically everything (and there are no limits here), then it is converted to hexadecimal to represent it on the screen (tracker), converting the values from decimal to hexadecimal. At least that’s how I understand it.
It is simply a matter of space. If you use 3 digits for automation parameters in the pattern editor, you have many more values.
Here is the difference of using two-digit automation parameters in the pattern editor, or using automation points in the automation editor, which according to the parameter, use a range or another of values (another resolution larger).
Do you need more resolution? Well there will be more numbers taking up more screen space.