Menu
What's new
By:
Filters

Reaticulate - articulation management for REAPER - 0.5.13 now available

Thanks Tack! I used FlexRouter before..just forgot about it wit time :)

I am trying to create my first bank and i am quite confused. On the tutorials site it says to just click on the pencil on the UI to edit the file and when i do that a reaticulate.reabank file opens, but the first 2 lines are:

// Generated file. DO NOT EDIT! CONTENTS WILL BE LOST!
// Edit this instead: C:\Users\...\AppData\Roaming\REAPER\Data\Reaticulate.reabank

So? Is this the right file to edit?
 
Last edited:
vicontrolu said:
So? Is this the right file to edit?
Click to expand...
Something looks wrong here. This should only appear on the dynamically generated files that have -tmp in their name. So you click the pencil icon, click edit from the menu, it opens notepad and that's what you see? If you locate the file mentioned there (you can click Show In Explorer off the popup menu when you click the pencil icon) and open the Reaticulate.reabank file yourself (again *not* the one that has -tmp in the name) can you confirm it says what you quoted?

Do you have the ability to do a screen capture (with OBS or Licecap or something) so I can see exactly what you're doing? If there's a bug here it's going to be a confusing one I think, so the more details the better. :)
 
Yeah i checked the file. Its Reaticulate.reabank, not the temp, which has these 2 lines. I have started writing custom banks in it and they work fine though
 
Another thing that surprised me is, once i have created a track with a Reaticulate bank on it, when i load the track as a track template into a new project, i dont need to run reaticulate_MAIN script anymore (the one that docks the UI, etc.).
I actually prefer it this way but then...if i edit the bank manually and then the interface is not needed..whats the purpose of the MAIN script then? Just pointing to the correct bank the first time you set it up?
 
vicontrolu said:
Yeah i checked the file. Its Reaticulate.reabank, not the temp, which has these 2 lines. I have started writing custom banks in it and they work fine though
Click to expand...
This one's got me stymied. Reaticulate.reabank, when it doesn't exist (as it wouldn't on a fresh install), is created by the Reaticulate main script on first open, and Reaticulate copies the first few comment lines from Reaticulate-factory.reabank (located in the Scripts directory) to that file. I am not sure how the "Generated file. DO NOT EDIT!" comment landed in this file. Had you ever opened the -tmp file yourself? Do you think it's possible you might have copied/pasted something from there into Reaticulate.reabank? I'm mainly just trying to figure out how deep down the rabbit hole I should go on this one :)

Suffice it to say, Reaticulate.reabank is exactly the right file to edit. You can remove those comments.


vicontrolu said:
if i edit the bank manually and then the interface is not needed..whats the purpose of the MAIN script then?
Click to expand...
The JSFX instances that are added to each track FX does the work of translating program changes to the output events defined by each articulation. It's actually a design goal that these JSFX instances are able to function autonomously, without the main GUI script, once they are configured. So indeed you should be able to load a project and have playback work without the Reaticulate GUI being open in that session. (While this is a design goal and it's true today, I'm not sure I can guarantee it in the future. :))

The purpose of the main script is:
  • Provide an accessible GUI for changing articulations and inserting articulations into MIDI items
  • Install Reaticulate JSFX on tracks, and configure the JSFX whenever changes to Reaticulate's track configuration are made (banks added to track, channel assignments, edits made to bank articulations, etc.)
  • Implement the logic behind almost all of the Reaticulate actions in Reaper's action list
 
I see. Well, thats a neat system you came up with Tack! Well done :)

Yeah, as i said..i prefer it without the UI. Once its setup, the idea is not having to look anywhere and just use your controller with your buttons the way they are supposed to work.

Thanks for everything!
 
vicontrolu said:
Once its setup, the idea is not having to look anywhere and just use your controller with your buttons the way they are supposed to work.
Click to expand...
Bearing in mind that if you're using your controller to change or insert articulations via Reaticulate by invoking one of the Reaticulate "activate articulation" actions, the main script will be needed to handle that.
 
Heya peeps,

I prepared Articulation Maps for 78-piece Best Service: Era series and thought it would be crime not to share. Libraries include Dark Era, Ancient Era, ERA II and Celtic era.

Here's the link: Google Drive

And while there, I've written some blog about it: https://gameaud.io/reaticulate-banks-era/

@tack: Maybe you'd like to include these in your Userbanks, too :)
 
Kabraxis said:
@tack: Maybe you'd like to include these in your Userbanks, too :)
Click to expand...
I will indeed! Thanks for this contribution. Having done this for all of my Spitfire libraries, I recognize it for the herculean effort that it is.

In your blog, you wrote:

After I got used to it over a weekend, I decided it's an invaluable tool for digital composing, and in some ways, better than it's commercial counterparts.
Click to expand...

I'm interested to know in what ways you think it's better? Knowing this helps me to ensure I avoid changing things that users actually like. :)
 
tack said:
I'm interested to know in what ways you think it's better? Knowing this helps me to ensure I avoid changing things that users actually like. :)
Click to expand...

Well, triggering multi messages with 1 key is killer. Usual problem with orchestral libraries are their sustains often needs a little lift from staccatos. Also, it did helped me with a synth patch once.

And conditional/contextual triggers. I never needed it to use it yet, but I can clearly see where it can be useful.

Thank you again, man. I still think the whole "articulation" thing must be built into the Reaper itself, but I can't deny Reaticulate offers a very straightforward and clean usage after you set it up once.
 
Ugh..its a bit too dense to read without a computer in front of you (on holidays here), bit if this goes beyong grupos in Exp maps then i guess yes, this is a feature only available in Reaticulate.

In Expression maps you can write the articulation in the notes themselves. Thst makes the most of using groups in Exp maps. AFAIK this is not possible with Reaticulate. Is that correct?
 
vicontrolu said:
In Expression maps you can write the articulation in the notes themselves. Thst makes the most of using groups in Exp maps. AFAIK this is not possible with Reaticulate. Is that correct?
Click to expand...
Yes, but there are several reasons for the current implementation.

This is something I recently wrote on the Reaper forum, which I'll cross-post here as it's applicable:

--snip--
A drawback of Reaticulate frequently called out by users and potential users is its use of Program Change (PC) events, which are by nature decoupled from notes, as opposed to notation events, which are tied to notes.

I do recognize the benefit of being able to tie articulations directly to notes, and to use Reaper's notation system so articulations -- those that are supported by Reaper anyway -- are visible in the notation view.

However, there are some drawbacks too. So I wanted to think out loud a bit about the pros and cons of using notation, and get feedback from other users as well:

  1. PC-based articulations aren't visible in the notation view, and if you want that, you need to juggle two mutually exclusive systems (one to affect visualization, and the other to affect playback).
  2. PCs are independent of notes, and so it is possible to copy or move notes and forget the articulations. (Although there are use-cases for this capability too.) However this is significantly mitigated in Reaper 6 with "Options: Bank/program change events follow note selection when CC selection follows note selection"
  3. PCs are visible from the arrange view, while notation isn't. This is a new feature in Reaper that a lot of Reaticulate users like.
  4. PCs can be used to influence changes unrelated to notes, such as a discrete modifier to a currently-playing note, which has many use-cases in virtual instruments. Note notations can't do this, and I previously thought track notation could be used for that, but recently realized that track notation isn't associated to a MIDI channel, so can't be used to control virtual instruments independent of notes.
  5. The notation events CC lane prefixes built-in articulations with "articulation" and custom articulations with "custom" taking up valuable real-estate in the editor, and making the actually useful information invisible when zoomed out enough. In contrast, PCs are no-nonsense, and display exactly what the program name is, so instead of "articulation staccatissimo" you see "staccatissimo":
    pc-vs-notation-1.png
  6. Notation events in the piano roll are overly repetitive: they occur on each articulated note which creates a large amount of visual noise, whereas PCs can more easily denote the start of a passage for visual clarity:
    pc-vs-notation-2.png
  7. With PCs, articulations can be renamed after-the-fact and because the PC is abstracted behind a program number, all references automatically update in all projects. With notation, the text is embedded in the event, so renaming would only apply to newly inserted events.
  8. Up until recently, renaming articulations also would have broken Reaticulate's ability to control virtual instruments, but fortunately schwa addressed this problem with this feature that allows hidden user data, so Reaticulate could leverage this in a notation-based implementation to decouple from the articulation name and to improve efficiency of lookups (numeric evaluation vs text parsing) of the notation event.
  9. PCs can be conveniently removed with alt-mouse-drag in the MIDI editor, the same as other MIDI events. Removing notations requires invoking a custom action.
    pc-vs-notation-3.gif
  10. At least one user (Klangfarben) has expressed a strong preference for program changes based on a workflow that involves exporting standard MIDI files to be passed to an orchestrator. A custom notation system risks losing this information.
  11. A hybrid system has been proposed where Reaticulate uses PCs for playback and synchronizes to notation events for notation editor purposes. This is extraordinarily difficult to implement though, considering that a sane user experience would require bidirectional syncing between PCs and notation events, which could be changed or moved manually by the user or via custom scripts across multiple tracks, and which would require Reaticulate to constantly enumerate all PCs and notation on all tracks all the time to identify and resolve out-of-sync cases. Apart from the frightening performance implications, this is fraught with many edge cases and I doubt it could be made bug free (at least not by me :)).

Can you think of other pros and cons of Reaticulate's PC-based approach vs notation?
--snip--
 
You must log in or register to reply here.
Top Bottom