Reaticulate Forum Discussion
Tack’s Original Post
Hello REAPER users,
I’d like to announce an alpha preview release of Reaticulate: an articulation management system for REAPER.
reaticulate.com
There are other solutions to this problem available of course, but I believe Reaticulate offers a few unique things.
A few highlights: Simple, (hopefully) attractive, dockable UI Highly flexible output events to control the underlying patches in just about every imaginable configuration Articulations are chased and clearly labeled on the piano roll Coexists with manual triggering of instrument keyswitches A number of factory banks for a variety of vendors are bundled to get you started Free and open source
Reaticulate is installable via ReaPack: https://reaticulate.com/release.xml
As this is an initial alpha preview release there are a few things missing, and probably a few things unintentionally broken. Notably, there is not yet a GUI for creating custom banks, so you’ll have to edit bank files by hand and learn a bit about Reaticulate’s custom markup used to extend reabank files. This is all documented, although the documentation, as with everything else, is a WIP.
If you can stand my rambling, I’ve done a video to cover the features and operation of Reaticulate. Even if you tune out after the 2 minute mark, you should have a pretty good sense of what it’s about.
[Q] pbattersby
I see in your picture, below the piano roll, the articulations are displayed. Can I draw in the articulation I want below the piano roll or do I have to record my key switch selections to get them to appear there?
[A-Tack]
You can step record them, as long as step input is enabled in the MIDI editor. At that point, after clicking on one of the articulation buttons or triggering one of the “activate articulation” actions (e.g. from a tablet running TouchOSC, or whatever), it will insert the articulation at the edit cursor position, or replace an existing program event if one is currently selected in the MIDI editor.
See 1:28 in the video for a demonstration.
[Q] pbattersby
With your Reaticulate plugin, can I still do something like that, where I can copy MIDI notes from one instrument to another and also copy your articulations from one instrument to another? I would imagine that would be 2 separate copy operations. One for the MIDI notes, one for the articulation changes.
[A-Tack]
Two separate select actions anyway (you’ll need to shift-select the program change events after you select the notes), and then you can copy and paste them both at once.
Unlike with CCs, Reaper doesn’t have a mode to automatically select program changes underneath selected notes. I plan to investigate the possibility of adding a feature to have Reaticulate optionally do this (tracked here), so you get a similar behavior to CCs.
[Q] pbattersby
When I compose, I like to perform the notes using a general purpose articulation (a short attack with sustain) and then I go back afterwards and draw in the key switch notes I want for each note or group of notes. C2 might be sustain, E2 for staccato, F2 for pizzicato for example.
[A-Tack]
Oh, related, I also intend to add an action to scan MIDI items and convert manually triggered keyswitches to program events (and that one is tracked here).
So you could do your live performing as described, trigger the action, and it’ll convert all the keyswitch notes (C2, E2, etc) to program changes for easy visibility in the MIDI Editor. Then you can go back over them and massage via step input.
I thought I’d mention in case it wasn’t clear: to have the program changes show in the MIDI editor, just add a lane that’s set to “Bank/Program Select”.
[Q] TonE
A .lua which can sync between these events could do the trick, as an early experimentation field. I mean sync from notation to reaticulate events.
[A-Tack]
It could work as an experiment. In practice the number of articulations available to us in many of these orchestral libraries vastly exceeds the built-in articulations, but we could extend it with custom notation events.
Ideally, in fact, these notation events could be used directly to trigger articulation changes in the underlying patches (translated by the Reaticulate JSFX as it currently does for program changes).
The problem though is that the articulation (or other custom notation) events seem to be sent after the notes they decorate, not before.
Hopefully that’s fixed by the time articulation maps lands. In the meanwhile, I think I’d rather not have any attempt at notation view integration at all than to do something half baked.
[Q] Vagalume
Anyway I have a doubt: my templates consist on instances of Kontakt, inside each of them I have 16 tracks, First I tried out using it in the Kontakt track, and them in each of the 16 tracks. Maybe I am wrong but I see that you are using just Kontakt instances without tracks inside. Is this the best way to use Reaticulate? Should I change my templates to use Reaticulate efficiently?
[A-Tack]
I don’t think it should matter which approach you go with. I prefer to have a separate Kontakt instance per track for various reasons (simplified routing; sharing audio FX, automation, and MIDI on the same track; better compatibility with disabled tracks; reduced overall track count) but it should work either way. With the Kontakt Group approach you described, you’d still install the RFX (Reaticulate FX) on each of the 16 tracks and set up the track bank(s) according to how you have the patches arranged in the Kontakt instance on the relevant channel used by that track. I’ll double check that works as expected later tonight.
[Q] gmgmgm
Another question, I may be missing something obvious but is there a way to add the articulations to the track other than recording while clicking them (or step recording them)?
[A-Tack]
There are a number of “activate articulation” actions. Open the actions list and search for Reaticulate to find them.
I also demonstrated a few in the video: actions for next/previous articulation (which I use from my control surface), an action to scroll through the list (to use via an encoder say, or the mousewheel if you prefer), and also actions to activate articulations by specific program number, which you could do from e.g. a tablet.
When you trigger these actions with the MIDI editor open and step input enabled, then they will be inserted in the MIDI item. Otherwise, they should be captured via live recording. Or, if not recording or step-inputting, you can of course activate them just for ad hoc use.
[Q] _Stevie_
I’m not 100% sure if I got this right, but I think the numbers in front of the articulation represent the program change number, which can be triggered by a MIDI controller / Lemur / TouchOSC.
[A-Tack]
Reaper can’t step record program events unfortunately (or at least it didn’t when I tried last year). So the right way to trigger an articulation is through one of the actions I mentioned earlier (or by clicking on the articulation button in the GUI, but that’s not always the most practical approach).
Tack’s Note
I wanted to underline one of the goals for factory banks.
This is an excerpt from the documentation that I’ll just quote directly:
Although the program numbers are arbitary and don’t influence any specific behavior, some form of standardization is recommended because this allows using the Reaticulate_Activate articulation by CC actions to trigger a given articulation (or at least its closest approximation) from a control surface, tablet, etc., no matter the underlying instrument.
Reaticulate’s factory banks will conform as closely as possible to Spitfire’s UACC specification.
So, for example, by consistently using program 42 to map to spiccato, or some similar very short articulation, you could have a control surface send CC value 42 (via a CC number of your choice bound to the Activate Articulation action) to set spiccato, no matter what track is selected.
I talk a bit about this in the video as well (starting at 18:48) and explain the reasoning and benefit of doing this.
UACC has got problems, but I think it’s mostly good enough for these purposes. I did think of doing my own spec for articulation mapping, but, well, oblig.
Of course you can do whatever you want for user banks, but if you’re sharing with the goal that your contribution is merged into the factory bank – something that I’m absolutely encouraging and thrilled to see as I’d love to flesh these out for other users – I just ask that you follow UACC where possible and follow the other recommendations in the docs.
Other key points: articulation names are lower case (except to differentiate between e.g. trill m2 and trill M2), and group 1 should be used for the main articulation group (the one with most articulations that control the instrument) rather than things like legato on/off.
[Q] gmgmgm
Or should this sort of functionality (not really articulation) remain outside banks aimed at inclusion in the factory banks?
[A-Tack]
Oh, no, it definitely belongs. Vibrato styles certainly qualify as articulation (perhaps even more traditionally correct compared to the way we tend to use it with VIs these days?). The goal of the bank should be to make the patch usable entirely via Reaticulate.
It really is a judgment call. For those programs that aren’t clear cut, I match them as best as I can, and if it’s completely in left field, yeah, pick either an unassigned program, or an uncommon program if you run out.
The ones I personally feel are more important to get right:
1: long normale (non-legato for chords) 7: long muted (e.g. con sordino) 8: long soft (sul tasto, or flautando, or hollow, or something played at an unusually soft dynamic) 9: long hard 11: tremolo/flutter 20: legato 40: staccato or generic short 42: spiccato or very short 56: pizzicato 70-74: trill
Of course many patches have multiple articulations that could qualify, so in those cases I assign the one I think is most representative or common in the context of the patch.
There’s something I haven’t quite settled on philosophically – I think that uncertainty shows through in the factory banks right now – which is what to do with patches that use mode toggles (e.g. legato on/off, con sordino on/off) as opposed to discrete articulations (long normale, long con sordino, legato normale, legato con sordino, etc.) like Spitfire does.
One idea I quite like in practice is activating a single program and knowing exactly what you’re going to get. Especially the ones listed above. For example, I like being able to send program 1 and know that, no matter what, I can play chords; or program 20, and know, if the patch supports it, I can play a play a monophonic line with legato transitions. Or program 42, and I’ll get biting shorts.
This is useful for sketching contexts – quickly activate the basic sound you want to achieve without farting around with multiple articulation keys – and then you can go in later and massage the MIDI data.
I was not always true to this idea in the factory banks (e.g. with the Bohemian and Cinematic Studio Strings), and I think I’m regretting that.
In these cases, I’ve been considering creating separate companion banks for the purpose of sketching, and avoiding the problematic program numbers in the main bank.
So, take for example Cinematic Studio Strings, where we have these programs:
20: legato on (group 2) 19: legato off (group 2) 7: con sordino (group 3) 2: senza sordino (group 3) 1: sustain (group 1)
This means it isn’t the case that I can send program 20 and know I’ll be able to play a legato normale line, because if the patch is currently on, say, staccato, I’ll need to additionally activate sustain. But that means sending program 1, where the expectation I should be able to play chords.
It’s a real mess.
Instead, I think it perhaps wise to avoid program 1, 7, and 20 in the main bank and reassign these to something else. Then have a companion bank, which could be loaded along side the main bank in the track, to implement this “one program to rule them all” combination programs, like what I ended up demonstrating in the video.
Maybe this does argue for something more precisely specified than what UACC is offering. I want to have my cake and eat it too: consistency and uniformity across different libraries from different vendors, and be able to support a varied ecosystem of different implementation approaches by those vendors. In case it’s not clear from the above, program numbers in the factory banks are subject to change during the alpha preview phase.
[Q] benigno
The problem with doing so many combination programs as you stated above so that there is not a whole lot of different controls to be applied at one time, (the most clear example for me is Legato/ non-legato switch) is that if you make out all the combinations so as to take care of the multiple output (with notes and ccs to match) you end up with twice as many programs.
[A-Tack]
And that’s with just legato on/off. Throw in con sordino on/off, or, say in the case of Embertone’s Friendlander, sul ponticello on/off (since it’s implemented through convolution), and you have a combinatorial explosion of permutations.
I think, though, there is a good reason to provide some consistency for a set of very common articulations for the sketching use-case. A strict set of programs which will emit all the necessary output events to get the patch into exactly the state defined by the program (e.g. program 1: non-legato long sustains senza sordino), that Just Work no matter what track is selected. All other programs, although perhaps still adhering to UACC if there’s a reasonable match, are more lax in that they don’t take extra care to set those things like sordino, legato, etc.
I’m warming up to the idea. There’s a gap in Reaticulate’s functionality that I’d need to close, which is that if a program emits an output event to set, say, legato off, and there is another specific “legato off” program in another group mapped to that output event, Reaticulate won’t realize it should activate that program in the other group. That should be easily fixed, and then it would allow these “all inclusive” programs to co-exist with the more narrowly defined programs that more closely align with the patch’s true behavior.
[Q] benigno
Now, one of the powers I like in your solution is that you have given us 10 actions ready to go straight to the articulation one wants, this in combination with another layer of abstraction seems to make the most sense to me. And that took some doing.
[A-Tack]
Early incarnations of Reaticulate defined the type of output event at the bank level (e.g. note, CC and which CC number, destination channel number) and then used the program number to signify the value for the output event (e.g. if the bank’s output type was note, then program 42 would send note 42). I had a minor breakthrough that made me realize I could allow for multiple specific output events for each individual program. This does allow for some great flexibility, as you point out.
[Q] benigno
Still, as I said is one more layer and more work on the user, but let’s not forget that these options are there to use.
[A-Tack]
Yes, of course I’m agonizing about exactly how the factory banks should work, but the user is free to do whatever suits their specific workflow and preferences. I like the idea of leveraging Web Remote, and I’m interested to see what users cook up there.
[Q] Vagalume
Maybe the message has to do with the Kontakt factory banks, in fact SSS V1 Core and V1 Decorative share an articulation (both have Sul Pont) and both patches sound at the same time when selected with this concrete articulation, no idea.
[A-Tack]
This is exactly the reason for the warning. It’s safe to ignore in this case. I’ve committed a fix for that (as it was reported over on The Sound Board) and it’ll be in the next release.
As for the Masse conflict, this is expected as these patches definitely do conflict (the patches themselves use the same UACC numbers and so they conflict). The only way to deal with this is to put them on different channels in Kontakt, and use dedicated source and destination channels in the Reaticulate bank configuration.
For example, Strings on source and destination channel 1, and Brass on source and destination channel 2 (with the Kontakt patches assigned accordingly). But then you would need to switch your controller to the appropriate channel as well. (I think perhaps the UX could be improved there.)
The same issue applies with Albion ONE Strings being on the same channel as SSS. The underlying patches themselves conflict and so can’t be on the same channel.
[Q] swiiscompos
for some reason the Reabank files don’t seem to match any of my libraries (all Spitfire), any idea why that would be the case?
[A-Tack]
Make sure you set the patches to “Locked to UACC”. (The little note field for each of the Spitfire banks says “Set patch to UACC”, and in general that message will give patch configuration information if relevant.)
The factory banks using Spitfire send UACC (CC32) events to trigger articulations, not the out-of-box note-based keyswitches.
Forum Page 3
[Q] DynamicK
On another issue, any problems found with chasing the art switches? Still a problem in CB and never really addressed.
[A-Tack]
Reaper will chase program changes on transport play (or on scrub preview MIDI in the piano roll), and since program changes are the basis of articulations with Reaticulate, they’ll be chased.
The main limitation is that you would expect each articulation in each group to be chased, however groups are an organization layer within Reaticulate that Reaper doesn’t understand. Consequently Reaper can only chase the last program change just before the play head, regardless of which group it might be in.
[Q] SymboliC
I’d like to control the articulation changes in Track envelopes rather than MIDI lanes.
[A-Tack]
Not really very easily achieved I’m afraid. The Reaticulate JSFX isn’t intended to be controlled through automation.
You could theoretically insert ReaControlMIDI before Reaticulate and enable it for Bank/Program select on the channel of your choice. Then you could automate ReaControlMIDI by adding the Program number as an envelope. However this would be very cumbersome to use, because the automation point values don’t translate 1:1 with program numbers, and nor is it compatible with any of Reaticulates activate program actions.
I’m afraid I never envisioned using Reaticulate this way, so its most basic assumptions are rather incompatible with envelopes.
[Q] PrimeEagle
They seem to work for the most part, except that by default neither On or Off is selected. Is there a way to either specify a default, or have it automatically sync to whatever is chosen by default in the VST?
[A-Tack]
There is no way to have it sync backwards from the VSTi, no. It’d be possible to include a new default flag which you can set on a given program, but in practice this is only really an issue on the initial configuration of the track. Once the track is configured (in your project template, or even a track template) then the last selected program will be remembered.
[Q] SymboliC
Is this line space and case sensitive?
[A-Tack]
Bank and program names are not case sensitive. By convention in the factory banks, the bank name is title cased, using human-readable abbreviations for the library name (e.g. SCS for Spitfire Chamber Strings) and the full name for the patch the bank describes. Meanwhile, program names are lower case, where some common terms are abbreviated if necessary to reduce length.
For your own custom banks you’re free to use whatever you want. The names can be changed after-the-fact without breaking anything. In terms of spaces, the program and bank names can have arbitrarily many spaces.
[Q] SymboliC
I randomly picked up 32-1 interval for Bank MSB & LSB. What is the importance of this and how should I determine what numbers will go there? It isn’t quite clear to me despite I watched the instructional video and looked through the documentation on the web.
[A-Tack]
At some point Reaticulate will come with a GUI to create and manage banks, and it will choose an unused bank number for automatically. But absent that, yes, I can see how it’d be confusing.
The only requirement is that the two numbers (MSB/LSB combination) are unique for your Reaper installation. MSB 64 and above are reserved for factory banks and are allocated by me. I’d suggest avoiding value 0 for your custom bank and program numbers, just to side step possible corner cases. So, for your custom banks, you could start at 1-1 if you like, and work upward. …I’m guessing the use of LSB=0 has hit one of those aforementioned corner cases… By specification it should be allowed, but I’m not surprised if there’s a bug there. Meanwhile just avoid 0 values for bank and program numbers.
[Q] SymboliC
Can I use 32-1 for another sample library or another instrument? Would this cause conflicts? Or, should I use 32-2 as values for another instrument in the same sample library?
[A-Tack]
Bank numbers need to be unique for your installation. So you’d need to use 32-2 for the second instrument, otherwise it would indeed conflict with the first.
[Q] PrimeEagle
What is the best way to handle this? If I do a different bank for each instrument, it doesn’t switch all the following notes to the new MIDI channel. Any suggestions?
[A-Tack]
Whether consolidated in a single large bank, or split out into separate banks (as with the factory library, which tends to have one bank per patch), ultimately you can’t duplicate program numbers on a given channel lest you have a conflict (e.g. if you have program 42 listed multiple times and you activate program 42, it can’t know which articulation you intend to activate).
Apart from splitting out into multiple tracks, the only way around this problem is to break things out into different source MIDI channels. Then in the track configuration page, you’d use a specific source channel instead of omni. This means you can have up to 16*128=2048 different programs on a given track – 128 per MIDI channel – but it comes with the added complexity of having to juggle MIDI channels as you input MIDI data. If you have any other ideas on how to overcome that limitation, I’d be curious. (from page 4) I should clarify this, because it’s non-obvious: Reaticulate largely ignores the bank changes. The only use of the bank MSB/LSB is so the program name comes up correctly in the MIDI editor.
Technically if the bank change was taken into account, you could have conflicting program numbers as long as they appeared in different banks. The bank change would disambiguate the program conflict.
The reason this isn’t considered in the design is that it’s a core part of my workflow to activate articulations by only program number. I have buttons on a control surface configured to emit program changes on specific numbers to activate common articulations, regardless of the track I’m on. It wouldn’t do to require a bank change as well (since the bank is very track dependent).
It might be possible to satisfy both cases just by changing the semantics of the various “activate articulation” actions to activate the articulation on the last switched bank if there’s a conflict.
But this would require such a drastic overhaul of how program data is stored and accessed that I’m not sure I could do it in a backward compatible way. Will need some serious thought.
Edit: gave it thought. No easy way without drastically increasing memory usage [~32MB per track] or brutalizing performance. Or coding a hash table in EEL.
Forum Page 4
[Q] PrimeEagle
Any chance of having more than 4 groups? I’ve come across some instruments that need up to 6, but when making user banks that are multis, the required number could be 3-4 times that.
[A-Tack]
This is much harder than you think it should be. Increasing it above 4 to even 6 requires a major overhaul of how this information is transferred from the JSFX to the controlling Lua script (the UI). I know how to do it (via a kludge I dare not speak further on), and probably will do said overhaul for other reasons, but even then there are performance implications to raising the number of groups. If I raise the limit, I might go to 8, but I can’t see going to 20 or higher.
[Q] SymboliC
I wish we were able to manage articulation in the main TCP arrange window.
[A-Tack]
I do plan to make it possible to insert articulations by (probably middle-)clicking on the articulations in the UI from the arrange view. But this isn’t exactly what you’re looking for, which is more of a complete way to view/edit articulation changes from the arrange view. I’m not quite sure how best to do this, as envelopes clearly aren’t suitable. If there’s no existing Reaper UI construct to leverage, I don’t see myself building an entirely different UI for it, which ultimately, as a Lua script, probably wouldn’t work that well anyway.
[Q] PrimeEagle
If Reaper doesn’t support multiple program changes simultaneously, though, then I’m not really sure how to approach it. That situation would likely necessitate not sending the articulation as a program change at all, but just as a chord made up of the keyswitch notes directly.
[A-Tack]
Reaper doesn’t support multiple program changes simultaneously, no. It will only chase the last program change on a given MIDI channel. We already run into this limitation with groups, where even though a bank can have up to 4 groups with independent articulations, only the last program in the last group for that channel will be chased.
So, we must live with those limitations.
To address your problem, I’m thinking about two new output event types: one that’s a more extreme version of note-hold – maybe call it note-pin or something – which, unlike the note-hold output type which simply defers the note-off event until the next program with a note or note-hold output event, will keep the pinned notes (within the given group) held until the presence of a note-clear output event, which would then send note-off events for all currently pinned notes in the group.
Then you would have each of your stop programs use the note-pin type, and another “end stop stack” program (with more appropriate language that an organist would understand) that uses a note-clear output. It would require the use of this “end stop stack” program before any new stop configuration.
[Q] Oberheim
- I have problem to understand what are then numbers with the technique name?
1 legato 1 = program change?
[A-Tack]
Yes, those are program numbers.
[Q] Oberheim
If yes how to not use program changes? I use libraries where I don’t use program changes for changing articulation.
[A-Tack]
The basic unit of articulation in Reaticulate is the program change, but this doesn’t mean that’s what your libraries have to use. Reaticulate translates program changes into arbitrary MIDI events to control the libraries. I call these “output events”. It’s documented here.
[Q] Oberheim
If I wrote only
legato
I got error after refresh Reaticulate.
[A-Tack]
Yes, that’s not syntactically valid for .reabank files.
[Q] Oberheim
can Reaticulate create arpegio effects? For example I create chord and when arpegio is used, it deley each higher or lower notes.
[A-Tack]
No, that’s not really a problem Reaticulate tries to solve.
[Q] Oberheim
can Reaticlate follow notation articulations and dynamics(crescendos and descrescendos too)?
[A-Tack]
It can’t follow notation yet. I’m waiting to see whatever becomes of articulation maps before I do anything related to notation.
[Q] thevisi0nary
Problem is solved. The bank has to communicate with the sample library itself, and then it displays the bank names properly in the midi editor upon reloading the reaper session. The reason I didn’t figure this out sooner is that I was experimenting with newly made banks before actually connecting them to the sample library instruments.
[A-Tack]
At risk of only adding to the confusion, I’ll try to clarify the design of Reaticulate a bit in case it can help you reason through things like this.
So you have a bunch of tracks on which you’ve added the Reaticulate FX at the top of the FX chain. The purpose of this FX is to translate Program Change MIDI events into whatever output events the VSTis later in the FX chain need to receive to control them. Reaticulate (hopefully) provides a convenient enough interface to insert these program events into MIDI items (stepwise or during live recording).
The main “process” of Reaticulate (the long-running plugin that presents the GUI) is responsible for programming the JSFX on each track according to the bank(s) you have assigned per track. It transfers the details of the the banks the user has selected for the track, on which channels, all the banks’ articulations, their flags (Should the articulation chase CCs? Should it attempt to avoid note-hanging? etc.), and all the output events to the JSFX. Then when the JSFX receives a program event on some channel, it knows how to respond to it.
When you create your own user banks by editing the Reaticulate.reabank file (and eventually there will be a built-in GUI to build banks so you won’t have to edit that file directly), you need to click the reload button at the top of the Reaticulate GUI to cause Reaticulate to rediscover the changes.
This “rediscovery” does a few things:
It combines all the factory banks and all the user banks into one big bank file (and strips out all of Reaticulate’s custom markup) into DataReaticulate-tmp<#>.reabank (where <#> is just some monotonically increasing number).
It modifies Reaper’s .ini file to update the MIDI default bank file to this new tmp reabank file.
It does some other tricks to smack Reaper upside the head so that it takes notice of this new config change.
On the currently selected track, it clears and reprograms the Reaticulate JSFX to sync any changes that may have been made to the banks on that trick.
Afterward, when selecting new tracks in the project, if Reaticulate notices the compiled bank version (that <#> above) reported by the track’s Reaticulate JSFX is different than the latest version, then it will also reprogram the JSFX to ensure it’s kept in sync with the latest bank changes.
So at the end of the day, if you’re modifying that Reaticulate.reabank file but not clicking that refresh button in the Reaticulate UI, Reaper won’t know about the changes you made. If you then manually insert a program event in the MIDI editor, indeed, Reaper won’t know how to resolve the program number into its name so it will report the bank/program number. I think this maybe is what happened from your description?
I suppose most users wouldn’t run into that problem because the way to insert a program event is by clicking an articulation in Reaticulate’s UI. And if Reaticulate is able to present the articulation in the UI, it’s because it refreshed the reabank file and discovered them, in which case it would have ensured Reaper itself knows about those changes.
Long winded, sorry, but maybe it’ll be helpful to someone.
[Q] sveinpetter
The GUI in Trillian shows the Key Select and sounds good, but the Key Select ends up as Type PC with the Value of the note. Not as Type Note. When recording to Midi. Sorry for all my Edits … When playing back the midi file, the PC Values triggers Key Select OK. Hhmm.
[A-Tack]
Reaticulate inserts program changes into the MIDI item, but those program changes are then translated as they pass through the Reaticulate JSFX on your FX chain so that the downstream VSTi receives the output events you configured for the articulation. (Notes, in this case.)
Forum Page 6
Full Change Log
Again, please read the 0.2.0 announcement on the website for much more detail.
New Features:
Added support for MIDI CC feedback to a control surface or other controller
Articulation output events may refer to other articulations in the same bank via new ‘art’ output type (#18)
Articulations can now be inserted from the arrange view (or MIDI editor without step input needing to be enabled) by right clicking the articulation button (#28)
Banks can now specify which CCs should be chased. Factory banks are much more selective about what’s chased. (#33)
Added support for conditional output events, where output events may now be optionally dependent on the state of articulations in other groups (#32)
Output events to specific target MIDI channels can now be optionally configured to not affect future routing (#30)
Added Settings UI to configure Reaticulate to autostart when Reaper starts
Minor Enhancements:
Spacebar in Reaticulate’s window will now toggle transport and focus arrange view
Bank list in track configuration can now be reordered via drag-and-drop (#37)
Ctrl-left/right now skips words in the articulation filter text input box (#9)
Existing program changes at edit cursor will be removed before inserting a new one (#35)
Bug fixes:
Fixed problem where UI may not use correct background color from theme
Fixed parsing of invalid colors and icons (#13)
Fixed “Add Reaticulate FX” button not working after first install (#15)
Fixed ultra critical bug where trill-min2 and trill-maj2 icons were swapped (#16)
Fixed routing issue when articulation had no output events defined (#27)
For articulations with multiple note outputs, all note-ons will now be sent before any note-offs (#20)
Articulations with multiple note-hold outputs now works as expected (#26)
Fixed embarrasing bug where channel 16 couldn’t be used for bank’s source channel
Reduced the likelihood of Reaticulate munging the last touched FX
Other minor bug fixes
[Q] K8ch
By the way…was hoping to simply select several notes in a passage, and make them all Staccato, with a single click…but I couldn’t get it to do that.
[A-Tack]
The program change MIDI events Reaticulate inserts into the MIDI item are decoupled from the notes themselves. This means the articulation change isn’t really a property of the notes, but more about the edit cursor position.
It’s similar to CCs in this way, where CCs used for performance are musically related to the notes above them but from a MIDI perspective they’re separate. Reaper has an option to auto-select CCs under a note when you select a note to help this a bit. It doesn’t do this with program changes. (It’s on my to-do list to have an option where Reaticulate will autoselect the closest previous program change when a note is selected to mimic this same sort of behavior.)
Consequently, you manage your articulation changes (program change events) independently of the notes. You insert them at the edit cursor (right-clicking an articulation as of Reaticulate 0.2.0) and resposition them separately from notes.
Some people actually prefer it this way. I know of at least one Cubase user who hates how articulations are a property of the note.
[Q] thevisi0nary
Say I have one kontakt instance, channel 1 is Symphonic Strings standard articulations, and channel 2 is decorative. Is there a way to have a separate channel for each one as I switch between channels?
[A-Tack]
Assuming you’re referring to Spitfire here, these patches can actually coexist on the same channel. You just need to set the patches to “Locked to UACC.” (This is required if you use the factory banks, anyway.) So you don’t need to use separate MIDI channels for this example, and in the Reaticulate config for the track you can set the source channel of both to Omni.
Now supposing we were talking about a different library where the two patches you mentioned clearly conflicted with one another such that you were forced to put them on different channels – for example, because they used the same keyswitches and couldn’t be reassigned to avoid the conflict. So in Kontakt, you had the standard patch set to channel 1, and the decorative patch set to channel 2.
You actually have two options:
You do everything in channel 1 (for example) and let Reaticulate reroute to Kontakt on channel 1 or channel 2 depending on which articulation you have activated. In other words, let Reaticulate abstract away the details about which channel the Kontakt patches are set to and just do all your performance on a single channel. This is the easiest and most obvious way, but it only works as long as there’s no overlap in the program numbers between the two banks.
You explicitly change MIDI channels in Reaper based on the articulation you want to activate (standard vs decorative). You need to keep track yourself of which bank is on which channel before you activate the articulation. This is more awkward than #1, but it would be necessary if you had the same program number listed in both banks: in this case Reaticulate can’t know which one you want, so you need to disambiguate it by sending the program change on the right channel.
So in Reaticulate’s track settings, for #1, you just set the source channel to Omni for both banks, and the target channel will be either 1 or 2 depending how the patch is set in Kontakt.
Meanwhile, for #2, you set the source channel to either 1 or 2 (depending on how they’re assigned in Kontakt) and then you can set the target channel to the same (1 or 2), or just leave it set to Source, which just means that program changes coming in on channel 1 get routed to Kontakt on channel 1, and program changes on channel 2 get routed to Kontakt on channel 2.
Clear as mud? Hopefully you can just set your Spitfire patches to UACC and call it a day.
[Q] PrimeEagle
Is there a way to change the volume/velocity when changing articulations, for example to make pizzicato quieter than arco?
[A-Tack]
Assuming your VI responds to CC7, you could chain a CC7 event to the articulation’s output event list to set the appropriate volume. Some patches, such as those from Spitfire, allow CC11 to control the volume for all articulations (including shorts), so this would probably be preferable to CC7.
Forum Page 7
[Q] G-Sun
But, this seems wrong (my file):
o=@2 o=cc:20,1
What’s the correct syntax?
[A-Tack]
From the docs: Multiple output events are separated by a / (forward slash) where each individual output event roughly takes the form:
type@channel:arg1,arg2
No whitespace allowed. So you would need:
o=@2/cc:20,1
But note as written that CC will go to the default channel. If you actually want to send it to channel 2 and route subsequent events there, this is actually what you want:
o=cc@2:20,1
[Q]G-Sun
Got it working by both by setting source to ch2 and coded as above. Will use setting source, as it seems more flexible.
[A-Tack]
Source relates to where your originating MIDI events are expected to come in on. If you don’t care about that then set Source to Omni. Setting the Destination channel to “Source” is fine (and what I’d do) if you’re explicitly defining the target channels in the banks.
In other words with “o=cc@2:20,1” you can set the bank to Source=Omni and Target=Source no problem because you’re dictating the target channel right in the articulation definition.
Or, if you wanted the bank itself to be agnostic to the target channel, you could choose not to define the target channel in the output events (“o=cc:20,1”) and then use Source=Omni and Target=2. Not sure which one makes sense for your case, it’d depend on the library. You’ll feel it out I’m sure.
[Q] G-Sun
Is the reabank-file limited to 128 Program lines articulations? I got some errors on same numbering, although it should be different <LSB> and Bank name.
[A-Tack]
Right, the warning you’re talking about is probably because you have conflicting program numbers between multiple banks loaded in on the same track?
This conflict happens when you have the same program numbers on the same source channels. If you have two banks, both defining e.g. program 1, and both set to the same Source channel (whether Omni or some specific number), the way Reaticulate works right now it can’t differentiate between them, because it only looks at the program numbers and not the bank select events that precedes it.
Right now the workaround is to use different source channels for the banks. This means your performance MIDI needs to be on different source channels.
Addressing this properly requires some pretty drastic design changes unfortunately.
[Q] G-Sun
For toggles-switches: Can I assign note-on and note-off message? Or do I then need 2 entries, one for on, another for off. (It’s a legato-switch).
[A-Tack]
No, a toggle sends the same MIDI event each time you trigger it, it just changes its visual state in the UI. An example of this is the Bohemian violin’s chord on/off toggle, where you send the same note to toggle it on and off.
[Q] G-Sun
Is there no way to comment in the bank-files now?
[A-Tack]
Yes, comment the normal way.:
// comment
In the -tmp file the markup (and maybe comments) get stripped but the -tmp file isn’t meant to be consumed by anything other than Reaper directly. Humans will edit the Reaticulate.reabank file.
Forum Page 8
[Q] Arthur McArthur
One thing I noticed is that if I have more than one track selected and I change articulations, that articulation gets pushed to all tracks that are record armed. Is that expected? Would it be possible for the articulation to only be passed to the selected track(s)?
[A-Tack]
That’s the expected behavior, yeah. When you click on an articulation, it emits the MIDI program change event, and Reaper will route that message to all record-armed tracks.
I feel like this actually makes more sense than just targeting selected tracks, because the articulation change is an element of a MIDI performance. So if I change an articulation and then play a note, I would expect those two things to go to the same tracks.
In any case that behaviour isn’t configurable. Although it technically could target only selected tracks (not easily though), I feel like that’s even more confusing than sending to all record-armed tracks – if anything, shouldn’t it only target the last touched track that the Reaticulate GUI is showing current banks for?
Does anyone else find the current behavior counter-intuitive? If so, how would you expect it to work?
[Q] fbeauvaisc
Is there a way to stack articulations in midi channel switching? With a Ctrl+click would open more midi channels.
[A-Tack]
This could technically work the way you described but only for the multi scenario like you’re using, and, more problematically, it wouldn’t work during recording or playback, because you can’t “layer” program change messages.
So there are two possibilities here:
Create custom layered articulations that route to multiple MIDI channels. Of course this means you have to think ahead-of-time which layerings you want and create articulations for them.
You can use multiple source channels. If you’ve added the bank to your track with the Omni source channel, you can map any source channel to any single articulations. This is how I layer, with multiple source channels, because I want to have independent CC curves for each layer anyway. But if you wanted to control multiple destination channels from a single source channel, this requires option 1.
I can’t think of a good way around this when using program changes the way Reaticulate does. But I’m open to ideas.
[Q] fbeauvaisc
Is there a way to have Reaticulate change midi bus to have more than 16 midi channels available per track?
[A-Tack]
Not without some sort of support from the VSTi. Someone had a similar question in the context of Kontakt, whether it was possible to address all 4 ports within Kontakt (ports A-D).
I offered this solution which combines FlexRouter, a Kontakt multiscript, with Reaticulate to address up to 64 different channels.
This theoretically would work with VEPro as well, but it only works with Kontakt.
As for using MIDI buses from Reaper, I’m afraid Reaticulate doesn’t support this yet. The Reaticulate Bus Translator JSFX you stumbled upon was just to solve the specific use-case of MIDI feedback to a CC controller and it was never meant to be used directly (only behind-the-scenes by Reaticulate). It’s no wonder you’re finding it working a bit wonky when trying to use it for this purpose.
Supporting multiple MIDI buses natively within Reaticulate is an interesting idea. So you’re saying this works properly between Reaper and VEPro? If Reaper sends out on a particular MIDI bus, VEPro handles this natively?
I suppose I could test this without VEPro (as unfortunately I don’t own it) by adding multiple VSTis to a track and assigning input to different buses. Then I’d need some way within Reaticulate to specify the destination MIDI bus. Something like:
//! c=short i=spiccato o=note:17,1@12.4
42 spiccato
…which would send note 17 velocity 1 to channel 4 on MIDI bus 4 and route future events there.
Do you think this would translate well to what you’re trying to accomplish with VEP6? mAnd would you find it a problem to your workflow if you, even though you could address destinations on any MIDI bus(*), your MIDI input could only come from bus 1? (*) I leverage bus 16 for CC feedback to a MIDI controller, so technically if you wanted to use that feature you couldn’t put anything on bus 16.
[Q] Klangfarben
I’m probably missing something because, well, I’m stupid. But in the including actions, is there an action to select a specific articulation slot 1-16 for groups 1-4? I see an action for next and previous articulation but not for a specific slot.
[A-Tack]
So the first misconception is that there are articulation slots 1-16. Reaticulate works differently than something like BRSO Articulate in that it isn’t channel-based, but rather program-number based. This means that you could define a bank that had up to 128 different articulations. For your custom banks the choice of program number is up to you, but the factory banks follow (to the extent possible) the numbering defined in Spitfire’s UACC standard. Arbitrary, but it was at least something to base some consistency on.
Within a bank, program numbers must be distinct. This means you can’t use program 42 (or whatever) in group 1 and reuse it again in group 2. Consequently it doesn’t matter what group program 42 is in. If you want to activate that articulation, you use an action to do it (via one of the activate articulations by CC actions) and it’ll activate it regardless of which group it’s in.
Actions to activate articulations are done by CC right now. Because there’s no good alternative – as I explain above in post 285, I would need a massive number of actions to cover all the program numbers and source channels and it makes it impractical. bHope that makes sense!