Re: [Rosegarden-devel] Re: grace notes

[Chris C. <ca...@al...>]

Hans Kieserman wrote:
>
> Hmm.  How much harder is (f)?

I don't know.  I've been thinking about it again anyway, though,
because when we get into how to edit these things on the GUI the
situation becomes more complicated again.

For (c), I was envisaging that the process of entering grace
notes would be something like "enter the notes with the durations
you want them played at, and then mark the grace notes as such".
So for example, you could enter two semiquavers and a quaver,
then mark the semiquavers as grace notes and the quaver would
magically become a crotchet.  That's not particularly intuitive,
but you could (presumably, if the GUI was consistent) mark the
semiquavers as grace notes before entering the main note, in which
case the notational duration of the rest following the grace notes
would be augmented accordingly instead: so if it had been a quaver
rest, it would become a crotchet rest, and then you could insert
a crotchet over it without actually getting more than a quaver of
playback from the note.  That's a more intuitive _process_, but
it doesn't seem to make much more sense (grace notes attached to
rests?) and you have the problem of dealing with the usual split/
tie insertion semantics with notes that are not actually the
duration they appear to be, which is distinctly nasty (it's a
problem we attempt to deal with for tuplets already, but I really
wouldn't like any more special cases of that kind because I'd be
surprised if I _ever_ manage to get rid of all the tuplet bugs).

For (f), the problem is at least more local: we have to make the
grace notes behave like non-note events but draw them as notes
(do we want to be able to do things like change the beam and stem
properties for the individual notes within a group of grace notes?),
we have the problem of working up a proper GUI for electing to
enter grace notes in the first place, and we have the problem of
how to manage the timing when playing them, but I'm not sure that
any of these problems would affect quite as much code or cause
quite so many elusive bugs as might happen with (c).

>> 58 means A# or Bb.  But it's not quite clever enough for the Fb/E
>> case.
>
> Or the Cb/B case.  It also seems to not do quite the correct thing
> for double-sharps and flats, although we never see it because they're
> not supported on the GUI. Mind if I take a crack at that?

Not at all -- I'd be delighted.  Definitely if you select one of
the accidental buttons on the toolbar when you enter a note, you
should see that accidental on the note when it's displayed; it's
certainly always stored in the accidental property.

The renderer (I mean NotePixmapFactory) should be able to draw
double-sharps and double-flats, and we have the pixmaps in both
of the available note fonts, and they're all wired up in NoteFont
and the mapping.xml files, so they should display on any event
whose display accidental property ends up containing one.  I
don't think there should be any work needed anywhere except
NotationDisplayPitch and possibly NotationHLayout::scanChord.


Chris