Notation Export

88 posts / 0 new
Last post
andre's picture
andre
Offline
Last seen 9 hours 38 min ago

Notation Export

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!

janamdo's picture
janamdo
Online
Last seen 59 min 36 sec ago

Get some examples from : The New Age Pianist - YouTube  from 

PG Music Inc. ? 
 

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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.

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

Thanks. That example will look much better with the next update.

https://docs.cognitone.com/synfire/EN/interface/InspectNotation.html

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

Thank you very much!

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

Here is another bug: the last note of the first bar should be connected with a tie with an extension of that note into the second bar. The tied note is missing. This example was created with a bass factory.

I attached again the Synfire file, a screenshot of the Synfire file, and a screenshot of the resulting notation.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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...).

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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.

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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?

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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

MusicXML

ex5-mx.png

LilyPond

ex5-lp.png

Attachments: 
scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

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.

One of my feature requests though was also to help the user with that, meaning warning the user when there are impossible to notate results, e.g. a note position/length that is not possible to output to notation not even with tuplets; so, then the user can manually correct that. A simple exclamation point icon, for example, near the symbol(s). This may be something for the far future, but if the goal of getting decent exporting is met, it should be easy, I think, to use the exact same code to detect when things are wrong.

I need a few short example arrangements that you care about.

I've sent you some emails about this in the past whose attachment files may be of help; I'm going to provide more via email soon.

Please also see https://users.cognitone.com/topic/my-list-bug-reports -> "Old bugs still present in V2" -> "Exporting" section, with the various yellow-marked bugs; because those are critical bugs for XML exporting in general.

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

(more files and info are being sent via email to the devs)

See the attached file rhythmic_figurations_examples.zip (28.06 KB).

It contains the file "Rhythmic figurations examples.mscz": this is a MuseScore file which contains some rhythmic figurations that I've took from pieces of classical music (ignoring simultaneous notes and pitches).
This file can then be exported via MuseScore to both MIDI and XML.

If you open the XML file e.g. in Dorico, you can notice good consistency, except some understandably different but equivalent rhythmic notation (triplets across bars).

If you open the MIDI file e.g. in Dorico, you can see it's relatively good even though it misses a 4plet and it gets some unwanted grace notes.

If you open the MIDI file with MuseScore itself, if you play with the "Quantization max." and "Irregular groups" import options, you can get pretty close to the original result. It recognizes the triplets, the 4plet too, and just misses e.g. a double dot.

Ideal goals that I wish for Synfire:

  1. To be able to write the same music in Synfire as in the provided ".mscz" and export it to XML with the highest possible precision.
  2. To be able to import with the highest possible precision these XML and MIDI files into Synfire (yes, XML import too would be very useful because it's more precise for weird tuplets, if I understand correctly).
  3. Slightly more advanced stuff like tagging tuplets that may however be discussed in the future when basic import/export is ok.

 

Update: more files and info are being sent via email to the devs

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:

tuplets_test_piece.png

I hope we can get there.

The "8va" marking and the clef changes would be very welcome. Anything else is unnecessary, or meant for the far future "tagging idea". 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.

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

@tanders

tie bug

Yup, already reported months ago in my bugs thread. Easy fix I suppose.

voices bug

Yup, voices are broken.
The user should actually have the possibility of selecting/specifying voices anyway, see my "list of suggestions" thread.

(Whether or not this can actually be performed by the relevant instrument should not be of a concern to Synfire, I feel.)

I agree, but this is really just a bug in individuating/separating voices. You did very good demonstrating it with chords, but it also happens e.g. with two lines moving together like in a counterpoint.

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

@andre

Are dotted tuplets commonly used?

Yes, e.g. tons of piano music.

Are there even notation symbols for that?

Normal tuplet with the note normally dotted. The same applies to rests too.

There's a bit of overlap between dotted tuplets and straight notes.
How's that handled in notation? I assume they are printed depending on context such that the number of beams need not change, correct?

Generally you only have one or two dotted notes inside a tuplet in order to break the rhythm of the tuplet: rarely all of them are dotted, if they can be replaced with an easier to read solution.
There's also another "equivalence" problem, e.g. a triplet in a whole 4/4 measure is the same as a sixtuplet in the whole 4/4 measure; what changes are the accents.
You basically have to consider the whole measure, the figuration (as in the movement of the line), the musicality, the accents, if it is "just a run", what's the actual purpose of the tuplet, the intentions of the composer, etc.; hence why the ideal is to have taggable tuplets in the future.

*cough cough* and being able to specify beaming groups / accents, which could then be not only used for XML export, but also interpreted by Synfire to create velocities basing on that. *cough cough*

 

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

dotted_tuplets_and_equivalent_tuplets.png

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.

 

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

> 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=beh...

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

nested

Interesting because I just suggested ignoring nested triplets. IMHO they will never output as the composer wants, so it's better to leave those to the future "tagging feature" where you directly specify them. There are already enough problems with non-nested tuplets. I don't know of other software programs that outputs those, unless it's a notation software.

If you disagree, I'm interested in your opinion.

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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).

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

>> 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.

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

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.

 

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

> 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).

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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

I understand your caution concerning higher tuplets, no problem.

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

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.»

This leads me to Synfire: it looks to me that from this point, the most reasonable way to proceed (also considering that we will then need nested tuplets too and there will never be enough resolution for that), is to directly go to the "tagging"/specifying tuplets idea, shaped in the following way:

  • Keep whichever resolution you want for Synfire, without going to higher resolutions (that can maybe cause problems)
  • Let the user just "fake it", by placing the symbols more or less like the tuplets he wants, with the help of the new Grid parameter, and then give the user the option to specify that a given segment / group of symbols are meant to be exported as a given tuplet, e.g. a septuplet or a nonuplet. The playback will already sound similar to the intention of the composer, which is enough; a lower priority feature is to change the Output parameter with the needed resolution and having therefore a perfect playback.
  • If you are worried about the GUI, make this feature something optional in the Preferences, so users that don't need it will get the same GUI that we already have, with no additional confusing buttons and indications.

Update: I realized that interpreting the notes placed by the user, though, would require quite some work, probably. So, yeah... it's not something that can come soon, probably. Let us know if this makes sense as the way to go, though.

Sorry for insisting about this topic, but as I wrote somewhere else, notation should be an important aspect of a music prototyping software program.

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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.

scriabiner's picture
scriabiner
Online
Last seen 58 sec ago

status_green_but_musescore_err.png

With 1/32 quantiz. it works fine.

andre's picture
andre
Offline
Last seen 9 hours 38 min ago

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.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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.

tanders's picture
tanders
Online
Last seen 2 min 38 sec ago

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.

Pages

Log in or register to post comments

Scholarly Lite is a free theme, contributed to the Drupal Community by More than Themes.