Hi @fratveno I’m just looking at your project (rather than Robert’s). I don’t quite understand how you’ve set up your HALion Sonic - you have two piano patches loaded on the same channel, and there seems to be a Transpose of 2 set in HALion itself for one of them. My guess is that you’re hoping that the xmap switch with velocity 101 and transpose of 2 will trigger the HALion slot with no transpose, and the xmap switch with velocity 102 and no transpose will trigger the HALion slot that has transpose of 2. In other words, what you want is to hear no difference, because both of them end up with the same amount of transposition in the end. Is that right?
Sorry, the transpose setting was a leftover from some experimentation. It should have been zero, but it has no effect, since the Transpose data are not transmitted by the NLC switches… my project is set up modelled on Robert’s initial post. My project works as expected in Dorico 3.5.1 (transpose data are not sent, but Velocity data are), but not in 4.3.3.
However, if Robert’s “discovery” (that the order of switch creation is important) is taken into account when a project is created in 3.5.1 it also works when opened in 4.3.3
Aha, that’s great. We’ve identified the bug now, at least (though I can’t say when a fix will be released). I just wanted to be sure there was just the one issue here rather than two - thanks!
4 Likes
Hello @dspreadbury and @Richard_Lanyon, I think I’ve encountered a similar (but not exactly the same) problem as above with Expression Maps in Dorico 5.
Could you let me know if you’ve attempted to fix this bug in Dorico 5?
If you have, then I might conduct a deep investigation and get to the bottom of what I’m experiencing. If you haven’t, then I’ll not waste my time and wait until the bug has been fixed, then re-assess.
Thank you. 
We’re aware of one possible outstanding issue that can occur with repeats - for which we hope to have a fix soon - but if that doesn’t sound like it might explain your problem then please let us know.
1 Like
My potential issue doesn’t have anything to do with repeats. Okay, I’ll try and work out what is happening, and when I do, I’ll create a new topic. Thanks!
@Richard_Lanyon, I’m happy to report it was a false alarm; my VST wasn’t quite playing the sounds I expected.
However, I’ve identified the reason I suspected a problem in the first place. There is a minor discrepancy in Velocities set by Expression Maps between MIDI Exports and what a VST receives.
- Velocities set in Expression Maps between 1 and 84 inclusive have 1 subtracted from them before heading to a VST, but are left as they are in a MIDI Export.
- Velocities set in Expression Maps between 85 and 127 inclusive are unaltered for both a VST and MIDI Export.
I would argue that this is probably not ideal; with the MIDI Export not identical to the internal MIDI in Dorico. In most cases the difference would be negligible, but probably not in all cases.
I’ve tried to work out why this happens at 84 and 85. My best guess is that this is the result of a rounding error, as the fractions 84/127 and 85/127 are suspiciously close to the fraction 2/3 (≈0.6614 and ≈0.6693 respectively), which is often incorrectly rounded to 0.66 rather than 0.67.
Anyway, I leave that with you.
Sorry @Richard_Lanyon, my false alarm was itself a false alarm; I have found a new problem very much related to above.
There is an inconsistency with Note Length mappings between what is sent to the VST and Audio Export and what Dorico is reporting in the Playing Techniques lane of the Key Editor. I’m not exactly sure why the problem exists, but I’ll have a guess at the end of this post.
You may need to read this a few times, but I’ve tried to construct a simple example which demonstrates the issue. I’m currently on Dorico 5.0.10.2029.
Consider the flow
with Expression Map
and HALion Sonic 7 VST,
the idea being that each Note Length Condition will trigger one of the five Programs in the VST.
[Note also that any Velocity ≤ 84 has one subtracted before reaching the VST, which is why the values 11, 36 and 63 are being used in the first three Programs rather than 12, 37 and 64. This is not the issue I’m reporting in this post, but I’d better mention it for anyone following along.]
Anyway, the Key Editor looks as follows.
The Playing Techniques lane of the Key Editor is reporting | L1 | L1 | L2 | L3 | L4 | L5 |. [Note the Velocities reported are | 12 | 12 | 37 | 64 | 89 | 115 |; the correct Velocities from the Expression Map.]
However, during playback, watching the meters of the Programs via the MIX tab of the VST reveals that it is playing Program | 1 | 2 | 3 | 4 | 5 | 5 |.
This is best demonstrated by looking at the Dorico Audio Export waveform. You can see an increase in volume in each bar, until the last two notes, which are the same volume.
For this to occur, Dorico must have sent the Velocities | 11 | 36 | 63 | 89 | 115 | 115 | to the VST, implying that the Note Length Conditions are being interpreted differently than what is reported in the Playing Techniques lane of the Key Editor.
By contrast, taking a Dorico Midi Export [which, by the way, has the correct Velocities | 12 | 12 | 37 | 64 | 89 | 115 |],
and importing into Cubase with the same HALion Sonic 7 VST [adjusted for the correct Velocities],
the Cubase Audio Export, after level matching, produces the following result; the same volume for the first two bars, then an increase on each subsequent bar, just as Dorico’s Playing Techniques lane of the Key Editor reports.
The difference between the Dorico Audio Export and the Dorico Midi Export then Cubase Audio Export highlights the problem; Dorico is still not sending the correct information to its internal VSTs and Audio Export.
Hopefully, that’s clear.
Now, I promised I would take a guess on the source of the problem. In the Dorico 5 manual, the Note Lengths are described as follows.
- Very Short: A dotted 16th note at 120 bpm, or 0.1875 seconds
- Short: A dotted eighth note at 120 bpm, or 0.375 seconds
- Medium: A dotted quarter note at 120 bpm, or 0.75 seconds
- Long: A dotted half note at 120 bpm, or 1.5 seconds
- Very Long: Any longer duration
I’ve always been a little confused as to why Very Short, Short, Medium, and Long are defined as specific lengths, yet Very Long is defined as an interval.
This has made me wonder whether some of the Note Lengths are actually defined as intervals too. Otherwise, there is very little reason to use the == Equal to condition type, as it would only work for tempos which are nice integer/fractional multiples of ♩=120 (such as ♩=60, ♩=160, etc).
Anyway, what I seek to achieve with my Expression Map is for all possible note lengths to be uniquely and consistently mapped to a Note Length Condition. If the Note Lengths have been implemented exactly as defined in the manual, then my Expression Map should achieve the following.
If, however, some of the Note Lengths have been implemented as intervals, which may or may not overlap, then it’s possible there is a non-unique mapping in my Expression Map.
I would also suggest looking at the implementations of < vs ≤ and > vs ≥. Incorrect uses of these inequalities could possibly explain why my intervals are being incorrectly mapped.
In any event, there is clearly a difference in the implementation of the algorithms between what is being sent to the VSTs and Audio Export with what is being reported in the Playing Techniques lane of the Key Editor. This really does need to be fixed, otherwise the Playing Techniques lane of the Key Editor is unusable for determining the Expression Map’s mapping of Note Lengths.
Thank you.
1 Like
Would you be able to attach one of your test scores, just so I can make sure I’m looking at the right thing?
Hello @Richard_Lanyon.
I upgraded to Dorico 5.0.20 this morning, and now I can’t replicate the problem (I don’t know whether to feel good or bad about this, haha). Perhaps my issue was related to one of the other Note Length issues that were corrected in this update.
Anyway, here is the very file I used to construct my above report, while using Dorico 5.0.10. If you can open this in Dorico 5.0.10, hopefully, will be able to see/hear the issue.
Untitled Project 1.dorico (543.7 KB)
Thanks.
Ah yes, I see the same thing - it’s wrong in 5.0.10 and right in 5.0.20. I have to admit I’m not entirely sure which of the tweaks we’ve made here have fixed it, but by all means let me know if you spot any remaining problems.
Hello @Richard_Lanyon. You asked me to let you know if I spot any remaining problems.
I think that Playback Techniques with the Direction articulation type are interrupting the Expression Map’s ability to send the correct Velicity based on a Note Length Condition.
Consider this Dorico 5.0.20 file. It contains a simple flow
with a custom Expression Map using Base Switches designed to set the Velocity of “≤ Short” notes (which is the first two bars above) to 90 and of “> Short” notes (which is the last bar above) to 120. The Key Editor demonstrates this nicely.
The Expression Map also includes two Add-on Switches for the built-in “Bow on bridge” Playback Technique as well as a custom Playing Technique named “Custom Direction Playback Technique” (though these aren’t set to do anything). Both of these Playback Techniques use the Direction articulation type.
This is being sent to an instance of HALion Sonic 7, in which Velocity=90 should play normally but Velocity=120 should be transposed up a tone. As in my previous reports, this is to provide audible confirmation that the correct Velocity is making it to the VST.
If you start Playback, you should hear CCCCCCCCDDDD, which is the intended behaviour.
Now, if you insert a Playing Technique which triggers a Playback Technique with the Direction articulation type, we start to encounter problems.
You can first try the in-built “Bow on bridge” Playback Technique.
This will produce CCCCCCCCCCCC, indicating that Velocity=90 is being sent to the VST for the whole passage, even though the Key Editor still indicates that the Velocities in the third bar are 120.
You can next try the “Custom Direction Playback Technique” Playback Technique (triggered by using the “Custom Direction Playing Technique” Playing Technique). This also incorrectly produces CCCCCCCCCCCC.
Thirdly, you can try a Playback Technique with the Direction articulation type not referenced in the Expression Map, such as “Col legno”. This still incorrectly produces CCCCCCCCCCCC.
That is essentially the end of my report, but there is something else that might help you get to the bottom of this.
When I first noticed this problem, I thought it was due to a bad interaction between a custom Playback Technique with the Direction articulation type and a custom Playback Technique with the Attribute articulation type (as this is what I was using in my actual project). In my Expression Map for this report, I created 6 Base Switches so that I could test out different combinations of custom and non-custom Playback Techniques with the Attribute articulation type against custom and non-custom Playback Techniques with the Direction articulation type described above.
To thoroughly test all combinations, my attached project also contains a custom Playback Technique with the Attribute articulation type called “Custom Attribute Playback Technique” (which can be triggered via the “Custom Attribute Playing Technique” Playing Technique [are you keeping up?]).
This “Custom Attribute Playing Technique” displays the following glyph.
Anyway, brace yourself for this upcoming table! The columns correspond to the Base Switch (“Natural”, “Staccato” and “Custom” [the one I just described]). The rows correspond to the Playback Techniques with the Direction articulation type that I’ve already used in this report (none, “Bow on bridge”, “Custom”, “Col legno”). You can click on this image to enlarge it.
While any Playback Technique with the Direction articulation failed (in red) “the velocity test”, strangely, the Playback Techniques with the Direction articulation that are in the Expression Map (“Bow on bridge”, “Custom”) failed in a different way than those that weren’t (“Col legno”) for the “Custom” Base Switch only; they set Velocity=120 for the whole passage rather than Velocity=90 for the whole passage.
I have no idea what this means, but thought I should report it anyway.
Good luck!!
1 Like
Thanks Robert. I’m on holiday this week and next but I will make a note to have a look at this on my return.
1 Like
I’ve had a bit of a chance to look at this now and I can at least reproduce what you describe. It’s related to the situation we addressed before. In those cases the issue was that we were unnecessarily considering the note length conditions on switches that didn’t match the requested playback techniques. Here I think it might be the converse - we’re sometimes failing to consider note length conditions on switches that are partial or “fallback” matches. In any case, I’ve logged it for further investigation, though as ever I can’t make any promises about when or what we’ll be able to do about it.
2 Likes
Brilliant, thank you @Richard_Lanyon. I’ve since employed a workaround for my specific case, so this issue isn’t holding me up anymore. However, if I spot anything else similar, I’ll let you know.