Warning: importing chords into Dorico

I tried a test I did with Sibelius several years ago: playing the same chord (a maj7 chord) 12 times (Cmaj7, C#maj7 and so on) in Logic, and exported the sequence both as a MIDI file and a MusicXML file. Logic simply can’t handle such chords - not inly does it show them in a wring way, but it also omits some of the notes, and shows three notes instead of 4 - totally unacceptable.

When importing the same sequence in Sibelius, things look better. Not perfect, but all notes are shown and there is - unlike in Logic - not an unexpected mix of flats and sharps in the result.

Trying the same in Dorico 1.1 gave a surprising result - please see the attached images.

Any plans for improving this? Something as simple as a basic maj7 chord should never be displayed this way.



There are a few separate issues here.

First, let’s look at what Logic is doing. Is there a possibility that actually all four notes are there, but that Logic doesn’t have a way of displaying two noteheads in the same line or space, next to each other, and won’t automatically give a natural unless that pitch has had a sharp or flat previously? Bar 10, for example, implies four pitches, though it only shows three noteheads. Bar 2 would imply four pitches IF there was a natural as well as a sharp next to the C. I believe Logic’s notation module just hasn’t provided for the possibility of a C and C# played simultaneously - as far as it’s concerned, it doesn’t need to show a natural given the C in the previous chord was also a natural.

In terms of rhythm, it looks as though the MIDI output that you’ve taken from Logic to Sibelius is a case of “what you played”, not “what you see”. If you’d hard-quantized your input in Logic then Sibelius would be showing crotchets (quarter notes) reliably.

Dorico - the choice is totally up to you. If you don’t like the split stems then bring up Notation Options (Cmd-Shift-n or Ctrl-Shift-n), go to the Accidentals category and scroll down to the penultimate section, “Altered unisons”. Changing “Split stem” to “Single stem” will give you what I think you want.

In terms of enharmonic spelling, Dorico tries to automatically spell stuff based on context, and most of the time it does a better job of it than Logic or Sibelius. By only giving it a series of 12 chromatically-shifting chords with no other material and a mostly unrelated key signature it’s not exactly a “fair test”. You can, of course, respell as you see fit, by using Alt-- (minus) and Alt-+ (plus).

At the moment, MIDI import in Dorico does not use any of the clever enharmonic spelling code that is used during note input. If you were to input those chords directly into the program via step-time input, you would get a very different result.

The medium-term plan for MIDI import is to use our modified version of David Meredith’s PS13 pitch spelling algorithm to determine the optimal spellings based on the overall musical context, which should ultimately give an even better result than what you get when playing in the music using step-time.

Apologies for the piggyback - Dan, while you’re here, could you point me towards the place where MusicXML import is explained, pretty please? I know that all layout stuff is rejected but a cursory search hasn’t yielded what I’m looking for.

There’s not really much in the way of specific documentation about this at the moment, Leo. What do you need to know?

Moving to email - best not keep bumping threads!

Daniel - since you’re in teasing mode, would you mind giving us a hint about the long-term plan? :smiley:

Don’t know what the technical explanation is. The notes are certainly there, but Logic is partially based on Notator on Atari, and for what I know, the algortihms that determines how chords should be displayed be be 25+ years old… and whatever the reason is, Logic can’t do what Dorico and Sibelius and I guess every other music app on the planet does: always display four notes when we are looking at and hearing four notes. In bar 2 in th eLogic example, there’s a C and a Db (or a C# and a B#, depending of how you look at it), but Logic simply doesn’t handle such situation.

After one has learnt minor and major chords, the next three chords people lean is usually minor 7, dominant 7, and major 7 (Cm7, C7 and Cmaj7). These are maj7 chords; nothing esoteric here. But neither Logic, which I have used since Notator, or Dorico recognises such basic chords and displays them correctly.

Usually, if a chord consists of something which in theory could have been interpreted as C and C#, or D and Db… that’s not what it is. One wants, as much as possible (in all relevant situations) to display four notes with unique pitches, meaning that we usually don’t want to see C and C# notated next to each other in the same chord, or D and Db - and so on. That’s where Logic fails. It shows the note head for the C and the note head for what i falsely assumes is a C# on top of each other, so they appear as and, and not two notes. But this is a Dorico forum. :slight_smile:

Regarding hard quantising, that’s what I did, but I quantised note starts, not note lengths.


“If you don’t like the split stems then bring up Notation Options (Cmd-Shift-n or Ctrl-Shift-n), go to the Accidentals category and scroll down to the penultimate section, “Altered unisons”. Changing “Split stem” to “Single stem” will give you what I think you want.”

Thanks, Leo, What I’m trying to point at is that in order to display something as basic as a maj7 chord, we shouldn’t need know that stuff. D. should be intelligent enough both to recognise such basic chords, and to display them in a normal and expected way. And - if D. should choose not not do that (eg because that code isn’t written yet), there should at least be some code in there which would display the chord erratically, but in a normal erratic way. I think a good starting point would be to force D. to understand that if there’s both a C and a C# (or a D and a Db) in there, they shouldn’t be displayed as two versions of the same pitch, but as two pitches - of with an accidental, and one without. It should simply do what Sob has been doing for many years.

Regarding “a series of 12 chromatically-shifting chords with no other material”:
I only recorded all 12 chords to illustrate how the outcome will look for the different possible maj 7 chords. Nobody would compose music like that (I hope). But maybe someone would make educational material like that.

So I think it’s a fair test; just forget about the last 10 chords, only look at the first two. Have you even seen sheet music, anywhere, with a chord written like that? With C and C# next to each other, with an extra, diagonal stem - and one with a natural and one with a sharp, instead of eg C/Cb? :slight_smile:

Thanks for the info, Daniel. I forgot to attach the result of the same material transferred using XML (attached now), so I guess the improvements you plan will apply to how D. deals with XML import as well.

While we are lamenting these chords being represented with split stems, let us realize we are overlooking how difficult split stems are to create in other notation programs. Dorico did it on its own.

+1

It’s good that Dorico can do that. What I don’t like is that it does that. :slight_smile:

Luckily, you can save your own personal preferences.
What Dorico does when it comes to spelling: it simply respects how it was written in Logic (which indeed was horrible). This can often be a very good thing, sometimes not. Therefore - I’m sure we’ll both be very well pleased with PS13 once it gets implemented.

Don’t know what PS13, but let’s hope it’s good. But since the problems in D also appears when importing a MIDI file, I don’t think it’s mainly about trying to replicate what Logic has done in it’s own score editor. The dual stems appear with MIDI files as well. Spelling a 7-chord right shouldn’t be that difficult.

PS13 is a (fairly) new algorithm for converting MIDI data into correctly spelled notation. See http://www.titanmusic.com/papers/public/meredith-ps13-jnmr.pdf (and its references) if you want to know how it works. The start of section 2 is quite a readable summary.

Well, you could always enter it in root position rather than third inversion.

Unless it was really a “German 6th” chord which should have been be spelled Ab C Eb F#, not Ab C Eb Gb :wink:

Well, what I wanted to test out was how Dorico* spelled common chords. And for me using chords in their root position is not a common thing to do.

German 6th, Rob? Errrrr - what? :slight_smile:

ETA**: as it’s default, when importing notes from a MIDI file.

**edited to add

For better or for worse, Daniel’s explained that chords imported from MusicXML or MIDI aren’t spelled the same way as actually playing in the chords on a MIDI keyboard. This is what I get:

Ole, I believe you’re being deliberately provocative, as increasingly seems to be your way. If you import a file via MusicXML, then you will get the spellings that are explicitly stated in the MusicXML file: it would not be helpful at all if Dorico were to unilaterally start ignoring the spellings encoded in the MusicXML file.

I have explained to you both by email back at the end of April and here on the forum this week that MIDI import does not use the same note spelling algorithms as MIDI step-time input, but that we have plans to change this in future.

Your complaint about Dorico’s use of split stems is unjustified, and as Anders has pointed out, you can easily prevent Dorico from using split stems via the Notation Options dialog (click ‘Save as Default’ if you want to make this the default for new projects too). Switching off this option will not, however, cause Dorico to spell a chord that contains C natural and C sharp as e.g. B sharp and C natural or C natural and D flat or A triple sharp and E triple flat or anything else.

If you want to see how Dorico spells common chords, then please input them via step-time input using your MIDI keyboard directly into Dorico, not using an imported MIDI or MusicXML file.