What's new

Reaticulate - articulation management for REAPER - 0.5.13 now available

By the way, here's my generic template so far, in case anyone wants to adapt it to their own use:


//! g=Strings n=Long
Bank 55 1 Long
//! c=legato i=legato o=@1
1 legato
//! c=long i=note-whole o=@2
2 sustains
//! c=long i=tremolo o=@3
3 tremolo
//! c=long i=trill-maj2 o=@4
4 trills Maj2
//! c=long i=trill-min2 o=@5
5 trills Min2

//! g=Strings n=Short
Bank 55 2 Violins Short
//! c=short-light i=marcato o=@6
6 marcato
//! c=short i=staccato o=@7
7 staccato
//! c=short i=spiccato o=@8
8 spiccato
//! c=short i=pizz o=@9
9 pizzicato
//! c=short i=pizz-bartok o=@10
10 bartok

//! g=Strings n=Sordino
Bank 55 3 Sordino
//! c=legato i=legato-con-sord o=@11
11 legato cs
//! c=long i=con-sord o=@12
12 sustains cs
//! c=long i=tremolo-con-sord o=@13
13 tremolo cs
//! c=short-light i=marcato o=@14
14 marcato cs
//! c=short i=staccato-con-sord o=@15
15 staccato cs
//! c=short i=spiccato-con-sord o=@16
16 spiccato cs


//! g=Strings n=Combinations
Bank 55 4 Combination
//! c=legato i=legato o=@1/@11
17 legato+legato cs
//! c=short i=spiccato o=@8/@16
18 spiccato+spiccato cs
//! c=short i=spiccato o=@7/@8
19 spiccato+staccato
 
Is there any way to connect to Kontakt's ports B, C, and D? And, if so, how would I indicate this?
No, REAPER isn't able to address those ports. For that you would have to leverage something like FlexRouter as an additional layer.
 
For example, you could use note C-2 with 4 different velocities to address the different ports. C-2 velocity 1 for port A, C-2 velocity 2 for port B, etc. You'd need keyswitches in FlexRouter to setup routing like:
  • C-2 vel 1 chan 1 -> [A]1
  • C-2 vel 2 chan 1 -> [B ]1
  • C-2 vel 3 chan 1 -> [C]1
  • C-2 vel 4 chan 1 -> [D]1
  • C-2 vel 1 chan 2 -> [A]2
  • C-2 vel 2 chan 2 -> [B ]2
  • ...
  • C-2 vel 4 chan 16 -> [D]16

Then with Reaticulate, if you wanted to route to D[16], you'd have like:

Code:
//! c=long i=note-whole o=note:0,4@16
120 whatever

Of course that's just one possibility. :)
 
Last edited:
Flattery will get you everywhere.
I can't seem to get OSC to work properly. I've set it at CC 119, but when I hit the "legato" button, for instance, it merely scrolls through the articulations rather than choosing just one. I've tried difference combinations of value ranges, but can't for the life of me make it work beyond scrolling. My brain hurts.
 
I can't seem to get OSC to work properly. I've set it at CC 119, but when I hit the "legato" button, for instance, it merely scrolls through the articulations rather than choosing just one.
It sounds like you assigned CC119 to one of the "Reaticulate_Activate articulation by CC in group <X> on default channel (MIDI CC relative or mousewheel)" actions? This is for scrolling.

Instead you want "Reaticulate_Activate articulation by CC on default channel" (or perhaps "Reaticulate_Activate articulation by CC on channel 01" for example if you want to force channel 1 regardless of which default channel is selected in the Reaticulate GUI). Also ensure it's set to absolute mode.
 
I added the following reabank files to the Reaticulate GitHub issues page:
EastWest - Hollywood Brass Diamond
EastWest - Hollywood Orchestral Woodwinds Diamond
Impact Soundworks - Bravura Scoring Brass
Native Instruments - Session Horns Pro
Native Instruments - Symphony Series Brass Ensemble
Native Instruments - Symphony Series Brass Solo
Native Instruments - Symphony Series String Ensemble
Native Instruments - Symphony Series Woodwind Ensemble
Native Instruments - Symphony Series Woodwind Solo
Orchestral Tools - Metropolis Ark 1
Orchestral Tools - Metropolis Ark 2

Please consider for inclusion in the factory reaticulate.
 
Last edited:
Please consider for inclusion in the factory reaticulate.
Thanks for your work here, Bradley!

Just responding to something you said over on GitHub on the forum here, because I think it may benefit from the wider audience:

I previously used Stephané's Inspector, so I have a fair about of reabank info already saved, it is just a chore to convert non-Spitfire libraries to UACC (clusters, bends, rips + shakes, multi vibrato types, etc.). The GUI editor will be a much welcome addition.
Yeah, I do understand the inconvenience of adapting the program numbers to UACC. Truth be told, I'm having some second thoughts about the suitability of UACC for this purpose. Some form of standardization for the most common articulations is definitely needed, because I put a high value on the "sketching" use-case (where we can quickly switch to the most common types of articulations for sketching and realtime input, and then massage it later with more nuanced articulations), but sifting through all the articulations in UACC for a match is definitely a burden.

So things may change before we hit beta in this regard. (I plan to have things locked for beta and onward, barring major errors.) But don't worry, I'll adapt all submitted factory banks to whatever the new thing is, if I decide at all to change it, so you won't need to go back to the drawing board. :)

My first instinct was to avoid creating a new list of program number assignments for articulations (because this), however:
  • UACC was never really that widely adopted
  • UACC spec hasn't been updated in ages
  • Spitfire itself has a history of failing to adhere to their own standard

The alternative I'm contemplating would be to pick the major 10-15 articulations, assign well-known program numbers for use in Reaticulate factory banks, where the program would include all output events necessary to trigger exactly that articulation (e.g. in CSS the program for long normale would set legato off, con sordino off, switch to sustains, etc.). Outside of these primary articulations, there wouldn't be any further requirements.

The major sketching ones for me would be something like:
  1. legato normale
  2. long normale (chords)
  3. long muted (e.g. con sordino)
  4. long soft (e.g. flautando, or sul tasto)
  5. long hard (e.g. marcato)
  6. long harmonics
  7. tremolo/flutter
  8. measured tremolo
  9. short (e.g. staccato)
  10. shorter (e.g. spiccato or staccatissimo)
  11. short hard (e.g. staccato digs or marcato shorts)
  12. pizzicato
  13. trill m2
  14. trill M2
The ones in purple I'm on the fence about, while the ones in red I see as non-negotiable (if applicable to the instrument).

I'd be interested to hear from others here about what they see as the essential general articulations for sketching out an idea (across any instrument, really).

Again, the idea for this use-case would be that you have easy access to these articulations (e.g. via a control surface for quick activation), which will work on any track regardless of instrument, to quickly record an idea, and then go back over later to tweak things to more specialized articulations if necessary.
 
Also @bradleybboone as someone who's used Stephane's inspector, I'd be curious to know if there's any important articulation related functionality you used his project that's missing from Reaticulate?
 
As usual, fantastic work tack! Brings me even closer to finally saying goodbye to Cubase. :)

If I may already bring up a feature request: I'd love it, if the interface of Reaticulate would be freely adjustable. What I mean by that is, that you'd be able to set a table with a specific number of rows and columns, and then drag around the articulations to whatever cell you like.

The reason for this is, that this way you could eliminate the need for complicated Lemur setups, and just hook up a touchscreen to your computer and then have your articulations on there (or use a screensharing app with your iPad). And being able to set the type of table and placing the articulations would allow for some organization of the patches (for example, in my current Cubase setup I have a table with 4 columns, where Column 1 is dedicated to long articulations (Legato, Sustain, Tremolo, etc), Column 2 is dedicated to Shorts (Spiccato, Pizzicato,...), Column 3 to Dynamics (Crescendi, Diminuendos,...) and Column 4 for all types of FX and 'unusal' articulations).
Just a thought. :)
 
@tack Thanks for the follow up on both boards. New poster here (I just lurk), but I love the different approaches people take to expanding the functionality of Reaper. I've only been working with Reaticulate for about a week, and am quite pleased!

1. I appreciate the desire to keep a sketch-ready standard (possibly modeled on UACC), and I will think further about the list of articulations you mentioned. There is just so much variability in sample mappings and styles that it may be a tough hill to climb.

2. Regarding Inspector by Stephané, it is a wonderful script (I have also used your FlexRouter, Blake Robinson's BRSO Articulate, & numerous scripts by David Healey). I like the following features in Inspector:
-adding/deleting "scenes" to the Piano Roll Editor (to show and hide unwanted midi controller lanes)
-horizontal page scroll for larger articulation lists
-easy access to track functions (color track, arm, monitor, height, etc.)
That said, none of these capabilities are deal breakers for me.
 
My current wish list for Reaticulate (other than whatever native articulation mapping is coming from the Reaper developers) is:
-a GUI for reabank creation and assigning banks
-More documentation/explanation of midi routing and CC chasing cases (the reaticulate.com site is a great introduction, and the ability to read through your factory reabank file answered many of my routing questions)
-CC range switching (utilized in many of my libraries), not necessary because they can all be used with standard keyswitches as well
 
If I may already bring up a feature request: I'd love it, if the interface of Reaticulate would be freely adjustable. What I mean by that is, that you'd be able to set a table with a specific number of rows and columns, and then drag around the articulations to whatever cell you like.
It's an interesting idea. A significant amount of work though, just in the UI alone. Perhaps worth considering this kind of thing once the basic capabilities are ironed out.

It'd also require a completely new strategy for maintaining track-specific data. Right now I'm restricted to a fairly small amount of data because I'm leveraging FX parameters (sliders) in the Reaticulate JSFX, and there's a limit on the amount of data that can be stored that way (192 bytes, specifically).

I think it's probably worth exploring an alternative, as there are other features that would need to be able to persist more than that at the track level. I have an idea on that, though.

Thanks for the feedback!
 
-adding/deleting "scenes" to the Piano Roll Editor (to show and hide unwanted midi controller lanes)
I use SWS's CC lane slots with various custom buttons in the MIDI Editor toolbar for this. I could see an argument for integrating this into Reaticulate, especially when also combined with custom note/CC name lists.

-horizontal page scroll for larger articulation lists
From your perspective, what are the benefits for horizontal page scroll versus vertical scrolling currently used by Reaticulate?

-easy access to track functions (color track, arm, monitor, height, etc.)
I think as there are already other mechanisms to make these things easily accessible (via the various native or SWS actions), I don't personally feel a strong itch to scratch in those areas. But if enough users ask for it, I'd definitely consider it.

-a GUI for reabank creation and assigning banks
Yep, it's definitely a big ticket item before the first beta (tracked here). Hoping to work on it during the Christmas break. We'll see how that goes. :)

-More documentation/explanation of midi routing and CC chasing cases (the reaticulate.com site is a great introduction, and the ability to read through your factory reabank file answered many of my routing questions)
Do you remember some of the initial questions or confusions you had? I'd certainly like to make sure they're answered in the documentation. As the author I'm really rather too close to it all and it's sometimes hard to anticipate where the main areas of confusion will be.

-CC range switching (utilized in many of my libraries), not necessary because they can all be used with standard keyswitches as well
Of course we can already trigger articulations in libraries that use CC ranges just by sending a single CC value anywhere in the range.

The aspect where support for ranges make sense is for manually triggering by CC. Or by note velocity range, as it's the same principle. Taking this example from CSS:

Code:
//! c=short i=spiccato o=note:17,1
42 spiccato
//! c=short i=spiccato o=note:17,33
41 staccatissimo
//! c=short i=staccato o=note:17,65
40 staccato
//! c=short i=sfz o=note:17,127
54 sfz

Here CSS will activate the articulations so long as we're anywhere in the range 1-32, 33-64, 65-96, 97-127. As it is with the above bank, although the articulations will activate fine, it's not compatible with manually triggering the articulation by keyswitch since right now Reaticulate requires exactly the right velocity to detect the user actually manually activated it. I'll definitely be adding the capability for CC range and velocity range soon. (Tracked here.)

Is that what you meant?
 
From your perspective, what are the benefits for horizontal page scroll versus vertical scrolling currently used by Reaticulate?
The vertical scrolling in Reaticulate is great. I used horizontal scrolling in Inspector when it was un-docked or with very large (percussion) patches. +1 for discovering I can scale the Reaticulate UI with CTRL+MouseWheel (which wasn't possible in Inspector). The only thing I could see gained is freezing the bank name at the top of the menu, which may be helpful for some people who use multiple libraries with the same articulation names.
Do you remember some of the initial questions or confusions you had? I'd certainly like to make sure they're answered in the documentation. As the author I'm really rather too close to it all and it's sometimes hard to anticipate where the main areas of confusion will be.
General initial questions:
-how to clone banks (I learned from scanning the reaticulate-factory, but did not apply it to my submitted reabanks)
-the significance/use cases of the g= attribute in the program line
-should I create banks that combine all articulations with complex channel routing, or just add banks (see below for a simple scenario)
Code:
//! g="Developer/Library" n="Flute COMBI"
Bank 20 1 Flute COMBI
//! c=long i=note-whole o=note:24
1 sustain
//! c=long i=vibrato o=note:25
16 vibrato
//! c=legato i=legato o=@2
20 legato
vs
Code:
//! g="Developer/Library" n="Flute Sustain"
Bank 20 1 Flute Sustain
//! c=long i=note-whole o=note:24
1 sustain
//! c=long i=vibrato o=note:25
16 vibrato

//! g="Developer/Library" n="Flute Legato"
Bank 20 2 Flute Legato
//! c=legato i=legato o=@2
20 legato
 
Top Bottom