The idea behind exclusion groups is that they allow you to specify which other playing techniques must be removed when another is added: at its simplest, “pizz.” removes “arco” and vice versa, or “mute” removes “open” and vice versa, but it gets a lot more complicated when you consider that e.g. “col legno” needs to remove “pizz.” which needs to remove “snap pizz.” which needs to remove “left-hand pizz.” which needs to remove “sul pont.” which needs to remove…
Hi Daniel and others,
Re: Programming a Con Sordino effect in the Chris Hein Solo Strings
I have put together an experimental expression map for Chris Hein Solo Strings Extended. Its based on the Cubase Expression Map which comes with the Library but I have extensively modified it to be more comprehensive of the many string techniques and to match it to the techniques that already exist in Dorico. I can say that its a great library if strings are important to you and you want use them all the various possibilities of these instruments. There are many types of short and spiccato/jeté/sautillé sounds and you can program a change in a sound in context by simply altering the attack on the note head using MIDI CC. As well there are many other effects even including a jazz doit and fall. Nice!
However I do not understand what I would to program in the con sordino function of this library. The CH solo strings uses an audio filter instead of samples to create the Con Sordino string mutes (as others have done), which is smart programming and saves a lot of sampling space. It uses CC 48 for Sordino on/off which I presume is a MIDI value of 127 for on and 1 for off. Dorico is using a mute glyph/symbol (looks a bit like an M) instead of the words “Con Sordino” or “Senza Sordino.”
My problem is that I am still not clear on how all this works. I want to program this effect using a CC controller and a value. However there is no sordino glyph to select or match to in the Techniques dialogue box on the Expression Maps page. That also means there is no Technique to select in the Techniques symbol dialogue page. How do I deal with this? Also is it possible to have all the other features of the sound library work along with the Sordino or is there some sort of exclusion principal at work? (Arne Wallander complained about a shortcoming such as this in his introduction to the NotePerformer for Dorico.) There are a lot techniques that you can map to keyswitches in the Chris Hein Solo Strings (and many keyswitches available too) and it would be great if I could just make them all sound as Con Sordino just by putting on the Sordino filter. Its effectively what happens on the instrument too.
I also just wanted to confirm whether basic legato works in Dorico or if notes just always default to 75% of their note value. I have had contradictory information about this.
Can anyone write down in plain English what the technique “Natural” is all about and how it has to be used or can refer me to where it is fully explained in one place? Is is just a stand-in for the basic Arco technique but which can one apply to any instrument?
I deeply respect what has transpired with the development of the Dorico music notation and performance software over the past two years or so. So many great advances! However, I wrote a post with a request a while ago in regards to the need for more documentation on Expression maps. You said in reply that there was no such document ready or one planned at this time and that the Expression maps feature set was not complete yet. You added some explanations on the forum about a few of these matters (which were appreciated) but some of it was a bit confusing for me or presumed some prior knowledge I did not have.
Would it not save time to write a document that clears up some of the more important questions rather than you having to read and reply to all of this stuff on the forum which is also itself partly generated in the first place by the lack of fuller documentation?
Re: Incomplete programming of Performance and Expression Maps Features in Dorico
I would like to express that it seems to me a bit pointless to add features to the Dorico that presume in the first place that the performance and expression maps features work properly, especially when I am increasingly getting the impression that they don’t. Myself and a colleague would really like to use Dorico to score to film. You have added that feature in a pretty comprehensive way to the program. Yet the performance aspect of Dorico needs to be at a critically high level in order to make use of what could be an excellent new video scoring capability. You have even added professional audio output features such as recording to stems. That is not available on Sibelius. Its impressive that you thought of doing this. And you are about to add transcription of real time keyboard playing. Yet you have admitted that the performance aspects of Dorico are incomplete right now. Why not fix this critical aspect of the program first before adding new features that entirely depend on this key aspect of the program?
I admit that I can not possibly understand the complexities of what you are doing so there may be a deeper programming reason for why you are not completing this area at this time. However, I want to just tell you that it is the performance aspect of Dorico that keeps me from switching fully from Sibelius and fully recommending your program to others at this stage. There are complex reasons for this on my part and I am using Dorico for some publishing and part printing - but I can’t ditch Sibelius yet although I really want to. Working with both programs in frustrating partly because I want to make the switch and fully learn all the many lovely streets and alleyways of your product.
However, if NotePerformer could just sound as good in Dorico as it does in Sibelius that would be all I would need right now. Unfortunately my music sounds choppy in the Dorico version and I think I know why. Arne’s critiques make sense to me and truly I do not fully understand some of your response to them. I am hoping this is all a very temporary situation but your recent replies to similar questions and requests on this part of the forum leaves me feeling discouraged.
I hope I am mistaken in what I assert here and would warmly welcome being corrected in these matters.
I’m increasingly under the impression that a specialised “keyswitch” ossia staff would be the best way to work in Dorico in the future, something that you could quickly open with a shortcut, that doesn’t get printed, that you can quickly hide again so it doesn’t interfere with layout and with dedicated clefs that go really low or really high. That, in combination with the already available MIDI CC drawing and the upcoming keyboard transcription would make Dorico as powerful as any DAW for quality Playback.
The reason being notation will never represent a players’ instinct, no matter how sophisticated the program is. For example,
- a staccato keyswitch is inappropriate at very fast tempos or slow ones, a real player will play staccatissimo on fast tempo, despite the score having staccato markings and simply cut the note short on a slow tempo (what VSL calls portato), in other words it’s completely tempo dependant.
2.- what we call sustain, most woodwinds will tongue, very delicately, on reasonable passages, but on very fast passages they will always play legato unless you specifically ask for double/triple tonguing.
3.- Legato in real life begins on the second note of a phrase, but it’s notated from the first
4.- SFZ, fp, etc. all need tempo and dynamic context, a one-dimensional keyswitch simply doesn’t cut it.
Most of the necessary tools are already in Dorico (for example the ossia has a Playback start offset, perfect for keyswitches!) It’s just missing this specialised staff that hides and has special cleffs.
I use to work like this in Sibelius when I needed a good playback demo and aside from the extra staves and the lack of proper CC control it was actually quite effective.
Bollen, I agree with your point. Since the intent here is for playback and not printed score, I’d think the team would rather expand the functionality of the current PT rows in Play mode. That would maintain the distinction between what is to be printed and what is to be played, which is the advantage of modes.
For the time being, I would suggest assigning an additional staff exclusively for Key Codes. You can assign the second staff to the same MIDI channel for playback and omit the staff in the conductor layout.
Derrek, are you saying identical parts in both, mute the first “written” staff, and write in the extra desired playback articulations on the second staff?
I’m saying notes on “Flute” staff and “Key Code” (ultra-Bass) “notes” on the “Flute KeyCodes” staff. IMO That makes as much sense as creating an ossia staff for them and avoids any possible restrictions/complications using an ossia might occasion.
Nice idea, but where do you write it in? In its own layout?
Bollen: sure. That’s the beauty of layouts. Super-easy to make a new one as needed.
I do this often for things like making a performing edition from an urtext. Copy the parts from one to another, and add stuff as needed. And the “both flutes” Layout is never printed or viewed beyond that.
Aha! So you would basically create an extra layout that contains just the instrument and its “key code” staff and you toggle to it when you need to make a change?
Yes. For a simultaneous urtext and performing edition, I make a layout called “flute master” or whatever, and use it for comparison purposes only. Easy way for me to quickly compare the difference between the two.
So for more accurate playback, your “playback score” would have your “playback” instrument parts, and your “print score” has your visually correct parts.
Hmmm… I’m not sure I’m following… So you have 3 staves then? 1 written part, 1 playback and one keyswitches?
I often have to produce a piano/vocal score in addition to a conductor’s score for the full instrumentation. So I have gotten into the habit in such projects of letting my first full score be a Working Score which contains everything, all the instruments, all the vocals, and the rehearsal piano part. It may also have multiple staves for, say, Flutes 1 & 2 combined and the individual flutes, at least until Dorico comes up with the combination capability. I never print the Working Score; so I do not need to format it beyond what Dorico does automatically. (This aspect of not formatting was even more important in Finale.)
From this Working Score I create two special layouts which I do format: one is a Conductor’s Score, which leaves out the rehearsal piano; and the other is the Piano/Vocal Score, which has all the vocals and the rehearsal piano.
I may create other layouts for special input, and of course I’ll eventually have layouts for each part.
Dorico’s layout system is a really flexible tool, and I try to make every use of it I can imagine and need.
Ok, I think I get it, but to stay on topic… You make a Working score and when you’re finished simply create a conductor’s score by clicking only on the instruments in the Working score that have music you want to print… Is that it?
Yes. Or actually, I just make layouts at the beginning when I’m setting up the score, since I know what I’m going to need.
For a string Quartet, your layouts may look like this:
- All scores
- Playback score
- Conductors score
- Violin 1 master (contains two players: violin 1 print and violin 1 playback
- Violin 2 master
- Viola master
- Cello master
- Violin 1 (print)
- Violin 2
It’s not necessary to make all these iterations, just showing you possible formats. As an added step, you could mute all the printed parts so they don’t playback; and propagate that property.
If this seems tedious, remember that creating a layout takes all of 5 seconds!
Brilliant! Although technically you might not need the violin playback, just a violin keyswitch lane, since Dorico allows you to edit duration, positions and MIDI CC without altering the notation… This is definitely the way I’ll work in the future if I ever get Dorico to work on my PC!
Thank you for your time!
Ah! Found a limitation with this approach and that is that you can’t export stems… boooo! Keyswitches get exported separately so the instrument doesn’t have any articulation changes… Also, some keyswitches play havoc with the layout, even with the appropriate clef, some are just too low or too high and there’s no way to move the staves away from each other in galley view. Oh well, we’ll just have to wait for a dedicated keyswitch lane/staff… Wink, wink devs…