From csr21 at cam.ac.uk Mon Mar 1 21:04:39 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 01 Mar 2004 21:04:39 +0000 Subject: [gsharp-devel] Lyrics! Message-ID: Hi, Over the weekend (well, really an hour on Friday and an hour today) I had a play with adding some kind of support for lyrics to gsharp. You can get some feel for my progress and wanderings by examining Lyric engraving has plenty of pitfalls that I haven't even begun to address: as you can see, I'm not adjusting spacing requirements based on the length of the lyric; I'm not getting hyphens and underscore extenders at all right -- I'm not even placing the lyrics below the staff! Also, from a representational point of view, I have currently got a firm association between a cluster and a lyric. This is non-optimal for two reasons: one, music with a verse structure often has more than one set of lyrics for the same notes; two, there is often a need for a more horizontal notion of lyrics (as an example, consider the act of deleting an element from the score: it is very unlikely that you also want to delete its associated lyric). Nevertheless, I attach my current patch, basically because I'd welcome comments as I don't really know what I'm doing. One thing that has become apparent is that my way of testing the horizontal extent of the lyrics (the WITH-OUTPUT-TO-OUTPUT-RECORD/WITH-BOUNDING-RECTANGLE* in drawing.lisp) is quite expensive -- it takes a significant time for the screen to refresh after each keystroke in lyric mode. Is there a way of making this less expensive? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: gsharp.diff URL: -------------- next part -------------- Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Tue Mar 2 04:36:53 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 2 Mar 2004 05:36:53 +0100 Subject: [gsharp-devel] Lyrics! In-Reply-To: References: Message-ID: <16452.3941.994968.247799@serveur5.labri.fr> Hello, Christophe Rhodes writes: > > Over the weekend (well, really an hour on Friday and an hour today) I > had a play with adding some kind of support for lyrics to gsharp. You > can get some feel for my progress and wanderings by examining > > > > > Nice progress. > Lyric engraving has plenty of pitfalls that I haven't even begun to > address: as you can see, I'm not adjusting spacing requirements based > on the length of the lyric; I think this is a more general problem. At the very least, a cluster should have an indication as to how much it sticks out to the left and to the right of its timeline. The calculation of the width of a measure must take these values into account. This would solve the problem of clusters with many alterations as well as the problem with lyric spacing. > I'm not getting hyphens and underscore > extenders at all right -- I'm not even placing the lyrics below the > staff! Perhaps lyrics should have their own (invisible) staff, they way percussion should have. All lyrics could then go in one staff with each line on a different "staff line". > Also, from a representational point of view, I have currently got a > firm association between a cluster and a lyric. This is non-optimal > for two reasons: one, music with a verse structure often has more than > one set of lyrics for the same notes; two, there is often a need for a > more horizontal notion of lyrics (as an example, consider the act of > deleting an element from the score: it is very unlikely that you also > want to delete its associated lyric). Right. I think lyrics should be placed in their own layer, probably one layer for each set of lyrics. Each "word" in the lyrics should have values for "notehead" and "dots" so that its duration can be calculated. One could even imagine that having the cursor in such a layer changes some aspects of the keyboard mappings so that `c', `d', etc will insert characters instead. There is also another (existing) general mechanism that will be useful for lyrics, namely the possibility of having a horizontal offset of an element compared to its timeline. I currently use it to avoid that crossing voices on the same staff overlap physically. For lyrics, it could be used to align whatever letter you want with the timeline. > Nevertheless, I attach my current patch, basically because I'd welcome > comments as I don't really know what I'm doing. One thing that has > become apparent is that my way of testing the horizontal extent of the > lyrics (the WITH-OUTPUT-TO-OUTPUT-RECORD/WITH-BOUNDING-RECTANGLE* in > drawing.lisp) is quite expensive -- it takes a significant time for > the screen to refresh after each keystroke in lyric mode. Is there a > way of making this less expensive? I will let Tim answer that question. Speaking of which: As an SBCL expert, perhaps you know more about how to profile code than I do. Refreshing a page of "rapsoden-sjunger" takes around a second, which is a little too much. I have tried profiling pretty much everything in the gsharp packages and in the McCLIM packages, without any conclusive results. As a started, I would like to know whether it is computing the score or drawing it that takes time. Do you have any ideas about how to do that? -- 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 Mar 8 20:34:39 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 08 Mar 2004 20:34:39 +0000 Subject: [gsharp-devel] Lyrics! In-Reply-To: <16452.3941.994968.247799@serveur5.labri.fr> (Robert STRANDH's message of "Tue, 2 Mar 2004 05:36:53 +0100") References: <16452.3941.994968.247799@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > Christophe Rhodes writes: > > I'm not getting hyphens and underscore > > extenders at all right -- I'm not even placing the lyrics below the > > staff! > > Perhaps lyrics should have their own (invisible) staff, they way > percussion should have. All lyrics could then go in one staff with > each line on a different "staff line". I think this, or something like it, is going to be necessary, yes. More below. > > Also, from a representational point of view, I have currently got a > > firm association between a cluster and a lyric. This is non-optimal > > for two reasons: one, music with a verse structure often has more than > > one set of lyrics for the same notes; two, there is often a need for a > > more horizontal notion of lyrics (as an example, consider the act of > > deleting an element from the score: it is very unlikely that you also > > want to delete its associated lyric). > > Right. I think lyrics should be placed in their own layer, probably > one layer for each set of lyrics. Each "word" in the lyrics should > have values for "notehead" and "dots" so that its duration can be > calculated. > > One could even imagine that having the cursor in such a layer changes > some aspects of the keyboard mappings so that `c', `d', etc will > insert characters instead. Right. Currently, I implemented this by having a Lyrics mode, which had alphabetic characters executing com-self-insert (shades of emacs!), and #\- and #\Space going to the next cluster, except that that was buggy. > There is also another (existing) general mechanism that will be useful > for lyrics, namely the possibility of having a horizontal offset of > an element compared to its timeline. I currently use it to avoid that > crossing voices on the same staff overlap physically. For lyrics, it > could be used to align whatever letter you want with the timeline. I think there are some basic rules that get you 90% of the way there: * align the middle of the syllable with the cluster... * ... except for the first word of a sentence, which should align the first letter with the cluster... * ... and the last word, which aligns the full stop. I think that's one convention, anyway. > Speaking of which: As an SBCL expert, perhaps you know more about > how to profile code than I do. Refreshing a page of > "rapsoden-sjunger" takes around a second, which is a little too > much. I have tried profiling pretty much everything in the gsharp > packages and in the McCLIM packages, without any conclusive results. > As a started, I would like to know whether it is computing the score > or drawing it that takes time. Do you have any ideas about how to > do that? I guess I would (profile "CLIMI" "GSHARP"), and see what hotspots that reveals with the workload you describe (refreshing the score 10 times, say). If you know the entry points to computation and drawing, then profiling just those functions would be worthwhile (time and space costs of their unprofiled callees is respectively tallied under the profiled callers). Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Wed Mar 10 07:03:01 2004 From: strandh at labri.fr (Robert STRANDH) Date: Wed, 10 Mar 2004 08:03:01 +0100 Subject: [gsharp-devel] Lyrics! In-Reply-To: References: <16452.3941.994968.247799@serveur5.labri.fr> Message-ID: <16462.48549.663302.263397@serveur5.labri.fr> Christophe Rhodes writes: > I think there are some basic rules that get you 90% of the way there: > * align the middle of the syllable with the cluster... > * ... except for the first word of a sentence, which should align > the first letter with the cluster... > * ... and the last word, which aligns the full stop. > I think that's one convention, anyway. I think you are right. Manual offset should probably be with respect to this default. > I guess I would (profile "CLIMI" "GSHARP"), and see what hotspots that > reveals with the workload you describe (refreshing the score 10 times, > say). If you know the entry points to computation and drawing, then > profiling just those functions would be worthwhile (time and space > costs of their unprofiled callees is respectively tallied under the > profiled callers). Thanks. That was the information I was missing. I started off by profiling every function in these packages, which gave me a result that was very hard to interpret, probably because the profiling overhead was considerable. I did not know that time includes unprofiled callees. The strategy, then, would be to start, as you point out, with the top two functions and then search downward. Thanks. Bonne journ?e, -- 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 Mar 10 07:41:26 2004 From: strandh at labri.fr (Robert STRANDH) Date: Wed, 10 Mar 2004 08:41:26 +0100 Subject: [gsharp-devel] Lyrics! In-Reply-To: References: <16452.3941.994968.247799@serveur5.labri.fr> Message-ID: <16462.50854.300783.194150@serveur5.labri.fr> Christophe Rhodes writes: > I guess I would (profile "CLIMI" "GSHARP"), and see what hotspots that > reveals with the workload you describe (refreshing the score 10 times, > say). If you know the entry points to computation and drawing, then > profiling just those functions would be worthwhile (time and space > costs of their unprofiled callees is respectively tallied under the > profiled callers). Some initial results: * it is definitely drawing (as opposed to computing the score) that takes time. This is good news, because time will not increase with the size of the score. * it seems to be the lowest-level drawing routines that take time, like draw-notehead, draw-ledger-line, draw-left-stem, etc. * creating output records does not seem to represent a disproportionate amount of time, so it is the medium-draw-xxx routines it seems. Either I find a common routine that all medium-draw-xxx ultimately call (such as with-drawing-options) that I can speed up or avoid altogether, or else I need to consider drawing only the part of the page that actually changes (using incremental redisplay, I guess). -- 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 Wed Mar 10 23:26:12 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 10 Mar 2004 23:26:12 +0000 Subject: [gsharp-devel] MIDI conversion Message-ID: Hi, On the off-chance that someone else will either find this useful, or will comment on it: I had need of conversion routines between MIDI format 0 and format 1 formats today. Attached is a patch to midi.lisp (which works standalone) to implement these conversions, via the function (SETF MIDIFILE-FORMAT). I have yet to encounter a format 2 file in the wild, so I haven't implemented anything related to that. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: midi.diff URL: -------------- next part -------------- I eventually settled on (SETF MIDIFILE-FORMAT) as the interface as the least bad of three options. They were: * COERCE-TO-FORMAT midifile format (not clear whether this would preserve the identity of MIDIFILE) * CHANGE-CLASS midifile class (exposing FORMAT{0,1,2}-MIDIFILE to the world feels ugly) * (SETF MIDIFILE-FORMAT) (possibly surprising amount of work for a SETF function; possibly disguises the fact that the conversion is lossy) In any case, the basic logic is there to support any of these three interfaces, and probably the perfect solution that I haven't thought of. Also in this patch is a bugfix allowing midifiles in flat keys to be written. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Thu Mar 11 04:26:20 2004 From: strandh at labri.fr (Robert STRANDH) Date: Thu, 11 Mar 2004 05:26:20 +0100 Subject: [gsharp-devel] MIDI conversion In-Reply-To: References: Message-ID: <16463.60012.50049.858692@serveur5.labri.fr> Christophe Rhodes writes: > Hi, > > On the off-chance that someone else will either find this useful, or > will comment on it: I had need of conversion routines between MIDI > format 0 and format 1 formats today. Attached is a patch to midi.lisp > (which works standalone) to implement these conversions, via the > function (SETF MIDIFILE-FORMAT). I have yet to encounter a format 2 > file in the wild, so I haven't implemented anything related to that. Looks good! You should commit those patches. -- 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 Mar 22 17:21:41 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 22 Mar 2004 17:21:41 +0000 Subject: [gsharp-devel] ties In-Reply-To: (Christophe Rhodes's message of "Mon, 22 Mar 2004 17:08:09 +0000") References: Message-ID: Hi, Attached is a partial implementation of ties. As seems to be usual, it comes with a bundle of various FIXMEs and caveats. The major problem I had here is with the read-only nature of notes. Why is this? Is it to ensure that there are always new objects for the GUI layer? In any case, it makes the work quite tricky, as each tie contains two temporally separated notes. I've implemented ties here as properties of notes themselves, rather than a more global approach, for constant-time performance reasons; however, given that ties contain notes themselves, each destructive operation on a score (e.g. adding or removing an accidental) will have to update or destroy all ties with which the original note was associated. At present, I have done this with the toggle tie command itself, but it needs to be factored out so that com-up, com-down, com-sharper et al. can use it. (Unless someone can think of a better representation). Caveat the second is that my drawing skills are not very good. The output can be seen at (the opening few bars of the top part in Janequin's _Les Cris de Paris_, if anyone's interested :-) and it's ugly. The ties, I think, need to be thicker in the middle (particularly when it's clashing with a staff-line, as in the Gs), thinner at the ends, and anti-aliased; oh, and posssibly a curve, rather than two straight lines. I haven't tested loading or saving, but I have implemented a print-object method and read macro, so maybe it works. MIDI performance of ties works, at least for logically consistent ties. No sanity checking is currently done -- ties can be made over logically non-adjacent notes -- so MIDI performance of this pathological case may or may not be optimal. Apart from all this, it's perfect. Oh yes, one last thing: the semibreve (whole note) rest appears to hang down from the wrong line by default; the normal position for that rest is to hang from the second line from the top of the staff. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ties.diff URL: -------------- next part -------------- Comments please, Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Tue Mar 23 05:46:28 2004 From: strandh at labri.fr (Robert STRANDH) Date: Tue, 23 Mar 2004 06:46:28 +0100 Subject: [gsharp-devel] ties In-Reply-To: References: Message-ID: <16479.53044.917855.642221@serveur5.labri.fr> Hello, Christophe Rhodes writes: > Attached is a partial implementation of ties. As seems to be usual, > it comes with a bundle of various FIXMEs and caveats. Wow, lot of work! I'll try it as soon as I can. > The major problem I had here is with the read-only nature of notes. > Why is this? Is it to ensure that there are always new objects for > the GUI layer? I don't think there is a terribly profound reason for this. > In any case, it makes the work quite tricky, as each > tie contains two temporally separated notes. I've implemented ties > here as properties of notes themselves, rather than a more global > approach, for constant-time performance reasons; I suspect that is the right thing to do. > however, given that > ties contain notes themselves, each destructive operation on a score > (e.g. adding or removing an accidental) will have to update or destroy > all ties with which the original note was associated. Yes, I see. > At present, I > have done this with the toggle tie command itself, but it needs to be > factored out so that com-up, com-down, com-sharper et al. can use it. > (Unless someone can think of a better representation). A simpler solution would be to do what the beaming commands do. For ties, each note would indicate whether it ties to the right and/or left. I tie would be drawn only if the left note of a pair is tied to the right and the right note of the same pair is tied to the left. It would then be up to the user to add and remove individual ties. > Caveat the second is that my drawing skills are not very good. The > output can be seen at > (the opening few > bars of the top part in Janequin's _Les Cris de Paris_, if anyone's > interested :-) and it's ugly. The ties, I think, need to be thicker > in the middle (particularly when it's clashing with a staff-line, as > in the Gs), thinner at the ends, and anti-aliased; oh, and posssibly a > curve, rather than two straight lines. Certainly, some anti-aliasing would not hurt. I am not sure how to do that, though. I wonder whether it would be possible to have some fixed-size ends and a variable-sized middle part. I'll give some thought to drawing ties. > I haven't tested loading or saving, but I have implemented a > print-object method and read macro, so maybe it works. MIDI > performance of ties works, at least for logically consistent ties. No > sanity checking is currently done -- ties can be made over logically > non-adjacent notes -- so MIDI performance of this pathological case > may or may not be optimal. Apart from all this, it's perfect. > Oh yes, one last thing: the semibreve (whole note) rest appears to > hang down from the wrong line by default; the normal position for that > rest is to hang from the second line from the top of the staff. Funny! Ross says it hangs beneath the third staff line (which is also what I remember from 5th grade), but then in all his examples it is places as you say. -- 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 Fri Mar 26 07:23:03 2004 From: strandh at labri.fr (Robert STRANDH) Date: Fri, 26 Mar 2004 08:23:03 +0100 Subject: [gsharp-devel] ties In-Reply-To: References: Message-ID: <16483.55895.87952.228830@serveur5.labri.fr> Bonjour, As you may have noticed, I am working on functionality for drawing pretty ties to be used with your latest stuff. Here is the plan (let me know what you think) : * write a function draw-tie (or something like that) or perhaps a pair of functions draw-tie-up draw-tie-down, which would take a staff step and two x positions corresponding to notehead centers. * the function will check the distance between the centers of the noteheads in terms of multiples of the staff line distance. If that distance is sufficiently small (say less than 4.5 times the staff line distance) a SMALL tie is used. Such a tie is characterized by the fact that it is entirely contained between two staff lines. The smallest small tie that I added to the font is roughly 2/3 the staff line distance, so if the center of the noteheads are closer than 2.2 staff line distances, they will overlap with the tie (but 2.2 is pretty tight). When the distance is greater than 4.5 (or perhaps even less), the small tie is no longer pretty, so a LARGE tie should be used. * the LARGE tie (not yet added) traverses one staff line. I am planning to make two different shapes of large ties, one to be used for noteheads ON a staff line, and another for noteheads BETWEEN two staff lines (because they do not end in the same y position). The draw-tie function(s) must then use a different glyph for the two possible y-positions of the noteheads. There will be a bunch of large ties to be used from distances of around 3 or so, to perhaps 9 or 10. * when the distance is even larger than 9 or 10, we must draw two glyphs representing the beginning and the end of the ties, and a rectangle for the middle. I have made all the glyphs so that the center falls on exact pixel boundaries which means that the center can be invisibly extended by an ordinary black rectangle. I may make a third kind of tie that takes up more vertical space to be used when all tied notes are OUTSIDE of a staff, but that is low priority for now. Currently I am working on the glyphs. I may or may not have time to write the draw-tie function any time soon, so if anyone else wants to work on that, let me know. It would be cute to get your example to draw with the new glyphs. I still have no idea how to draw slurs and phrase marks that would make them both pretty and fast to draw. Bonne journ?e, -- 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 Fri Mar 26 07:27:43 2004 From: strandh at labri.fr (Robert STRANDH) Date: Fri, 26 Mar 2004 08:27:43 +0100 Subject: [gsharp-devel] ties In-Reply-To: <16483.55895.87952.228830@serveur5.labri.fr> References: <16483.55895.87952.228830@serveur5.labri.fr> Message-ID: <16483.56175.704915.402028@serveur5.labri.fr> Robert STRANDH writes: > > * the function will check the distance between the centers of the > noteheads in terms of multiples of the staff line distance. If > that distance is sufficiently small (say less than 4.5 times the > staff line distance) a SMALL tie is used. Such a tie is > characterized by the fact that it is entirely contained between > two staff lines. The smallest small tie that I added to the font > is roughly 2/3 the staff line distance, so if the center of the > noteheads are closer than 2.2 staff line distances, they will > overlap with the tie (but 2.2 is pretty tight). When the distance > is greater than 4.5 (or perhaps even less), the small tie is no > longer pretty, so a LARGE tie should be used. > > * the LARGE tie (not yet added) traverses one staff line. I am > planning to make two different shapes of large ties, one to be > used for noteheads ON a staff line, and another for noteheads > BETWEEN two staff lines (because they do not end in the same y > position). The draw-tie function(s) must then use a different > glyph for the two possible y-positions of the noteheads. There > will be a bunch of large ties to be used from distances of around > 3 or so, to perhaps 9 or 10. > > * when the distance is even larger than 9 or 10, we must draw two > glyphs representing the beginning and the end of the ties, and a > rectangle for the middle. I have made all the glyphs so that the > center falls on exact pixel boundaries which means that the center > can be invisibly extended by an ordinary black rectangle. This is all based on what I decoded from Ted Ross' book, of course. -- 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 Fri Mar 26 07:47:55 2004 From: strandh at labri.fr (Robert STRANDH) Date: Fri, 26 Mar 2004 08:47:55 +0100 Subject: [gsharp-devel] ties In-Reply-To: References: Message-ID: <16483.57387.669118.805676@serveur5.labri.fr> Bonjour, Also, as you probably noticed, I included a gf font viewer that I wrote so that I could have a more decent environment when working on the Gsharp font. I am afraid there are no installation or end-user documentation, so here are some hints. It requires Gsharp to be loaded because it uses some of its packages. It displays the raw bits of the glyph, but also the anti-aliased version that Gsharp will display. However, I do not handle exposure events correctly, so sometimes the anti-aliased glyph will not be displayed automatically, for instance after the window has been hidden and then is exposed. Displaying the grid requires a sufficiently high zoom factor, so do not be surprises if the grid disappears when you zoom out. Like I said, I wrote the viewer just to be able to work on the Gsharp font, and improving the viewer itself is low on my list of priorities. However, if someone likes it and wants to maintain it, feel free. Here is a small list of things to do : * handle file names better * handle exposure events * add pk file support * add keyboard shortcuts * add an overview page with clickable thumbnails * etc. Bonne journ?e, -- 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 Fri Mar 26 08:52:13 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 26 Mar 2004 08:52:13 +0000 Subject: [gsharp-devel] ties In-Reply-To: <16483.55895.87952.228830@serveur5.labri.fr> (Robert STRANDH's message of "Fri, 26 Mar 2004 08:23:03 +0100") References: <16483.55895.87952.228830@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > As you may have noticed, I am working on functionality for drawing > pretty ties to be used with your latest stuff. Yes, I saw... one day I shall learn to speak MetaFont. It looks cool, though. > Here is the plan (let me know what you think) : [some snippage] > * write a function draw-tie (or something like that) or perhaps a > pair of functions draw-tie-up draw-tie-down, which would take a > staff step and two x positions corresponding to notehead centers. > > * the function will check the distance between the centers of the > noteheads in terms of multiples of the staff line distance. If > that distance is sufficiently small (say less than 4.5 times the > staff line distance) a SMALL tie is used. Such a tie is > characterized by the fact that it is entirely contained between > two staff lines. The smallest small tie that I added to the font > is roughly 2/3 the staff line distance, so if the center of the > noteheads are closer than 2.2 staff line distances, they will > overlap with the tie (but 2.2 is pretty tight). When the distance > is greater than 4.5 (or perhaps even less), the small tie is no > longer pretty, so a LARGE tie should be used. > > * the LARGE tie (not yet added) traverses one staff line. I am > planning to make two different shapes of large ties, one to be > used for noteheads ON a staff line, and another for noteheads > BETWEEN two staff lines (because they do not end in the same y > position). The draw-tie function(s) must then use a different > glyph for the two possible y-positions of the noteheads. There > will be a bunch of large ties to be used from distances of around > 3 or so, to perhaps 9 or 10. > > * when the distance is even larger than 9 or 10, we must draw two > glyphs representing the beginning and the end of the ties, and a > rectangle for the middle. I have made all the glyphs so that the > center falls on exact pixel boundaries which means that the center > can be invisibly extended by an ordinary black rectangle. All of this sounds sensible. I need to look at an example, I fear, but here are two immediate edge cases: * trivially: all of this works only when the two notes in question are on the same line of the score; however, it will happen that the last note on one line is tied to a note on the next. What I think happens here is that the first note gets a tie more-or-less to the barline, and the second a (very small) tie from after the key-signature. My guess is that traditionally this second tie doesn't affect the spacing calculations, but I don't see any firm aesthetic reason why it shouldn't. * more controversially: consider a sequence such that there are several ties in a row, but one of them is a small tie. I suspect that it would be more aesthetically pleasing to have all of the extenders of the ties line up horizontally... but maybe this just isn't possible. These are just minor niggles; the basic plan sounds good. > Currently I am working on the glyphs. I may or may not have time to > write the draw-tie function any time soon, so if anyone else wants to > work on that, let me know. It would be cute to get your example to > draw with the new glyphs. It would indeed. I also need to refactor and fix what we currently have, ideally so that tie manipulation and note manipulation become as transparent as possible (with fewer nasty interactions between the two). Sadly, this weekend is booked up, but I can try to work on some code next week. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Fri Mar 26 10:01:54 2004 From: strandh at labri.fr (Robert STRANDH) Date: Fri, 26 Mar 2004 11:01:54 +0100 Subject: [gsharp-devel] ties In-Reply-To: References: <16483.55895.87952.228830@serveur5.labri.fr> Message-ID: <16483.65426.183362.144335@serveur5.labri.fr> Christophe Rhodes writes: > Robert STRANDH writes: > > > As you may have noticed, I am working on functionality for drawing > > pretty ties to be used with your latest stuff. > > Yes, I saw... one day I shall learn to speak MetaFont. It looks cool, > though. Metafont does? You have GOT to be kidding. Or perhaps you were talking about the ties? In that case, thanks. > All of this sounds sensible. I need to look at an example, I fear, > but here are two immediate edge cases: > > * trivially: all of this works only when the two notes in question > are on the same line of the score; Absolutely. And there are of course nasty things like enharmonic ties that would have to be drawn as slurs. > however, it will happen that > the last note on one line is tied to a note on the next. What I > think happens here is that the first note gets a tie more-or-less > to the barline, and the second a (very small) tie from after the > key-signature. My guess is that traditionally this second tie > doesn't affect the spacing calculations, but I don't see any firm > aesthetic reason why it shouldn't. It might. Ross does not talk about this case, so I have to study sometimes quite crappy engravings to find examples. > > * more controversially: consider a sequence such that there are > several ties in a row, but one of them is a small tie. I suspect > that it would be more aesthetically pleasing to have all of the > extenders of the ties line up horizontally... but maybe this just > isn't possible. I am not sure I understand this case. > > Currently I am working on the glyphs. I may or may not have time to > > write the draw-tie function any time soon, so if anyone else wants to > > work on that, let me know. It would be cute to get your example to > > draw with the new glyphs. > > It would indeed. I also need to refactor and fix what we currently > have, ideally so that tie manipulation and note manipulation become as > transparent as possible (with fewer nasty interactions between the > two). Sadly, this weekend is booked up, but I can try to work on some > code next week. OK, I'll try to get as far as possible, even though we have a very busy social schedule this weekend. The glyphs should be finished in a few hours. I'll start thinking about draw-tie after that. -- 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 Fri Mar 26 10:17:22 2004 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 26 Mar 2004 10:17:22 +0000 Subject: [gsharp-devel] ties In-Reply-To: <16483.65426.183362.144335@serveur5.labri.fr> (Robert STRANDH's message of "Fri, 26 Mar 2004 11:01:54 +0100") References: <16483.55895.87952.228830@serveur5.labri.fr> <16483.65426.183362.144335@serveur5.labri.fr> Message-ID: Robert STRANDH writes: > > * more controversially: consider a sequence such that there are > > several ties in a row, but one of them is a small tie. I suspect > > that it would be more aesthetically pleasing to have all of the > > extenders of the ties line up horizontally... but maybe this just > > isn't possible. > > I am not sure I understand this case. ascii art rendition: | |\ | | | |\ | | | | | | O @ O O \_________________/ \__/ \__________________/ My claim is that I think the bottom of the middle, short, tie in this example might be prettier if it is aligned with the bottom of the outer ties. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) From strandh at labri.fr Fri Mar 26 10:42:23 2004 From: strandh at labri.fr (Robert STRANDH) Date: Fri, 26 Mar 2004 11:42:23 +0100 Subject: [gsharp-devel] ties In-Reply-To: References: <16483.55895.87952.228830@serveur5.labri.fr> <16483.65426.183362.144335@serveur5.labri.fr> Message-ID: <16484.2319.70011.296694@serveur5.labri.fr> Christophe Rhodes writes: > > I am not sure I understand this case. > > ascii art rendition: > > | |\ | | > | |\ | | > | | | | > O @ O O > \_________________/ \__/ \__________________/ Nice picture! > My claim is that I think the bottom of the middle, short, tie in this > example might be prettier if it is aligned with the bottom of the > outer ties. quite possibly so. There are essentially only two solutions: * either allow for very wide "small" ties, i.e. ties that fit between two staff lines. Such ties will be fairly straight. * or else allow for a very narrow "large" ties, i.e. ties that span a staff line. Such a tie will look more like a fermata than a tie. Both solutions are probably acceptable. The first one will require small ties to be infinitely extended like I planned to do with small ties. The second solution will require additional glyphs for narrow large ties. Bonne journ?e, -- 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. ---------------------------------------------------------------------