Track Delay Issues

Hi Daniel and crew, I had some quick observations about odd behavior with track delay I wanted to run through as it’s been one area of consistent friction in the otherwise great experience of using Dorico.

On the Mac version I noticed that track delay via expression maps does not delay the CC change triggered by dynamic markings along with the note delay, so the user isn’t able to use score dynamic markings to functionally control CC data if using track delay. I did notice that dynamic markings do show up in expression maps so I tried to apply offset to the dynamic markings but it did not change the location of the CC data.

Another unique aspect is delay through expression maps delays the onset of notes, but not the release. To correct this the user has to know to adjust the % duration to shorten the note lengths because the delay of onset has essentially lengthened the notes. This seems very unintuitive as typically track delay functions equally delays both onset and offset equally, but maybe there is some advantage to having control of both - so this could be a feature rather than a issue. Still I’d be concerned that this will throw many users off. Clearer labeling could also help if the functions are really onset vs offset delay.

One last odd aspect is, in selecting individual notes, you can apply note onset and offset delay in ticks, while in expression maps there’s a much more useful delay function in milliseconds. It would probably more useful/valuable for both to function in milliseconds since the value of ticks is tempo dependent, something very difficult to use if tempo mapping is being used or changes in tempo are made; also communities typically share delay knowledge in milliseconds because it is consistent across conditions.

There’s one last limitation on track delay that, if changed, would set Dorico above competition in this arear; being able to set, within expression maps, a separate delay or the first note in a legato phrase. Some libraries do not have a consistent delay between first note and remaining notes of a legato phrase. This means, even with a global track delay, you will still need to manually adjust the start of every legato phrase. I’m currently using KSP to address this, but it would be more elegant if this function were built into one consistent system and would make expression maps one of the best options out there.

Just some thoughts/concerns about the current state of track delay - Dorico is wonderful and and the addition of track delay has significantly increased the usability of integrated score notation with samples libraries. These are just a few remaining limitations that are still causing friction in the user experience. Thank you for considering the concerns, and for making such a great program!

3 Likes

Welcome to the forum, Marc, and thanks for your feedback.

You’re quite right that dynamics are not currently offset by the delay amount specified in the expression map, and they probably should be. I’ve made a note of this.

I’ve also made a note that we should add an option to apply the delay to the ends of notes as well as to the starts. I know that in e.g. Cubase the track delay option applies to every MIDI event on the track, but things in Dorico are a bit different: it felt to us that the main goal was to adjust onsets to make notes sound at the right moment and not to interfere with the rest of the positions. But it would be possible to add this if required.

I’ll have a think too about the idea of specifying a different delay value for the first note in a legato passage. That’s a bit complicated, but of course it can be done with sufficient time, effort and application!

5 Likes

Thanks for the thoughtful reply Daniel!

Hi @dspreadbury,

I wanted to add some thoughts to this very helpful thread by @Marc_Tannous.

I just picked up Audio Imperia’s Nucleus over BF and have been trying it out in Dorico. I was hoping that this new feature would be perfect for it, but I’m running into the same issues as Marc did.

If you’re not aware, Audio Imperia’s engine has a super helpful feature where you can apply a constant “Sample Start” delay in millis to every articulation. So, fully quantized MIDI will play back perfectly for any articulations, but with a configurable delay (configurable between 0ms to 250ms, the lower side being best for tracking, the higher side being best realism in rendering). So, rather than needing each switch to have a separate delay, this can apply to a whole instrument (helpful!).

However, this isn’t working well in Dorico’s current implementation. Here’s a very short passage:

Basically, I alternate p and f notes in a melodic sequence or sustains. Nucleus uses cc1 for dynamics, see key editor below.

So observe the following issues:

  1. As @Marc_Tannous observes, the sample end is note adjusted by the delay, so the notes overlap in an unexpected way.
  2. While the dynamic cc lines follow the pitches reasonably well, they run into issues (perhaps with beat emphasis?) where they change during the note across the measure lines.
  3. Nitpicky: when you start playback / when repeats happen, it starts at the beginning of the physical bar, not when the note actually starts. So the first note is cutoff.

My suggestions / hopes for each of these:

  1. Support two scenarios “simple delay” (as currently implemented) and “corresponding start/end offset”, as discussed above. The former (current implementation) is mostly implemented if you have a small number of articulations with non-zero delays that you don’t want to have to nudge each time. The latter would be useful in most classic scenarios of dealing with sample instrument delays, I think.
  2. Render cc before calculating any offsets, then offset the cc back accordingly.
  3. I admit, I don’t know what to do about this one.

One note that I can work around this and leverage Audio Imperia libraries sample consistency using negative audio delay with delay compensation, after the (non-delayed) MIDI is rendered. This works, but it adds, the worst case, unnecessary 250ms which I’d rather avoid if possible.

Also note that the manual start/end offset in the inspector doesn’t work well for this as it’s relative to tempo, not absolute.

I hope you consider addressing these issues in an upcoming release of Dorico!

Thanks,
David

2 Likes

Hi Daniel, I was wondering if your team is still exploring having dynamic markings CC changes match the delays triggered by expression maps (and setting a separate lead note legato delay)? Loved the last update!!! - this just feels like a small missing piece to expression maps truly allowing for notation based playback outside of NPPE playback (which is great but has it’s own sound signature) without needing to draw CC1 and 11 for every line.

Yes, it’s certainly still planned, but I’m afraid I can’t say for sure when we will be able to implement this. I’m sorry for the inconvenience caused in the meantime.

No apologies necessary - I was just curious and I appreciate you taking the time to respond. I appreciate all the work you and the team do and all the growth of Dorico over the past few years.

Sorry to bump an old post, but just this morning I was wondering if there’s any timeframe for separate delay of first note of a legato passage. It’s one of the only things left for a really strong engine.

The Development Team does not usually give a “timeframe” for release of features; more often than not, we all learn of a new feature when it is released.

1 Like

I want this feature too, but I suspect it involves enough changes to the engine that it is probably unlikely we would see it in an update for Dorico 5, and that it would probably be part of Dorico 6 at the earliest.

Just an update that the CC delay was added in the latest update so this issue is resolved. Apparently though there are libraries that anticipate the CC not being delayed (unexpected!) so it’s a trade off unfortunately, gain for some, loss for others, but expression maps are now more compatible with the Cinematic Studio Series and similarly designed libraries. There’s been discussion of an expression map toggle for the delay potentially in the future so it can be adjusted per design of library.