From csr21 at cam.ac.uk Wed Nov 9 21:54:08 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 09 Nov 2005 21:54:08 +0000 Subject: [gsharp-devel] key signatures Message-ID: Hi, Attached is a work-in-progress patch implementing key signatures as elements rather than attributes of a clef. * they have a fake (1/8) duration, to avoid a division-by-zero error in the layout code; * they have enough added-mixinness to make them work. I didn't try to work out what they actually needed; * the first element added to each staff needs to be a key signature. This should probably be made to happen by default (and be an undeletable element); * the code to find the most recent key signature on a staff doesn't work terribly well; it seems easy to have a null CURSOR-ELEMENT. Having said that, starting gsharp and typing K c d e C-b C-b M-# M-# C-f K C-f M-@ M-@ seems to do the right thing. (Very many other keysequences will yield errors; as I said, work in progress...) Screenshot at . -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysig.diff URL: -------------- next part -------------- Cheers, Christophe From strandh at labri.fr Thu Nov 10 03:08:57 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 10 Nov 2005 04:08:57 +0100 Subject: [gsharp-devel] key signatures In-Reply-To: References: Message-ID: <17266.47561.599709.192262@serveur5.labri.fr> Hello, Christophe Rhodes writes: > * the first element added to each staff needs to be a key signature. > This should probably be made to happen by default (and be an > undeletable element); I would rather it would not be mandatory but have an staff with no explicit key signature start out in C major. This rule would make it easier to use Gsharp for tiny snippets used in text books. In fact, the same could be said for the clef. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Thu Nov 10 17:49:28 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 10 Nov 2005 17:49:28 +0000 Subject: [gsharp-devel] bugs Message-ID: Hi, I fixed a couple of bugs in MAKE-LAYER and its callees, and adding layers from the gui now works again. As well as , another casualty of the change of coordinate systems is in multistaff clusters: the stem calculation is wrong. Reversing the signs of the staff-yoffset comparisons in COMPUTE-STEM-LENGTH and COMPUTE-MAXPOS-MINPOS almost gets it right, but not quite, and COMPUTE-STEM-DIRECTION seems wrong as well. Additionally, semibreve (or whole-note) rests hang from the wrong staff line, and indeed seem to be out by a pixel or two (to reproduce, type , C-r and observe the disconnect; another C-r shows that the minim (half-note) rest is wrong as well, clashing with the middle staff line. (Key signatures almost work properly now; the remaining problems are generally connected with multiple layers on one staff: a layer spanning multiple staves interprets key signatures correctly. Patch forthcoming in a few days, I hope.) Cheers, Christophe From strandh at labri.fr Thu Nov 10 19:00:25 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 10 Nov 2005 20:00:25 +0100 Subject: [gsharp-devel] bugs In-Reply-To: References: Message-ID: <17267.39113.884751.466441@serveur5.labri.fr> Christophe Rhodes writes: > COMPUTE-STEM-DIRECTION seems wrong as well. FWIW, I think COMPUTE-STEM-DIRECTION works. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Thu Nov 10 22:39:28 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 10 Nov 2005 23:39:28 +0100 Subject: [gsharp-devel] bugs In-Reply-To: References: Message-ID: <17267.52256.836819.50782@serveur5.labri.fr> Hello, Christophe Rhodes writes: > another casualty of the change of coordinate systems is in multistaff > clusters: the stem calculation is wrong. I think I (partially) fixed this problem. Doing so was painful, however, because, before I changed the y transformation, the terms `max' and `min' were unambiguous. Now, however, the note with the maximum position will have the minimum y offset. To make the code a little bit more readable, I suggest a new convention: using `top' and `bot' instead of `max' and `min' when staff step positions or y offsets are referred to. Thus the top note in a cluster will have the highest position on its staff and the smallest y offset. However, for fear of causing too many collisions with your current modifications, I did not make the global modifications yet. Personally, I commit frequently to avoid such problems, but not everyone does. So, I suggest either 1) you let me know when it is "safe" for me to make such global changes or 2) you do them at the same time you commit some of your other stuff. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Thu Nov 10 23:59:49 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 10 Nov 2005 23:59:49 +0000 Subject: [gsharp-devel] bugs In-Reply-To: <17267.52256.836819.50782@serveur5.labri.fr> (Robert Strandh's message of "Thu, 10 Nov 2005 23:39:28 +0100") References: <17267.52256.836819.50782@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Hello, > > Christophe Rhodes writes: > > > another casualty of the change of coordinate systems is in multistaff > > clusters: the stem calculation is wrong. > > I think I (partially) fixed this problem. Doing so was painful, > however, because, before I changed the y transformation, the terms > `max' and `min' were unambiguous. Now, however, the note with the > maximum position will have the minimum y offset. > > To make the code a little bit more readable, I suggest a new > convention: using `top' and `bot' instead of `max' and `min' when > staff step positions or y offsets are referred to. Thus the top note > in a cluster will have the highest position on its staff and the > smallest y offset. This sounds good. > However, for fear of causing too many collisions with your current > modifications, I did not make the global modifications yet. > Personally, I commit frequently to avoid such problems, but not > everyone does. So, I suggest either 1) you let me know when it is > "safe" for me to make such global changes or 2) you do them at the > same time you commit some of your other stuff. Please commit. I will undertake to resolve conflicts in any work-in-progress patches of my own without complaint :) Cheers, Christophe From strandh at labri.fr Fri Nov 11 02:12:54 2005 From: strandh at labri.fr (Robert Strandh) Date: Fri, 11 Nov 2005 03:12:54 +0100 Subject: [gsharp-devel] bugs In-Reply-To: References: Message-ID: <17267.65062.942960.597301@serveur5.labri.fr> Christophe Rhodes writes: > , I think this is fixed now. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Mon Nov 14 14:04:39 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 14 Nov 2005 14:04:39 +0000 Subject: [gsharp-devel] bugs In-Reply-To: (Christophe Rhodes's message of "Thu, 10 Nov 2005 17:49:28 +0000") References: Message-ID: Christophe Rhodes writes: > Additionally, semibreve (or whole-note) rests hang from the wrong > staff line, and indeed seem to be out by a pixel or two (to reproduce, > type > , C-r > and observe the disconnect; another > C-r > shows that the minim (half-note) rest is wrong as well, clashing with > the middle staff line. The attached patch fixes whole_rest.mf. It doesn't fix the out-by-half-a-pixel bug that I'm observing, which is demonstrated in ; I had a little look at the metafont, and in particular at staff_line_thickness and yoffset; nothing sprang to my mind as immediately obviously wrong, but I'm not convinced I understand how this font works yet. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: whole.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Mon Nov 14 15:12:09 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 14 Nov 2005 15:12:09 +0000 Subject: [gsharp-devel] notehead glitch Message-ID: Hi, I've found another graphical glitch. This one does not affect the drawing of the main buffer in the default font size (staff-separation 6), but in larger sizes, the noteheads seem to be slightly too big. illustrates what I consider to be the problem: noteheads on lines seem off-centre, while noteheads in spaces hang down too far. As I say, this doesn't seem to be a problem with staff-size 6; redefining the DRAW-BUFFER method on-the-fly should be enough to reproduce the problem. Cheers, Christophe From strandh at labri.fr Mon Nov 14 22:04:03 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 14 Nov 2005 23:04:03 +0100 Subject: [gsharp-devel] bugs In-Reply-To: References: Message-ID: <17273.2515.709528.403301@serveur5.labri.fr> Christophe Rhodes writes: > > Additionally, semibreve (or whole-note) rests [... > ...] indeed seem to be out by a pixel or two (to reproduce, > type > , C-r > and observe the disconnect; another > C-r > shows that the minim (half-note) rest is wrong as well, clashing with > the middle staff line. I believe this problem is now fixed. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Mon Nov 14 22:07:13 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 14 Nov 2005 23:07:13 +0100 Subject: [gsharp-devel] notehead glitch In-Reply-To: References: Message-ID: <17273.2705.619410.408458@serveur5.labri.fr> Christophe Rhodes writes: > > I've found another graphical glitch. This one does not affect the > drawing of the main buffer in the default font size (staff-separation > 6), but in larger sizes, the noteheads seem to be slightly too big. > > illustrates what I consider to be the problem: noteheads on lines seem > off-centre, while noteheads in spaces hang down too far. As I say, > this doesn't seem to be a problem with staff-size 6; redefining the > DRAW-BUFFER method on-the-fly should be enough to reproduce the > problem. This problem looks like it is due to the same off-by-one-pixel pixmap drawing bug that I just fixed. Let me know if this problem is still there. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From gsharp at rojoma.com Mon Nov 14 23:01:25 2005 From: gsharp at rojoma.com (Robert J. Macomber) Date: Mon, 14 Nov 2005 16:01:25 -0700 Subject: [gsharp-devel] remove-current-note command Message-ID: <20051114230125.GA7403@oja.no> Here's the command I (as Thas) talked about on #lisp today, to remove the current note from the current cluster. Once the note's removed, the current one becomes the next-lower remaining note, or if the removed note was the lowest, the next-higher one, or otherwise the cluster is empty and is removed. This may be too complex (easier just to make the lowest note the new current, for example) but it fits my usage pattern for music typesetting software, which in the past has been "build chords lowest to highest", so this command acts like backspace for chords. I'm not sure LOWER-BOUND is in a good place - maybe it should live in utilities.lisp? The command's not bound to anything as I'm not yet comfortable enough with G#'s keymapping to have a good idea where it'd fit in with existing keystrokes. Index: buffer.lisp =================================================================== RCS file: /project/gsharp/cvsroot/gsharp/buffer.lisp,v retrieving revision 1.25 diff -r1.25 buffer.lisp 354a355,372 > (defun lower-bound (bound list &key (test #'<)) > "Return the `largest' element in the sorted list LIST such that > \(TEST element BOUND) is true." > (let ((last nil)) > (dolist (item list) > (unless (funcall test item bound) > (return-from lower-bound last)) > (setf last item)) > last)) > > (defmethod cluster-lower-bound ((cluster cluster) (bound note)) > (with-slots (notes) cluster > (lower-bound bound notes :test #'note-less))) > > (defmethod cluster-upper-bound ((cluster cluster) (bound note)) > (with-slots (notes) cluster > (lower-bound bound (reverse notes) :test (complement #'note-less)))) > Index: gui.lisp =================================================================== RCS file: /project/gsharp/cvsroot/gsharp/gui.lisp,v retrieving revision 1.43 diff -r1.43 gui.lisp 814a815,827 > (define-gsharp-command com-remove-current-note () > (let ((cluster (cur-cluster)) > (note (cur-note))) > (when note > (remove-note note) > ;; try to set current-note to the highest note lower than the > ;; removed note. If that fails, to the lowest note higher than > ;; it. > (setf *current-note* (or (cluster-lower-bound cluster note) > (cluster-upper-bound cluster note))) > (unless *current-note* > (com-erase-element))))) > Index: packages.lisp =================================================================== RCS file: /project/gsharp/cvsroot/gsharp/packages.lisp,v retrieving revision 1.27 diff -r1.27 packages.lisp 47a48 > #:cluster-upper-bound #:cluster-lower-bound From csr21 at cam.ac.uk Thu Nov 17 16:40:33 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 17 Nov 2005 16:40:33 +0000 Subject: [gsharp-devel] key signatures In-Reply-To: <17266.47561.599709.192262@serveur5.labri.fr> (Robert Strandh's message of "Thu, 10 Nov 2005 04:08:57 +0100") References: <17266.47561.599709.192262@serveur5.labri.fr> Message-ID: Robert Strandh writes: > Christophe Rhodes writes: > > * the first element added to each staff needs to be a key signature. > > This should probably be made to happen by default (and be an > > undeletable element); > > I would rather it would not be mandatory but have an staff with no > explicit key signature start out in C major. This rule would make it > easier to use Gsharp for tiny snippets used in text books. In fact, > the same could be said for the clef. Right. The current implementation of this makes a staff have a key signature which is in effect if there is no other key signature on that staff. I'm attaching my current diff, which covers all but two cases, I believe. The two remaining pieces are * drawing the current key signature, not necessarily the staff's, in draw-staff-and-clef (via the function passed to new-map-over-obseq-subsequences in draw-buffer); * when two or more layers share a staff, we will only find the right key signature for elements in the key signature's layer. Apart from solving these, the interface/protocol needs documenting and renaming: there is a need for a key-signature element distinct from the keysig seven-element array. Then, of course, the element needs to be made durationless, and aware of its graphical extent... Still, here it is; by all means have a play. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysig3.diff URL: -------------- next part -------------- Cheers, Christophe From strandh at labri.fr Sun Nov 20 19:11:48 2005 From: strandh at labri.fr (Robert Strandh) Date: Sun, 20 Nov 2005 20:11:48 +0100 Subject: [gsharp-devel] Gsharp progress report Message-ID: <17280.51828.420153.636852@serveur5.labri.fr> Dear mailing-list member, This is the first in what I hope to be a series of regular Gsharp progress reports for people who do not follow the cvs mailing list and who do not participate in the #lisp IRC channel. Since it is hard to talk about `progess' in a first report like this, let me instead give a brief list of what Gsharp can do, what it can not yet do, and what things are, should, or ought to be worked on first. What we have: * The fundamental buffer data structure is not perfect yet, but it is getting there. We don't have a formal buffer protocol yet, but such a protocol is getting possible as I learn what could be implemented efficiently. * The line-breaking algorithm seems to work, and has been abstracted out into a library called Obseq. Gsharp uses this library only in a trivial way right now for producing `roll of paper' output. We would like to add various page-based output styles (fixed number of pages, number of pages modulo n = 0, last page filled or not, etc). * The spacing algorithm is similar to that of the Lime score editor, and seems to work. However currently only temporal spacing is implemented. So called lyric spacing which is used in crowded conditions, is not yet implemented, because the spacing algorithm does not know the physical width of clusters and lyrics elements. * The beaming algorithm seems to be work. * Functionality-wise, Gsharp can handle multiple staves, multiple voices (called layers), multi-staff note clusters, complex accidental placements, etc. What can not do yet: * Literally hundreds of little things that are necessary in any score editor, like staccato marks, fermata, etc. It is my hope that advanced potential Gsharp users will eventually be able to add such functionality, so that I can concentrate my energy on fundamental algorithms and data structures. * Multiple beams. The main difficulty is to get secondary and fractional beams to come out exactly parallel to the main beam. Doing this requires fiddling with regions for the output. * Triplets, etc. The spacing algorithm needs to be improved to handle this. * Many minor things like creating a buffer when a non-existing file name is used for loading, doing the right thing when the user remove a staff, etc. What is being worked on: * Changing key signatures and clefs at arbitrary places in the score (Christophe Rhodes is working on this). * Personally, I am working on restructuring some computations such as stem direction and accidental placement, so that the result of these computations are known to the line-breaking algorithm. This will enable that algorithm to take physical width into account, which is a prerequisite for lyrics spacing. * In parallel with restructuring the code, I have added many comments to it, and tried to improve it so as to facilitate future modifications. Other things that are high priority but that nobody is working on yet (as far as I know): * Multiple beams (see above) * Improving the appearance of stacks of notes by substituting special glyphs for such stacks. * Adding a "mode line" giving the name of the file being edited, and more. * Using presentation types for better user interaction * Introducing Flexichains for the buffer implementation * Improving the documentation and synchronizing it with the code. * Probably dozens of things that I can't think of right now. Lower-priority things that need to be done: [Too many to enumerate] Finally, thanks to Robert J. Macomber for the patch that enables the user to delete the current note from the current cluster. If you have any questions or remarks with respect to this report, please do not hesitate to let us know by sending mail to the gsharp-devel mailing list. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Tue Nov 22 11:01:50 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 22 Nov 2005 11:01:50 +0000 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp In-Reply-To: <20051121221839.5C6BD88545@common-lisp.net> (Robert Strandh's message of "Mon, 21 Nov 2005 23:18:39 +0100 (CET)") References: <20051121221839.5C6BD88545@common-lisp.net> Message-ID: rstrandh at common-lisp.net (Robert Strandh) writes: > moved the computation of the final accidental (determine whether > one should be displayed or not according to the key signature) from > drawing.lisp to measure.lisp. > [...] > (defun compute-staff-group-parameters (staff-group stem-direction) > - (compute-final-relative-note-xoffsets staff-group stem-direction)) > + (compute-final-relative-note-xoffsets staff-group stem-direction) > + (compute-final-accidentals staff-group)) Hi, 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...) To reproduce the problem, start gsharp and type c M-# M-# the key signature will acquire a c-sharp, and yet the c-natural will remain without an accidental; typing # @ will cause it to acquire one. Cheers, Christophe From strandh at labri.fr Sat Nov 26 21:47:55 2005 From: strandh at labri.fr (Robert Strandh) Date: Sat, 26 Nov 2005 22:47:55 +0100 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp In-Reply-To: References: <20051121221839.5C6BD88545@common-lisp.net> Message-ID: <17288.55307.84346.531237@serveur5.labri.fr> Christophe Rhodes writes: > rstrandh at common-lisp.net (Robert Strandh) writes: > > > moved the computation of the final accidental (determine whether > > one should be displayed or not according to the key signature) from > > drawing.lisp to measure.lisp. > > 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. However, I am no longer sure that my moving the computation cited above was a good idea. Here is the dilemma: * in order to produce a good line-breaking result, we need to know the physical width of elements as accurately as possible. This is an argument in favor of computing accidentals early. * however, accidentals depend on key the signature of the staff. So when the key signature changes, we must invalidate large numbers of elements, with increased computations as a result. The question, then, is whether we need the extra accuracy for line-breaking, or whether we can do an approximate job computing the widths of some elements and then try to do a better job when rendering the final page. I am now leaning towards NOT computing accidentals before estimating physical dimensions, but I am not going to change the code again at this point. We'll see when we start having large scores whether this is a problem. For all I know, recomputing the entire score is a matter of a few seconds, in which case invalidating lots of elements is not a problem. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Mon Nov 28 11:23:10 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 28 Nov 2005 11:23:10 +0000 Subject: [gsharp-devel] Flexichain FLEXI-LAST-P Message-ID: Hi, Today's gsharp doesn't build for me, because of an unexported and undefined FLEXI-LAST-P. I attach a patch which might be right, but is only lightly tested. (If this is part of the flexirank protocol, is there likely to be a FLEXI-FIRST-P too?) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: flexi.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Mon Nov 28 11:31:04 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 28 Nov 2005 11:31:04 +0000 Subject: [gsharp-devel] key signatures In-Reply-To: (Christophe Rhodes's message of "Thu, 17 Nov 2005 16:40:33 +0000") References: <17266.47561.599709.192262@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > I'm attaching my current diff, which covers all but two cases, I > believe. The two remaining pieces are Exactly the same caveats as in my previous message still apply. I attach my current patch, updated for the weekend's rearrangements (now using INVALIDATE-SLICE-USING-STAFF in the relevant places). Sorry I'm not being terribly good at actually finishing the remaining functionality... What I basically need is, I think, to be able to treat a staff as a temporally-ordered sequence of elements, irrespective of which layer they come from; then I can use analogues of CL's sequence functions (e.g. FIND-IF #'KEY-SIGNATURE-P :end :from-end t) to find the applicable key signature for a given element. I'm not certain that this is the right interface, of course: it looks a bit like it could lead to O(n^2) behaviour quite easily; I think this could be mitigated by having the sequence for a staff's elements be a flexirank, because I already keep a cache of a staff's key signatures in a slot in that staff, so searching for key signatures (and deciding whether an element is after a key signature or not) would be a simple comparison of ranks. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysig5.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Mon Nov 28 11:34:40 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 28 Nov 2005 11:34:40 +0000 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp In-Reply-To: <17288.55307.84346.531237@serveur5.labri.fr> (Robert Strandh's message of "Sat, 26 Nov 2005 22:47:55 +0100") References: <20051121221839.5C6BD88545@common-lisp.net> <17288.55307.84346.531237@serveur5.labri.fr> Message-ID: Robert Strandh 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) > However, I am no longer sure that my moving the computation cited > above was a good idea. Here is the dilemma: > > * in order to produce a good line-breaking result, we need to know > the physical width of elements as accurately as possible. This is > an argument in favor of computing accidentals early. > > * however, accidentals depend on key the signature of the staff. So > when the key signature changes, we must invalidate large numbers > of elements, with increased computations as a result. Right. One could save a fair amount of this by only invalidating those elements with a note matching the change in the key signature, but this could be either too messy or an abstraction violation. > The question, then, is whether we need the extra accuracy for > line-breaking, or whether we can do an approximate job computing the > widths of some elements and then try to do a better job when rendering > the final page. > > I am now leaning towards NOT computing accidentals before estimating > physical dimensions, but I am not going to change the code again at > this point. We'll see when we start having large scores whether this > is a problem. For all I know, recomputing the entire score is a > matter of a few seconds, in which case invalidating lots of elements > is not a problem. I don't know what the right answer is either; the current code seems at least workable. Cheers, Christophe From strandh at labri.fr Mon Nov 28 21:29:15 2005 From: strandh at labri.fr (Robert Strandh) Date: Mon, 28 Nov 2005 22:29:15 +0100 Subject: [gsharp-devel] Flexichain FLEXI-LAST-P In-Reply-To: References: Message-ID: <17291.30379.808890.470163@serveur5.labri.fr> Christophe Rhodes writes: > > Today's gsharp doesn't build for me, because of an unexported and > undefined FLEXI-LAST-P. I attach a patch which might be right, but is > only lightly tested. (If this is part of the flexirank protocol, is > there likely to be a FLEXI-FIRST-P too?) Yes, the code for both of them was sitting on my computer at work. Thanks for pointing this out. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From csr21 at cam.ac.uk Tue Nov 29 17:40:10 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 29 Nov 2005 17:40:10 +0000 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp In-Reply-To: (Christophe Rhodes's message of "Mon, 28 Nov 2005 11:34:40 +0000") References: <20051121221839.5C6BD88545@common-lisp.net> <17288.55307.84346.531237@serveur5.labri.fr> Message-ID: Christophe Rhodes writes: > Robert Strandh 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 From strandh at labri.fr Wed Nov 30 03:15:20 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 30 Nov 2005 04:15:20 +0100 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp In-Reply-To: References: <20051121221839.5C6BD88545@common-lisp.net> <17288.55307.84346.531237@serveur5.labri.fr> Message-ID: <17293.6472.682434.506506@serveur5.labri.fr> Hello, Christophe Rhodes writes: > 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. OK, looks good. I also suggest generic functions MORE-SHARPS and MORE-FLATS on key signatures that return a new key signature with more sharps and more flat, as defined by common-practice music notation. > 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... It took me a few minutes to understand this, but now I do and it seems OK to me. > 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). Yep. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From strandh at labri.fr Wed Nov 30 04:13:41 2005 From: strandh at labri.fr (Robert Strandh) Date: Wed, 30 Nov 2005 05:13:41 +0100 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS update: gsharp/drawing.lisp gsharp/measure.lisp gsharp/packages.lisp In-Reply-To: References: <20051121221839.5C6BD88545@common-lisp.net> <17288.55307.84346.531237@serveur5.labri.fr> Message-ID: <17293.9973.90491.517420@serveur5.labri.fr> Christophe Rhodes writes: > Robert Strandh writes: > > However, I am no longer sure that my moving the computation cited > > above was a good idea. Here is the dilemma: > > > > * in order to produce a good line-breaking result, we need to know > > the physical width of elements as accurately as possible. This is > > an argument in favor of computing accidentals early. > > > > * however, accidentals depend on key the signature of the staff. So > > when the key signature changes, we must invalidate large numbers > > of elements, with increased computations as a result. > > Right. One could save a fair amount of this by only invalidating > those elements with a note matching the change in the key signature, > but this could be either too messy or an abstraction violation. Neither, I think. Again, if we could rely on the segment to delimit the effect of a change in key signature, then the number of measures to be recomputed would be limited. But if it can effect a very large score, it might just be too expensive. > > The question, then, is whether we need the extra accuracy for > > line-breaking, or whether we can do an approximate job computing the > > widths of some elements and then try to do a better job when rendering > > the final page. > > > > I am now leaning towards NOT computing accidentals before estimating > > physical dimensions, but I am not going to change the code again at > > this point. We'll see when we start having large scores whether this > > is a problem. For all I know, recomputing the entire score is a > > matter of a few seconds, in which case invalidating lots of elements > > is not a problem. > > I don't know what the right answer is either; the current code seems > at least workable. Yes, although invalidating the measure computation should probably be done in an :after method on (setf key-signature) on a staff, and not in the GUI. I suggest keeping the code as it is for now. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------