seventh-sam
commented
2 years ago Extending this further, we could also define note names. Given that in Reaper CC names and note names are defined in the same file, the plumbing would already be in place.
This would be an incredibly useful and welcome addition to Reaticulate! As you mentioned in the SYN Perc. thread, having to line up specific drum maps with each track is a pain, so streamlining this in addition to pre-configuring the CC names? A feature no one would object to, I'm sure!
CC/note name files are per track. Whereas Reaticulate dynamically generates a single consolidated reabank per project, here it would need to juggle individual dynamically created files per track which is extremely cumbersome.
I think you might've hit upon the answer to this in #41, wherein you mention: "Unless Reaticulate introduces a new class of object altogether that sits apart from the bank." Allow me to clarify:
Instead of defining CC and note names on an articulation map basis, what if they're defined in - as you said above - a separate class altogether? Let's call them Parameter Groups for purposes of this thread.
Most sample libraries (in my experience) are going to use a common set of CCs and note names across many individual libraries. For example, SYN Strings Pro may have different keyswitches for Violins, Violas, Celli, etc., but use the same CCs to control dynamics, expression, and all that good stuff. Therefore, Reaticulate only needs to generate one Parameter Group for the entire group of libraries, meaning only one MIDI note name/CC text file. Unless I'm missing something, it (Reaticulate) would then only need to apply that singular text file on any track that's assigned to it (via the Parameter Group) rather than generate a bunch of text files for each track.
If CC and note name definitions were defined in the reabank file (and later, in the graphical articulation map editor) as a Parameter Group, then said Parameter Group could be assigned to as many Articulation Maps as needed.
The definition of the Parameter Group might look something like this (as per your example):
ParameterGroup 1
//! cc=1 name=Dynamics shortname=Dyn group=Performance
//! cc=7 name=Expression shortname=Expr group=Performance
//! cc=21 name=Vibrato shortname=Vib group=Performance
//! cc=22 name=Close shortname=C group=Microphones
//! cc=23 name=Tree shortname=T group=Microphones
//! cc=24 name=Ambient shortname=A group=Microphones
//! cc=25 name=Outriggers shortname=O group=Microphones
//! note=72 name="High Variant 1"
//! note=74 name="High Variant 2"
//! note=76 name="High Variant 3"
//! note=77 name="High Variant 4"These would essentially be instructions for Reaticulate to generate a MIDI Note Name/CC text file (and, as #41 is implemented, sliders in the GUI). They would then be "attached" to Articulation Maps like so (where p=[] refers to the number assigned to the Parameter Group in the above syntax):
//! g="Vendor/Sample Library Category" n="Sample Library" p=1
//! id=whateveritassigns
Bank * * Sample LibraryIf I'm thinking this through correctly, this means that any track that has an Articulation Map linked to it with an attribute of p=1 will load up and use Parameter Group 1's text file. This would be an optional attribute. If the parameter group's MIDI Note Name/CC file doesn't exist, it would be generated upon being called. Every subsequent call would refer to the already generated text file.
So, if I have, say, 5 separate articulation maps for Violins, Violas, etc. but that all use p=1, then they would only need one text file for five tracks and be able to assign each track to that text file. This should dramatically reduce the amount of files needing to be generated. Unless I'm missing something, of course...
Apologies for the long-winded explanation! What do you think?
As a precursor to #41, there would need to be some means of defining a map of CC numbers to names. The use case in #41 was to present CC sliders in Reaticulate's GUI, but an obvious extension to this is, once we know the CC names, assign that to the MIDI editor on the current track.
Extending this further, we could also define note names. Given that in Reaper CC names and note names are defined in the same file, the plumbing would already be in place.
A couple complications come to mind:
By way of syntax, something like:
Where
ccornoteon a given line will create a new entry. This is different than the current Reaticulate annotations because bank attributes or articulation attributes are terminated by the presence of a bank or program line.shortname, if it's defined, is what's displayed in Reaticulate's GUI (per #41) whilenameis what's used in the CC/note name file passed to Reaper