Dorico in Cubase

Hi @PjotrB,
Yes, the recent Dorification is an amazing first step, and it’s just the beginning of the journey towards what I’m suggesting here, and in posts few years ago.
Just the very beginning of every long and eventful journey has to be planned carefully and well.
In this, particular case, this is the exact time for all of us to share our thoughts, ideas, needs and expectations with the developers’ team.
I’m aware that many things are, probably, in their list already. Many of them are professional musicians, too. Having all these things in mind, I don’t think that we have just to stay away from the process waiting for the things we need to happen. Still we do not access to their list of features that are planned for implementation, so we don’t know what is there, no matter how logical it sounds/looks…

A small example with something that just came in Cubase 14. Something that I (and many others) have been asking for for (I don’t know how) many ages (in the old Steinberg forum), and logically it had to be there since the integration of the Audio into Cubase - The Event Volume Curve and the Event Volume Fader. The earliest request I was able to find here, on this topic, dates back to 2013. It took 11 years for such an essential feature to finally be implemented in Cubase… (probably there were even earlier requests about this feature. Many archived Cubase forums weren’t moved to the new Discourse platform). The evolution in the software and technology world is a very rapid thing.

Best wishes,
Thurisaz

1 Like

A question for those who are now using the new score editor in Cubase 14.

Is it now possible to in an efficient Dorico like way enter all articulations available in an EM in the score editor?

That would at least for me be a reason to update.

The present ways articulations can be entered is not very user friendly for modern libraries with dozens or if you have VSL hundreds of articulations in your EM. The two main methods available are using the control lanes in the key editor or the info list.

The first will only work if your library and EM has 30-40 articulations maximum. If you have more, it will not fit the maximum window size (which is not adjusting to contents but which has to be manually resized after you added the artiuclation lane till you see text appearing…).

The list entry is in principle OK. It is similar to how it works in Logic Pro. However in Cubase it for some reason only works for articulations defined as attribute in the EM. Art Conductor offers normal mixed directional/attribute based EMs (to use in the controller lane method) and EMs where all articulations are defined as attribute even if in a normal score they would be directional. So with this EM you can use the list entry (highlight notes and choose an articulation from the list). This method leads to a weird score however with e.g. each legato note labeled legato.

It’s been a while now since I used the Cubase Score Editor, but I don’t remember this being the case at all. What I remember is that articulations defined as attribute would show up on every note in the Score Editor, and articulations defined as direction would show up once until cancelled by some other conflicting direction articulation.

However, in Cubase 14 it is a rewrite so not everything is there yet, and I don’t believe the new Score Editor’s expression map capabilities are fully there yet. We may not see them there until the expression maps themselves are rewritten by bringing in enhancements from the Dorico side.

The new Score Editor doesn’t currently work with Expression Maps. It was my hope that we would be able to, but on investigation it proved to be massively more complicated than expected. Part of this is due to the problems that @mavros describes. I’ve come across many expression maps that have things that should be directions but are actually defined as directions. There is another problem that in many cases the names of EM articulations aren’t things you want in the score, eg ‘EW Vln 1 CS Legato 100ms’ (I’ve seen plenty this like)

I think the fundamental problem here is that there are two user groups who use EMs in very different ways:

  • Notation first: define the things you want to see in the score as instructions to the player, and then set up the EMs to render the correct articulations. This is the Dorico model
  • Playback first: set up the EM to store every playback articulation in a plugin and then use this as a palette of sounds to choose from for every note (eg in the key editor). In this use case, it doesn’t matter to the user if articulations are attributes or directions.

The challenge for us is how we bring EMs and the Score Editor together. We have a lot of experience now with Dorico EMs that resolve many of the issues (eg you don’t need to have hundreds of articulations because there is a way of separating the dimensions using Base + Addon articulations), so I hope that will be useful for the future.

6 Likes

Thanks for the explanation Paul. Covering all versions of what is in principle the same articulation in the score editor as well as on the Cubase « DAW side » seems a huge challenge.

As Cubase is a DAW the entry using the info line only would in my opinion be a good option as it would be available for the two user groups you mention plus those who do not use the score editor at all. It would only need to be able to also accept and correctly process directional articulations as in Logic.

If that works the score editor could in first stage just generate the best possible score to cover the midi and related articulation entries on the DAW side which if I look at the different YouTube contributions on the score editor it already does very well. It would then only need, in Dorico terms, an Engraving mode (which although not very user friendly the old score editor in Cubase 13 has) to make it perfect. A full two way Write mode would strictly speaking not be necessary (although it would be nice of course).

All the best with the next steps.

I assume you mean “aren’t” actually defined as directions. That is likely because of reasons like this video:

I’ve known since expression maps were first introduced in Cubase that the attribute vs direction was mostly intended to be a distinction for the score editor, and what they meant, but I’ve seen tons of videos and posts similar to this where they recommend making everything an attribute for UI reasons. I’ve avoided this because of the score editor and I knew what Steinberg’s intent was, I used directions for things that should be directions and attributes for things that should be attributes, sometimes modifying official vendor expression maps to take care of this. I did this because, even though I didn’t use the score editor at the time, I figured in the future it might improve to the point where I could use it. Now that has actually happened, and there is a big mess made from expression maps designed the wrong way.

Very few other people seemed to know that the direction vs attribute distinction was intended to be used based on how it should show up in the score, and very few cared, because they didn’t use the old score editor at all.

IMO, if you aren’t able to equalize the time entering direction vs attribute, then in situations where this is a big benefit like film scoring, you’re going to have composers who don’t care about the appearance of the score continuing to use attributes because it is faster in terms of UI like shown in that video. Then they’re going to send their Cubase files over to the orchestrators who are going to end up with things like “arco” over every single note which they then have to clean up - not good. But given how much pressure composers are under, they are going to pick the option easier for them every time, even if it is more work for the orchestrator.

If you’re going to keep this direction vs attribute distinction, directions and attributes in my view need to be equally fast to enter, so that composers won’t feel that they are less efficient in Cubase using directions rather than attributes. If they are equally fast to enter, then their own speed won’t be a factor, and they’ll more likely prefer the way that makes it show up properly on the score view.

2 Likes

Thanks Michael, that’s really useful context.

I am really intrigued by the speed argument. In the case of simpler expression maps, eg for plugins that can only change one dimension at a time (eg switch between arco/pizz/col legno) then I can see that selecting some notes and clicking the info line dropdown could be quicker.

For the more complex libraries such as VSL you have several different dimensions: basic technique (pizz/arco), con sord/senza sord, legato on/off, molto/con/senza vibrato, etc. So you would have to select multiple combinations of notes and set different articulations each time in order to get the same effect as adding a smaller number of directions, so I think it would take longer.

I would say that many composers are not using the more complex libraries (I use a lot of VSL).

I would very much like to see a better UI for entering expression map entries in the piano roll - at the moment the lanes are too tall, I have some VSL libraries that have so many techniques it would take up half the screen vertically, so sometimes VSL has to exclude some techniques from their maps, and this shouldn’t have to be the case when other DAWs accomplish this with less vertical real-estate.

I’m not sure whether add-on techniques completely solves this, because there can be cases in which the add-on is more limited (ex. a sordino that only has a subset of the articulations of the senza sord rather than having the full set) and this could lead to it trying to use a non-existent articulation if you try to activate the sordino add-on and choose an articulation that doesn’t exist.

People do really seem to like the UI in Studio One for articulation selection, but I’ve never used Studio One myself. I’m not sure if a structure/UI like that would work for Cubase, as they did it with no specific ideas of linkages to a musical score in mind.

I also like aspects of the logic of the classic Cubase expression maps system, since not every articulation cancels out every other, but some work in parallel “streams” (ex. con sord and senza sord don’t necessarily cancel out other directions like molto vib or sul tasto). But some users find it confusing or a bit overengineered. In Dorico as well it seems like these “streams” are present in the form of the mutual exclusion groups, but are not necessarily obvious or visible in terms of their current state, carried through on the back end. It does present certain troubleshooting challenges in cases where things do not work like you would want - both in the case of Dorico and Cubase. I get confused sometimes myself - if I select a combination of articulations that doesn’t actually exist, which ones will get selected instead? Like if I choose tremolo + con sord + sul tasto and there is a sul tasto tremolo and a con sord tremolo and there might even be a con sord sul tasto ord. but no con sord sul tasto tremolo. It is ambiguous to me which one one will “win” in this event and will actually be selected instead when I direct it to play tremolo + con sord + sul tasto (this is more in the Dorico side but applies to Cubase as well).

3 Likes

Another consideration as well that you might want to think about (this will have an impact on MIDI 2.0 orchestral articulation profiles as well). In some cases users can have two notes simultaneously on the same track/channel with different articulations, one for instance sustain or legato, another staccato, by having two notes at the same instant but one with one articulation selected and one with the other. There is a DAW that I read supports this properly, I forget whether it is Digital Performer or Logic, but I think it is one of those two. In this DAW, you can have the equivalent of what would be in Cubase an expression map entry of type “attribute” for two notes that fall on exactly the same beat, completely quantized, in the same part, one sustain and the other staccato, and they will play back together with the correct techniques. If you look at the MIDI stream, the messages are arranged in the correct way so that in the exact same MIDI tick it first sends the keyswitch for the first note, then the first note, then sends the keyswitch for the second note, then plays the second note, all in the same instant. This of course requires a library where articulations can be switched with zero delay - not all libraries can do this at the moment. I don’t think this is possible with Cubase at the moment and so you would have to use two tracks/channels to accomplish this, or slightly offset the two notes. I also don’t see how this could be made to be possible with the “direction” type as it is currently implemented because there’s no linkage between the directions and specific notes - directions currently apply to all notes on the track.

In MIDI 2.0 orchestral articulation profiles this becomes a real concern, if they do take off (and I hope they do), because that cements instant articulation switching per-note into the standard, making everything an “attribute” as a result. If you kept the “direction” lanes in this particular case, you could lose the ability to set the articulations per note and as a consequence lose the ability to have multiple simultaneous conflicting articulations in the same part. Being able to simultaneously have multiple conflicting articulations in the same part for notes falling on the same beat is a big benefit of the MIDI 2.0 orchestral articulation profiles.

1 Like

I think that is a VST problem, not a Dorico problem. I am continually frustrated by the libraries that have fewer articulations for Violas than for Violins. The con/senza sord problem is just another example.

I agree the logic is not clear, but you can influence it by adding fallbacks to the playback technique definition (so eg. a fallback for a bartok pizz might be a normal pizz.)

1 Like

This ends up being a Dorico problem because the instrument creators can only record the articulations that it makes sense financially to record. Less common articulations (often involving mutes) don’t end up recouping the cost. You aren’t going to convince the vendors to make them consistent if the financials don’t make sense for them. Library recording and programming is extremely expensive and time consuming, and a lot of younger composers aren’t going to care about anything other than the most basic articulations and are most concerned about cost. The DAW (or notation program) has to support what is there, not vice-versa.

I’m really bringing all this up from the Cubase perspective, not the Dorico perspective, but it does sound like they want to unify the expression maps between them (which I think makes a great deal of sense) and so we could have knock-on effects where the workflow in both programs could change a bit.

Especially in Cubase, composers want to be able to select an articulation and know they are selecting that one, and not have to worry that the program is going to select a different one than the one they actually wanted or thought was being used. In Cubase, they will want to know that the “sul tasto + tremolo” is going to be the one that wins or whatever. Otherwise they will redesign their maps to remove all of the layers of articulations (or “streams” as I called them) and then you’ll just end up with a big flat list of “tremolo sul tasto” “tremolo con sord” etc. instead of those being separate things, even if it throws wrenches into the score view and makes it look atrocious - it becomes someone else’s problem to clean up. But for them it becomes easier because there is never any doubt as to what it will select. They don’t want to be having to troubleshoot why a map isn’t selecting the right articulation when they have a deadline looming and have to get it done. They’re going to reprogram the expression map to be single layer and idiot-proof, so simple that nothing can go wrong, no matter how big of a mess it makes on the printed score.

In Cubase I sometimes get confused navigating the articulation lanes because there are so many and I don’t know which ones override the others or which ones are grouped together. That’s not a good starting point. I’ve been tempted to simplify and make it single-level, but I’d have to remove a lot of articulations in the process.

Composers working in notation are generally a bit less picky about this because as long as it plays back decently they are happy.

I’m only bringing all this up because since they are having to take another look at expression maps from the Cubase and Cubase 14 Score Editor perspective, to see what has to be done with them, any solution has to take into account the practical aspects. No composer working on film is going to go with a solution that is riskier for them or makes more work for them just because it saves work for the next guy in the chain (the orchestrator). And the film scoring workflow is one of the places this solution can save the most time. If the composers don’t use it correctly because the “correct way” is either too time consuming or too vague / open to issues (“which articulation is it going to select?”) then they’re going to use it the wrong way and orchestrators are still going to have a mess.

1 Like

That is perhaps the most ridiculous argument I’ve heard. You are saying that Dorico’s logic and capability should be determined by the financial interests of 3rd parties.

What’s ridiculous about the argument? I’m trying to say that we can’t build systems based on what wish we had and what we might have in a perfect world but we don’t actually have. You don’t set up medical infrastructure in such a way that assumes that cancer has been cured already if it has not been. You won’t allocate proper research/treatment if you assume that a cure that we wish existed was actually there.

You can’t build Cubase in such a way that it expects and requires that all sample libraries to be 100% complete in terms of con sord / sul tasto / sul pont etc. that all articulations are available across all possible variants. Because then it won’t support a single sample library out there, except those which use simulated con sord / simulated sul tasto / simulated sul pont.

And I’m not talking about things like bad crossfades or dynamic mismatches or out of tune notes - that’s up to the sample library vendors to handle better where the vendors aren’t being careful enough. At least people can work around those issues for now by adding manual CC shaping and other things, and that’s what they do in DAW’s. So I’m not suggesting a big infrastructure be built to fix vendor sloppiness in programming. That’s not Steinberg’s job, and any vendor sloppiness has to be worked around by the user as part of the job. But recording of articulations is a totally different thing and the vendors have limitations that aren’t down to their sloppiness, and you can’t build Cubase in such a way that your intended way of using it only works in a perfect world where all vendors support all possible combinations of techniques, since that perfect world currently is made up of a grand total of zero vendors.

Articulations should be like pitches ideally - with absolutely no doubt as to which one will get triggered. When the composer makes a selection, they should immediately know that it is valid and exists, and not have to wait for being able to hear it and then try to figure out “why am I not hearing this?”. There should be some immediate visual indication that the selection isn’t valid (and in that case, immediately show what will actually be triggered), or hide it as an option, or something.

I have the VSL Duality Strings complete package. When using con sord it excludes a couple of articulations - non vibrato longs, hard staccato shorts, and Bartok pizz. If the lanes show articulations that theoretically should exist, but might not, then composers are likely to choose a combination that doesn’t work (ex. non-vibrato con sord longs) and wonder why they aren’t hearing what they should be. Afterwards they are likely to reevaluate their expression map usage and reconfigure their expression maps in a way that Steinberg doesn’t want and would make the scores a mess - probably making them single-level, one big giant list of options.

The composers would probably say “Steinberg, why did you build a system that has this big problem if this technique doesn’t exist, that it will seem to use it but not actually with no warning or anything?”. They probably wouldn’t go to the library vendor and say “VSL, this is your fault, you should have recorded this technique because Cubase now requires that you be 100% complete in everything you record across all con sord sul tasto sul pont combinations, otherwise it won’t work properly”. It’s just not realistic.

I realized something else here that I didn’t address before. As I said, many composers are not using libraries that are that complete in terms of articulations (which results in a certain “sameness” and sometimes pedestrian writing, relying more on unusual size forces like 18 horns and 100 cellos, and losing out on the wealth of techniques available for the instruments).

What I know composers do who use libraries with a lot of articulations like this is they divide it up. That way you could avoid needing different dimensions by having two or three tracks - ex. one for long notes, one for shorts, one for “effects”, or a similar division. Each track would have its own map, and each one would be shorter, and flat. That’s what people are doing right now largely.

I think composers would be willing to move to a single track per instrument per library (matching a score layout if only one library was in use), if it was able to handle negative track delay properly for articulations, and if the articulations were suitably convenient to select from, with speed of entry being given the priority, as well as a way to be 100% sure that the selection will play the expected technique on the back end.

A lot of them currently work with articulation-per-track templates at the moment, to be honest, just because of negative track delay handling. So they will have one track for Violins 1 slow legato, one for Violins 1 fast legato, one for Violins 1 staccato, one for Violins 1 spiccato, etc… It is not unusual for templates to grow to 1000 tracks or even more as a result. If the maps supported negative delay it would be a way forward from there, but the UI also has to make sense in terms of efficiency, otherwise people are not going to use the system the way the designers intended or expected.

We see this with Dorico, where the feature that was added in Dorico 5 to allow creation of custom instruments without hacking XML files is being mis-used for layering of libraries by different vendors, with people creating a duplicate copy of “violin” in the instrument library called “VSL violin” and another copy of for Berlin so that they can add them to the score simultaneously and get both libraries going for layering. The custom instruments feature was not meant to facilitate the layering of libraries, but people started to implement this “wrong way” of doing things because the right way did not give the flexibility and capability they wanted.

In this particular case, I’m hoping that the design that the Cubase team comes up with is efficient enough, handy enough and accurate/predictable enough that composers want to use it in the way as designed and as intended, and aren’t tempted to change it around to the wrong way.

2 Likes

I won’t disagree with you, but I will employ the “state them up front” method to warn/guard against my own biases. I am allergic to the 1001 track DAW approach, and dedicated to a score approach to film etc. I’ll try to avoid any more of that slippery conversation slope. :slight_smile:

We all know the student / amateur trap of overusing - I dunno - everything from the sustain pedal on down. I don’t think it’s about using more articulations (grabbing every crayon in the box) so much as it is about envelope control.

There’s a great but sorta strange book that referred to notes as being like the tracks left by animals; that an experienced tracker can tell the story from the track’s edges of shifting weight to run, to stop, turn, relax, etc. Wallander has alluded to a bit of that I think.

Lacking sufficient adult supervision, I can say that it works to use a library (as normal basically) as an oscillator in a polyphonic modular synth, but followed by an ADSR or slew limiter where you adjust the envelope of selected notes to get that punch on the attack, shorter, faster decay or bit of separation, smooth it out - like the animal tracks.

The composer control mechanism though - I suspect that the histogram tool gets overlooked sometimes. @PaulWalmsley, I don’t wanna articulate every note! Without hopefully solutioning too much, I think of the histogram tool pretty similar to the way it is today, except I want an easy way without too much context switching to select the sort of short or long notes @mducharme is describing as separate tracks for the tool to operate upon. It is fine imo just to use it to send a cc - when I’m using the modular at least.

The modular reference I meant just to describe the idea, not to hopefully get too distracted. The key of the modular though versus using an insert, is that as an instrument, you receive all of the note and gate info to use as triggers. Versus just inserting an envelope follower for example on a track, which I found doesn’t distinguish individual notes well enough to work on strings. I’ve done some things for variation- I think I see Steinberg already heading somewhat in that direction in Cubase with some of its new effects? The ones for modulation and variation? So just a thought that If the same midi information made it all the way to each insert in Dorico - then those might be interesting already. The modular is a bit much perhaps. :slight_smile:

I do think that those kind of tools provide perhaps a glimpse of the future - something different from explicitly articulating each note.

I think of it as extending the pre-delay thoughts mentioned above, and I recall a post by @BasseART asking about the ability to adjust onset/offset in the histogram tool, What I’m really saying in my head usually is “I need this part to be a bit more lyrical “ Or “that tightened up” rather than playing with articulations.

A more macro way of interacting is how I’ve always thought that the histogram tool was intended, but its name might seem a little too engineer for some? Dunno. But I think the direction is/will be light years faster to work with versus every stinking…

On the subject, you know how something like the Turing Machine synth module and its clones work, right? Maybe something inspired by that? It’s not really I think that we want true randomness, but that kind of controllable—ish variation for the spread, probability of certain things, speed of evolving, having the option to constrain, ability to drive different but related outputs (cc) as the original or complement or shift them? Knobs aside, an enhanced tool to not have to hand draw curves explicitly, but more describe and adjust your intent for a given situation,- seems to align with Dorico’s philosophy?

Okay, I’ll be quiet now.

3 Likes

The info line entry would indeed solve this speed issue. As Logic has solved the issue of not labeling each note in the score for directional articulations the Cubase developers would certainly also be able to find a solution for this.

As Paul mentioned the different variations of the same technique would benefit a lot from add ons like in Dorico. The Art Conductor maps have a separate line for each combination. So with 3-4 variants per basic technique this gives to a very long pull down list In the control lane entry in Cubase these add ons actually exist as normal key switches in Cubase. If you use the VSL provided expression maps vibrato, non-vibrato etc. are at the top of the lanes and can be combined with the directional articulation further down.

1 Like

The problem is that it is rare when libraries have all articulations available. You’d need a way to extend add-on techniques to somehow forbid certain combinations - ex. it is an addon but excluding these techniques that are missing. Like Duality Strings sordino has most of the articulations from the regular library (about 60), but it is missing four articulations. If you use addons, they don’t know that those four are missing. Film composers who use expression maps will need to know the articulation is missing - even if it selects another articulation automatically in its place, that might be OK, but the composer still has to see some visual indication that that articulation does not actually exist and has been substituted. Otherwise they could decide something like “oh I’ll choose con sordino harmonics because this library has that according to the expression map” and it actually doesn’t (it’s just the addon technique in the map makes it falsely look like it does) so it replaces it automatically with regular harmonics or something. This is the point where the composer would more likely set up their maps in a different way so that they could be guaranteed that they don’t see things as options if they don’t actually exist - and probably this different way would be the wrong way when it comes to correct score generation and display.

Where I use addons is when the library does things like simulated con sordino (like CSS) and then all techniques are always going to be available in both. That’s the perfect use of addon techniques in my view - but that’s a minority of libraries out there. In other cases you’d have to configure additional techniques as “substitutions” for things that the addon doesn’t actually have.

In Dorico these types of substitutions can happen without the composer knowing, and it is kind of OK, because we are already mostly dealing with an abstraction system (the score) which gives us an abstraction layer from the actual raw playback (even though we have control over that too at a level we don’t normally have in notation programs). But Cubase users are going to expect to deal with the raw techniques and not an abstraction layer getting between them and the techniques. So if you give them an abstraction layer, they still have to know clearly what raw techniques are being used. Dorico users largely don’t care that the program has swapped out a non-existent technique for one that does exist as long as it still sounds close enough, but I think Cubase users do care about this.

This is I think part of the reason why Studio One Sound Variations are so popular - a simple tree view of techniques, built by the plugin itself. If it is in the list, you are guaranteed that that technique is actually there and doesn’t just falsely show as being there, because it is a list the plugin itself made. VSL makes this full tree automatically from its dimension tree, etc. You end up selecting from a real official list of techniques, not an abstracted one where you choose based on what you want in the score rather than choosing based on what the library actually has.

Cubase actually has partial support for creating expression maps from Sound Variations, but it doesn’t work at all for when Sound Variations have a tree structure (like with VSL). This could be extended to support the tree structure, and then for each technique you could specify what it should appear in the score as. For instance, all of the muted techniques would need two items “con sord.” and something else. There would need to be an algorithm that could filter out technique repetitions on the score (not show needless extra “con sord.” for every note since it is a direction) - as everything would essentially be like the current “attribute” entry. You could take this approach and extend it a bit by giving the program some intelligence to decipher what a technique might mean from the name the vendor gave to the Sound Variations - ex. picking up on a key word “muted” or “sord” in the technique name and automatically linking the con sord. score technique with it. With this type of method, you could satisfy both requirements - it gives the composer a raw list of techniques they know will exist and they choose from that, while intelligently associating those raw techniques with certain abstract concepts in the score for display purposes, and then filtering out repetitions so that you don’t get arco or con sord. over every note, etc. In case the intelligent system chooses the wrong score technique by picking up incorrectly on the text string, the user would need the ability to correct it. In terms of UI it would actually be something like the current system, but the user would choose from the technique name instead of the score name, and there would be the tree structure. Then you don’t need this super tall articulations lane at all, it can be quite short, because you can just select the notes and choose the technique, and each note would have one and only one technique (but each technique could be associated with multiple score markings, like a note might be simultaneously con sord. and staccato and with an accent and sul tasto).

I’m not saying this is the best way to do it or that it is the only way to do it, but it strikes me as a potentially good alternative.

2 Likes

@PaulWalmsley I wonder if there might be a spot for either top-down or bottom-up selection of the techniques contained in expression maps, maybe in both Cubase and Dorico somehow. I know some other users have requested the ability in the past for Dorico to be able to select a note in the piano roll and select a technique manually for that note, without having to add the technique to the score, as a sort of “manual override” for when you know you want a note to be a certain technique and it is hard to get it to be that technique otherwise.

There could essentially be two working methods - if each expression map entry was associated with certain playback/playing techniques or whatever (like if the expression “EW vlns 1 con sord. sul pont tremolo” was associated with the techniques con sord., sul pont, and tremolo), it could be selected dynamically as a combination of the three techniques active at the time (con sord., sul tasto, and tremolo), or statically as a “manual override” by choosing the “EW vlns 1 con sord. sul tasto tremolo” from a drop-down list.

The dynamic entry is basically what we have in Dorico right now, and Cubase too to some extent. But both methods could potentially have use cases in both Cubase and Dorico. For techniques entered in the score, it would make more sense for the technique to be dynamically selected for each note based on the techniques entered in the score at the time. For techniques entered in the piano roll, a static setting or “manual override”, as an attribute for the note, is probably what most users would want. But there is room for the other method in both programs potentially - Dorico could potentially allow manual setting of a specific technique for a certain note in the piano roll as an override attribute for that note, and Cubase could allow dynamic selection based on playing techniques entered into the Cubase 14 Score Editor.

You’d want to make sure of course that in both cases that the manually selected techniques would appear in the score, which would mean identifying when manual techniques would result in adding extra needless “con sord” or “arco” markings to successive notes and hide those.

Again, these are just random thoughts/ideas that I have, take them or leave them. But there have been many Cubase users who find the current expression maps system too complicated (and some Dorico users too) who would prefer at least some ability for manual “override” selection of technique for individual notes. Some users might just want to work with overrides for everything and would be happy with that, if they find deciphering the logic of the current dynamic selection too complicated.

It might also be worth it for you to reach out to Marc at Babylonwaves who makes Art Conductor for Cubase, as he explained to me a lot of their users already have difficulty with the complexity of expression maps in Cubase as it stands, and he also has some special insights as to the expression map needs of Cubase users in comparison to Dorico users. He’s currently working on version of Art Conductor for Dorico.

2 Likes

@PaulWalmsley In case it helps, here’s an example of where the current UI in Cubase for expression maps really goes wrong. In the past weeks, I’ve been working on a new track in Cubase essentially for the first time in about a year, and using VSL Duality Strings, where I have the regular+sordino+colors+virtuoso package. Here is what the articulations lane looks like:

For VSL Duality Strings, which has a lot of articulations, the articulations lanes take up about 1/3 of my 4K screen height. Reducing it more makes the articulation names disappear so then you can’t tell what anything is. And VSL had to exclude some of the techniques from their map because it would have made it too tall. The map is so huge that troubleshooting it becomes a bit crazy when it doesn’t work properly. Dorico expression maps are more reliable than these complex ones in Cubase, I am finding, mainly due to the fact that you are not stuck with these fixed four “Art” layers (Art 1, Art 2, Art 3, and Art 4) and can instead combine the techniques as needed, with automatic fallback if a technique doesn’t exist.

I think Steinberg designed the expression maps system in Cubase for more complicated instruments than were generally available at the time, but the screenshot should make clear, the current UI is getting kinda ridiculous with modern VSL sample libraries like Duality Strings. And it would have to be much taller to actually support all of the articulations that Duality can do, so they had to leave some out because it is already at 1/3 of the screen on a 4K display.

On the other hand, Studio One has a nice simple tree-list for picking articulations, generated directly by the Synchron Player automatically via Sound Variations, so you don’t need this crazy amount of real-estate taken up. Because they are organized into a tree, it isn’t some giant flat disorganized list at least.

With most libraries it isn’t quite this bad - but VSL Duality Strings has become so complete in terms of techniques that it is becoming kinda ridiculous. I hope whatever solution is developed for Cubase significantly improves this UI situation.

And I should also add that these UI issues don’t affect Dorico of course because of the completely different situation for entry (entering the techniques as playing techniques or articulations or ornaments doesn’t “stack up” like this). I’m sure Dorico users would be complaining a lot if they had this much vertical screen space taken up by an articulation selection UI that they had to keep open at all times.

6 Likes

Thanks - this is all very helpful. If you have some sample projects using these expression maps then I would very appreciate seeing them, if you are able to send them via DM.

1 Like