An new idea dealing with grace notes

[unbored]

I have a new implement dealing with grace notes and already had some basic tests. The general idea is to add a scaled score inside the markup, along with the curve currently drew. So that the beams and articulations could be easily modified, and octave dots would be normally put below the beams. However, the modify needs a new input for grace notes because durations are necessary in the case. I suppose that we can use the way tuplets do, such as:

g[ s2 s3 ] 5

The grace notes after should be done in the same way, but I've not tested yet.

[ssb22]

Thanks. We should try to make sure old input files still work if possible, because lots of people are using this now, and it would be really nice if an update didn't break everyone's scores. Maybe we can keep the re.match(r"g\[[#b',1-9]+\]$",word) and re.match(r"\[[#b',1-9]+\]g$",word) to detect old grace-note input, and either translate it to new input (by spacing it and adding s on every note), or have "both old and new code" options (we might have to still use old code for old Lilypond versions anyway, unless we say we won't support old Lilypond versions anymore—may have to just do that, but I've still not worked out how to get my old Mac Mini to upgrade past 2.22 :smile: ).

[unbored]

@ssb22 I wonder why you put the octaves before the numbers the first time you realize the grace feature, as it doesn't match the way the main notes do.

[ssb22]

@ssb22 I wonder why you put the octaves before the numbers the first time you realize the grace feature, as it doesn't match the way the main notes do.

对, that's why I had grace_octave_fix so if someone writes octaves after, it changes them to before. The main music accepts octaves after or before—either is OK, because the notes are space separated so it's clear which note the octave applies to ('3 and 3' are the same: parseNote does re.findall to take out all the ' and , characters no matter where they are in the word). But it was easier to write graceNotes_markup and gracenotes_western if octaves are made always before, so grace_octave_fix just rewrites 3' to '3 before the code gets there.

But grace_octave_fix doesn't handle all cases well, e.g. 3'3' gets incorrectly rewritten to 3''3 instead of '3'3. A recursive call could fix this, but it might have been better just to error if it gets something too complicated, rather than risking a wrong fix that the user might not realise has happened.

Also, graceNotes_markup and gracenotes_western assume any # or b will come before the note—if anyone puts a # or b right at the end, this is not auto moved to before the note and an error is not detected, it's just ignored. That's probably a bug as well.

[ssb22]

If we're creating a new NoteheadMarkup,

1. I think it might be clearer to make isGrace a property of the NoteheadMarkup object, instead of passing it in every time it's called (otherwise, when maintaining it later, we get worries like "oh, why are we still updating barPos ... oh, because this is a different object..." - using self.isGrace would make that more obvious)
2. we copy defines_done on the way in, but we don't re-copy it on the way out - I wonder if we should (if a new number is used first in a grace note and later in the main music)

[unbored]

If we're creating a new NoteheadMarkup,

1. I think it might be clearer to make isGrace a property of the NoteheadMarkup object, instead of passing it in every time it's called (otherwise, when maintaining it later, we get worries like "oh, why are we still updating barPos ... oh, because this is a different object..." - using self.isGrace would make that more obvious)
2. we copy defines_done on the way in, but we don't re-copy it on the way out - I wonder if we should (if a new number is used first in a grace note and later in the main music)

1. Sure. I'm not that familiar with python.
2. The main problem is that we process grace notes before the related main note, but put the code after. If a new number firstly occurs in the grace then is also the main note, such as g[12] 2, we defined note-two in the grace code. But actually the code is put in the markup after the main note, which yields an undefined error. Current codes generate duplicated definitions sometimes, but I don't have better ideas at the moment.

[ssb22]

Don't worry, I'll play around with it and see if I can come up with something.

Duplicate definitions are OK as long as all versions of Lilypond don't mind :) otherwise maybe we can put all the definitions into a new list and put it near the start of the output