Tidy up the TimeSig dialog a bit.

Stop trying to do everything with bound attributes, and just attach to
the notify signal directly.
Track MooX::Gtk2 changes.
Dialog for rehearsal marks.

I really need a role for this pattern: an attribute with a predicate
which needs a control to turn it on and off.
Track MooX::Misc changes.
Tweaks.

Allow attaching random Lily tweaks to items that support them. Currently
this is just Text::Mark, and the only tweaks supported are direction
(vertical alignment) and self-alignment-X (horizontal alignment), but
that should be easy to extend.

Create a generic dialog role, to build the tweaks section of the dialog.
This includes classes for the individual tweaks, since they need
different entry methods. (Both the tweaks that exist at the moment are
'Enum', meaning a combo box.)
Stop mucking about with the voices.

Now I'm actually using this to do work it's getting distracting.
Allow the playback speed to be adjusted.

This is entirely unfriendly at the moment; the number entered is
'milliseconds per qhdsq'. I need to make a proper X=Y dialog; I also
need to introduce Music::Tempo so the tempo can change partway through a
piece. However, I would like to see if I can't rework the timeout
handling first; I don't allow triplets yet, but when I do they will be
timed entirely incorrectly.

(Actually, I'd like to see if I can't get the fluidsynth sequencer
working; but that requires callbacks that can run in another pthread,
and I'm not really sure how to pass messages back. I suppose I could
just use a pipe...)
Region.

I am less and less convinced a linked list is the right data structure
here. Even simple questions like 'which of these two items comes first'
are hard to answer. Hmmm.

Implement a region (selection), by giving the View an optional 'mark'
pointer. Implement octave up/down over the region, because that's easy.
At the moment cursor and mark have to be in the same voice for mark to
be useful; possibly I should move mark as cursor changes voice? Or
change mark to be a point-in-time rather than a particular note (I don't
think that would be a good idea...).
Transposing.

This isn't perfect yet; it tends to insert redundant key signature
changes, particularly if you transpose a passage and then transpose it
back. But it's finished enough to be useful.
Delete/move staffs.

Also insert in the right place.
Cut and paste.

No copy yet, because I don't have a clone method on Music. I don't know
if I can get away with just copying Copiable atts; it might be enough,
though I would have to move (say) Note->octave and ->tie into a role.

Also fix a bug in LinkList->remove, which I didn't notice before because
I was only ever removing one element at a time, and then throwing it
away.

My plan was for clips to be headed by a subclass of Voice, so they could
preserve ambient key/time/&c. I haven't done that yet: the clip is just
the bare notes. Ambients generally are being annoying: I've introduced a
break_ambient method, which I'm calling everywhere; I'm not sure how
many of those calls are necessary, and I don't want to be making them at
all. I need some different system, I think; some sort of 'cached
information up to this point' object, including things like layout
position and point-in-the-bar, which can be cleared all in one go.

I would like a second form of cut which replaces the cut music with
rests, but this needs the time signature (which I can get) and the
point-in-the-bar of the start of the cut (which is harder, at the
moment). Ideally I would also want multi-measure rests (this is a really
annoying Lily feature).
Restore the playing marker.

Make the display more efficient by not rerendering when marks (cursor,
mark, playing points) move. Instead of colouring the notes, just draw
rectangles under the prerendered music. This is actually better UI, as
well: the blue notes were not always easy to see in edit mode.
Edit commands now need an explicit refresh.

Previously some were relying on Cursor->position to call refresh, which
it doesn't any more.
Multi-bar rests.

Inserting a new bar immediately after an existing MultiRest extends it;
inserting before makes a new MultiRest. I probably also want an 'insert
N bars rest' command, but it isn't irritating me yet.

Make StaffCtx::Draw allow individual items to be multiple bars long, as
long as the barline still falls between items.

Label bad barlines with the duration the previous bar was over.
Move the Region actions into a new role.

Using roles simply as a way to divide up a class seems a little odd to
me, but it makes some sense. It's necessary to load this new role after
the attributes, not before, since it requires some of the accessors.

Move the actions into their own menu, and make them apply to the whole
voice if the mark is unset, and move the mark to the current voice if
necessary.
Remove some debugging.
Halve and double lengths.

This doesn't handle MultiRests properly. I'm not entirely convinced they
should be HasLength at all: maybe I need a HasDuration?
New.

I'm still not doing SDI properly... I still don't rightly know what to
do about application-level actions. Without a proper window-system-level
app UI there aren't any good answers.

(I think Gtk3 might have some answers, or at least some APIs, here.)
Make LinkList generic.

I want Voices (and Movements) to be in linked lists. Since Voice isa
Music, this means Voices need to be in two different lists at the same
time. One of the advantages of linklists is that they can do this; you
just need the glue to create the attributes and methods.

Change LinkList from a role to a module which exports a new Moo keyword,
'linklist'. This takes a single parameter, the name of the list, and
creates the attributes and methods required to operate the list.

Unfortunately, although CMM provides install_modifier and RT provides
apply_roles_to_package, Moo itself provides no equivalent for 'has'.
This means that to create dynamic attributes I need an eval. Probably I
should port the whole shebang over to Moose proper at this point; I'm
sure it would make everything (including all of MooX::Misc) easier to
have a proper metaclass system. However... that's quite a bit of work.

Give Music a 'music' linklist. For now, proxy the old method names
across; I want to carry through most of the renames, but 'next' and
'prev' could usefully check for list start/end rather than being plain
accessors, and 'insert' and 'remove' are probably too Huffman to lose.
Follow through on the music method renames.

Keep insert and remove, they're too useful. Also keep next and prev, as
methods which return undef at the ends of the list. (I seem to have
already been assuming they did this in some places...)