Skip to main content

Notation Export

Posted

We have quite a lot feedback on this topic in several threads, so I wanted to focus this here. The next update will bring a few improvements, albeit more needs to be done.

The issue with current export is that Synfire attempts to quantize a human-like (or randomly generated) performance into something that lends itself to readable notation, before doing the actual export. These quantization and filtering options are bloating the settings and make them difficult to understand and optimize. 

The plan is to separate the pre-processing from the export. So if you are really disciplined and have a clean notation-friendly composition from the start, you can skip this altogether.

In order to do tests, I need a few short example arrangements that you care about. Something with a reasonable amount of triplets and quintuplets, 16th, 32th, syncopes (please only music that humans can actually play). Also tonally, something that exposes current bugs. This will save me a lot of time and make a quick fix more likely. Thank you!


Fri, 2022-05-13 - 17:34 Permalink

Thank you very much for doing this.

> I need a few short example arrangements

Here is again an example that I shared before, which demonstrates at least 2 problems.

  • A track with plain 1/2-note chords (actually dotted quarter notes followed by rests) generated with a chord factory is not correctly notated, some chords are simply skipped.
  • A track with plain sequences of quintuplets (all note values evenly 1/20, and no other figures in this track) are not correctly notated if this track also contains rests. In this example, the first quintuplet in the first track should start on beat 1 with two 1/20 rests.

Synfire export settings where the Auto-generated settings.

Attached is the Synfire project file, a screen shot of it, and an attempted/wrong notation import (only MuseScore for now, Dorico completely failed to import the resulting MusicXML file).

Will later share some more examples.

Sat, 2022-05-14 - 17:04 Permalink

The next example involves figures layered in the same track and export staff. There are simultaneously sustained chords here and a melody.

In the resulting notation, Synfire fails to separate the two layers. I actually tried to somewhat separate the pitch range of the simultaneous figures, but on purposes I did this only partially, there is still some overlap, and seemingly this pitch overlap is what causes Synfire to struggle. The first bar should (after the rest) start with a four-note chord, and this chord should then be sustained. One 1/8-beat later the melody should enter, and the melody should be purely monophonic.

Synfire instead partially merges these two layers. The melody starts too early and takes over two of the first chord tones. In the second bar, the melody "steals" even more chord tones. On the other hand, the "stolen" chord tones are then too short.

I would like to see that the notation export retains exactly what is contained in the Synfire figures, i.e., the full 4 chord tones should be sustained for their full duration, and the simultaneous melody should happen in a *separate voice*, partly using the same pitches. (Whether or not this can actually be performed by the relevant instrument should not be of a concern to Synfire, I feel.)

There is also another bug here already reported above, namely in the chord layer again the ties into the following bars are again missing.

Also, the first melody note of the second bar is too short.

Sat, 2022-05-14 - 19:07 Permalink

The next example involves somewhat more complex quintuplets. The example starts with a bar with "straight" notes, which should *not* be notated as quintuplets, in contrast to what Synfire does. In the second bar, it so happens that there should be four quintuplets, each subdividing one quarter note. For example, the first quintuplet of the second bar should consist of the following rhythmic values: 3/20 (notated as a dotted eighth quintuplet note), 1/20, 1/20 -- the last note then tied to the following quintuplet. The second quintuplet should start with a 1/20 (sixthteenth quintuplet), as mentioned tied over, followed by a rest that is part of the quintuplet, and ending in a sequence of five 1/40 note values. etc.

For completeness, the second bar of this example was also create with a factory (creating music for 5/8 meter, which was then scaled by factor 4/5). The first bar is simply written by hand here.

Sat, 2022-05-14 - 19:28 Permalink

OK, here is a last example for now, this time involving different tuplets in a single track and staff. The current Synfire notation export settings don't really handle this case. What would be needed for the quantisation is likely some factor of the different tuplet prime factors (perhaps 1/60?).

Problematic in the result here is mainly 4th quarter of the first bar, which should be a quintuplet.

I kept this example more simple on purpose, but ideally Synfire would be able to handle different tuplets in the same track/staff that still can feature all the things tested in other examples uploaded above, like starting with a rest, ties across tuplet boundaries and within the tuplet, and different note values in a single tuplet (e.g., a quintuplet might consist of all possible durations with prime factor  5 in the denominator, like 3/20, 1/10, 1/20, 1/40...).

Sat, 2022-05-14 - 21:13 Permalink

Thanks a lot for the examples. All of them already look great with the next update I'm currently working on.

Some rests can still not be expressed as a single symbol: 1/60 is a dotted quintuplet. Are dotted tuplets commonly used? Are there even notation symbols for that? It may make sense to add dotted tuplets to the mix, if only for internal processing. Let me know.

Sat, 2022-05-14 - 21:42 Permalink

There's a bit of overlap between dotted tuplets and straight notes.

 1/96° = 1/64
 1/48° = 1/32
 1/24° = 1/16
 1/12° = 1/8
 1/6° = 1/4
 1/3° = 1/2

How's that handled in notation? I assume they are printed depending on context such that the number of beams need not change, correct?

Sat, 2022-10-01 - 19:28 Permalink

The plan is to separate the pre-processing from the export. So if you are really disciplined and have a clean notation-friendly composition from the start, you can skip this altogether.

Perfect.

 

[redacted old info]

Sat, 2022-10-01 - 19:28 Permalink

I've made a short piece for the piano for testing tuplets and staff splitting, and I've sent it to the devs via email.

This is the expected XML result:

I hope we can get there.

The "8va" marking and the clef changes would be very welcome. Anything else is unnecessary, but this is the minimum, IMHO.
Pages styling and stuff like that is not expected and is actually preferable not to have it, to avoid cluttering the XML file with useless info.

 

[redacted old info]

Sat, 2022-10-01 - 19:31 Permalink

[redacted old stuff and misconceptions]

 

I've made a picture to demonstrate some equivalent scenarios:

A1, A2 and A3 are the same exact rhythm. B1 and B2 are the same exact rhythm. And so on.
Some pitches are changed to demonstrate different musical purposes.

A1 is fine. A2 gets rid of the dotted note inside the tuplet, so it's probably easier to read.
A3 is similar than A1, so maybe it's not that good, unless you want to keep musically clear the waltzer rhythm superimposed to the 4/4.

With B1, unless I'm wrong, there is no equivalent to replace that dotted note with some non-dotted note. However, even if we imagine a similar example where that's possible, it may not make sense to "break" the tuplet at that particular point anyway, because it's just the very end of the measure, so "just let the piano run go." So in this case we are considering the whole measure to determine a solution.
B2 is just the equivalent of B1, but with different composer's accents intentions, also reflected in the beaming; the interpreter may then disregard the accents because of a lot of factors.

"C" is similar to the "A" example in the sense that the dotted note can be replaced with a non-dotted one by using a different tuplet solution (basically removing the tuplet for that last beat). I've written that C1 is good for a "run" ("run" intended the same as intended in Synfire's factories), so if the accents are not intended to be particularly important, you just assign a tuplet to the whole measure; inversely, if the accents are important, then C2 will be a better solution, especially if you want to hear those three triplets as unique music figures, and then you want to hear the landing B note as an "anchor", to use a Synfire word.
C3 is a bit difficult (I've marked it in red, but that was probably excessive); I would say it is bad because it divides the measure in two different ways, it's inconsistent; still, the composer may actually want those beaming / accents, so it's not like it's a wrong notation (I guess?); it's however a complex case that the software can't obviously understand, so if it exports C2 that's totally reasonable.

( Please everyone feel free to correct me or add more insights. Thanks. )

 

That said,

smart and easy guesses could already be made by the software, e.g. avoiding "A1" and "C3" in my example picture; if then the user prefers "A1", he will change it in the notation software.

 

Mon, 2022-05-16 - 20:32 Permalink

> 1/60 is a dotted quintuplet.

I actually meant 1/60 as the duration of a triplet note subdividing a quintuplet note. Lets do this step by step: if we subdivide a quarter note (1/4) into five even notes (1/4 : 5) we reach 1/20. As you know, this is notated with two beams plus the tuplet numeral 5. If we now subdivide one of these notes further into three even notes (1/20 : 3), then we reach a triplet subdivision of the quintuplet note (1/60, a nested tuplet). This would be notated with three beams and the tuplet numeral 3 nested within the surrounding tuplet numeral 5 bracket or beam. (Alternatively, we could also reach the note duration 1/60 as a quintuplet nested within a triplet, i.e. the other way round.)

A dotted quintuplet instead would be 3/40 (dotted quintuplet with two beams) or 3/20 (dotted quintuplet with one beam) etc. As you know of course, a dotted note is the duration of an undotted note extended by half of its duration. A quintuplet with two beams is 1/20 (again, 5 even notes subdividing a quarter note). Half of that is 1/40, and 1/20 + 1/40 = 3/40.

Apologies, I do not in any way mean to come across patronising or anything. I could easily do such a mixup myself...

> Are dotted tuplets commonly used?

How widely used such note values are depends of course on the musical style, but indeed dotted tuplet notes are part of the standard Western music notation, that would not require any explanation in a score. If you are interested, a nicely comprehensive overview of the means of Western music notation (i.e. of established notation practice) is provided by the following book: Elaine Gould (2011) Behind Bars: The Definitive Guide To Music Notation. Chapter 7 deals with tuplets.

There is also (an incomplete) preview available here: (https://books.google.lu/books?id=yBK_DwAAQBAJ&printsec=frontcover&dq=be…)

Sat, 2022-10-01 - 19:32 Permalink

nested

Interesting because I just suggested ignoring nested triplets. There are already enough problems with non-nested tuplets.

Mon, 2022-05-16 - 21:31 Permalink

Thanks a lot for your helpful input and advice. 

Spent two days rewriting some of the export classes, mainly the handling of note and rest durations. These now support any combination of straight notes, tuplets and dots (up to three dots). What's still missing is the disambiguation of note type depending on context (there are many durations with the same length but different names).

Most example files already export fine here. Will report more on progress.

Mon, 2022-05-16 - 21:33 Permalink

I would agree to deprioritise nested tuplets. Initially, I only brought up 1/60 as a potential quantisation value (with question mark) if we want to have both quintuplets and triplets in the same track. 

Talking about prioritising: I think fixing that ties are possible should have highest priority. Ties are needed for very many musical styles and rhythmic situations, and they are also essential for popular music.

For me, having support for (plain, not nested) tuplets would be the next priority.

Lowest priority out of the bugs I listed above for me would be fixing the notation of simultaneous figures (multiple voices within a single track/staff), because an easy workaround would be to just introduce more tracks/staffs (and if necessary merging these later manually in the notation software).

Mon, 2022-05-16 - 21:45 Permalink

>> More complex tuplets...

> Here's what we have so far for the most challenging example:

For completeness, I should perhaps mention that the results shared here are not correct. Hasn't Lilypond complained over overful bars with this output

Note that in the Synfire file, the first note of the first bar and the first note of the second bar do not have the same duration. Same with the second note of the first bar and the second note of the second bar and so on. In this example, it so happens that there are four (more complex) quintuplets in the second bar, each subdividing one quarter note.

Let me know if I should better share the expected notation.

Tue, 2022-10-04 - 03:27 Permalink

as a potential quantisation value if we want to have both quintuplets and triplets in the same track

Oh, I think I understand, sorry for the confusion.

Lowest priority out of the bugs I listed above for me would be fixing the notation of simultaneous figures (multiple voices within a single track/staff), because an easy workaround would be to just introduce more tracks/staffs (and if necessary merging these later manually in the notation software).

I would agree if splitting and merging would be usable, but right now splitting creates a new track every time leading to incredible waste of time; in fact I've suggested a "Split to below track" feature.
Moreover, sometimes you have two voices with the same symbol color, like two melodic horizontal lines moving together.

Just pointing out why it would be useful to me, but your priority order certainly makes sense.

 

Mon, 2022-05-16 - 22:03 Permalink

> overlap between dotted tuplets and straight notes

Indeed, those are equivalent rhythmic values. Which one is preferable depends on which one is more easy to read, but there might be multiple potentially conflicting criteria for that and it depends on the context. I would feel that in simple meter (in contrast to compound meter), plain note values are simpler than dotted triplets. On the other hand, if a triplet rhythm is required anyway in the music -- and in compound meter (where "triplets" are basically baked in), then for consistency a dotted "triplet" might be more easy to read.

In compound meter, instead of a dotted note also (German term) Duolen are an alternative, basically a tuplet expressive a 2-subdivision. 

Anyway, I feel even discussing such finer points might be misplaced here. If Synfire simply outputs the correct note values I would already be happy, I gladly handle the finer points manually (and software like Dorico also does a lot of this automatically).

Tue, 2022-05-17 - 14:12 Permalink

I did some math.

Triplets and quintuplets are no problem.

In order to represent septuplets and nonuplets, internal resolution would need to be increased from 1920 to 40320, which is probably doable, but definitely a fundamental change with wide ranging implications. A change of resolution has never been tested and there will be unexpected side effects on backwards compatibility, MIDI export and transmission (not sure if anyone ever tested 10080 ticks/quarter note).

With 11-tuplets it gets to an insane 443520 ticks per whole. Not sure what that imples down the road, but I expect MIDI file import and export procedures to break.

I'm not inclined to take the risk of making such a radical change anytime soon. That's an experiment to try when things have settled a bit after the 2.0 release.

Tue, 2022-05-17 - 14:39 Permalink

Thank you very much for improving the support for triplets and quintuplets. Highly appreciated!

I understand your caution concerning higher tuplets, no problem.

Sat, 2022-10-01 - 19:35 Permalink

Good that you fixed what was possible to be fixed.

Anyway, if I understand correctly (feel free to correct me of course), notation programs have their internal way of storing notes that obviously differs from a DAW (they store tuplets using a dedicated class, etc.), so when it comes to MIDI (both playback and exporting) they can simply generate on the fly the required MIDI in whichever resolution is needed.
DAWs and Synfire instead, work with actual MIDI notes internally, so if you can't do something due to the resolution, you also can't export it or play it.

Dorico is a notation program, but they also implemented a piano-roll. A solution to the resolution problem for Dorico, provided to a user, is the following:

Dorico always uses 480 ticks per quarter note, so there is no way to increase the MIDI resolution. However, the “jankiness” can be greatly reduced by going to Playback Options>Timing>Note Start Positions and setting “Humanize the start positions of notes” to zero percent.

( (https://forums.steinberg.net/t/midi-export-precision/736275/2) )

Which in other words means: «just manually fake it a bit.»

[redacted old stuff]

Wed, 2022-05-18 - 13:59 Permalink

Notation programs probably use a symbolic representation of time (fractions, duration expressions) without any quantization. That's great. They don't need to process data in real-time. Although Synfire's timeline is not MIDI-based, it is integral (numbers). All parameters use it to store values and compute spans, etc. Using a different indexing system would slow down everything to a crawl.

It may be possible to use a high resolution internally and scale that down for MIDI export. Introducing a different timeline for export is not feasible. All time must be deduced from the internal timeline in some way.

Fri, 2022-05-20 - 09:12 Permalink

Sometimes the status indicator still misses something in its pre-flight and shows green despite remaining issues.

Why some XML measures end up incomplete is a mistery. There shouldn't be a single blip of time that's not covered. Probably a misunderstanding of the XML format on my part. Fortunately, notation programs allow to ignore this.

Fri, 2022-05-20 - 14:08 Permalink

After the release of version 2.0.4 I am now going through the problematic examples I shared above. The new GUI for the notation export is very welcome and the options make sense to me. Two points, though.

Under Quantize Notes > Combined, there are options to choose that certain "straight" note durations are combined with triplets and/or quintuplets. Are these triplets/quintuplets those that are nearest to the chosen straight duration? For example, when selecting 1/8 + Triplets, does that mean 1/8 + 1/12, and 1/8 + Quintuplets means 1/8 + 1/10?

Minor: The tooltip shown for Notation > Prep > Status cuts off some lines at the right edge.

Fri, 2022-05-20 - 20:22 Permalink

After the update, when opening files that previously contained figures (e.g., those shared above), these figures may no longer be recognised (all symbols turned gray, like they are only takes). However, figure groups are still maintained. At other times, the figures are shown when the file is opened, but soon after, this information is seemingly lost and only gray symbols are shown.

I can also no longer edit this unrecognised figures in any way, and failed to perform any figure recognition (though the latter may be just me missing something). Also the chord symbols are grayed out and cannot be edited anymore.

Question: Has the file format been updated again, and are these updates not compatible with the former fle format? More importantly, will the file format be frozen or any changes backward compatible after the final version is released? It appears the current pre-release should not be used for any actual work, if any new version can make existing files un-editable.

Perhaps I am also simply missing something.

Attached is a screenshot.