Notation routine for splitting notes in order to reinforce meter

[Hwanggang]

music21 version

6.7.1

Problem summary

Converter midi to musicxml with one 4/4 bar ,which grouped by one sixteenth note and dotted eighth note and dotted

half note(tie pre eightth note) .

Steps to reproduce

Expected vs. actual behavior

Expected in Measure:

Actual in Measure :
convert midi to xml like

so musicxml show as

More information

[jacobtylerwalls]

Greetings, and thanks for taking the time to write. This is a known missing feature. Can be reproduced without external files like this:

>>> from music21 import *
>>> n = note.Note(quarterLength = 0.25)
>>> n2 = note.Note(quarterLength = 3.75)
>>> m = stream.Measure()
>>> m.append([n, n2])
>>> m.show()

Mailing list discussion where @MarkGotham shared some code for handling this:
https://groups.google.com/g/music21list/c/5G-UafJeW94/m/YcEBE0PFAQAJ

[mscuthbert]

I think that this is fine behavior. The input has two notes and the output is able to be represented as two notes, so it does so. Many composers (e.g., Bartok) prefer this output to the tied version, and there is an easy way to represent the tied version in musicxml. I'd lean towards not-fix.

[jacobtylerwalls]

Got it, but what about this case?

[mscuthbert]

I think that there's a need for a function to split that, but I don't think that it's makeTies() -- makeTies is for creating the minimum number of ties needed to make measures fit, etc. This might be a sort of meter.reduceNotatedSyncopation() or something like that. And there should presumably be different levels of syncopation to remove. For instance, does this reduce to8 8~2~8 8, or to 8 4.~4. 8, or to 8 8~4~4~8 8? And then imagine the same thing with 16 2.. 16 or something with tuplets. The number of "correct" simplifications gets enormous. Is the most important thing to show the highest level beat groupings or the lowest level or all of them? Do we weigh negatively number of ties/notes vs. difficulty of reading? And how do we make sure that 3/4 2~8 8 doesn't become 4~4~8 8 which seems much less readable to me.

It's a worthwhile exercise to consider implementing, and some level of it should go into MIDI parsing, but I don't want to change the makeTies behavior for this.

[jacobtylerwalls]

Yeah, there are always going to be multiple solutions. My inclination would be to define some violations to reexpress. For instance, when I taught music fundies and wanted to express this idea without introducing overwhelming detail to people just beginning to learn notation, I did something like: Make an effort to show beat 3 in 4/4 meter, but don't bother if:

• rhythm can be expressed simply, i.e. in no more than two notes or quarter-half-quarter etc.
• there is pervasive syncopation (I gave them the opening of mozart piano concerto no. 20)
• etc

That would cover the vast majority of MIDI files. Behind Bars has some more robust rules starting at p.166, but we wouldn't need to implement all of it.

[MarkGotham]

Thanks all, and for keeping sight of my proposed solution @jacobtylerwalls . Amazing that it's only been c. one year since this exchange ... seems much longer. I guess it's been a long year!

Totally agree with the emerging consensus that the best solution is to:

• prep. some separate code for effecting this,
• with a few, clear user-controls, and
• offer it as a (non-default) option that users can apply to re-notate streams they find unsatisfactory. (I.e. leave judgement calls to the user for their specific use case).

Looking again at that code I offered, the logic is currently:

• context from a note's starting position, length, and metrical structure in terms of a pulseLengths pattern like [6, 3, 1]
• break up every duration that traverses from lower to higher metrical levels boundaries.

So that's a strict implementation, but set up to make it easy to add a user control for relaxing the condition by ignoring certain metrical levels from consideration.

So in answer to @mscuthbert , solutions like:

• 8 4.~4. 8 mean implementing breaks at the 1/2 note level but not smaller values;
• 8 8~2~8 8 are still possible by checking the 1/4 note level but not higher ones (I'd vote to make this non-default because of the 2 traversing a metrical boundary).

Here's are some examples:

So then the user could be able to specify any option of that kind that's consistent with the time signature (raising an error otherwise), or to rely on the system's defaults, which could be set to something sensible like, say, 2 levels below that of the full metrical cycle so:

• 1/2 and 1/4 notes in the case of 4/4;
• 1/4 and 1/8 notes in the case of 2/4;

Worth emphasising that notes going from a strong to a weaker metrical position are unaffected (e.g. dotted note on the downbeat in simple time).

[mscuthbert]

great examples and I like the alternatives. The user's proposed answer (dotted 16th. + dotted half) should be something to consider also -- it has the advantage of showing the main beat of 4/4.

The Q of the interface for this is almost as hard as the implementation. What are these things called and how will people know how to use it? That's the part I'm banging my head on.

[jacobtylerwalls]

Maybe something similar to #845 where we override the base split() methods for Stream subclasses.

Maybe we need Stream.splitByQuarterLengths() where instead of splitting one huge note at a bunch of places, we split a stream's components at certain places. And then a new method to get the array of split points from the various config options.

[jacobtylerwalls]

Just discovered we have Stream.sliceAtOffsets(). I propose we get a noncontroversial version of it (splitting at 2.0 only in 4/4 meter etc) into the MIDI parsing flow and then we continue the discussion around creating a method to help people calculate the offsets they need to slice at for other cases, as Mark proposes above.

[jacobtylerwalls]

Worth emphasising that notes going from a strong to a weaker metrical position are unaffected (e.g. dotted note on the downbeat in simple time).

Mark, I'd be interested to hear how you accomplished this. Perhaps you can point to a snippet of code. If this is as elegant as it sounds, it's better than my special casing proposal for the 4/4 MIDI case.

In any case, yes, I would endorse getting your set of solutions into the system to generate a list of offsets and then pass them to sliceAtOffsets(). Would you be inclined to prepare a patch?

[MarkGotham]

Thanks @jacobtylerwalls !

I'm happy to finish off an implementation of this one (based on what I sent before) if that's ok by @Hwanggang and @mscuthbert.

In any case, I'll be in touch with a proposed implementation first, soon.