an articulation management system for REAPER
July 2, 2018
After a longer-than-expected development cycle, I’m happy to release the next alpha version of Reaticulate.
I’m hoping the next major release will be beta worthy. The main release criteria for beta is a GUI editor for creating and modifying banks.
Important note: this version requires reinstallation with a new ReaPack URL.
Unfortunately due to significant backward-incompatible changes in the ReaPack structure, upgrading requires uninstalling the old version and installing the new one.
I did warn you this was alpha software, right? :)
Follow these steps to uninstall the old version:
Extensions | ReaPack | Manage Repositories
And now follow the installation instructions.
Reaticulate itself is fully backward compatible with the previous version, so all your existing projects will work with the new version. However, the old version is not forward compatible with this new version, so projects saved with Reaticulate 0.2.0 will not function properly in Reaticulate 0.1.0.
It’s a good idea to save backups of your projects before resaving with Reaticulate 0.2.0 just in case you find yourself needing to downgrade to Reaticulate 0.1.0.
This will be generally true of all releases (i.e. backward compatible but not forward compatible).
If you do realtime performance of your MIDI CCs using a control surface that supports incoming feedback, such as a MIDI Fighter Twister or iCON Platform-M, it’s possible to have Reaticulate-managed tracks sync their current CCs back to the control surface, either on track select or during playback.
There are some new actions to control this behaviour, including to enable or disable it, or to do a one-time dump of current CCs to the control surface.
See the Usage page for more details.
One of the most requested features was the ability to insert program change events in MIDI items without the need to open the MIDI editor and enable step input. This is now possible by right clicking an articulation in the list.
Banks in the track configuration page can now be reordered via drag and drop (depicted right) rather than the cumbersome up/down buttons in the previous release.
The Settings Page now has an option to autostart Reaticulate when Reaper starts. This works by
modifying Reaper’s special
__startup.lua script to invoke the
There are a few other little odds and ends improving usability. For example, if the Reaticulate UI panel has focus and the spacebar is hit, it will toggle transport play/pause and move focus back to the arrange view (or MIDI editor if it’s open). Unfortunately there’s no way to solve this problem in a general sense (passthrough keystrokes to the arrange window) but play/pause was the single biggest workflow killer for me, so hopefully you find it helpful too.
All these new features described below are fully documented on the Bank Files page.
There’s a new output event type
art which allows articulations to be chained. Consider the
//! c=long i=note-whole o=art:3/art:19/art:2 1 all-in-one long //! c=long i=note-whole o=note:12 3 sustain //! c=legato i=legato g=2 o=note:22,65 20 legato on //! c=legato i=note-whole g=2 o=note:22,1 19 legato off //! c=long-light i=con-sord g=3 o=note:23,65 7 con sordino //! c=long-light i=note-whole g=3 o=note:23,1 2 senza sordino
This bank models a patch that has separate keyswitches for legato on/off and con sord on/off, which are placed in different groups. You can activate them independently, but the all-in-one long on program 1 references the other articulations to provide a convenient, er, all-in-one articulation.
When you activate it, the GUI will automatically update to reflect the legato and sordino states.
Previously, if Reaticulate observed any CC then it would chase it. This ended up doing frustrating things, such as zeroing out CC 7 (volume) at unexpected times.
Now banks can specify which CCs should be chased. The factory banks have been updated accordingly. And now by default, unless a bank specifies a CC list, only CCs 1,2,11,64-69 will be chased.
Sometimes you just want an articulation to fire a MIDI event to a specific channel but not have future non-articulation events get routed to that channel.
This is now possible by prefixing the output event type with a
-. For example:
- prefix in the first note output event tells Reaticlate not to setup routing of
future events to channel 13. Meanwhile, because the second note output event isn’t so prefixed,
subsequent events will get sent to channel 10.
It’s now possible to have output events emit only if another articulation is active. We call this a filter program and it requires that the filter program be activated in another group on the same channel, otherwise the output event will be filtered (i.e. not emitted).
This allows articulations to be contextual based on articulations in other groups.
Filter programs are optional, and are specified by appending
[%program] to the output event spec.
For example, consider a library such as Berlin Brass with its expansion packs, where trumpet articulations can be performed unmuted, or with straight mutes, or with harmon mutes. You could have separate programs for each articulation with each type of mute – and this is a perfectly cromulent approach to be sure – but it’s now also possible to have a single program for each articulation and the type of mute be defined in another group.
//! c=long i=note-whole g=2 120 unmuted //! c=long-light i=stopped g=2 121 straight mute //! c=long-light i=stopped g=2 122 harmon mute //! c=long i=note-whole o=note:24@1%120/note:24@2%121/note:24@3%122 1 long //! c=short i=staccato o=note:27@1%120/note:27@2%121/note:27@3%122 40 staccato //! c=short i=marcato-quarter o=note:28@1%120/note:28@2%121/note:28@3%122 52 marcato
So here we have the mute types in group 2, and the articulations in group 1. This example describes a multi, where the unmuted patch (the one that comes with the base Berlin Brass library) is on channel 1, the straight mute variant is on channel 2, and the harmon mute variant on channel 3.
Here when activating the long articulation, only one of the output events will be emitted, depending on the state of group 2.
If one of the mute types in group 2 is changed later, Reaticulate understands that it must retrigger program 1 and emit the new note output event on the other channel, and redirect future MIDI events to that channel.
The standard caveat of using multiple groups with Reaticulate applies: Reaper will only chase the last program on each channel, so if you have a MIDI item with e.g. program 120 followed by program 1, and you manually activate program 121, when you begin playback again, depending on the playhead position, program 120 may not be refired.
In spite of that limitation, this new ability to filter output events based the state of other groups provides a lot of interesting capabilities.
There is now the beginnings of a user manual on the Usage page. It’s a bit information-dense right now but I intend to polish it up over time.