I’ve found the Transpose function and enabled it for the minor sound playing technique, i.e. transpose set to “12”, but after applying it to a note, it doesn’t actually transpose it an octave higher. I’ll try the tricks you described above as well …
EDIT: It seems the problem is that the playing technique simply refuses to apply, and it stays on Natural. I’ve been able to make it work in a fresh document, but in my existing notation, there seems to be some conflict …
I might have been mistaken about being redundant with the natural node.
Give it a try like so.
natural (transposition value)
maj (transposition value)
min (transposition value)
dim (transposition value)
Put all these in an exclusion group.
I like the sound of the CSS Solo Strings but it seems the company are determined to dissuade you from trying to use it with Dorico or other notation software primarily because of the complex way they implement legato. From your latest experiments, would you say it’s more trouble than it’s worth or is it already viable with Dorico 3.5 (of course new EM features will be added in time). Do you have any projects which could give an idea of what we might expect? I’m largely interested in the solo strings but orchestral would also be of interest.
I’m working with the BBCSO Celeste. In the default map the primary output is set to CC1 and the secondary CC11, as it is for all the rest of BBCSO. However the Celeste, being a keyboard instrument, responds to velocity first and CC11 second in the BBCSO. Changing that however I don’t get altered output. By default, for example a pp line with “muted” playing technique triggers the proper switch, and all the notes are set to velocity of 100 (per the velocity lane) which is really banging the Celeste. I’d expect in this case that the pp volume would output a quieter velocity, but not so. The only way to get quieter output is to pull all the velocities down manually.
How is this supposed to work? I’m expecting that while the created note has a velocity of 100, that the expression should bring in the volume of pp to tone it down, and output some combination of velocity and CC11 to do it. Note that for this instrument velocity != CC11. Velocity actually triggers a different patch layer (e.g. a hard hit really rings the celeste), where CC11 probably is just an algorithmic volume.
bit lost here. You can change the default CC1 to velocity if you want and it shows velocities pp = 24, p=41 f=87 as an example. The dynamic contrasts are higher using velocity than CC1 - excessively so in my opinion which is why the default has been mapped to CC1 which gives more natural dynamic scaling. However as the celesta does respond to velocity you can fine tune the CC results using velocity – that’s how I would do it. I don’t think I’ve ever needed to change the CC11 value with that instrument.
yeah me too 
Working with BBCSO I find that velocity so sometimes ends up being a sticking point. With the horns I kept getting “blats” on a quiet passage, and the only way to quiet it down was manually toning down the velocity. OK fine, but now with the celeste I’m having the same issue which is velocity is “pinging” the notes way to hard, and the volume isn’t changing with dynamics. Let me show you
Here’s the celeste line, notice the pp volume, the velocity of 100, and the muted expression. This is all correct, except AFAIK I didn’t specify the velocity and have no way to change the default. Of course I can change the individual velocities manually.
Here’s the expression map
Let’s stick just to the standard “sustained patch” just now to make life simpler (I’m getting slightly odd things with damped/mute). You have four basic ways to control this 1. primary velocity secondary CC11 2. primary CC1 secondary CC11 3. primary velocity secondary disabled 4. primary CC1 secondary disabled. I show the controller lanes for the first three options. When activated, CC11 should match CC1, otherwise just a straight line. Disabling the secondary CC11 seems to almost eliminate the dynamic response so I’m wondering if that’s what you’ve maybe done on some tests? At any rate, it seems it must be activated for the system to work properly.
I find actually not such a great difference between using vel and CC1 on the primary but, as before, a somewhat smoother response with CC1. Velocity always shows 100 when not activated as a controller-- this is the Dorico default which as far as I’m aware cannot be changed – there have been one or two discussions on this. If you need to change it then it will respond with instruments like celesta which I think is what you’re finding.
A final consideration, though I haven’t found an issue with a small test project like this, is that the correct dynamics don’t always kick in straightaway If, for instance you stop playback and then continue, it sometimes sounds on one or more tracks much too loud until a new dynamic forces a refresh. The readback is not totally reliable. It’s much worse with the BBC SO than any other library I’ve tried and could be what you’re experiencing at times.
Exactly how velocity and CC1 interrelate across the board is most certainly not a simple thing to understand and get right with this library under Dorico but there are none that don’t need tweaking (why otherwise would anyone want to use a DAW?).
Here is a simple example where I used CSS with legato:
Creating the legato for CSS was pretty fast with my custom playing techniques, it took maybe 10 minutes total. But I didn’t do any tweaking with the dynamics, which you can certainly hear.
The whole process of scripting legato could be automated in expression maps, if it had these conditions:
Previous note length
Possibility for note length to be 0 (rest)
Previous note length is necessary to determine the correct speed of legato. If the previous note length would return 0, that means that the note is first of the phrase. Besides that, also possibility to control note offset (in ms) is needed for this.
I personally think, that CSS is very friendly library for notation softwares, since they have spent a lot of time balancing the instruments.
Hi everyone!
I’m really happy to announce the Expression Maps for our SYNCHRON-ized Special Editions Vol. 1-7.
Simply go to https://www.vsl.co.at/MyVSL/Notation_Related and download and run the installer from there.
And make sure to check out the Dorico live-stream in a few hours!
Best, Ben
AIeeeeeeee! Bug with my setup, I’m using MIDI Instruments outputs (over the IAC midi interface) to Cubase. The Harp and Celeste had gotten swapped. In fact I don’t remember setting these up, Dorico must have intelligently assigned them when I first mapped an instrument? Or maybe I did do it … at any rate at one point I changed the ports for Harp and Celeste but the maps didn’t swap.
At any rate yes it’s now setting the velocity properly. But in the map I suggest setting velocity instead of CC1, as CC1 doesn’t affect the patch (you can verify by playing some notes while twiddling CC1).
It’s interesting seeing the interplay between velocity and CC11 now. Working much better, except a pp is staring from zero in the dynamics, and it also sets a velocity that’s way too low. What’s the handoff between the primary and secondary dynamic? From the naming it seems the first is for volume, and the second is expression. With the Celeste CC11 is apprantely an algorithmic volume (which doesn’t exist for a real player, you can only hit the key with a handful of intensities)
In an experiment with volume markings and hairpins, a pp< starts off from silent which isn’t good, and slowly increases. I pushed the minimum velocity up to 40 which helps a bit and also played with a volume power curve dynamic. Still starts from zero. Hmmm
thanks for the example – sounds perfectly decent to me. Perhaps John and others from CSS support may be persuaded to add Dorico to their “approved” list before too long. What I’d ideally like hear is something is something which mixes lyrical and fast and dramatic music together as this is where libraries tend to run into difficulties. They may be very nice on lyrical (as CSS clearly can be) or crisp and punchy (like NotePerformer) but getting everything right in mixed music is often a challenge.
just a heads up – I have updated my VSL Synchronised solo strings post here with a new version Expression Maps for VSL and Dorico 3.5 - #16 by dko22 - Dorico - Steinberg Forums. Perhaps the sticky could be updated in due course. The original (or at any rate lupus2’s modification) is already there.
Question regarding Spitfire expression maps, if anyone knows… why do the mappings posted by Paul Walmsley for Solo Strings employ “Note velocity” for the primary volume dynamic?
I get a better result using CC11 for the primary volume dynamic, which decision I made after reading in the Spitfire documentation that CC11 is used for expression. (My own maps for Spitfire, which are a work-in-progress comprising Symphony Complete and Solo Strings, are here. Dr. Walsley’s examples employ CC1 for the secondary dynamic, which I do for my own maps, as well.)
The difference isn’t great – e.g., a few bars of mine featuring solo violin and solo cello, with note velocity vs. with CC 11 – but it’s noticeable enough (especially at the ends of the given excerpts) that I prefer one over the other.
I’d just like to know why Dr. Walmsley (or whoever came up with those Spitfire maps) chose “Note velocity” for the primary volume dynamic. I wonder whether there’s some distinct advantage to the “Note velocity” setting on which I’m missing out.
GM protocol…CC11 is usually expression volume for doing gradual changes to gain/volume…such as crescendo and sforzando effects and is relative to the main channel volume. Velocity does instrument amp/bus volume (usually relative to expression volume, but some instruments might have the latest event of either expression or velocity over-ride…depends on how an instruments amps/virtual signal busses are designed…some might even be configurable at patch level to work either way). CC7 is the top level, true channel volume, and all dynamics for instruments on the channel ‘scale’ with it.
Not sure about Spitfire, but some libraries do use ‘both’ in ways that aren’t exactly conventional for GM protocol. CC11 for gain level and/or changing or crossfading among sample layers. Example String Instrument: Velocity for changing among layers of samples and/or the first attack time in the amp and/or filter driving envelopes (higher velocity leads to a shorter amount of time ramping up amplitude, and might alter filter resonance/levels/ranges or open/close gates to frequency exciing/damping effects at higher velocities…the time/amplitude/filter envelope variable changed by velocity might also be somewhat impacted relative to the expression controller value), while a continuous controller is used to manage the overall volume of the instrument. Sometimes the effects of the velocity control is pretty subtle (or simply doesn’t kick in unless approaching the full velocity of 127), but still there. Adding a pedal event (CC68 or CC64) might even get rid of the initial attack time all together, while extending the release time (legato effect).
It’s conceivable that some libraries might separate many things on purpose, for total DAW control of many things independently. Maybe expression only scales the overall maximum volume, while velocity changes the sample layer, and yet something else might control attack time, and so forth. So, dive into the manuals with instruments, experiment, and where an instrument allows, even look into the design parameters/patches themselves (some are even quite user configurable).
Some libraries give the user choices. Example: HSO that ships with Dorico has a page in its control macro where one can change the main amp volume between a number of methods, and it also has a user adjustable dynamic curve. If one wanted to play a true GM MIDI/SMF file using HSO, he’d want to change the default HSO instrument’s dynamic control from CC1 to Key Velocity.
Disregard CC11 for the celeste. Like other hammered instruments it responds to velocity only.
Actually it’s CC1 - CC11 does work.
Thanks for the detailed response, Brian. After playing about with volume control some more, I’ve discovered that the difference between using Note Velocity vs. CC11 is HUGE with many other samples. CC11 sounds much, MUCH better for Spitfire instruments; using Note Velocity yields an anemic sound that frequently doesn’t even respect my dynamic markings.
If you haven’t already, in the expression map, you might also try setting velocity as the primary, and the expression continuous controller as the secondary dynamic controller, and vice verse.
Also, experiment with the velocity of individual notes in the play tab editor(s) in isolation, with the primary dynamic controller in the expression map being CC11. Why? You might learn that you have extra control over the ‘character’ or ‘timber’ of the note in addition to volume. Experimenting with the velocity of individual notes in some dynamically rich passages might yield interesting options for future compositions. I.E. Higher velocity for a bowed instrument might give a more ‘aggressive’ sound. If this is the case with your library, by experimenting note by note directly from the play tab, you can become familiar with your ‘options’ in getting more from your instrument.
Another way to test the theory is to play the plugin directly with a velocity sensitive MIDI controller/keyboard. Change the expression volume with a wheel/fader/pot on your keyboard, try different key velocities, and you might even try pushing into a key while it is sustaining a note (if your keyboard has after-touch…it might engage an lfo based vibrato, crescendo effects, dampers, etc.). Giving instruments a test drive like this might open you to a whole new world of options that you can either factor into your expression maps, or simply apply directly in the play tab editors of your score.
As suggested earlier, percussion and pianos (and some ‘plucked/strummed’ instruments’) are often very much dependent on velocity for primary dynamic control. Brass, Winds, Organs and Sustained Synths will often be more inclined to rely upon expression volume (possibly others as well if emulating organs with multiple ranks) for shutter/volume control.
Sorry, I don’t have Spitfire at hand to check it out myself, but it’s also worth mention that some plugins/libraries have variations of the same instrument. I.E. A Violin set up to use the General MIDI methods strictly, another that uses the same core set of samples, but handles dynamic and timber control differently (more controller options, but most if not all of them strictly manually controlled by you working the wheels and dials, or events sent by your DAW). Some might classify it as ‘live playing’ vs ‘scoring software or DAW controlled’. BOTH can yield great results with Dorico, with the live variants being super for quick scoring sessions (simple expression maps), and the ones with more intricate/independent controls being great for very detailed mock-up work.
Instruments more geared for ‘live performing on stage’ often try to make things easier for a single musician on stage who only has two hands by applying expressive effects automatically based upon velocity and note value (More aggressive when keys are struck harder/faster, maybe go sharp or flat by micro amounts when playing higher or lower notes such as Brass, or other instruments that often tend to suffer intonation issues in certain ranges in the real world), while the more DAW/Score-Software centric ones tend to spread things out over more independent controls that a DAW can learn and send interpretive information according to your expression maps (or controller entries in linear style tracking DAWS).
Thank you for the example!! Apreciate it!
Hi there,
I have done some small research for my self how to configure Seaboard Rise and Audiomodeling/ Samplemodeling vst instruments for use in Dorico.
If you want to use Seaboard rise in Dorico as an midi input controller for virtual instruments which allows to play with continuous expression, which is suitable for violin, trumpet etc., there is a small issue.
Seaboard Rise transmits polyaftertouch or channel pressure which are not accepted in Dorico as a source of midi data for expression maps. If you create an expression map in Dorico, you can choose midi cc as a source, but not channel pressure or poly aftertouch.
To solve this problem, one can transform poly aftertouch or channel pressure messages from seaboard to midi CC 11 with Midi-ox utility and LoopBe1 virtual midi driver, before it is transmitted to Dorico. After configuring that one can use Dorico expression map for expression cc 11, which is available in Dorico. With this setting it is possible to record expression data with Seaboard Rise in Dorico, edit it and use dynamics which will affect playback. This can yield good results comparable with NotePerformer, or maybe better, because one can tweak every midi data by itself with controller lanes in playback mode.
Audiomodelling vst instruments accept after touch (AT) messages and work with Seaboard Rise, but such setting is not compatibile with Dorico expression maps. Samplemodeling accept AT messages if you set expression CC number to 129, but one can not set 129 in Dorico as a CC in expression map.
A short tuturial how to connect LoopBe1 and Midi-ox
and how to configure Midi-ox to transform midi messages:
In this scenario Midi-ox translation map should be used with input event type “ChanAft”, channel “any” and output event type “ctrl” with “use input value one” checked.I set Seaboard Rise to piano mode to have better performance with legato minor seconds. Seaboard Rise sends midi messages to Midi-ox, then Midi-ox transform it, then send it to LoopBe1. Dorico input midi devices should exclude Seaboard Rise but include LoopBe1.
I wish that Dorico could transform midi messages like Cubase, so using third party utilities would be not necessary.
I hope it helps.
Thanks,
Piotr
