From csr21 at cam.ac.uk Tue Jan 3 12:14:33 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 03 Jan 2006 12:14:33 +0000 Subject: [gsharp-devel] key signatures Message-ID: Happy New Year. I've updated my key signature work to cope with the new per-view buffer and cursors. I still haven't made the elements zero-length :-( -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysig7.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Tue Jan 3 15:11:18 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 03 Jan 2006 15:11:18 +0000 Subject: [gsharp-devel] glitches Message-ID: Hi, Currently, there seems to be a glitch in beaming: start up gsharp, and type c [ c ] the beam between the notes is not aligned with the bottom of the stem. The mirror image of this (type "a [ a ]") does not have this problem. A second glitch I found today when changing clefs. The positions of the noteheads and the beams are recalculated, but not the length of the stems. This can be seen by taking the score from the above test, and doing Set Clef RET RET c RET 4 RET the resulting score has no useful stems. Cheers, Christophe From strandh at labri.fr Thu Jan 5 19:16:45 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 5 Jan 2006 20:16:45 +0100 Subject: [gsharp-devel] glitches In-Reply-To: References: Message-ID: <17341.28829.723359.128238@serveur5.labri.fr> Hello Christophe, Christophe Rhodes writes: > > Currently, there seems to be a glitch in beaming: start up gsharp, and > type > c [ c ] > the beam between the notes is not aligned with the bottom of the stem. > The mirror image of this (type "a [ a ]") does not have this problem. > > A second glitch I found today when changing clefs. The positions of > the noteheads and the beams are recalculated, but not the length of > the stems. This can be seen by taking the score from the above test, > and doing > Set Clef RET RET c RET 4 RET > the resulting score has no useful stems. These problems have now been fixed. Thank you for reporting them. -- 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 Jan 5 19:44:26 2006 From: strandh at labri.fr (Robert Strandh) Date: Thu, 5 Jan 2006 20:44:26 +0100 Subject: [gsharp-devel] Gsharp progress report Message-ID: <17341.30490.211031.92558@serveur5.labri.fr> Dear mailing list member, As promised, here is another Gsharp progress report, again mainly for those who follow neither the CVS mailing list nor the #lisp IRC channel. Since the previous progress report, I have been working on multiple beams. The tricky part is to get secondary beams exactly parallel to the primary beam. Simply rounding the end points to integer coordinates does not work. Instead, one has to draw the secondary beams as if they were the primary beam offset by a certain y position, and with a clip mask that will show the secondary beam only when appropriate. This method mostly works, except that McCLIM seems to ignore the clip mask when output records are repainted. Thus, when a Gsharp score is exposed after having been invisible, secondary beams are displayed where there should not be any. At the moment, I have not attempted to find exactly where the problem is. I have also been working on preparing Gsharp for handling multiple buffers and multiple windows. For this, I am using a recent idea that I discussed with Dave Murray, namely to use a pane -> view -> buffer hierarchy. Essentially, a pane displays a view and a view contains a buffer and some other information that is specific to the view, such as the cursor. This model will allow us to have different kinds of views, such as orchestra views and parts views. A bug report from Christophe Rhodes indicating that horizontal beams had the wrong y position made me add some information relative to beams in the SDL package. In particular, the font object now knows the upper and lower edges of a beam relative to the reference point, as well as how much a beam should be moved vertically in order for it to sit on or hang from a staff line. There have also been some minor improvements since the last progress report: * The calculation of the physical width of clusters with suspended notes has been improved; * The position of accidentals when a C clef was used was wrong and has been fixed (thanks to Christophe Rhodes); * The octave of the C clef was wrong. This has been fixed (thanks to Christophe Rhodes); * When a clef was modified, the clusters did not get recomputed. This problem has now been fixed (thanks to Christophe Rhodes for reporting this problem). That's all for this time. I'll be back with another progress report when there is something worth reporting. -- 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 root at common-lisp.net Wed Jan 18 16:23:33 2006 From: root at common-lisp.net (root) Date: Wed, 18 Jan 2006 10:23:33 -0600 (CST) Subject: [gsharp-devel] Auto-nag: gsharp link verifier failed Message-ID: <20060118162333.A60C61025D@common-lisp.net> You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at admin at common-lisp.net Thanks! From root at common-lisp.net Mon Jan 23 08:15:23 2006 From: root at common-lisp.net (root) Date: Mon, 23 Jan 2006 02:15:23 -0600 (CST) Subject: [gsharp-devel] Auto-nag: gsharp link verifier failed Message-ID: <20060123081523.C54FB1E23A@common-lisp.net> You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at clo-devel at common-lisp.net Thanks! From csr21 at cam.ac.uk Mon Jan 23 09:24:38 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 23 Jan 2006 09:24:38 +0000 Subject: [gsharp-devel] Auto-nag: gsharp link verifier failed In-Reply-To: <20060123081523.C54FB1E23A@common-lisp.net> (root@common-lisp.net's message of "Mon, 23 Jan 2006 02:15:23 -0600 (CST)") References: <20060123081523.C54FB1E23A@common-lisp.net> Message-ID: root at common-lisp.net (root) writes: > You are being nagged on because your project's I've added mailto: to the href for "rstrandh (at) common-lisp (dot) net". Whether this stops the nagging, I don't know; one possible resolution is to do the spamproofing using . and @, which would allow conforming user agents to use the mailto link directly while defeating at least the simplest text-mining. Cheers, Christophe From csr21 at cam.ac.uk Mon Jan 23 11:32:45 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 23 Jan 2006 11:32:45 +0000 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS gsharp In-Reply-To: <20060122203852.BEFB21D490@common-lisp.net> (CVS User's message of "Sun, 22 Jan 2006 14:38:52 -0600 (CST)") References: <20060122203852.BEFB21D490@common-lisp.net> Message-ID: "CVS User rstrandh" writes: > The conversion to allow Gsharp to deal with elements (and thus > timelines) and measures of zero duration should now be complete. Of > course, there might still be some issues, since I haven't really > tested it with elements of zero duration. Hi, I'm afraid I get a floating point error when attempting to incorporate zero-length keysignature elements. The relevant parts of the backtrace are below; this occurs just after the first insertion of a zero-duration element. I also attach the current diff: if instead of returning 0 from DURATION (ELEMENT) I return 1/8 (or some such non-zero quantity) things appear to work. Cheers, Christophe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysig8.diff URL: -------------- next part -------------- 7: (SB-KERNEL:TWO-ARG-/ 0 0.0) 8: (GSHARP-DRAWING::MAKE-ELEMENTARY-ELASTICITY 0 0.0) 9: (GSHARP-DRAWING::COMPUTE-ELASTICITY-FUNCTIONS (#) # #) 10: ((LAMBDA (GSHARP-MEASURE:MEASURES)) (#)) 11: (GSHARP-MEASURE::NEW-MAP-OVER-OBSEQ-SUBSEQUENCES # [B :staves ([= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] ) :segments ([S :layers ([_ :name "default layer" :staves ([= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] ) :head [/ :bars ([| :elements NIL ] ) ] :body [/ :bars ([| :elements ([% :xoffset 0 :notehead :FILLED :rbeams 0 :lbeams 0 :dots 0 :stem-direction :AUTO :notes ([N :pitch 35 :staff [= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig # ] :head :FILLED :accidentals :NATURAL :dots 0 ] ) ] [% :xoffset 0 :notehead :FILLED :rbeams 0 :lbeams 0 :dots 0 :stem-direction :AUTO :notes ([N :pitch 36 :staff [= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig # ] :head :FILLED :accidentals :NATURAL :dots 0 ] ) ] [# :xoffset 0 :staff [= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] ) ] ) ] :tail [/ :bars ([| :elements NIL ] ) ] ] ) ] ) :min-width 17 :spacing-style 0.4 :right-edge 700 :left-offset 30 :left-margin 20 ] ) 12: ((SB-PCL::FAST-METHOD GSHARP-DRAWING:DRAW-BUFFER (T BUFFER T T T)) # # # [B :staves ([= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] ) :segments ([S :layers ([_ :name "default layer" :staves ([= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] ) :head [/ :bars ([| :elements NIL ] ) ] :body [/ :bars ([| :elements ([% :xoffset 0 :notehead :FILLED :rbeams 0 :lbeams 0 :dots 0 :stem-direction :AUTO :notes ([N :pitch 35 :staff [= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig # ] :head :FILLED :accidentals :NATURAL :dots 0 ] ) ] [% :xoffset 0 :notehead :FILLED :rbeams 0 :lbeams 0 :dots 0 :stem-direction :AUTO :notes ([N :pitch 36 :staff [= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig # ] :head :FILLED :accidentals :NATURAL :dots 0 ] ) ] [# :xoffset 0 :staff [= :name "default staff" :clef [K :name :TREBLE :lineno 2 ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] :keysig #(:NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL :NATURAL) ] ) ] ) ] :tail [/ :bars ([| :elements NIL ] ) ] ] ) ] ) :min-width 17 :spacing-style 0.4 :right-edge 700 :left-offset 30 :left-margin 20 ] # 20 100) 13: ((SB-PCL::FAST-METHOD GSHARP::DISPLAY-SCORE (GSHARP:GSHARP T)) # # # #) 14: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::MEDIUM-INVOKE-WITH-POSSIBLE-DOUBLE-BUFFERING (T T CLIM-CLX::CLX-MEDIUM T)) # # # # # #) 15: ((SB-PCL::FAST-METHOD CLIM:REDISPLAY-FRAME-PANE :AROUND (CLIM:APPLICATION-FRAME T)) # #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL #S(SB-PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (2 . T)) :ARG-INFO (2 . T)) :ARG-INFO (2 . T)) # # (:FORCE-P NIL)) 16: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 17: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 18: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 19: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 20: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 21: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 22: ((SB-PCL::FAST-METHOD CLIM:MAP-OVER-SHEETS (T CLIM:BASIC-SHEET)) # # # #) 23: (ESA:ESA-TOP-LEVEL # :COMMAND-PARSER # :COMMAND-UNPARSER # :PARTIAL-COMMAND-PARSER # :PROMPT #) 24: (ESA:ESA-TOP-LEVEL #) From csr21 at cam.ac.uk Thu Jan 26 10:42:17 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 26 Jan 2006 10:42:17 +0000 Subject: [gsharp-devel] Re: [gsharp-cvs] CVS gsharp In-Reply-To: (Christophe Rhodes's message of "Mon, 23 Jan 2006 11:32:45 +0000") References: <20060122203852.BEFB21D490@common-lisp.net> Message-ID: Christophe Rhodes writes: > I'm afraid I get a floating point error when attempting to incorporate > zero-length keysignature elements. The relevant parts of the > backtrace are below; this occurs just after the first insertion of a > zero-duration element. I also attach the current diff: if instead of > returning 0 from DURATION (ELEMENT) I return 1/8 (or some such > non-zero quantity) things appear to work. Just so people know: this is now resolved, and the attached patch appears to have the basic functionality needed. The agenda now is * fix the easiest FIXMEs in the patch; * rework the patch to implement and use the discussed protocols (key signature protocol and staffwise-element protocol); * implement insertable clefs, to check that the protocols do actually make things easier; * merge. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysig9.diff URL: -------------- next part -------------- Cheers, Christophe