As you know, I am in charge of maintaining this tool. For those interested and followers of this tool, at the end of January I plan to launch the next version of the PRE, version 8.
This version will bring interesting additions to control and play multiple instruments at once from the same piano MIDI controller (or several), deepening the piano division in up to 16 parts with 15 cuts, each part capable of being transposed on the fly (one important news), all integrated into the ChordBuilder, which is probably one of the best tools that exist today for Renoise related to shooting/stopping notes.
ChordBuilder is capable of firing up to 7 notes at a time from a single key, configurable between a range of 4 octaves. This is useful for firing chords, but also for setting up complex drum kits. In addition, it allows you to save forever the settings of the custom chord or group of notes to shoot, with up to 120 chord slots / groups of notes per bank, offering up to 99 banks that can be changed on the fly.
Another interesting addition is the ability to mute the ChordBuilder’s pads to be able to change the shot firing chords while playing from a piano (the pads will not sound and therefore will not record notes, but will change the chord). This is tremendously useful for live performance or recording even for 2 or 3 users.
If you have a piano MIDI controller (or several) and want to do more with it, I recommend you at least try the PRE, especially the new version 8 that is to come and everything that has to do with the ChordBuilder.
Another addition, finally, is the ability to load MIDI mapping files prepared for the PRE into new projects, focused on mapping all virtual pianos with one click (the superior mirror piano and lower virtual piano, as well as the 120 pads of the Chordbuilder). This topic has always been annoying (having to map many controls to create an XRNM file to save later). With the new version of the PRE, the whole theme of MIDI mapping is much more direct. Unfortunately, the API does not allow loading an XRNM file without first deleting all the MIDI mapping that the song could already have. From my point of view, this is a design error.
Users who do not understand programming, it is good that know that programmers can not do everything they want, because the API is “limited.” I have received some requests in private that I cannot attend due to this reason. Here is an example:
-- Load/save all global MIDI mappings in the song into a XRNM file.
-- Returns true when loading/saving succeeded, else false and the error_message.
renoise.song():load_midi_mappings(filename)
-> [boolean, error_message or nil]
This code removes the existing mapping and then adds the mapping of the filename. @taktik, if you read this, I think that the operation renoise.song():load_midi_mappings(filename) should be modified only by adding the mapping of the filename, retaining as much as possible of the existing mapping. That is, do not erase the existing mapping, just overwrite what is necessary.
If the programmer wishes to eliminate the existing mapping before, it has the following code:
-- clear all MIDI mappings in the song
renoise.song():clear_midi_mappings()
It would only be necessary to stack it like this (in the case of changing the load_midi_mapping):
local function load_midi_map()
renoise.song():clear_midi_mappings()
renoise.song():load_midi_mappings("folder/file.xrnm")
end
If it is not possible to change the behavior of load_midi_mapping, it would be appropriate to add a new one, like this:
-- Overwrite all global MIDI mappings in the song into a XRNM file, preserving the existing mapping as much as possible.
-- Returns true when overwrite succeeded, else false and the error_message.
renoise.song():overwrite_midi_mappings(filename)
-> [boolean, error_message or nil]
Solving this would allow you to add or change portions of MIDI mapping in the middle of the project (without losing the existing mapping).