My list of bug reports

Thank you for this extensive list and the attached files.

Since 2.0 is about to be released soon, many issues (especially graphics/UI) may have become obsolete, because large parts of the code have been rewritten. We will see. 

Some good observations and suggestions. Notation export will get another look, too. Tuplets are hard because figure segments are not tagged as such. maybe they should. As a temporary workaround you could export to MIDI file and import that into MuseScore.

BTW, the parameter block is scrollable with the mouse wheel.

I can verify that. It's not very bad, just a bad bug, that prob easily fixed.

It's a simple mistake. Fixing it however will make a few phrases out there render different output for instruments with a narrow total pitch range. Not a big deal, unless it's a lead melody, of course. Expanding the range should restore the previous output.

What's the output preview feature? Is that a new thing? How do I activate it?

Cool. Thanks for this Scriabiner

Thanks a lot for collecting this detailed list of bugs, much appreciated! 

A word of caution concerning MusicXML problems: unfortuantely, different music notation packages deviate from the MusicXML standard in different ways, and some of these packages seemingly recognise certain oddities of their competitors, while others don't. The different MusicXML versions do not make this situation more simple either. 

So, in order to be fair when critisising the MusicXML export of Synfire, it appears one should always compare the import results of multiple notation packages (e.g., Finaly, Sibelius, Dorico, MuseScore), which unfortuantely may all behave a bit different with the same input. For example, I know from a composer colleague struggling with the MusicXML output of some other composition system, who reported that for best results he always had first to import the results into Finale (which seemingly has a rather mature MusicXML support), then export it as MusicXML again and then import it into his actual notation software Sibelius. I had some time a similar experience with Dorico, and was using Finale to preprocess the MusicXML files. You reported something similar for MuseScore & Dorico.

It seems the MusicXML situation is unfortuantely a bit tricky, at least for certain corner cases.

If I remember correctly, at the occasions that I mentioned these notation packages happened to differ in how they recognised or did not recognise corner cases of pitch and rhythmic notation, like microtonal pitches (irrelevant for Synfire), but also certain more complex tuplets. These were not just layout differences (those as easy to fix with something like Dorico).

Of course, I am not saying that there are no problems with Synfire's MusicXML export.

Just for fun, I now created some simple demo with a rhythm based on quintuplets. Unfortunately, the exported MusicXML file could not be read by any of the music notation packages I have (a very old Final 2012, an old Sibelius 7, an up-to-date Dorico 4 and MuseScore). Most applications just opened the music as empty bars with the correct time signature.

Attached is the Synfire file for completeness. The music consists of a stream of even 1/20 note value pulses, but the notes are distributed over two different parts (i.e. the quintuplets would not all consist of notes with the same note values).

This is just a quickly created demo. In an actual piece I would use more complex quintuplets (i.e. not just a even pulse, and including note durations like 1/40 and perhaps even 1/80), and combined with other tuplets. For completeness, I created this piece with a factory composing music in 5/8 time, and then used the "strech by Parameter" feature to scale it by factor 4/5.

I had used the MuiscXML export settings that Synfire automatically suggests. There is no setting available for 1/20 tuplet note values, though this happens to be a particularly common use of quintuplets (more common, e.g., than 1/5).

BTW, I also got something like the following error message, telling me that the file is "not a valid MusicXML file", but with any MusicXML output, not just tuplets. (But without tuplets the content could nevertheless be opened.) 

Fatal error: line 56 column 34 Content of attribute port does not match its type definition: Engine1:02 is not valid according to xs:positiveInteger..

If we can get access to the underlying event data, we could probably write our own exporters?

> write our own exporters

While Music-XML is a highly complex format, when using a tool like Fomus, this is actually not too hard. Fomus is a software and format designed for exporting the results of algorithmic composition systems to music notation, both Music-XML and Lilypond. The software has not been maintained for 10 years or so, the supported Music-XML version is outdated, and the latest version is still officially an alpha version, but nevertheless, it does its job. I have successfully used it myself for creating Music-XML exporters for other composition systems. 

While I would probably _not_ use it in some commercial software for providing notation output, for a community project, where ease and flexibility of the implemention are important, this might be the way to go.

There might also be other ways to simplify Music-XML generation, but Fomus is particularly useful for algorithmic composition system output.

> write our own exporters

All we would need is Synfire exporting all the necessary information that are relevant for the score export, but that may be tricky and not something they want to do. If this could be done natively in the implementation language (translate SmallTalk objects into some textual format?) this could be great.

Alternatively, once/if there would be some KIM API, having an interface to the score representation might be a side effect of that and then the music notation export might perhaps also use that interface (if the KIM API could have access to the data of an arrangement).

Just blue sky speculating here, of course...

>> opened the music as empty bars
> because you didn't select "Auto" or set manually the correct values

Thanks a lot for your feedback, but I need a bit more help here, it seems. I did press the Auto button for the instrument-specific music notation settings before exporting. After that, the Tuplets dropdown menu was set to None. Note that there is no entry 1/20 is this menu, which I would need for this piece, I assume (if I understand this setting correctly). However, the Quantisation drop down menu had automatically been set to 1/20 after pressing Auto.

Long story short: it might be that common quintuplet note values like 1/20, 1/40 and perhaps even 1/80 are still missing in the Tuplets drop down menu in the instrument specific notation settings (and also subdivisions of triplets, BTW). Note that with the MIDI tick resolution recently reported by Andre, all these quintuplet and triplet values (and even smaller quintuplet values like 1/160) should be precisely represented by Synfire without rounding error. For other tuplets (septuplets and higher primes) this is different.

For completeness, all events in this Synfire project (which I attached) should be quantised to a grid of 1/20 note values (assuming the Strech Parameter feature works correctly with arbitrary fractions as factors) -- and the automatically derived quantisation setting quantised the music to that grid anyway. The only rhythm-related parameter used by this piece is the Figure, all the other rhythm parameters -- in particular Shift -- are unset.

Some context information on a few issues:

There is indeed an issue with positioning popup menus and tooltips on HiDPI monitors. If a menu reaches out of screen estate, you can scroll items with the mouse wheel.

The Grid is indicated in green only for odd grids that you picked from the menu. Once you select a regular grid from the tool buttons, the display disappears again. A grid is nevertheless active. Since this confused you, it's worth thinking about a more intuitive grid indication. Just want to avoid having the green grid there all the time.

There are no separate grids for positions and lengths. A single point & click with a pen creates a symbol that starts at the closest grid position and ends and the next. If you want a longer symbol, drag the desired length with the mouse before you release.

Follow Container will unlikely come back. While it was visually interesting, jumping into an arbitrary container that happens to get the next priority during playback is practically useless once you begin nesting containers. A confusing flicker fest.

With a lot of options what to show/hide in a window layout, some parts will inevitably be clipped. We won't introduce frames and scrollbars around every part however. Responsive layout is a science unto itself. Spending time on an entirely new layout engine is currently not a priority. Increasing window size should do it for the time being.

Some of the minor graphics glitches cannot be easily solved. They are due to cross-platform issues in the UI framework we use. Will note them down, but not a priority at the time, except for the most disruptive cases.

Speaking of which, the text entry glitch is serious a HiDPI issue on Windows. The character spacing is not properly scaled in the virtual machine. Hard to fix, as this is not our own code. A high priority nevertheless.

Thanks for sharing all this. 

> The Grid is indicated in green only for odd grids that you picked from the menu. Once you select a regular grid from the tool buttons, the display disappears again. A grid is nevertheless active. 

I am grateful for the flexibility offered by the custom grid button, and personally don't find it confusing. For me, this grid button means basically "custom grid". I assume that always some grid is active (and even the infinity symbol clicked activates some kind of grid it seems). Is this correctly understood?

If so, perhaps there is a way to communicate this with the interface, e.g., that the Grid button is called CGrid (for custom grid) or something. Tool tips and the new interactive help could then spell out that there is always some grid active, and that CGrid stands of custom grid.

Note, the term CGrid is just a spontaneous idea, and perhaps not the best one, because it does not explain itself and cannot even be pronouced easily. Perhaps someone has a better idea along these lines?