audiveris
audiveris copied to clipboard
Audiveris
measures containing only small note heads are not exported
When exporting this score, the first measures that contain only notes with small note heads are not exported, resp. the exported measures are empty.
Yes, I can confirm that the small chords are not exported to MusicXML.
The "reason" is such small chords are generally located just before "standard" head chords, with even sometimes a slur linking small and standard chords. Such small chords are not considered during the RHYTHYM step, not contributing to the time slots. Their voice is only inferred from the voice of the related standard chord.
At export time, we work voice after voice. Hence, a small chord is exported only when it is somehow related to a standard chord. In the example at hand, we have a series of small chords at the end of measure 29, and for the whole measure 30.
There is no "standard" chord on the right side of these small chords, hence no relation and nothing to trigger their export.
To fix this, we have to rework the RHYTHYM algorithm:
- in general cases, such small chords do not interfere with time computation, based only on standard chords
- in the case at hand, they should be treated more or less like standard chords.
The question is: how the engine OMR could detect the latter case? Perhaps because there is not suitable standard chord on the right side of each of these small chords...
If you have any idea, I'm interested.
The normal function of small note heads are grace notes. And they must not be considered in the rhythm control system - just as you describe above. On the other hand, sometimes small note heads are used for variants of the melody for different verses: in the case above, the 1st verse only uses the normal notes while the 2nd verse additionally needs the small ones (due to some more syllables in the lyrics). To make things not too complicated I suppose to handle these notes as normal ones - ignoring the small heads during transcription. This can later be easily performed in the notation system (if necessary).
On the other hand, sometimes small note heads are used for variants of the melody for different verses: in the case above, the 1st verse only uses the normal notes while the 2nd verse additionally needs the small ones (due to some more syllables in the lyrics).
In the case at hand there is only one verse, so we can't rely on this.
Oh, I forgot about the 3rd case of using these small notes: an instrumental melody played between the melody. This appears sometimes esp. for scores for guitar players: They get the chords and melody for singing, and get a hint for playing a typical melody between the singing parts. But anyway: It makes things too complicated to perform any splitting of this. Or... maybe it makes sense just to move them to a 2nd voice (which may be critical because of the position inside a measure..)
I like this idea of a second voice. The problem is still for the OMR engine to decide to start a new voice or not.
For the time being, and for lack of clear algorithm, we can resort to a new user indication in the existing Chords popup menu. Something like: "This chord starts a new voice". Then if it's a small head chord, the engine will know what to do with it, and with the following small chords in the same measure.
concerning "2nd voice or not..." I think that a 2nd voice can be used as normal case: as you seen from the example above. There are even worse cases:
and horrible ones:
Looking your Ain't Nobody example:
The small E4 note is meant for the 3rd verse (precisely the "I" syllable).
So, what should we export to MusicXML:
- Just one voice (quarter rest, small E4, standard E4, standard E4)
- Or what? 2 separate voices one after the other? Does it make sense?
Plus, AFAIK, MusicXML expect just one melodic line, regardless of the number of verses in the lyrics underneath.
In that case, I'd expect the end-user to point to the small E4 and to indicate: Consider this small chord as a standard chord. With the consequences in terms of voice continuity and time computation.
Regarding the last "horrible" example, I prefer to ignore it, at least for now :-)
Ok, you are right. Finally I see no way to automate these cases... And about the last example: I agree completely ;-)