[gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp

Christophe Rhodes csr21 at cam.ac.uk
Tue Nov 29 17:40:10 UTC 2005


Christophe Rhodes <csr21 at cam.ac.uk> writes:

> Robert Strandh <strandh at labri.fr> writes:
>
>> Christophe Rhodes writes:
>>  > This change causes a problem: compute-staff-group-parameters is only
>>  > called if the element containing the staff group is modified; however,
>>  > the final accidentals need to be recomputed if the staff's key
>>  > signature changes (and also, in my working copy, if a key signature
>>  > has been inserted earlier on the staff...)
>>
>> I fixed this problem by invalidating layers using the staff that has
>> it key signature changed.  
>
> Thanks.  (As you'll see in my previous message, I've updated my key
> signature work-in-progress patch)

For discussion, as requested:

Key signature protocol:

  Protocol class key-signature

    The base class for elements implementing the key signature
    protocol.

  Accessor key-signature-data (key-signature key-signature)

    Returns a seven-element simple-vector containing keywords
    :DOUBLE-SHARP, :SHARP, :NATURAL, :FLAT or :DOUBLE-FLAT indicating
    the musical key signature indicated by the key-signature.  The
    effect of modifying the vector returned by this accessor is
    undefined.

    [ Note: in Gsharp we currently modify the underlying data
      structure, but it seems elegant instead to keep it unmodifiable,
      and place an :after method on (setf key-signature-data) to
      invalidate element caches of e.g. accidentals; we can't do this
      if we're allowed to do (setf aref) on (key-signature-data
      key-signature), which is why I've forbidden it. ]

Now, the proposed :after method on (setf key-signature-data) here
would ideally use more support for walking staffwise elements than is
currently implemented, though the pessimistic implementation would
simply use the existing loop over layers and
invalidate-slice-using-staff.

In addition to that support, we need something like this:

Staff scope protocol:

  Protocol class staff-scope-mixin 

    A mixin for elements with staff scope.  Not intended to be directly
    instantiated.

  Generic Function staff-scope-element staff position specifier

    Returns the staff-scope-element of type specifier which applies to
    the position denoted by position.

  Method staff-scope-element (staff staff) (cursor gsharp-cursor) specifier
  Method staff-scope-element (staff staff) (element element) specifier

    The position denoted by a gsharp-cursor is the same as the
    position denoted by the element which would be inserted at that
    cursor position.  Note that some elements, such as complicated
    clusters, do not have an associated staff; however, they denote a
    position on that staff by virtue of having notes which are
    associated with that staff.  It is an error if specifier is not
    subtypep staff-scope-mixin.

This staff scope protocol would be used for elements which have
staffwise effect, such as key-signatures, but also clefs, time
signatures, instrumentation markings, piano pedal markings...

We need to know the applicable element at a cursor position, as the
applicable element can influence what we insert (e.g. #\c will insert
different notes depending on the prevailing key signature); we need to
know the applicable element at an element in order to compute how it
looks (e.g. the clef, to know which staff line a note belongs on, or a
key signature again to know whether a note needs an accidental).

Comments?

Cheers,

Christophe



More information about the gsharp-devel mailing list