Articulation Mapper pre-release thread

[Hafer]

I'm still looking for a solution for attaching "one-note-artics", that is, articulations which turn itself off after affecting the attached note only.

Why? Because the notation shouldn't be cluttered with articulations like "long" or whatever it takes to switch back to normal play.

The screenshot shows where I want to attach artics (every 8th, even those yellow ones) - no artics for the 4th.

It's probably only a matter of configuring the articMap correctly, but that's beyond my understanding.
Any hints?

[pcartwright]

I don't think there's a way to designate a default setting (that is, a setting for non articulation notes) yet.

[Soli Deo Gloria]

Originally Posted by Commala

I don't know what you mean by text articulations exactly. There is the action "Insert text notation..." but I didn't realize this could insert text articulations... but if that's what you meant, there are separate actions to delete "text notation" (aka text articulation?) vs glyph articulation. It'd be good to be clear though about text articulations, I wasn't aware that those existed. I think text notation includes chord texts

Or do you mean text ornaments? If so there appears to be an action now that does work to delete text ornaments and not other ornaments, called "Notation: delete note text ornament". At least since pre 9.

I know, you blink and you miss it right?

Yes, sorry, I blinked and I effectively missed it since there already are actions to insert what I want (the note texts that are loaded with a ReaperArtic map). Two things I could observe about them :

- They don´t show the list of text names loaded with the articulation map for now (you have also commented about this here http://forum.cockos.com/showpost.php...postcount=1104). A popup menu or dialog to select the names would be useful.

- The actions refer to "Text ornaments". This confused me for a while since "ornaments" are another type in the maps´definitions, aren´t they? Nevertheless, they do what I´m talking about, without the popup list of text names loaded with the map. My workaround for now is to copy the list of text names in a spreadsheet and I click on each cell, copy the name and paste it rapidly when the box of the "add text ornament" action appears.

[hopi]

Originally Posted by TryingToMakeMusic

Cockos, please remove this limitation and allow us to define custom articulations? Some orchestral libraries offer an array of articulations which won't correspond well with any predefined list based in the notation-editor. For example, Orchestral Tools:

I'm in this same boat...
would like to use Track [not note] artic's and have them show up in the menu in the same way I have named them in the map file...

Am I dreaming?

[hopi]

Originally Posted by pcartwright

I don't think there's a way to designate a default setting (that is, a setting for non articulation notes) yet.

for a temp workaround ... could he perhaps define one note artic that used a MIDI note number that was not in the instrument... in other words it did nothing.... and put that on the next note where he does not want articulation...

[hopi]

Originally Posted by pcartwright

Also, I think track articulations must have a channel assignment (no * allowed). So this text map wouldn't work.

This should send a keyswitch to channel 1 at note 95 with a velocity of 127 whenever text value of Overblown is given:


track text Overblown : keyswitch 0 95 127

Oh PC ... YOU are Soooo right I could kiss you!

That is exactly the formatting that makes it work!
...and it makes me feel a little better that I am not the only one confused... hahaha

[pcartwright]

@hopi and anyone else looking for help with articulation maps:

Would you be interested in a video tutorial about building and using articulation maps? Perhaps a corresponding pdf that would that walks you through the basics and maybe venture into some advanced concepts?

Based on schwa's comments in this thread, I think we still have a long way to go before articulation maps are officially released, so some of these issues and pain points may get resolved by then. I'd be happy to put something together once articulation maps get to a release candidate build.

Let me know your thoughts.

[pcartwright]

Originally Posted by hopi

for a temp workaround ... could he perhaps define one note artic that used a MIDI note number that was not in the instrument... in other words it did nothing.... and put that on the next note where he does not want articulation...

I haven't tried it, but a strategy like that sounds possible. He'd probably want to assign the "nothing" note artic to whatever keyswitch, cc, or channel that he wants to be his default sound (assigning to an unused key probably won't do much).

Personally, I probably won't use this feature for a project until it gets built out a little more (just for the sake of compatibility later). It sounds schwa intends to spend some time on this, so I'm not going to look into workarounds until I get a better sense of what the final version will look like.

That's just my two cents.

[mpb2016]

I love the articulation mapper! I have a problem getting whole note trills working though. Normal trills are no problem:

note ornament trill : keyswitch * 14 127

..but what should I use for whole note trills ?

I tried this, but it didn't work:

note ornament "Whole note trill" : keyswitch * 15 127

Also, making a subfolder in the articulation map folder seems to produce some sort of loop where the same folder appears several times:

[pcartwright]

try whole_note_trill instead of "Whole note trill" and it should work.

The articulation or ornament name needs to be exactly as it appears in Reaper's MIDI event list for the built in articulations and ornaments to work.

[mpb2016]

Yes, that worked! Thanks a lot

[hopi]

to pccartwright...

first a little report... though most likely everyone but me already knows this..

using the format you gave me for track text... we are nicely able to enter the matcing text in Sibelius, export that as an XML file, load it into Reaper with the corresponding Artic map and it all matches up and works fine.

That said... with great thanks... back to your thoughts about a PDF and video guide:

The basic answer of course is a big YES...
...for some people, dealing with the abstract instructions for Artic file creation and formatting suits them fine... but for others like this dummy, what is needed are more 'learn by example' instructions.

I'm really brilliant at some things... just not these things... %^)

However, I can follow instructions that clearly show examples ...
For instance... the instrument I've been trying to articulate is the Mojo Horns tenor sax... lot's of keyswitches and not especially common to some more simple instruments.

I took the PDF pages of the switches out of the manual as jpegs, rotated them in PS cuz they are sideways in the PDF, removed a lot of black background bullshit, again in PS.... made a new PDF of that, and got a decent OCR out of that as a text file. Good starting point from which to create the Reaper Artic map.

But then the thrashing about with what the various Artic map formats actually do and don't do in Reaper. And lots of trial and error... such as not understanding that note text gets bound to a note and cannot [AFAIK] be removed or repositioned without affecting the note it bound to. Seems odd but that was a major issue.... that eventually, thanks to you, led to the 'tarck text' method.

The point is that without a clearly explained and "example-a-fied" [now there is a George Bush word!] the frustration and pain can really put one off. I almost gave up more than twice.

So again, YEAH... A PDF guide and videos would be a great help to everyone, DEV's included!

And yes, I understand what Schwa has said, but I've been around this joint long enough to have great faith in him and all the DEV's. Clearly Reaper is their 'baby' and they do want it to shine and be the best it can be. Maybe not always on the date "I" want it, but they do seem to get there in their own Cockos way.

FYI, I'm better at graphics and document layout than this stuff so if I can be of help to you, consider me 'in'.

Amen

[MorkV]

By the way, after Reaper has got Articulation maps I think should embed delay(such as how js_time_adjustment) at a track, It's especially necessary for orchestral template with >100 tracks...
And It would be very good if also a 'delay adjustment' add in articulation mapper, for example:

track text staccato(articulation "staccato" in SuperEpicOrchestralLibrary delayed at 100ms) : keyswitch * 97 127 -100ms


track text legato(articulation "legato" in SuperEpicOrchestralLibrary delayed at 300ms) : keyswitch * 98 127 -300ms

[musicbynumbers]

Although this technically could be dealt with as a latency plugin (that adds just enough latency to pull the vst back in time) I would love delay too if possible as then it can be forgot about and doesn't affect recording.

Quite a few sets of things like strings (looking at you LASS) have some quite bad latency when dealing with divisi scripts prior to outputting from them.

The ability to pull them back in time would be great (but, if a lot of effort, maybe not that needed?)

[Hafer]

Originally Posted by pcartwright

Would you be interested in a video tutorial about building and using articulation maps? Perhaps a corresponding pdf that would that walks you through the basics and maybe venture into some advanced concepts?

That would be great. A stash category would help, too.

It's probably too early, though.

[pcartwright]

A nitpick:

Suppose I have the following map:

	track	text	Normale	: cc	0	1	0
	track	text	Normale	: cc	0	11	0

Currently, Normale shows up twice in my text menu. It would be preferable to dedup this list.

[pcartwright]

Thoughts on crescendo, decrescendo and other continuous markings:

It would be ideal if we could link these kinds of markings between two events so that the articulation mapper would know how to adjust the velocity or cc events over time. That is, if I crescendo from pp to mp, it would be cool for the articulation mapper to get the cc value associated with pp and adjust the cc over time until it reached the valued associated with mp.

I think the same thing can be done between other like text markings. For example, connect little vibrato to normal vibrato with a dotted line and have the articulation mapper send cc values to connect the two values.

Does that make any sense?

[pcartwright]

One last post from me today

Referring to trills (http://forum.cockos.com/showpost.php...postcount=1106), it would be ideal if the articulation map would differentiate between half step and whole step trills (and others?) based on the key snap in Reaper and not just the type of trill ornament applied.

[musicbynumbers]

Just curious if the amazing CC mapping stuff is going to stay with note mapping files or will it be coming over to articulation files?

I'm still not sure myself which is more useful. Maybe note mappings since it is more accessible then to synth guys

Ideally, I'd like to see all 3 go into one file (but with backwards compatibility for note maps as they are now)

That way this one "editor mappings" file can contain all of it if needed or only the stuff you want.


What's everyone's opinion on this?

[EvilDragon]

I think they should be duplicated to articulation maps (and overriding note maps if a note map with CC names is loaded).

[schwa]

The CC names will definitely stay with the note names, as many users may want to rename notes and CC but not deal with any mappings. But we will probably also add support for renaming notes and CC in the mapping file (or whatever UI ends up providing the mapping functionality).

[Vagalume]

Originally Posted by pcartwright

@hopi and anyone else looking for help with articulation maps:
Would you be interested in a video tutorial about building and using articulation maps? Perhaps a corresponding pdf that would that walks you through the basics and maybe venture into some advanced concepts?
Let me know your thoughts.

Of couse we need that tutorial, you know it

[musicbynumbers]

Originally Posted by schwa

The CC names will definitely stay with the note names, as many users may want to rename notes and CC but not deal with any mappings. But we will probably also add support for renaming notes and CC in the mapping file (or whatever UI ends up providing the mapping functionality).

cool. A UI sounds awesome!

I thought that it could be that this "mapping" file is blank and if people want to use it just for note mapping or CC mapping or articulation then they could just enter the text for those areas alone or a mixture of all 3 (and other bits not even thought of yet too for the future)

It seems a good way (to me anyway) that you should be able to put all of them in one "mappings" file if wanted and that this should overrule any other note mapping settings but the old ones should be kept for compatibility.


Maybe that's just too simplistic though and I'm missing something!

[paaltio]

Originally Posted by musicbynumbers

Although this technically could be dealt with as a latency plugin (that adds just enough latency to pull the vst back in time) I would love delay too if possible as then it can be forgot about and doesn't affect recording.

Quite a few sets of things like strings (looking at you LASS) have some quite bad latency when dealing with divisi scripts prior to outputting from them.

The ability to pull them back in time would be great (but, if a lot of effort, maybe not that needed?)

I'm wondering if a (negative and positive) delay setting is too simple here. Essentially what we're talking about are two different categories: non-zero position transients for short articulations, and slow attacks for sustained or legato articulations. For the latter you need not just offsetting, but overlapping note endings and starts.

I think if the articulation mapper develops into this direction, you should probably implement a more full-featured event transformer that allows doing that and more.

In fact, if we're going on the route of further articulation metadata, I'd argue dynamics mappings become a thing as well, because then we're already so close to really good score playback (i.e. without any piano roll tinkering or CC recording) that you might as well go the full way.

Since this is REAPER after all, maybe there's some way to include scripting in this as well, so someone can write a neural network articulation AI!

Okay, getting a bit out of hand, so let's stick to the event transformer idea first...

[EvilDragon]

Originally Posted by schwa

The CC names will definitely stay with the note names, as many users may want to rename notes and CC but not deal with any mappings. But we will probably also add support for renaming notes and CC in the mapping file (or whatever UI ends up providing the mapping functionality).

Schwa, what about the possibility to completely remove a CC from the list?

[musicbynumbers]

Originally Posted by EvilDragon

Schwa, what about the possibility to completely remove a CC from the list?

I'd like that too.

Maybe a line of text you could put in that would make it wipe all but the ones you've changed the names for?

[EvilDragon]

In fact, perhaps outright hiding them from all CC lists might be a bit... er, heavy-handed?

How about actually tucking it away in a submenu? So, instead of a huge list with over 128 entries, you get a list with just the entries the articulation map/that particular VST instrument NEEDS, and all others are still accessible, but in another menu sub-level?

Makes things a lot more organized, no? schwa, please say you like this idea!

[musicbynumbers]

Originally Posted by EvilDragon

In fact, perhaps outright hiding them from all CC lists might be a bit... er, heavy-handed?

How about actually tucking it away in a submenu? So, instead of a huge list with over 128 entries, you get a list with just the entries the articulation map/that particular VST instrument NEEDS, and all others are still accessible, but in another menu sub-level?

Makes things a lot more organized, no? schwa, please say you like this idea!

Agreed that's a good middle ground there!

[pcartwright]

Originally Posted by pcartwright

One last post from me today

Referring to trills (http://forum.cockos.com/showpost.php...postcount=1106), it would be ideal if the articulation map would differentiate between half step and whole step trills (and others?) based on the key snap in Reaper and not just the type of trill ornament applied.

I still think having the articulation map differentiate between half step and whole step trills based on key snap is the right way to go. However, I think this would be a good alternate solution.

Create trills indicating number of steps between root and trilled note. For example:

half-step trill
1/2 tr ~~~~~~
or
m2 tr~~~~~~~

whole-step trill
1 tr~~~~~~
or
M2 tr~~~~~~

whole and a helf trill
1 1/2 tr~~~~~~~~~
or
m3 tr~~~~~~

whole and whole trill
2 tr~~~~~~~~
M3 tr~~~~~~~

This method isn't really standard, but it would cause less confusion when writing map files.

Thoughts?

[Hafer]

Originally Posted by pcartwright

Thoughts on crescendo, decrescendo and other continuous markings:

It would be ideal if we could link these kinds of markings between two events so that the articulation mapper would know how to adjust the velocity or cc events over time. That is, if I crescendo from pp to mp, it would be cool for the articulation mapper to get the cc value associated with pp and adjust the cc over time until it reached the valued associated with mp.

[...]

Does that make any sense?

+1
Let's make dynamics, er, dynamic!

[DANIELE]

Originally Posted by pcartwright

@hopi and anyone else looking for help with articulation maps:

Would you be interested in a video tutorial about building and using articulation maps? Perhaps a corresponding pdf that would that walks you through the basics and maybe venture into some advanced concepts?

Based on schwa's comments in this thread, I think we still have a long way to go before articulation maps are officially released, so some of these issues and pain points may get resolved by then. I'd be happy to put something together once articulation maps get to a release candidate build.

Let me know your thoughts.

I'm very interested.

[Soli Deo Gloria]

Originally Posted by EvilDragon

In fact, perhaps outright hiding them from all CC lists might be a bit... er, heavy-handed?

How about actually tucking it away in a submenu? So, instead of a huge list with over 128 entries, you get a list with just the entries the articulation map/that particular VST instrument NEEDS, and all others are still accessible, but in another menu sub-level?

Makes things a lot more organized, no? schwa, please say you like this idea!

Totally agreed!

Further suggestions for the articulation names in the notation editor :

- Ability to be selected
- Possibility to clean selected names
- Separation between names when there is clutter (putting them maybe up and/or down to avoid collisions)
- Some kind of tie for each name to be related in a visually clear manner to its corresponding note. With many articulations, if the kind of separation suggested above (or similar) was implemented, some kind of ligature between notes and their articulations would be needed, I think.

Some of these were already proposed somewhere, but I just wanted to compile what I think are some useful potential features...

[paaltio]

Something that I just realized that is tangentially related to the recording of articulations is that current scripted solutions to retrospective record, like eugen2777's excellent one at http://forum.cockos.com/showthread.php?t=168855, won't work with them given that articulations are non-MIDI metadata.

If there will be full scripting support for articulations I guess this issue will be solved eventually... but I can't help but use this occasion to strongly wish for an official, native retrospective record again! I feel this is the stage where it's really going to become obvious that the scripted solution will be a compromise. Retrospective record is really the only way many people work, and I personally can't see myself ever going back into a separate recording phase anymore...

But if official support is not coming, then hopefully at least the existing scripts can be updated to support articulations with some new APIs.

[pcartwright]

Originally Posted by paaltio

Something that I just realized that is tangentially related to the recording of articulations is that current scripted solutions to retrospective record, like eugen2777's excellent one at http://forum.cockos.com/showthread.php?t=168855, won't work with them given that articulations are non-MIDI metadata.

Maybe I'm misunderstanding you, but I'm pretty sure articulations, ornaments, etc., are indeed MIDI metadata. Notation events (outside typical note placement) can be seen in the event view. The first two MIDI bytes are 0xFF and 0x0F followed by a string describing the articulation.

[schwa]

As you may have seen, we've pulled the articulation mapping code out of the official release for REAPER 5.32. I think we are going to work on this offline for a few releases, because the feature needs to be a lot more complete, especially on the UI side, to be useful.

[hopi]

yeah... it does... and darn, we were just getting used to the new flavors

well at least we know it will only get better!

[Hafer]

Originally Posted by schwa

I think we are going to work on this offline for a few releases, because the feature needs to be a lot more complete

ACK, but does that mean no user feedback until official release?

[schwa]

Articulation mapping will definitely not end up in a release without a lot more user feedback

[paaltio]

Originally Posted by pcartwright

Maybe I'm misunderstanding you, but I'm pretty sure articulations, ornaments, etc., are indeed MIDI metadata. Notation events (outside typical note placement) can be seen in the event view. The first two MIDI bytes are 0xFF and 0x0F followed by a string describing the articulation.

Oh, that's interesting! Did not notice that. Still though depends on the articulation recording implenentation whether an input JSFX will be able to catch these.

[pcartwright]

Originally Posted by schwa

Articulation mapping will definitely not end up in a release without a lot more user feedback

Hehe, good. In that case you might want to consider adding support for channel pressure and pitch bend.