I’m writing an exrepssion map for EW Voices of the Empire. There are a lot of patches that are based on a series of attribute combination (i.e. “Melisma”, “MOD”, “VS”, “Mong”, “Legato”, “Live”, segments, etc…). I begun defining each attribute as “Choral” Playing technique, and then in the expression map I created “Base switches” that just combine them. It seems to work, but now the “Choral” tab is extremely cluttered and I’m not really sure if the template would be easy to use: do you think it would be better to just create one entry for each patch in the “Choral” tab ? Hey would be easier to understand, but would make the tab still more cluttered… What is the common/best approach in such cases ?
Any help would be really appreciated !
Having gone down that rabbit hole a few times, my personal learning is to always put the logic and convention of notation as the most important criteria, certainly above the clutter of the expression map.
When I just started I would create a bunch of playing techniques that were instrument specific - but once the initial set-up was done, I realized that the template lives in the background while I was getting hopelessly lost in the myriad techniques that only worked in this or that single instrument.
The other big issue is that developers often give highly misleading names to patches that in regular notation would be understood as something else.
What I do now is first consider how this or that patch should be notated. So I use the techniques only from the “Common” tab for any patch that’s notated the same way across the instruments (legato, staccato, “natural”).
And finally, I work out how this or that technique would be triggered in the expression map, including multiple patches that are really variations of a single technique and can be triggered via note length conditions, or as add-on switches, etc.
I am not familiar with this EW library, but I had cases before where EW would use the term “slur” to mean a portamento from note to note. It’s not impossible that by “melisma” they might mean an ornamentation with the notation that’s already defined in Dorico. And if I remember correctly EW would use MOD for CC1 and VS for velocity - these were available as “either/or” but perhaps it’s different in this case.
Hi @ebrooks , many thanks for your comment. Actually, “melisma” is a vocal-specific ornamentation where the singer plays more note over a sillable - like in gregorian chant. Melisma. There is also a mention about melismatic lyrics inside Dorico documentation, but it does not apply in this case, since the lyrics are in the patch itself. Anyway, the issue is that there are five different kinds of “melisma” in those pathces (i.e. number of notes over a syllable) and even if there was a “melisma” sign, I do not have any idea what already existing symbol I could use to differentiate them For the moment being, I’ve ended up creating the five “Mel” indication (Mel1 → Mel5)…
Once upon a time I attempted to prebuild expression maps that would ‘hopefully’ interpret almost any score well out of the box so to speak.
Without having a big library of scores at hand to try and test different styles/tempos/etc, I gave up. Not only do I lack the time and score collection to hunt down the best settings…in some cases the maps were growing to get quite large. The score markings required could grow pretty quickly into a myriad of options that’d be really difficult to ‘remember’, thus requiring a lot of extra ‘documentation’ to remember/explain what I’d done and how to use it and make minor adjustments as needed.
Now my work flow is to begin with a very simple map that initializes things (select the proper dynamics type and default articulations keyswitch/program/channel whatever) if required; attempts to choose and set up the best method for dealing with stuff like slurs/legato; and, it might also include all the base articulations/keyswitches/programs/channels, but not yet have them assigned to any score playing techniques.
I pretty much go by what an individual score needs from here (I’ll export a copy of the expression map to live beside my project in the same storage location in case it might come in handy for a similar score later). After all, different scores can have very different needs. Sometimes it’s simpler and more responsive to simply use the CC lanes.
Sometimes it’s even easier and less cluttered to just use a separate hidden instrument or percussion stave with an endpoint to the relative plugin instance to send various keyswitches/CCs/etc (effectively keeping the fancy controller stuff separate from the base notation that’ll show and be printed in engrave mode).
When I say percussion stave…it’d mostly be of interest if you have a really complex plugin with dozens-or-more of keyswitching articulation options/variations at hand. It could get pretty confusing to build and visually keep up with so many of the custom playing techniques for the ‘expression map’ method. An interesting perk of this type of stave is that we can build maps for these, assign custom symbols, and whatever line/space it draws over. If you have a really complicated instrument with dozens of articulations, using a percussion staff just under your printed stave that will ultimately be ‘hidden from view’ outside of galley view, can be a neat way to have an orderly place to just draw in articulation/style changes. Another perk of this, is sometimes you might have an instrument that responds better if you send it various commands well before, or well after the time it’d be sent if you just attached to a note up in the actual printed stave (It can be a challenge to get Dorico to send events at arbitrary times otherwise). In the drum staff, you can use 32nd or 64th notes (sometimes might require a dummy note that you know will yield silence in your plugin, along with a CC or whatever) to send it ahead or behind time if that works better for the application at hand. Finally, it’s pretty cool that you could have different ‘versions’ of this stave. A/B takes to compare and contrast (To disable one go to play tab and point it to nowhere. To enable one, point it to the same plugin/channel as the primary stave you’re providing controls).
It all just depends really. In most cases, when I simply start from scratch with a very basic expression map and add things I need as I go for playback, the maps tend to stay pretty small, and it’s easy to look at them and see what’s going on.
In contrast, when I’ve tried to build all purpose ‘smart maps’, they can get HUGE really fast. It’s confusing to sort through if I need to make changes or build something new/different. It adds to project file size, and could even be less efficient for the playback engine.
Thanks @Brian_Roland . So, I have the impression, from your and @ebrooks comments (but also something else I found in the forum) that those “expression map” could be extremely “neat” when they refer to patches that relies on “common” symbols (e.g. instruments) but then they can became a mess as soon as we attempt to map more “complex” ones (e.g.: some choral/voices that contains words, letters, phrases, etc…), for which I do not have any idea how to properly do: is by chance possible to use, somehow, the “Text” above a note to creat a mapping ?
Over time, as you get to know a given plugin, you might well come up with a good general map that just ‘works’ with most projects.
If you’re in need of really digging in and producing a high quality mock-up…I can pretty much promise you that every score will require ‘different’ things.
Also, as you get to know your plugins…it’s not hard at all to add stuff on the fly as you require it.
I think the most important thing is to set it as simple as possible (like a basic general MIDI instrument) by default. This way you can start composing out of the box, and go back to worry about the ‘fluff’ when you get time and inspiration for all that.
Don’t let tinkering with your toys destroy your compositional flow/inspiration. If you start to sense this happening in the middle of a project, grab a notepad and write down your ideas, and worry about implementing that techy playback stuff later