If I understand correctly, 1) and 2) would happen in rendermidi somewhere, hence after layout, hence no issues, and it's only 3) where you are trying to actually add notes as opposed to playback events?
The I guess the more basic question is, if you are starting from a point of knowing what line you want to add a note on, why are you adding the note by pitch? Why not add it by line in the first place? Then the line would already be set, as would the accidental. In other words, don't call Score::addNote(), but instead one of the addPitch() functions that already handles lines & accidentals. Or, at least, use the same functions they use to calculate the necessary values. Eg, noteValForPosition(), which calculates the proper pitch and tpc for you given the segment and line, taking accidental state into account. Marc On Wed, Aug 19, 2015 at 3:08 AM Jim Newton <[email protected]> wrote: > Hi Marc, this type of question has come up three times for me so far. > > 1. calculating the notes of an ornament (trill, turn etc). A trill is > played by playing the note that is written in combination with the note on > the line/space above or below. This is not always the neighbouring note in > the diatonic scale as any of the notes might have been modified by an > accidental earlier in the measure. So the code needs to find notes earlier > in the measure which appear on the same line/space and assure that the > trill > note has the same pitch as the "antecedent" note. > > 2. calculating a glissando as if for the harp. In this case we not only > need to take into account notes on the exact same line/space earlier in the > measure (to match accidentals) we must also examine antecedent notes which > are on the same line/space modulo 7. E.g., in the key of C, if the measure > contains a g# then all g's in the glissando need to be g# (assuming > diatonic > glissando style). This code must not get confused about enharmonic. > E.g., > the existence of a G# causes G's to be sharpened, but does not cause A's to > be flattened. Similarly if G is double-sharpened earlier in the measure. > etc. > > 3. calculating figured bass realisation. If the bass note is a C (for > example) and the FB annotation is "3 5", then the derived notes are E and > G, > but they should be modified by the key signature, and in some cases also by > accidentals previous in the measure (there is some debate about this, but I > have found cases where FB should ignore previous accidentals, and where it > should recognise previous accidentals). Again the most obvious way to > implement this is with line/space calculation. Find the line the starting > not is on, and subtract a number 1 less than the indicated value. E.g., "3 > 5" implies (line_of_bass_note - (3 - 1)) and (line_of_base_note - (5 - 1)). > The (3-1) and (5-1) are because an intervals of 3 and 5 are actually deltas > of 2 and 4 (the interval from C to C is 1, not 0). The (line_of_bass - X) > is because lines are numbered from top to bottom, rather than bottom to > top. > So to move UP the staff, you must subtract rather than add. > > Marizio suggested that this calculation could be done with tpc rather than > lines, so I'm interested in finding out how to perform arithmetic with tpc. > > Does this explanation help? > > > > > -- > View this message in context: > http://dev-list.musescore.org/note-not-yet-ready-tp7579475p7579498.html > Sent from the MuseScore Developer mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Mscore-developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mscore-developer >
------------------------------------------------------------------------------
_______________________________________________ Mscore-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mscore-developer
