I can confirm that ties are now notated correctly for the example I shared above (notation_straight_tie_1.cognac), if suitable pre-processing settings are chosen.
However, the automatically chosen pre-processing settings are not helpful. No problem for me, but might confuse new users.
I attach two screen shots, one with preprocessing settings that work well for this example, and also the automatic settings that do not work.
Anyway, as I said, good enough for me. Perhaps simply a warning that the Auto button is experimental might be sufficient for now?
Unfortuantely, the notation resulting for the more complex quintuplet example is not correct yet. So, to make things sure (and as I could not further edit the previously shared example) I now basically recreated the example and manually quantised it (checking it with the corresponding grid lines). I am sharing below the updated Synfire file, and how the exported notation should look like (manually created in Dorico -- only the correct rhythm is relevant here), and the resulting MusicXML file exported by Dorico for good measures (trying to help with some potential format difficulties).
If this Dorico MusicXML file is imported into MuseScore, then there is no error and the music is also shown there correctly. By contrast, if the MusicXML file exported by Synfire is imported to MuseScore, then it complains with the following error message (similarily already shared above):
Bar 2, stave 1 incomplete. Expected: 68/64; Found: 351/320
Bar 4, stave 1 incomplete. Expected: 68/64; Found: 351/320
More importantly, the automatically generated MusicXML file shows a wrong rhythm (see a further notation screenshot below). Note that in the correct rhythm, the second bar contains exactly 4 quarter notes, each split into a somewhat complex quintuplet. Also, each quintuplet contains notes that together are exactly 5 * 1/20 = 1/4 notes. For example, the first quintuplet consists of the durations 3/20 + 1/20 + 1/20 = 1/4 (note the tie at the end of the first quintuplet). By contrast, in the Dorico result the first quintuplet consists of the durations 3/20 + 1/20 + 2/20 = 1/4 + 1/20, i.e. the first quintuplet is already too long. There is later another such over-long quintuplet in the first bar etc.
With the example notation_straight_oddmeter_layered.cognac (see my post above from Sat, 05/14/2022 - 15:04), the layers are still not kept separate (though the ties are improved now). Would it be helpful if I also share for this example how a correct solution should look like?
Anyway, for me fixing the notation of tuplets would be more important than the correct handling of layers/voices, as there exists kind-of a workaround (simply using only tracks with a single figure at any time).
Notation Export: Accidentals and enharmonic mismatches fixed
Enharmonic mismatches, yes, but the accidentals-problem is not fixed at all.
I don't know if it is because you didn't consider the key or what, but you cannot be careless about this because it's about wrong notes; it is not acceptable.
I'll repost the old picture here highlighting the problem inside the XML file (assuming that's still the cause, I don't care to check):
Notation Export: Configure external editors to launch after export
Doesn't work though. I've double-checked the MS path.
Notation Export: Fixed note ties across measures
Fix confirmed. Also works across meter changes.
Notation Export: Meter changes not exported with MusicXML
I couldn't use some of your examples because septuplets, nonuplets and 11-plets are not yet supported. I'll check if I missed a particular one.
Concerning the E from hell:
In the key of Gb Major, Synfire exports an E as Fb. It's probably not the best and only spelling for this out-of-scale pitch, but it is definitely NOT the wrong pitch! MuseScore gets this and prints the pitch as E natural. Dorico takes the b of Fb literally and displays it as such, which is wrong. In my opinion it's a bug.
The challenge with Gb/F# Major is that it can be written as all flats or all sharps. I may have missed something, but I currently can't tell which option the notation program will choose. LilyPond chooses flats, MuseScore happens to choose sharps. Therefore it is hard to decide whether it's flats or sharps that should be canceled out by a 'natural' sign (as MuseScore correctly does).
In the current build, Synfire therefore leaves it to the notation program to make that decision based on its preferences. Dorico can't handle this.
I'm also not yet 100% sure where MusicXML wants pitch information literally ("as printed in the score"), and where they are supposed to be semantical ("as you spell them in the key"), which is what Synfire does by default.
This is still an unresolved issue, but the case is not trivial at all, so please don't mock me for not getting it right from the start.
@tanders
Thanks for the detailed feedback and files. I'm surprised that rhythm gets altered to that extent. Have you tried the 'Already Quantized' option? Synfire shouldn't alter rhythm with this setting, except what you configured per each voice using the menus below.
But the marked note in the last Dorico score is an Eb, not a Fb.
By the way: I hope that now not all the development resources will go into this XML stuff, which will never work usably anyway. Generating reasonably readable scores from MIDI data automatically and with a few general settings has never worked and will never work.
You're talking about harmony, which has nothing to do with it: as juergen pointed out to you, the problem is that MuseScore gives one result while Dorico gives another (a different note! - it's not about spelling, it's a wrong note as in pitch!), and this is because the "alter" tag says one thing while the "accidental" tag says another thing, which is obviously a bug from Synfire's part (clearly shown in the picture).
All this is regardless of what spelling Synfire chose in the first place, which I'm sure internally it uses a correct one since it works with harmony internally.
I couldn't use some of your examples because septuplets, nonuplets and 11-plets are not yet supported. I'll check if I missed a particular one.
But triplets and quintuplets are, and they still are exported wrong in those particular measures. Unless having other tuplets messes up the recognition of triplets and quintuplets too, which I wouldn't see why.
@juergen
By the way: I hope that now not all the development resources will go into this XML stuff, which will never work usably anyway. Generating reasonably readable scores from MIDI data automatically and with a few general settings has never worked and will never work.
Thank you for understanding and supporting this issues.
Isnt the xml saying the note is an E on the second octave, due to the scale used that would normally be an E# but the accidental parameter makes it a natural E as you highlighted in the picture. So the xml is correct (music xml only allows A-G as a step value). One notation package gets it right the other gets it wrong but the xml surely is correct assuming your picture correctly identifiedthe note as a natural E rather than a sharp? Sorry if I've missunderstood what you were describing.
@blacksun I don't know why it's hard to understand that picture. Maybe because you guys are missing the first sub-picture that says that inside Synfire the sound is an "E natural", or because you are missing the sub-picture on the right that shows the wrong accidental?
Or because you don't know that the <accidental> tag in XML is meant to be the SHOWN/NOTATED ACTUAL accidental for that note symbol?
If you now understand this, then:
One notation package gets it right the other gets it wrong but the XML is correct
No, the XML is ambiguous and uncorrect, and therefore the notation packages have to make guesses.
To summarize: MuseScore gets the note right, because it interprets the XML wrong and Dorico gets the note wrong, because it interprets the XML right. :))
Pretty much, however MuseScore actually sees the ambiguity, and it makes a correct guess.
MuseScore in fact is the best when it comes to export/import.
I'm not sure what is the actual use of the accidental tag, since you would expect it to always match the alter tag anyway. Probably for micro-tonal music so even if it's a semi-sharp or whatever it's called, you can graphically display a normal sharp for easier reading, and specify at the start of the score the composers' intention. Then, of course, you would need a notation program that is able to read this behavior.
( Edit: Oh, and for courtesy accidentals, of course! )
In normal situations, you shouldn't use the accidental tag at all.
I don't think that MuseScore makes a guess. It just takes the E# note from the key and shifts it down to E because of the accidental tag. Which is a wrong interpretation, IMO. It were correct, if it were an "alter" tag.
If the XML code says there should be an Eb, then the software should write an Eb. Irrespective of the key.
I am surprised by the tone here. It goes without saying that cordiality is of upmost importance if we want to get anywhere here. Telling some company addressing a niche market they should hire more staff is not helpful, certainly not in this tone.
By contrast, thank you scriabiner for also providing concrete technical MusicXML advice! I understand that it can be frustrating that you seemingly have to keep repeating the same advice, but still.
Sorry for interferring this way, but I hope you see where I am coming from.
No, that's not how it works (we're going off-topic by the way): as I said, notes are absolute, independent of the key. So, since the alter parameter is not specified, MuseScore assumes it to be 0 (zero), and therefore a natural (correctly): therefore, as a notation software program, MS puts a natural accidental by itself, because of the key signature. The accidental tag is simply ignored, and is never (and should never) be interpreted in the way that you intended (as in "flatten this note" - it's an actual flat accidental instead, as Dorico knows).
@tanders
The niche market is already reflected in the price of the software. And I don't know which tone I should use to express my disappointment.
You do have a point regardless so, sorry for the behavior. I'll try to keep it technical.
As i understand it correct ?: E natural note in the example of the key Gb major is belonging to that key ( that is why it named ..naturel)
On the keyboard it is pressed Eb
> I'm surprised that rhythm gets altered to that extent. Have you tried the 'Already Quantized' option?
Thanks for your efforts addressing this. I guesstimate that the problem here might be the handling of ties between tuplets. I will soon prepare and share further tests only checking this aspect.
> Generating reasonably readable scores from MIDI data automatically and with a few general settings has never worked and will never work.
For the general case of generating notation from arbitrary MIDI data, probably the most tricky subproblem is quanitisation (in particular when tuplets should be supported as well). However, that problem is eliminated here, as with Synfire's MIDI ticks resolution triplets and quintuplets are represented with durations that are exact (as if they would be true fractions).
The outstanding problem of tuplet notation here is to correctly group notes (e.g., to recognise when the duration of, e.g., a beat is "full" and whether a tie should be notated), but that problem is solveable (as it has seemingly been solved for "plain" durations that are not tuplets already).
probably the most tricky subproblem is quanitisation
No, voicing is the main problem. All I see in this thread is monophonic score. Something like that is of course solvable.
For music above a certain level of complexity however, you will never find a setting for voicing and quantization that fits the whole piece. You would have to be able to set this at least bar by bar. Just like in a notation program. Otherwise it makes no sense at all.
There used to be a software (Scorecleaner) that the manufacturer claimed to address this problem with the help of artificial intelligence. With moderate success, however.
@scriabiner I miss read the xml specs before and assumed that as the alter parameter was left as default but the scale meant that the note would normally be sharp, that the note would be sharpened, hence the accidental to 'flatten the sharp'. Re-reading the spec I now hope I've understood it better? The alter parameter is to do with playback and transposition, not notation and should be explicity set if a flat or sharp is needed even if that sharped/flatteren note is in key, so it was correct to leave it out in this case; accidentals are used to alter the notation so that parameter should have been natural not flat?
As a workaround it is possible to work with monophonic lines only and represent each track by multiple layers. E.g., even a texture as complex as a Debussy piano piece can be represented by, say, three to five layers for the right hand of the piano. Piano factory results are commonly simpler and would not even need that many layers. It is only a workaround, but it is possible, and these many layers can then later manually be combined into a single staff in the music notation editor.
Deducing voicing from the Synfire data structure is much simpler than doing that with a MIDI file. While the MIDI representation is a flat sequence of events, the Synfire data structure is already structured into groups of symbols, and symbols can be distinguished by figure type. There still has to have some analysis happening, and might also involve guesswork, but it is not as complex.
As I've previously stated, the workaround is non-usable because Synfire lacks a "Split to below instrument(s)" option. It creates a new one every time, making it a pain. Moreover, the symbol colors are not an appropriate way to separate voices. Two voices can make sense to be both blue.
Finally, it's literally impossible to detect voices via AI, because there can be multiple final solutions. E.g. the composer may want two simultaneus notes to be two separate voices or a single one. Giving the user control is the only option.
> Synfire lacks a "Split to below instrument(s)" option
I meanwhile accepted that for music notation output I currently have to do certain things manually, e.g., splitting layered tracks in Synfire and moving them back together in a notation editor. That is something I can do by hand (though it takes time). Sure, not ideal and I certainly see your point.
However, if the rhythm of a single layer is distorted by the notation output, that is more difficult to fix manually.
As a workaround it is possible to work with monophonic lines only and represent each track by multiple layers.
Yes, that may be possible, but it's certainly not any faster than if I just do a MIDI export and edit it all manually right away in the notion program. Which also has several advantages over the XML export:
Any notation program has better options for setting up quantization and voicing than Synfire
If I export as XML, I'm stuck with the quantization I chose at the export, i.e. it can't be changed anymore at the notation program. If I export as MIDI I can re-quantize any part of the score at any time.
If I change the quantization settings for the imported MIDI data in the notation editor, I can see instantly the result. The settings in Synfire are a shot in the dark and you will certainly need a couple of tries until it fits reasonably well.
The suggestion to pack monophonic lines into individual layers only works if Synfire recognizes the correct notes as a monophonic line. I doubt that this works reliably and correcting this later in the notation program is much more work than editing the voicing manually from the beginning.
> Any notation program has better options for setting up quantization and voicing than Synfire
I don't quite agree: with Synfire I can quantise individual figures directly in the library (and also the arrangement window) while composing or generating these figures. I can there choose custom quantisation settings (grids) per figure or even per individual phrase. I can also kind of verify these quantisations when comparing the note start/ends with the grid lines. In other words, I don't have to rely on the quantisation of the notation export in the end, I would use quantised notes throughout anyway.
> The suggestion to pack monophonic lines into individual layers only works if Synfire recognizes the correct notes as a monophonic line.
Indeed, currently Synfire still has problems to recognise exactly tuplets even of single layers (chords or monophonic lines), but I hope this can be fixed.
I would not be against using a different workflow, but so far from what you are saying I fail to see the advantage of using MIDI export and then MIDI input in a notation program. Perhaps I am missing something?
I don't quite agree: with Synfire I can quantise individual figures directly in the library (and also the arrangement window) while composing or generating these figures.
You are talking about the quantization options in the phrase editor. There I can quantize each figure individually, thats right. But I am talking about the quantization and voicing options for the XML export which apply for the whole composition. Only these are relevant to the topic of notation. At least as far as my workflow is concerned. To help you understand this better, I may have to explain this workflow briefly:
While working on a composition, I don't care in any way about things like quantization, voice splitting, playability, or visual appearance. I use all the phrase processing and transformation features Synfire has to offer and judge the result solely on what comes out of the speaker and not on how it looks on the screen. When I am satisfied with the musical result at some point, then this creative phase of the work is finished and the composition is complete. Only then do I even begin to think about the notation. I won't touch the figures in the phrase editor anymore, because that would change the musical result. Only the quantization and voicing options for the export are then still available to me.
Of course, because of the way I work, the figures in the phrase editor always end up looking totally messed up. But that's not what matters. The only thing that matters is how it sounds. Making playable sheet music out of it is hard work anyway, regularly taking much longer than the actual work on the composition. I only do it when it's necessary, i.e. when I need the sheet music. At this point, of course, you also have to think about things like quantization. But since some musical information will inevitably be lost in this process, you have to think about it very carefully, note by note and measure by measure. Nothing happens automatically.
But as I said, of course, it all depends on the workflow. If someone composes in such a way that he brushes note by note into the phrase editor and always diligently presses the right quantize buttons, then things naturally look different. But I can't work like that.
Thanks everyone for your helpful input. I just returned from a few days off to regenerate and am now tackling this so we can move forward.
@scriabiner
Since it created some confusion, I should note that the pictures you re-posted here and some comments that ensued no longer reflect the current XML output. Potential candidates for that particular E in this key would be D##, E natural and Fb (as currently exported). The unresolved challenge is which one to choose, i.e. the general algorithm that works for all out-of-scale pitches in all keys, and how to best export that in XML.
If the "accidental" element is not needed and the notation programs are expected to fill-in the missing notation details themselves, all the better. I'll try that and see. The sparsely documented MusicXML format is full of redundancies and obscure dependencies. I've been on Michael Good's discussion list when the format was created. Even met him in person. Much of what was discussed back in the day can no longer be found in the documentation.
@tanders
The outstanding problem of tuplet notation here is to correctly group notes
Thanks for stating the problem in detail. Correct me if I'm wrong. My understanding of tuplets is that isolated 1/5, 1/10, 1/6, 1/12 or whatever notes don't make sense. They should always be grouped in numbers that fill a meaningful span in the time signature (including intermittent rests).
But what if they don't? Synfire attempts to fill the gaps with rests (or by stretching a note, if the user opted so), preferably continuing the type of tuplet of the most recent note. But often these gaps can't be filled with meaningful rests and then things start looking ugly.
Inside one measure, is it more common to split rests into smaller units to match the beat, or to use the longest possible rest that fits the gap, possibly with lots of dots, even if it crosses beats? The answer probably is "it depends", but how is it specifically with tuplets?
@juergen
you will never find a setting for voicing and quantization that fits the whole piece
The main reason "Auto" doesn't always work as intended. We should eventually have notation preferences per container, like a regular parameter.
The only thing that matters is how it sounds.
This even had a name when Synfire was born: Composing By Listening. Although, I think other workflows should be accommodated where possible, too. Since the various transformations of Figure make about 50% of the power of Synfire, when it comes to tagging something manually, the focus should be on tags that can survive this treatment.
Fri, 2022-05-20 - 14:39 Permalink
I can confirm that ties are now notated correctly for the example I shared above (notation_straight_tie_1.cognac), if suitable pre-processing settings are chosen.
However, the automatically chosen pre-processing settings are not helpful. No problem for me, but might confuse new users.
I attach two screen shots, one with preprocessing settings that work well for this example, and also the automatic settings that do not work.
Anyway, as I said, good enough for me. Perhaps simply a warning that the Auto button is experimental might be sufficient for now?
Fri, 2022-05-20 - 16:12 Permalink
Unfortuantely, the notation resulting for the more complex quintuplet example is not correct yet. So, to make things sure (and as I could not further edit the previously shared example) I now basically recreated the example and manually quantised it (checking it with the corresponding grid lines). I am sharing below the updated Synfire file, and how the exported notation should look like (manually created in Dorico -- only the correct rhythm is relevant here), and the resulting MusicXML file exported by Dorico for good measures (trying to help with some potential format difficulties).
If this Dorico MusicXML file is imported into MuseScore, then there is no error and the music is also shown there correctly. By contrast, if the MusicXML file exported by Synfire is imported to MuseScore, then it complains with the following error message (similarily already shared above):
More importantly, the automatically generated MusicXML file shows a wrong rhythm (see a further notation screenshot below). Note that in the correct rhythm, the second bar contains exactly 4 quarter notes, each split into a somewhat complex quintuplet. Also, each quintuplet contains notes that together are exactly 5 * 1/20 = 1/4 notes. For example, the first quintuplet consists of the durations 3/20 + 1/20 + 1/20 = 1/4 (note the tie at the end of the first quintuplet). By contrast, in the Dorico result the first quintuplet consists of the durations 3/20 + 1/20 + 2/20 = 1/4 + 1/20, i.e. the first quintuplet is already too long. There is later another such over-long quintuplet in the first bar etc.
Fri, 2022-05-20 - 16:27 Permalink
With the example notation_straight_oddmeter_layered.cognac (see my post above from Sat, 05/14/2022 - 15:04), the layers are still not kept separate (though the ties are improved now). Would it be helpful if I also share for this example how a correct solution should look like?
Anyway, for me fixing the notation of tuplets would be more important than the correct handling of layers/voices, as there exists kind-of a workaround (simply using only tracks with a single figure at any time).
Fri, 2022-05-20 - 22:30 Permalink
The Figure in your example is gray because it's in an other container ;-)
Sat, 2022-05-21 - 07:54 Permalink
> The Figure in your example is gray because it's in an other container ;-)
Oops. Thanks man, and sorry for the noise.
Tue, 2022-05-24 - 21:52 Permalink
Got the time to check around a bit. Unsurprisingly, I must say, nothing works.
Did you use the attachment files from my old emails? If you did, how were you able to export correctly?
After importing from MIDI and attempting to export to XML:
The files you already have. They are in my old email with the numbered attachments:
The example posted here: (https://users.cognitone.com/comment/19664#comment-19664)
does not work for tuplets and quintuplets.
Enharmonic mismatches, yes, but the accidentals-problem is not fixed at all.
I don't know if it is because you didn't consider the key or what, but you cannot be careless about this because it's about wrong notes; it is not acceptable.
I'll repost the old picture here highlighting the problem inside the XML file (assuming that's still the cause, I don't care to check):
Doesn't work though. I've double-checked the MS path.
Fix confirmed. Also works across meter changes.
Fix confirmed.
Wed, 2022-05-25 - 20:52 Permalink
@scriabiner
I couldn't use some of your examples because septuplets, nonuplets and 11-plets are not yet supported. I'll check if I missed a particular one.
Concerning the E from hell:
In the key of Gb Major, Synfire exports an E as Fb. It's probably not the best and only spelling for this out-of-scale pitch, but it is definitely NOT the wrong pitch! MuseScore gets this and prints the pitch as E natural. Dorico takes the b of Fb literally and displays it as such, which is wrong. In my opinion it's a bug.
The challenge with Gb/F# Major is that it can be written as all flats or all sharps. I may have missed something, but I currently can't tell which option the notation program will choose. LilyPond chooses flats, MuseScore happens to choose sharps. Therefore it is hard to decide whether it's flats or sharps that should be canceled out by a 'natural' sign (as MuseScore correctly does).
In the current build, Synfire therefore leaves it to the notation program to make that decision based on its preferences. Dorico can't handle this.
I'm also not yet 100% sure where MusicXML wants pitch information literally ("as printed in the score"), and where they are supposed to be semantical ("as you spell them in the key"), which is what Synfire does by default.
This is still an unresolved issue, but the case is not trivial at all, so please don't mock me for not getting it right from the start.
@tanders
Thanks for the detailed feedback and files. I'm surprised that rhythm gets altered to that extent. Have you tried the 'Already Quantized' option? Synfire shouldn't alter rhythm with this setting, except what you configured per each voice using the menus below.
Thu, 2022-05-26 - 00:41 Permalink
But the marked note in the last Dorico score is an Eb, not a Fb.
By the way: I hope that now not all the development resources will go into this XML stuff, which will never work usably anyway. Generating reasonably readable scores from MIDI data automatically and with a few general settings has never worked and will never work.
Sat, 2022-10-01 - 19:36 Permalink
@andre
You're talking about harmony, which has nothing to do with it: as juergen pointed out to you, the problem is that MuseScore gives one result while Dorico gives another (a different note! - it's not about spelling, it's a wrong note as in pitch!), and this is because the "alter" tag says one thing while the "accidental" tag says another thing, which is obviously a bug from Synfire's part (clearly shown in the picture).
All this is regardless of what spelling Synfire chose in the first place, which I'm sure internally it uses a correct one since it works with harmony internally.
But triplets and quintuplets are, and they still are exported wrong in those particular measures. Unless having other tuplets messes up the recognition of triplets and quintuplets too, which I wouldn't see why.
@juergen
Thank you for understanding and supporting this issues.
Thu, 2022-05-26 - 12:43 Permalink
Isnt the xml saying the note is an E on the second octave, due to the scale used that would normally be an E# but the accidental parameter makes it a natural E as you highlighted in the picture. So the xml is correct (music xml only allows A-G as a step value). One notation package gets it right the other gets it wrong but the xml surely is correct assuming your picture correctly identifiedthe note as a natural E rather than a sharp? Sorry if I've missunderstood what you were describing.
Thu, 2022-05-26 - 14:28 Permalink
@blacksun I don't know why it's hard to understand that picture. Maybe because you guys are missing the first sub-picture that says that inside Synfire the sound is an "E natural", or because you are missing the sub-picture on the right that shows the wrong accidental?
Or because you don't know that the <accidental> tag in XML is meant to be the SHOWN/NOTATED ACTUAL accidental for that note symbol?
If you now understand this, then:
No, the XML is ambiguous and uncorrect, and therefore the notation packages have to make guesses.
Sat, 2022-10-01 - 19:37 Permalink
Thu, 2022-05-26 - 15:10 Permalink
Gb major key is the same key as F# major key, if i am correct..
Gives the F# major key the same wrong note?
Never dived deep into the keys in Synfire, but probably the Gb major key and the F # major key are both selectable ?
Thu, 2022-05-26 - 15:28 Permalink
To summarize: MuseScore gets the note right, because it interprets the XML wrong and Dorico gets the note wrong, because it interprets the XML right. :))
Sat, 2022-05-28 - 19:08 Permalink
Pretty much, however MuseScore actually sees the ambiguity, and it makes a correct guess.
MuseScore in fact is the best when it comes to export/import.
I'm not sure what is the actual use of the accidental tag, since you would expect it to always match the alter tag anyway. Probably for micro-tonal music so even if it's a semi-sharp or whatever it's called, you can graphically display a normal sharp for easier reading, and specify at the start of the score the composers' intention. Then, of course, you would need a notation program that is able to read this behavior.
( Edit: Oh, and for courtesy accidentals, of course! )
In normal situations, you shouldn't use the accidental tag at all.
Thu, 2022-05-26 - 15:58 Permalink
I don't think that MuseScore makes a guess. It just takes the E# note from the key and shifts it down to E because of the accidental tag. Which is a wrong interpretation, IMO. It were correct, if it were an "alter" tag.
If the XML code says there should be an Eb, then the software should write an Eb. Irrespective of the key.
Thu, 2022-05-26 - 16:01 Permalink
>> so please don't mock me
> And we should tell you?
I am surprised by the tone here. It goes without saying that cordiality is of upmost importance if we want to get anywhere here. Telling some company addressing a niche market they should hire more staff is not helpful, certainly not in this tone.
By contrast, thank you scriabiner for also providing concrete technical MusicXML advice! I understand that it can be frustrating that you seemingly have to keep repeating the same advice, but still.
Sorry for interferring this way, but I hope you see where I am coming from.
Thu, 2022-05-26 - 16:48 Permalink
@juergen
No, that's not how it works (we're going off-topic by the way): as I said, notes are absolute, independent of the key. So, since the alter parameter is not specified, MuseScore assumes it to be 0 (zero), and therefore a natural (correctly): therefore, as a notation software program, MS puts a natural accidental by itself, because of the key signature. The accidental tag is simply ignored, and is never (and should never) be interpreted in the way that you intended (as in "flatten this note" - it's an actual flat accidental instead, as Dorico knows).
@tanders
The niche market is already reflected in the price of the software. And I don't know which tone I should use to express my disappointment.
You do have a point regardless so, sorry for the behavior. I'll try to keep it technical.
Thu, 2022-05-26 - 17:00 Permalink
As i understand it correct ?: E natural note in the example of the key Gb major is belonging to that key ( that is why it named ..naturel)
On the keyboard it is pressed Eb
Thu, 2022-05-26 - 20:09 Permalink
> I'm surprised that rhythm gets altered to that extent. Have you tried the 'Already Quantized' option?
Thanks for your efforts addressing this. I guesstimate that the problem here might be the handling of ties between tuplets. I will soon prepare and share further tests only checking this aspect.
> Generating reasonably readable scores from MIDI data automatically and with a few general settings has never worked and will never work.
For the general case of generating notation from arbitrary MIDI data, probably the most tricky subproblem is quanitisation (in particular when tuplets should be supported as well). However, that problem is eliminated here, as with Synfire's MIDI ticks resolution triplets and quintuplets are represented with durations that are exact (as if they would be true fractions).
The outstanding problem of tuplet notation here is to correctly group notes (e.g., to recognise when the duration of, e.g., a beat is "full" and whether a tie should be notated), but that problem is solveable (as it has seemingly been solved for "plain" durations that are not tuplets already).
Thu, 2022-05-26 - 21:06 Permalink
No, voicing is the main problem. All I see in this thread is monophonic score. Something like that is of course solvable.
For music above a certain level of complexity however, you will never find a setting for voicing and quantization that fits the whole piece. You would have to be able to set this at least bar by bar. Just like in a notation program. Otherwise it makes no sense at all.
There used to be a software (Scorecleaner) that the manufacturer claimed to address this problem with the help of artificial intelligence. With moderate success, however.
Thu, 2022-05-26 - 21:43 Permalink
@scriabiner I miss read the xml specs before and assumed that as the alter parameter was left as default but the scale meant that the note would normally be sharp, that the note would be sharpened, hence the accidental to 'flatten the sharp'. Re-reading the spec I now hope I've understood it better? The alter parameter is to do with playback and transposition, not notation and should be explicity set if a flat or sharp is needed even if that sharped/flatteren note is in key, so it was correct to leave it out in this case; accidentals are used to alter the notation so that parameter should have been natural not flat?
Thu, 2022-05-26 - 23:39 Permalink
Correct.
True. By the way, the ability to tag voices is one of my feature requests.
Fri, 2022-05-27 - 08:19 Permalink
> voicing is the main problem.
That might well be but
Fri, 2022-05-27 - 12:33 Permalink
As I've previously stated, the workaround is non-usable because Synfire lacks a "Split to below instrument(s)" option. It creates a new one every time, making it a pain. Moreover, the symbol colors are not an appropriate way to separate voices. Two voices can make sense to be both blue.
Finally, it's literally impossible to detect voices via AI, because there can be multiple final solutions. E.g. the composer may want two simultaneus notes to be two separate voices or a single one. Giving the user control is the only option.
Fri, 2022-05-27 - 22:34 Permalink
> Synfire lacks a "Split to below instrument(s)" option
I meanwhile accepted that for music notation output I currently have to do certain things manually, e.g., splitting layered tracks in Synfire and moving them back together in a notation editor. That is something I can do by hand (though it takes time). Sure, not ideal and I certainly see your point.
However, if the rhythm of a single layer is distorted by the notation output, that is more difficult to fix manually.
Fri, 2022-05-27 - 23:28 Permalink
Yes, that may be possible, but it's certainly not any faster than if I just do a MIDI export and edit it all manually right away in the notion program. Which also has several advantages over the XML export:
Sat, 2022-05-28 - 09:14 Permalink
> Any notation program has better options for setting up quantization and voicing than Synfire
I don't quite agree: with Synfire I can quantise individual figures directly in the library (and also the arrangement window) while composing or generating these figures. I can there choose custom quantisation settings (grids) per figure or even per individual phrase. I can also kind of verify these quantisations when comparing the note start/ends with the grid lines. In other words, I don't have to rely on the quantisation of the notation export in the end, I would use quantised notes throughout anyway.
> The suggestion to pack monophonic lines into individual layers only works if Synfire recognizes the correct notes as a monophonic line.
Indeed, currently Synfire still has problems to recognise exactly tuplets even of single layers (chords or monophonic lines), but I hope this can be fixed.
I would not be against using a different workflow, but so far from what you are saying I fail to see the advantage of using MIDI export and then MIDI input in a notation program. Perhaps I am missing something?
Sat, 2022-05-28 - 11:43 Permalink
You are talking about the quantization options in the phrase editor. There I can quantize each figure individually, thats right. But I am talking about the quantization and voicing options for the XML export which apply for the whole composition. Only these are relevant to the topic of notation. At least as far as my workflow is concerned. To help you understand this better, I may have to explain this workflow briefly:
While working on a composition, I don't care in any way about things like quantization, voice splitting, playability, or visual appearance. I use all the phrase processing and transformation features Synfire has to offer and judge the result solely on what comes out of the speaker and not on how it looks on the screen. When I am satisfied with the musical result at some point, then this creative phase of the work is finished and the composition is complete. Only then do I even begin to think about the notation. I won't touch the figures in the phrase editor anymore, because that would change the musical result. Only the quantization and voicing options for the export are then still available to me.
Of course, because of the way I work, the figures in the phrase editor always end up looking totally messed up. But that's not what matters. The only thing that matters is how it sounds. Making playable sheet music out of it is hard work anyway, regularly taking much longer than the actual work on the composition. I only do it when it's necessary, i.e. when I need the sheet music. At this point, of course, you also have to think about things like quantization. But since some musical information will inevitably be lost in this process, you have to think about it very carefully, note by note and measure by measure. Nothing happens automatically.
But as I said, of course, it all depends on the workflow. If someone composes in such a way that he brushes note by note into the phrase editor and always diligently presses the right quantize buttons, then things naturally look different. But I can't work like that.
Sat, 2022-05-28 - 17:01 Permalink
Thanks everyone for your helpful input. I just returned from a few days off to regenerate and am now tackling this so we can move forward.
@scriabiner
Since it created some confusion, I should note that the pictures you re-posted here and some comments that ensued no longer reflect the current XML output. Potential candidates for that particular E in this key would be D##, E natural and Fb (as currently exported). The unresolved challenge is which one to choose, i.e. the general algorithm that works for all out-of-scale pitches in all keys, and how to best export that in XML.
If the "accidental" element is not needed and the notation programs are expected to fill-in the missing notation details themselves, all the better. I'll try that and see. The sparsely documented MusicXML format is full of redundancies and obscure dependencies. I've been on Michael Good's discussion list when the format was created. Even met him in person. Much of what was discussed back in the day can no longer be found in the documentation.
@tanders
Thanks for stating the problem in detail. Correct me if I'm wrong. My understanding of tuplets is that isolated 1/5, 1/10, 1/6, 1/12 or whatever notes don't make sense. They should always be grouped in numbers that fill a meaningful span in the time signature (including intermittent rests).
But what if they don't? Synfire attempts to fill the gaps with rests (or by stretching a note, if the user opted so), preferably continuing the type of tuplet of the most recent note. But often these gaps can't be filled with meaningful rests and then things start looking ugly.
Inside one measure, is it more common to split rests into smaller units to match the beat, or to use the longest possible rest that fits the gap, possibly with lots of dots, even if it crosses beats? The answer probably is "it depends", but how is it specifically with tuplets?
@juergen
The main reason "Auto" doesn't always work as intended. We should eventually have notation preferences per container, like a regular parameter.
This even had a name when Synfire was born: Composing By Listening. Although, I think other workflows should be accommodated where possible, too. Since the various transformations of Figure make about 50% of the power of Synfire, when it comes to tagging something manually, the focus should be on tags that can survive this treatment.