BUG: MIDI file import does not preserve note positions

Dorico
1

I start a new Dorico project, set all playback options to the factory defaults, apply the HSSE+HSO playback template, add a single oboe player, and enter the following notes to be played at the default tempo of q=120:

Oboe Notes

I select all of the notes, set their playback start and end offsets to zero, and then export a MIDI file. This is what I see when I examine the MIDI note events in that file:

Elapsed     MIDI Note     MIDI Note
 Ticks        Value         Event
-------     ---------     ---------
    0           60           on
  480           60           off
  480           64           on
  960           64           off
  960           67           on
 1440           67           off
 1440           72           on
 1920           72           off

Now I import that MIDI file into a new flow, making sure that Preserve note positions is checked in the Import Options. When I select the notes in the new flow, I find that their playback start and end offsets are not set. If I export the new flow to another MIDI file, this is what I see when I examine the MIDI note events:

Elapsed     MIDI Note     MIDI Note
 Ticks        Value         Event
-------     ---------     ---------
    0           60           on
  456           60           off
  480           64           on
  936           64           off
  954           67           on
 1416           67           off
 1441           72           on
 1896           72           off

Some of the notes do not start on the beat because Humanize the start positions of notes is set to 30%, and all of the notes end before the following beat because the played durations of default notes is set to 95% of their written durations.

2

What happens if you rest Humanize to zero?

3

I can solve the problem by setting Humanize the start positions of notes to zero percent and the played durations of default notes to 100% of their written durations. However, what is the point of having the MIDI file import option to preserve note positions if it doesn’t do anything in this case?

4

I’m pretty sure this is all explained in this much older thread: Questions about MIDI Import Options in Dorico (using Note Performer for ultimate playback)

5

This is the description that Paul Walmsley gave of the Preserve note positions option in that thread:

But I have shown that this option does not always apply a start and end offset so that the notes play with the same timing as the MIDI file.

6

But as explained (or at least confirmed) in the thread I linked to, the humanisation settings in Playback Options add another layer for playback purposes (and thus for MIDI export). I can’t see that this is a bug, given the person who designed it has confirmed that it is working the way he designed it to work.

7

I will leave it for the Dorico team to decide whether or not what I have reported in this topic is a bug.

8

It isn’t a bug. Dorico will preserve the note positions if they deviate from the notated positions, but if you import a perfectly quantized MIDI file, there are no deviations, and so nothing to preserve. This feels to me like the most sensible approach Dorico could take: it would I think be annoying if in the general case none of Dorico’s features for adjusting timing etc. can take effect after importing a MIDI file.

1 Like
9

To allow Dorico’s features for adjusting timing to take effect after importing any MIDI file, the user simply needs to ensure that Preserve note positions is not checked in the Import Options. Currently, whenever a note starts or ends precisely on the beat and this option is checked, the corresponding playback offset is not set. The whole point of preserving note positions is that Dorico should play the imported flow with the same timing as the MIDI file, regardless of the current playback options. You may not think this is a bug, but I have to disagree.

1 Like
10

Well, reasonable people can certainly disagree, but only we get to say what’s a bug and what’s not :smiley:

It’s a bug if it doesn’t work as intended, and this is working as intended.

4 Likes
11

God, grant me the serenity to accept the bug feature I cannot change… :pray:

12

Just to add a sidenote: The German Wikipedia page mentions one special definition of a bug: When a system behaves in a way that is unexpected to the user while being technically perfectly correct.
Having that said, it seems that we, too, can decide what is a bug :wink:

13

If German Wikipedia is like its U.S. sibling, it is not considered reliable as a scholarly source. Just saying.

14

A bug has long been defined as ‘something that doesn’t work the way the developers intended’.

Here’s the “Hackers’ Jargon File” (a venerable repository of the folk-culture of early computing) entry on the distinction between bugs, features, and other terms.:

http://www.catb.org/jargon/html/F/feature.html