Reaticulate - articulation management for REAPER - 0.5.13 released (2024-02-19)

[tack]

Originally Posted by Kitarraman

it be possible to make so that there's a check on the banks, if there are any differences, we get a warning telling that the banks are different and asks for confirmation before overwriting them?

That's exactly the idea. Except the prompt would happen when you load a project with an old version of the bank, rather than when you just import/replace the current system-wide bank.

So:

1. Import bank from the TBD online database of banks
2. Create Project 1 that uses that bank
3. Create Project 2
4. Import a new version of the bank from step 1
5. Reload Project 1
6. Reaticulate detects the new version and prompts you to update current project with new (possibly incompatible) bank, or leave it alone (where you could do it in the future).

[Kitarraman]

Originally Posted by tack

That's exactly the idea. Except the prompt would happen when you load a project with an old version of the bank, rather than when you just import/replace the current system-wide bank.

So:

1. Import bank from the TBD online database of banks
2. Create Project 1 that uses that bank
3. Create Project 2
4. Import a new version of the bank from step 1
5. Reload Project 1
6. Reaticulate detects the new version and prompts you to update current project with new (possibly incompatible) bank, or leave it alone (where you could do it in the future).

Ok. Great idea Tack. Where would the bank datas be stored in the project? Just to be sure this won't backfire in any way

[tack]

Originally Posted by Kitarraman

Ok. Great idea Tack. Where would the bank datas be stored in the project? Just to be sure this won't backfire in any way

I'd use SetProjExtState to hold per-project data.

[_Stevie_]

Originally Posted by tack

Except my goal will be to make upgrading projects somewhat less obnoxious than upgrading Kontakt patches. So I'll need to devise some means of detecting new versions, and when you select a track that has an old revision of the bank, it will ask (unobtrusively) if you want to update the bank on the track. At this point you can either update the bank on that track or dismiss the prompt, whereupon Reaticulate will just show some subtle icon on the bank indicating it's an old version (which you can then later click to update or ignore as you wish).

Any thoughts good or bad on the above proposal?

I think that covers your question

EDIT: damn, you were already ahead of me, sorry...

[Vadium]

a little distracted from the topic of banks:

So, if we have a Reaper-limit of 16 midi buses for internal routing, what about to make the ability to address from articulation to any track directly, by a track id or track name?
(it will very useful for a Reaper network orchestral workflow, where Reaper instances on each computer connected together by LAN without VePro (this project in progress)

[tack]

Originally Posted by Vadium

So, if we have a Reaper-limit of 16 midi buses for internal routing, what about to make the ability to address from articulation to any track directly, by a track id or track name?

This is sounding pretty esoteric.

I'm not sure I can imagine how it would work. The JSFX processes program changes, so it would have to set up the sends to other tracks dynamically as articulations are activated. But I don't actually think JSFX has this capability.

(The main Lua script won't do this. It's a core design principle that articulation changes still function even if the main script is not running.)

Do you have ideas on how it would work?

[Aleksandr_Oleynik]

Originally Posted by tack

I'd use SetProjExtState to hold per-project data.

Exactly!

[Vadium]

Originally Posted by tack

This is sounding pretty esoteric.

Do you have ideas on how it would work?

I haven't (I am novice in Reaper engine), but @Aleksandr_Oleynik has.
this is my attempt to translate his idea:

there are API functions that control all MIDI send functions -
reaper.BR_GetSetTrackSendInfo( track, category, sendidx, parmname, setNewValue, newValue )

List of possible parameters:
here is only MIDI -
I_MIDI_SRCCHAN : source MIDI channel, -1 if the MIDI send is disabled (0=all, 1-16)
I_MIDI_DSTCHAN : destination MIDI channel, -1 if the MIDI send is disabled (0=original, 1-16)
I_MIDI_SRCBUS : source MIDI bus, -1 if the MIDI send is disabled (0=all, otherwise bus index)
I_MIDI_DSTBUS : receive MIDI bus, -1 if the MIDI send is disabled (0=all, otherwise bus index)
I_MIDI_LINK_VOLPAN: link volume/pan controls to MIDI

In other words, it's possible by script in some case to switch any MIDI SEND on any channel and any bus, and to extinguish the rest all Sends on other tracks.

At all:
There is a MIDI item on the track, that contain notes, under each note you draw a point from 0 to 16383 in any free CC 14 bit controller. Each point means its own articulation of a particular instrument.
There is a JSFX on track, which takes the signal of this CC 14 bit with Val = 16 - and puts its fader (which may not be visible) on val 16.
Launched in defere LUA script sees the change of this parameter in this JSFX and sends a command to disable all midi sends except one - which set 6 BUS 12 channel - which is a target instrument with a target articulation.

it's all!
Since on each track you have a number equal to 16 buses with 16 channels in each, there are 256 articulations.
CC 14 Bit has a 0 - 16383 means that one CC we will be able to access to 64 track with 256 articulations.

[tack]

Originally Posted by Vadium

Launched in defere LUA script sees the change of this parameter in this JSFX and sends a command to disable all midi sends except one - which set 6 BUS 12 channel - which is a target instrument with a target articulation.

Yeah, I also think this is necessary.

Setting aside the point I made about earlier it being a core design principle that articulations continue to function even without the main script, there is another problem: this is fraught with races.

Deferred scripts execute roughly 30 times a second. Imagine a MIDI item with an articulation change inserted at the note position (which is also how the new insert-at-selected-notes logic works). Even suppose it was a few ticks ahead of the note, it doesn't matter to this scenario.

The JSFX could process the program change and signal the main script of the requirement to setup the send. But with an execution of only ~30Hz, it's almost a certainty that the main script will fail to create the send quickly enough before the note is passed through the JSFX.

For this to work reliably, all such program changes would need to precede the note by at least 33ms, perhaps even more like 50ms for it to be truly robust (because 30Hz is not guaranteed).

IMO that's a showstopper.

[_Stevie_]

Hey Jason,

apparently I still got issues with writing the articulation to the beginning of an item. This seems to happen when two items are butted up against each other.

In the GIF you can see me trying to set the articulation, without success. Then I make the first item shorter and suddenly it works. The figues should all be visible (edit cursor position, item length of the 1st item):

[tack]

Originally Posted by _Stevie_

apparently I still got issues with writing the articulation to the beginning of an item. This seems to happen when two items are butted up against each other.

Thank again Stephan. Yeah, silly off-by-one error there that your new test case made a lot clearer than the earlier one.

Some silly edge cases here, but I'll be sure to add those test scenarios for future releases.

Anyway, this fix will get picked up in the next release. Thanks again.

[_Stevie_]

Ahh these bloody edge cases, tell me about it, haha. Those are the worst and there are TONS of them.

You're more than welcome! I'm heavily using Reaticulate during work, a real life scenario, so to say. I guess this is the most practical testing a software can get

Thanks for already committing!

[G-Sun]

Originally Posted by tack

Reaticulate 0.4.0 is now available!

Thanks a lot!
(Not an active user at the moment )

[tack]

Originally Posted by _Stevie_

You're more than welcome! I'm heavily using Reaticulate during work, a real life scenario, so to say. I guess this is the most practical testing a software can get

Absolutely. I'm not a working composer, just a hobbyist, and given I have a full time gig elsewhere, I just can't exercise it as quickly as someone banging on it every day. So your kind of feedback is gold.

Originally Posted by G-Sun

(Not an active user at the moment )

What's holding you back? Too complicated due to the need to manually edit banks in a text editor? No clear use-case? Something else?

[_Stevie_]

Originally Posted by tack

Absolutely. I'm not a working composer, just a hobbyist, and given I have a full time gig elsewhere, I just can't exercise it as quickly as someone banging on it every day. So your kind of feedback is gold.

Thank you, thank you, doing my very best!

[vsthem]

Question:

When I hit record, will this plugin automatically input the articulation that's been set? With my current setup, it will default to whatever articulation has been inputted, which means I need to program in an articulation before I record. I'm hoping to be able to set my articulation wherever I am in the song, hit record, and have it automatically input the current articulation selected.

Preferably, also the CC position. Right now, I get my sound at the right volume, but until I make a change while recording, it will set to the previous CC value.

Basically, I'm hoping to be able to setup the sound and the CC dynamics, hit record, and have it record the sound as I have it set, not what the last values that have been inputted.

Thanks all!

[tack]

Originally Posted by vsthem

When I hit record, will this plugin automatically input the articulation that's been set? With my current setup, it will default to whatever articulation has been inputted, which means I need to program in an articulation before I record. I'm hoping to be able to set my articulation wherever I am in the song, hit record, and have it automatically input the current articulation selected.

When you hit record, Reaper itself (not Reaticulate) will always chase the last program change event and all CCs. The general behavior you're describing you don't like is Reaper's standard CC chasing. I'm not aware of any way to disable this functionality.

But you can always insert the articulation into the current MIDI item before you start recording. This would require you to have an existing MIDI item and use one of the MIDI overdub/replace record modes in Reaper so you can extend the item while recording.

Originally Posted by vsthem

Basically, I'm hoping to be able to setup the sound and the CC dynamics, hit record, and have it record the sound as I have it set, not what the last values that have been inputted.

Again this is Reaper's native chasing behavior at play. I don't think it can be disabled.

I do understand your use-case though. Theoretically it would be possible for Reaticulate to create an action like "Insert current articulation and CC profile in current MIDI item or create new item". Reaticulate watches all the CC events that pass through to the VSTi, so it could technically insert the current selected articulation and the current value of all CCs that have ever been sent on that track into the current item. Then at least when Reaper does chase All The Things, those things are what you want.

I'd be curious to hear what others think of that idea.

As of today, you have to manually insert the CCs and the articulation into a MIDI item before recording. Inserting the articulation is pretty easy (right-click with the edit cursor over the item) but the CCs would be pretty inconveniently done through the MIDI editor.

[vsthem]

Thank you for that very helpful reply! Always good to know what's currently fixable and what's baked in.

[vsthem]

One other problem I have...perhaps Re articulate can help with this.

If I'm editing a later point in the song where the flutes are trilling.
Then I navigate back to an earlier section where the flutes are playing unison, but after the articulation change, it will still trill the flutes.

Can reaper or rearticulate look back to the previous articulation change in the timeline, and switch the articulation, or will it always default to the last thing that was triggered through playback (even if it occurred later in the song)?

Hopefully this makes sense.

Thanks for your quick and helpful replies!

[tack]

Originally Posted by vsthem

Can reaper or rearticulate look back to the previous articulation change in the timeline, and switch the articulation, or will it always default to the last thing that was triggered through playback (even if it occurred later in the song)?

Yep, this is exactly what "chasing" is. Reaper chases all CCs and program changes in this way, based on the point that playback begins.

This is one of the main disadvantages of using note-based keyswitches in your MIDI items. Reaticulate uses program changes because a) you get proper chasing for free, and b) you can see the names of the articulations in the MIDI editor by adding the Bank/Program Select lane.

[vsthem]

so just to be clear. Rearticulate solves this problem?

[tack]

Originally Posted by vsthem

so just to be clear. Rearticulate solves this problem?

Yep, that's right.

[vsthem]

Awesome. Can't way to try this.

I have the same problem with changes to dynamics (play a loud part, go back to a quiet part, it plays loud).

In theory, could dynamics respond through program changes, as you built the articulations to do? Or do you not have the level of detail and control that you do with a CC lane? (Might be a cool project).

Last question I promise! Do other DAWs behave the same way?

[tack]

Originally Posted by vsthem

In theory, could dynamics respond through program changes, as you built the articulations to do? Or do you not have the level of detail and control that you do with a CC lane? (Might be a cool project).

Well I'm surprised to hear you say you're experiencing this with CCs, because Reaper chases CCs too. If you have a CC1 or CC11 event some time before the cursor and you hit play, Reaper will replay the previous CC1 and CC11 values before emitting any of the MIDI events in the MIDI items.

Originally Posted by vsthem

Do other DAWs behave the same way?

I don't really know. Haven't spent a lot of time with other DAWs. CC chasing is pretty common, so I would expect so.

[Kitarraman]

Originally Posted by tack

I'd be curious to hear what others think of that idea.

Personally I'll never make use of something like that... I'm really a crappy pianist and I never record live using my master keyboard, I usually sketch with it before opening the editor and entering the single notes with the mouse

[_Stevie_]

Originally Posted by tack

I'd be curious to hear what others think of that idea.

This would be brilliant, really. My problem is, I usually don't record, instead I mostly use retrospective record. But, still, this feature would be great!

Originally Posted by tack

Yep, this is exactly what "chasing" is. Reaper chases all CCs and program changes in this way, based on the point that playback begins.

This is one of the main disadvantages of using note-based keyswitches in your MIDI items. Reaticulate uses program changes because a) you get proper chasing for free, and b) you can see the names of the articulations in the MIDI editor by adding the Bank/Program Select lane.

Ah, that's why the chasing issue never happened to me with Spitfire Libraries (UACC).

[_Stevie_]

BTW, the Cinematic Studio Series can also be controlled via CC58 (UACC).
So, I'm gonna remove the CC1 control in the GUI (right click on the wheel and choose remove CC1) and try to switch overto CC58 for everything.

EDIT: I just noticed that there was a CC58 bank in Reaticulate but it is deprecated. Is there a reason why you switched from CC to note based articulation switching?

[tack]

Originally Posted by _Stevie_

My problem is, I usually don't record, instead I mostly use retrospective record. But, still, this feature would be great!

I guess you mean you don't have a use for it personally but you understand the value of it for other users?

Originally Posted by _Stevie_

Ah, that's why the chasing issue never happened to me with Spitfire Libraries (UACC).

It actually ought to have, because Reaper will chase the CC32 values. The problem would be using note-based keyswitches, but CCs should have been chased the same as program changes.

Originally Posted by _Stevie_

BTW, the Cinematic Studio Series can also be controlled via CC58 (UACC).

Technically it's not UACC (which is a Spitfire spec that defines a specific mapping of values to articulations on CC32), but I'm being pedantic.

Originally Posted by _Stevie_

EDIT: I just noticed that there was a CC58 bank in Reaticulate but it is deprecated. Is there a reason why you switched from CC to note based articulation switching?

Yep. Kontakt, or Reaper, or some magical faeries in between -- I think Kontakt though -- would consolidate multiple events on the same CC number so that only the last one was actually processed by the underlying patch in Kontakt.

So if you want to have an articulation that required sending multiple CC58 values at once, like say "legato tremolo" which requires sending CC58/76 to turn legato on and CC58/56 to switch to tremolo, only one of those CCs would actually reach the patch.

I spent a fair bit of time trying to work around this, and found that the distance between the CC values actually needed to be pretty significant to prevent Kontakt from consolidating them -- more than 1 block IIRC -- and that just became way too problematic to workaround when there was another obvious solution to the problem:

Switching to note-based keyswitches made this work consistently. And note-based keyswitches are fine, because Reaticulate abstracts all that way from you anyway, and by using program changes you still get proper chasing.

This is different with Spitfire and UACC, where e.g. "legato tremolo" is a dedicated CC number. So you send a single CC32/30 for legato trem with UACC, which avoids the multiple-values-get-swallowed.

[_Stevie_]

Originally Posted by tack

I guess you mean you don't have a use for it personally but you understand the value of it for other users?

No, in that case I would definitely use it and switch to regular recording mode, because this is something I can't get in RR mode. So, thumbs up on this one!

Technically it's not UACC (which is a Spitfire spec that defines a specific mapping of values to articulations on CC32), but I'm being pedantic.

Hah, yes you are right, completely forgot that UACC is on CC32

Yep. Kontakt, or Reaper, or some magical faeries in between -- I think Kontakt though -- would consolidate multiple events on the same CC number so that only the last one was actually processed by the underlying patch in Kontakt.
.
.
.

Wow, that's pretty unfortunate. Then a solution to the CC1 problem would be:

- remove CC1 from the Kontakt patch
- still use artic switching per note in Reaticulate, but use a combination of note ons + CCs for the shorts artics (stac, rep, pizz, bartok, etc...).

I'll fiddle around a bit with the bank file!

[tack]

Originally Posted by _Stevie_

Then a solution to the CC1 problem would be:

- remove CC1 from the Kontakt patch
- still use artic switching per note in Reaticulate, but use a combination of note ons + CCs for the shorts artics (stac, rep, pizz, bartok, etc...).

I think you might be over complicating this?

The factory banks for CSS that come with Reaticulate don't use CC1 at all. The different shorts can be engaged just by different note velocities. You can do all keyswitching purely with notes.

So this should just be a matter of unassigning CC1 from the shorts dial. And it should work just the same with CSB.

[_Stevie_]

Oh! LOL, I was just about to have a look at the bank file.
I didn't know that you could literally choose the shorts via velocity. That indeed makes things super easy. Thanks for pointing that out. Will just remove the CC1 then

[vsthem]

Discovered that Reaper is chasing my CCs for velocity, but not my keyswitches. Before I dive into Rearticulate, one other question:

I have my libraries setup to latch on Staccato whenever I hit the sustain pedal, and then go back to my previous articulation. This is because my most common move is to go to staccato in the middle of a phrase, and I like to be able to do it with my foot. I'm using Reaper's CC Mapper to change the control value of my sustain pedal to CC116, and then assigning that CC in Kontakt.

Is this , or something with a similar outcome, possible to setup in Rearticulate?

Thanks again for all of your quick, clear, and detailed replies!

[tack]

Originally Posted by vsthem

I have my libraries setup to latch on Staccato whenever I hit the sustain pedal, and then go back to my previous articulation. This is because my most common move is to go to staccato in the middle of a phrase, and I like to be able to do it with my foot. I'm using Reaper's CC Mapper to change the control value of my sustain pedal to CC116, and then assigning that CC in Kontakt.

Is this , or something with a similar outcome, possible to setup in Rearticulate?

Reaticulate can send pretty much whatever you want (CC64 events in this case) when you activate an articulation via Reaticulate itself. What you're talking about though is effectively equivalent to manually using a keyswitching system outside of Reaticulate. This will work, technically, in that you'll be able to control the patch as usual. It's just that, depending on how you've configured staccato in Reaticulate, the articulation change might be invisible to Reaticulate because you're bypassing it. So Reaticulate will think you're on longs (or whatever) when in fact you're actually on staccato because you've got the sustain pedal pressed.

Reaticulate doesn't currently have the facility to observe a CC64 range (here any CC64 value between say 1-127 to reflect sustain is active) and realize that you've actually manually triggered staccato. (It's planned.) It actually does currently support this for discrete events, so if you had a discrete sustain pedal that sent CC64/127 and your staccato articulation as defined for Reaticulate sent CC64/127, if you pressed the sustain pedal Reaticulate would notice you've gone ahead and manually triggered the articulation and reflect that change visually in the GUI. But it has no notion of "previous articulation" to show that once you've released the sustain pedal (CC64/0) it went back to whatever was active before.

In other words, there's no way to model your latching behavior to have Reaticulate detect that you've in fact bypassed it for the articulation change (i.e. you didn't use a program change event). But that should just purely be a cosmetic issue and I think things should otherwise right in terms of controlling the patch.

[Shootkin]

Thanks so much for your excellent work! I'd like to take the liberty of asking you for a small FR: is it possible to remove the gradients from the buttons so this would perfectly fit to my completely flat theme? Thank you

[vsthem]

OK. Installed it. Love the simplicity and look of it. So far though, I have not been able to use my touch OSC to trigger Reaticulate. I was using Touch osc to send keyswitches before.

I changed the sample library to UACC, and then made a test button that sends CC32, range: min 1 max 1, ch1 to trigger Unison Long. This button works within the library, but when I start up Reaticulate, it no longer activates the articulation change.

Any suggestions as to how to get this to work? Or is there additional documentation that I can peruse?

Really looking forward to integrating this extension. It looks great! I just want to be able to trigger articulations, in addition to being able to click them in.

Thanks!

[vsthem]

managed to trigger "long" with

program change

channel: 1

Range: 1 1

But I can't get Staccato (or any others to trigger) with

program change

channel 1

range: 40 40

Getting closer, but any help nudging me in the right direction would be greatly appreciated. Trying to get this to work mostly through trial and error.

[tack]

Originally Posted by vsthem

Getting closer, but any help nudging me in the right direction would be greatly appreciated. Trying to get this to work mostly through trial and error.

You'll want to do this by binding to one of the actions to select/insert articulations:

https://reaticulate.com/usage.html#actions

So for example, suppose you had your control surface send out CC 119 on various values to activate various articulations. Then you'd bind CC119 to "Activate articulation by CC on default channel" as a standard Reaper action. Then when you send CC119 value 1 on your control surface, Reaticulate will activate the articulation with program 1.

As of 0.4.0, triggering this (and similar) actions twice within 500ms will change from activation to insertion (as if you had right-clicked the articulation in the GUI).

[tack]

Originally Posted by Shootkin

is it possible to remove the gradients from the buttons so this would perfectly fit to my completely flat theme?

It's technically possible of course, but adding more features to control Reaticulate's look and feel isn't super high on the priority list.

But as always, the more demand/interest in a thing, the earlier I'm inclined to do it.

[_Stevie_]

I’m not sure if there is a solution for this issue:

Often, I want to record another item with a new articulation. Let’s say, the previous item had Legato but for the next one, I want to record a Staccato part. Now the issue is, every time I press the Staccato button in Reaticulate, Reaper will chase the previous PC and switch back to the Legato articulation again.
Would there be a way to solve this, something like a „lock articulation“?

[tack]

Originally Posted by _Stevie_

Would there be a way to solve this, something like a „lock articulation“?

Isn't that basically what the "Insert current articulation and CC profile in current MIDI item or create new item" idea from above would solve?

For now you'd have to manually create the MIDI item and insert the new starting articulation before recording.

Or just insert the articulation while recording.