Skip to main content

My list of bug reports


This is the thread about bugs. 
For feature requests see My list of suggestions.

This is only a personal list for not having to open 1000 threads, it doesn't represent a roadmap or anything official, etc.

Updated for version 2.0.10 Build #17

Mind that I'm on Windows 10 64-bit.

Marked in yellow are serious problems (IMHO).

Issues introduced with V2

  • With not even a very far zoom, you can't place/move/resize containers with different Schemes because it glitches bad. 
    So you need to zoom in, but it's very hard for the user to guess the cause.
  • Manually (with the mouse) resizing a group of symbols is glitched and unusable. All the lenghts glitches and stretches to the end of the cursor.
  • New around 2.0.9: After creating a new instrument, it appears that by setting any option like "Hide" or "Staves" in the export settings, for such instrument, it actually applies the option to ALL instruments. 
    Still there in build 0.10b17
  • With build #9 or #10, instrument labels just stopped working.
  • A lot of times when clicking on chords in the Palette I get no audio and I have to click "Reset Audio/MIDI System" (or just press stop? suggest but not tried yet) to get playback again. Very easy to reproduce when changing the clicking from the Palette to the Progression above.
  • Selection (the type where you click on the void and you start dragging, in order to enclose symbols) is very broken; e.g.if I release the selection here: 
    it doesn't select anything. If you select quickly, it fails probably because of the slow GUI; however, even if you select slowly but, before releasing the mouse button, you just slightly move the mouse, the selection fails. Especially happens with chords.
  • Selection with the arrow tool ("Pointer") doesn't work. It only works with the "Symbol" tool. This might be on purpose, however the selection rectangle is shown to the user, but no actual selection results from the action, so this is very confusing.
  • Factories: Parameters.Velcity Metric Velocities: Min and Max don't work. Update: I've been able to find out that the bug happens when the range is small, e.g. 62 to 70. In such a case, Synfire just use the entire 0 to 127 range. However small the range input by the user, it should still work with it.
  • The playback vertical line is not shown in the "Phrase Editor", and that's annoying because it's harder to keep track of the position by watching only the top part.
  • In the Palette tab, the orange-highlighted chord, which is currently playing, is often not highlighted in its equivalent palette block when it's currently selected (and so it is blue and it hides among the other colors). When you click on the progression, it should highlight the chord even if it is the correct one (maybe with some border, or by flashing the selected chord, or whichever method).
  • Bad perfomance with the Embedded Help active. The slowest thing is when you click chords in the progression tab: more than 1 second lag. 
    Update 2.0.7: some more improvement. Still a bit laggy when clicking chords and using factories.
  • When you resize the main container such that it fits the window, the horizontal scrollbar is not updated; it disappears only by manually refreshing the window. Same problem that existed for the "tracks" panel.
  • About the feature "Show all velocities in context when altering with mouse": 
    The velocity points are hidden behind notes, including the point you're editing, so, depending on the Figure, sometimes you don't see most of the points.
  • In chord segments, there is no help for inversions and "Close" / "Open", both in tooltips and in the embedded help. Probably due to the usual Smalltalk GUI issues.
  • If Synfire is already open, you cannot open an arrangement or a library from file explorer (at least on Windows): (…)
  • Progression tab, empty section: 
  • There is the "Show Grid" option in the Progression tab too, but it doesn't do anything there.
  • When you have a lot of panels open, factory settings can get hidden and there is no vertical separator to fix this: 
    There should be at least a non-functional visual separator to make clear what's going on.
  • What's this button? 
    Here since 2.0.4; seems like debug stuff.
  • Typing / text edits: (complicated because of technical reasons; Smalltalk, etc.) 
    This is not just a visual glitch, it makes it extremely difficult to edit text, including number sequences. 
    Update 2.0.6 Build #3: slightly improved.
  • In the keyboard shortcut settings, the Spacebar key is shown as empty, probably the space character itself is printed.
  • Assigning a keyboard shortcut combination that uses the Alt key is impossible in Windows.
  • Playback metric scheme glitch, both in the track sheet and in the phrase editor
    Also the playback cursor stutters sometimes, but this may not be fixable with the current GUI. 
    Update 2.0.9: I mean, completely removing the vertical bar in the scheme bar is not a solution... ...
  • New "Dynamics" parameter: the global parameter shadow is drawn even when editing the parameter itself which is casting the shadow.
  • Factory -> Segments -> Check "Tails": the text edits for the tails don't get enabled (they stay grayed out), so you have to switch to another setting and back to correctly reload the panel. 
    To reproduce this you have to start with "Tails" unchecked and coming from another setting.
  • In the factory: 
  • The tooltip / Embedded Help says that to check "Complete chord" in a chord segment there must be at least two vertical symbols in the segment: however you actually need three, otherwise the checkbox is not clickable; a > / >= bug? :)
  • With Factory pages, the width of the Embedded Help gets messed up and I get this: 
    Update: adding an horizontal scrollbar is not a solution to the problem... Because the glitch happens anyway, and then you have to manually fix it with the scrollbar. You have to understand why it happens; it happens only with factories.
  • Tooltips for Preferences -> User Interface -> Tweaks, says Open Embedded Help for information, which however is impossible to open in that window; and other entries have the same problem.
  • Factories: IMHO "Runs" should be called "Segments" to reflect what they actually do and to give an hint to the user when he's getting no output.
  • IMHO it doesn't make sense that crash reports are sent via "Online updates". It's confusing.
  • Minor: unclickable links in the tooltips: ( ; may be complex to fix but it's annoying.
  • Minor: the message "Currently no MIDI port is set for input" etc., at the start, can be reset in the options by resetting all warnings, but its checkbox entry is not there with the others, instead it's in Audio/MIDI Setups -> Inputs
  • Inconsistency in the software icon: there are two different icons being used (one the new light blue one, the other the old one with the pipes) in Windows, depending on where it is displayed.

Old bugs still present in V2

Exporting to notation

Without good support for exporting and for notation, a program cannot be considered music prototyping / composing aid software.


Dedicated thread: (


Sum up:

The goal is to reach at least this basic level: ( in order to make exporting to XML usable.

Synfire's MIDI resolution must be increased to allow the most common tuplets. Nested tuplets are not required (it will be impossible or very complex to do).

Voice splitting is completely unusable

Its A.I. should be improved at least with the piano as the target. Anyway, most importantly, see "Voices support in my suggestions thread.

Usability / GUI


At least on Windows, the GUI can be very slow. For example, moving containers is ultra-slow and glitchy. 
See (
When it is not very slow, it is still a pain to use, because it has enough delay that you feel like you are using some antique emulated software, and it hurts bad. 
2.0.7: big improvements. There's still the thing about the selection gray empty rectangle, which is always behind.

Spacebar and focus

The spacebar sometimes doesn't work because the GUI focus is somewhere else: this is very annoying because sometimes you are not able to start/stop the playback.

This happens with other actions and with other keys/hotkeys too.

Moving note up down with Shift + Up / Down crazy lag

Using Shift + Up hotkey you can move a note up, and if you keep the hotkey pressed the note keeps moving: this as a bit of lag, but if the instant playback is on it has a crazy lag and if freezes the program for a while; so maybe the rendering could be called differently in this particular case.

Container panel: scrolling down makes the metric scheme disappear

In the container panel, scrolling down makes the metric scheme disappear, which is annoying when e.g. moving containers around. The metric scheme should stay visible as it does in the instruments sheet. 

Tabs support

There currently is no support for the tab key. If I'm e.g. in the factory and I'm on a text edit, by pressing tab I expect to move to the next textedit below, instead the focus jumps to a completely different panel.

Text edits/areas: Home and End keys don't work

Especially programmers, but everyone who is familiar enough with computers uses the Home and End keys to quickly jump at the start and at the end of some text. This is currently not supported.

GUI: minor things and glitches

Inspector panel: no scroll

The inspector panel does not scroll, so if the whole bottom panel doesn't have enough height, the content will be truncated. Instead, the parameters list panel to its left, for example, does scroll, preventing this problem.

Tue, 2022-03-01 - 17:30 Permalink

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.

Sun, 2022-04-10 - 17:14 Permalink

Tuplets are hard because figure segments are not tagged as such. maybe they should.

It would be a much appreciated feature. However, in the meanwhile, it's still possible to improve their recognition a lot: just try importing a MIDI from Synfire to MuseScore, and you'll see that MuseScore only fails with 11plets.

As a temporary workaround you could export to MIDI file and import that into MuseScore.

I've tried, and the problem with this approach is that you lose meaningful accidentals / correct enharmonic notes - that's obvious because in MIDI any note is just a number. So I could maybe make a script that copies the notes from the XML file to another XML file derived from the MIDI which has the correct rhytm, but as you can see this is really bad when the XML file could just export correctly in the first place.

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

The "parameters list panel" yes, but not the panel on the right with the actual parameter content.

Mon, 2022-04-25 - 00:19 Permalink

Re-updated for V2. I see that none of the bugs about XML exporting are being touched. Every bug in OP is still valid.

Moreover V2 introduced quite a bunch of new bugs.

Tue, 2022-04-26 - 01:29 Permalink

Updated for Build #49.

I've also been able to find the cause of the bad performance I was getting: it's the Embedded Help. Something should be done about it, e.g. making it run on another thread or something, because it makes the whole software lag a lot.

Wed, 2022-04-27 - 02:40 Permalink

Just found out that in the Interpretation parameter, Clip does work (it drops the notes out of the range of the instrument as set by the user), while Fold and Shift instead do not work, regardless of the Octave setting. The MIDI notes are sent out of range.

This is very bad.

Wed, 2022-04-27 - 22:38 Permalink

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

Thu, 2022-04-28 - 11:58 Permalink

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.

Thu, 2022-04-28 - 14:43 Permalink

Fixing it however will make a few phrases out there render different output for instruments with a narrow total pitch range.

Well isn't that the whole point of "Fold" and "Shift"? It's kind of a compromise, but that's what those options were supposed to do.

If then one wants to have 100% control on the notes, he will carefully draw the figures when they are at the edges of the range, which today is even easier thanks to the "Output" preview feature.

Thu, 2022-04-28 - 15:56 Permalink

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

Thu, 2022-04-28 - 16:35 Permalink

"Output" is what the devs call Synfire's view of the rendering (the actual notes). In V2 it's what you see when you click the Interpretation parameter and when you click the "Overview" tab.

Fri, 2022-04-29 - 11:47 Permalink

For the devs: I didn't bother using V1 because I was waiting for V2, so some bugs that I'm finding right now were present in V1 too; for those, please refere to the section "Old bugs still present in V2", which contains some critical ones, e.g. the palette one.

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

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.

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

If you read the bugs that I've reported regarding XML exporting, you'll see that they have nothing to do with what you are saying. What you're saying is true but has more to do with formatting elements and stuff like that, features that most won't care about when importing to a different notation program which will take care of those elements by its own; those that I've described are just "stupid" bugs, in the sense that they're not complex or related to complex technical problems with the XML format.

Recognizing tuplets may be complex but it's recognizing Synfire's own tuplets, so that one too, is not a problem regarding technical difficulties with the XML format itself.

Sat, 2022-05-07 - 15:47 Permalink

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.

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

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


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

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

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

Most applications just opened the music as empty bars with the correct time signature.

When that happens, it's because you didn't select "Auto" or set manually the correct confusing values like "X + Y" in the dropdown menu for tuplets. By playing around with those dropdown menus for each instrument's own export panel, you should be able to at least get some output.
Of course those menus should not even exist, the reason why they do is that Synfire uses all those Shift / Morph things and so when you're going to export your music, the developer thought "well let's ask the user how he wants to export this confusing resulting bunch of rhythms and notes", and so the user says "well I want 1/4 + whatever" and then the software supposedly tries to quantize the output following the provided info; but of course it's unusable in practice.


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

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

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

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

Sat, 2022-05-07 - 20:44 Permalink

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

Thu, 2022-05-19 - 09:03 Permalink

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.

Thu, 2022-05-19 - 11:27 Permalink

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?