From csr21 at cam.ac.uk Mon Jun 5 14:43:01 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 05 Jun 2006 15:43:01 +0100 Subject: [gsharp-devel] beams and printing Message-ID: Hi, The attached patch implements most of what is necessary to print beams. There's much that's basically hacky and needs reworking -- I think we want a medium-draw-{up,down}ward-beam generic function -- but the reason I'm asking for advice is that I don't understand the 1+ in DRAW-DOWNWARD-BEAM-SEGMENT (and the asymmetry compared with DRAW-UPWARD-BEAM-SEGMENT). The unfinished business in this patch involves that 1+: the issue is that output records need to store transformed quantities, not untransformed ones, as the medium transformation is ignored when replaying ORs. X1, Y1 and Y2 are correctly transformed in the record, and INVERSE-SLOPE is invariant under uniform scaling, but thickness is not. My patch transforms the thickness, but the final problem is that the 1+ in draw-downward-beam-segment (and faithfully copied in my polygon implementation for postscript mediums) is not invariant under transformations either. So I think we need to rework the beam output record to hold the actually drawn y values, but before doing that I wanted to understand where the 1+ came from in the first place. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: beams.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Wed Jun 7 16:00:22 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 07 Jun 2006 17:00:22 +0100 Subject: [gsharp-devel] line motion commands Message-ID: Hi, I have C-a and C-e wired into my fingers. The attached implements them for gsharp. It's a little bit worrying to have to dig into the gsharp-drawing package to be able to implement this, but that's probably a fact of life. If nobody's too worried about that kind of cross-cutting, I'll check this in. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: line-movement.lisp URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Wed Jun 7 16:40:15 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 07 Jun 2006 17:40:15 +0100 Subject: [gsharp-devel] semibreve (whole) position Message-ID: Hi, According to Ross (and to my experience) the semibreve rest should be placed in the middle of a bar. Probably this ought to be restricted to bars where the semibreve rest is the only element, but that's harder to implement than the global rule, which is implemented hackily by the attached patch. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rest.diff URL: -------------- next part -------------- Cheers, Christophe From strandh at labri.fr Wed Jun 7 18:07:16 2006 From: strandh at labri.fr (Robert Strandh) Date: Wed, 7 Jun 2006 20:07:16 +0200 Subject: [gsharp-devel] line motion commands In-Reply-To: References: Message-ID: <17543.5588.226914.288554@serveur5.labri.fr> Christophe Rhodes writes: > > I have C-a and C-e wired into my fingers. I agree, I try to do that all the time. > The attached implements > them for gsharp. It's a little bit worrying to have to dig into the > gsharp-drawing package to be able to implement this, but that's > probably a fact of life. If nobody's too worried about that kind of > cross-cutting, I'll check this in. Go ahead. Before doing the page breaks, I might clean up the entire view business anyway. As it turn out, page and line breaks are specific to a view, so I have to rework that part of Gsharp. -- 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 Tue Jun 13 08:08:04 2006 From: strandh at labri.fr (Robert Strandh) Date: Tue, 13 Jun 2006 10:08:04 +0200 Subject: [gsharp-devel] Gsharp progress report Message-ID: <17550.29284.893658.743854@serveur5.labri.fr> Dear mailing list member, There has not been a progress report for four months, for which I apologize. A lot of things have happened since the last report, some minor, some major. At the end of this message, you will find a list of these items. Now starts a period of a very large number of mostly minor, but not very interesting, improvements. Some of them will be directly visible to the user, such as more music symbols, more commands and improved ways of changing various parameters of the score. Others will be cleanups of the code, such as better modularity, and replacement of magic constants by real parameters that will either be computed or set and modified by the user. There are also a few medium-sized improvements that are necessary. For instance, the computation of measures should be moved to a view-specific object, so that we can have different simultaneous views of the score (such as for different parts). Major improvements since last progress report: * I implemented a new system for displaying music symbols. The previous system used Metafont to generate .gf files (one for each font size) and loaded those files as necessary. The main disadvantage of that system was that it was not easy to produce a printed version of the score. The new system takes slightly modified Metafont path descriptions for the music symbol and turn them into areas bounded by Bezier curves. These curves can be turned into PostScript path descriptions for printing or into pixmaps for on-line viewing. In fact, the new system is very general and could be used by other CLIM applications as well, as it integrates with CLIM areas. A minor advantage of the new system is that score symbols can be drawn using any color. * Christophe Rhodes implemented the necessary medium-draw methods on a PostScript medium so that generating a PostScript file for printing is now possible. The PostScript output looks very similar to the screen version, except that the resolution is usually better. * I implemented a new font viewer for the new font rendering system. It is a 170-line CLIM application that allows you to view symbols in various sizes, as pixels (with or without a grid) or as the resulting anti-aliased glyph (with or without a staff). This application is part of Gsharp, so anyone can start it to debug old or new glyphs. * Gsharp can now do multi-page scores. In order to accomplish that, I implemented one new algorithm and modified an existing one. The modified algorithm used to divide the score into `lines', and uses a modified cost measure to divide it into pages instead. The new algorithm takes a sequence of measures to be rendered on the same page and computes an optimal way of dividing those measures into lines. * Gsharp can now draw ties. A variety of ties are now included in the Gsharp fonts and the right one is selected automatically. Ties are saved to disk and rendered to MIDI as expected. * Gsharp now uses the ESA modules from Climacs, which makes it possible to take advantage of independent improvements to ESA. This has already resulted in better on-line help, better file completion, better handling of I/O, modified buffers, etc. * Gsharp now uses Flexichain as an independent module, available as a project on common-lisp.net. Again, this allows us to take advantage of independent improvements to the Flexichain module. * Christophe Rhodes made scrolling work correctly. This means that even on smaller screens, it is now possible to work on the full page. * Christophe Rhodes fixed the problem we had with partial beams by making sure the clipping region got saved and restored correctly in the corresponding output record. Minor improvements: * Introduced a new command table for commands that operate on rhythmic elements. * Christophe Rhodes implemented octaviated treble clefs. * Movement by measure, bound to M-C-f and M-C-b, implemented by Christophe Rhodes. * The file menu now works, thanks to Christophe Rhodes. New scores: * Les Cris De Paris, entered by Christophe Rhodes. * The beginning of the 4th English suite by Bach. * Dvorak's Humoresque, entered by Christophe Rhodes. -- 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 Sun Jun 18 02:41:33 2006 From: strandh at labri.fr (Robert Strandh) Date: Sun, 18 Jun 2006 04:41:33 +0200 Subject: [gsharp-devel] future development of Gsharp Message-ID: <17556.48477.662566.298994@serveur5.labri.fr> Hello, Here is some food for thought. It seems to me that the user would want to preserve between editing sessions various pieces of information that are not directly associated with the music contents of the buffer, such as the value of the spacing style (which determines how space relates to time), the smallest distance between notes (which determines the density of the score). Furthermore, the user certainly would like to edit several "views" of the score, such as a full orchestra view and several "parts" views, and those views should be preserved between sessions as well. In my opinion, the spacing style and the smallest distance between notes are also part of a view, simply because one can imagine wanting different values for these parameters in a single editing session. The current cursor position is also part of the view. On the other hand, Gsharp should be able to load a buffer from disk without any preexisting view, say if the buffer contents has been generated by some other program. I suggest solving these problems as follows: A Gsharp file should contain the buffer (much like now) without any view-related parameters followed by zero, one, or several named views. When a file is loaded into Gsharp, if there are no views following the buffer description, a default one is created (a full orchestra view with default parameter values). When a buffer is saved, existing views are appended to the file. This system makes it possible for programs that don't deal with views to read and write Gsharp files (by only reading and writing the buffer contents) while still allowing for Gsharp to preserve views between editing sessions. Thoughts? -- 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 Jun 19 14:10:18 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 19 Jun 2006 15:10:18 +0100 Subject: [gsharp-devel] keysignatures (was [gsharp-cvs] CVS gsharp/Scores) In-Reply-To: <20060614182408.DB9F0111E8@common-lisp.net> (rstrandh@common-lisp.net's message of "Wed, 14 Jun 2006 14:24:08 -0400 (EDT)") References: <20060614182408.DB9F0111E8@common-lisp.net> Message-ID: "rstrandh" writes: > Modified Files: > bach-suite-iv-prelude.gsh > Log Message: > Typed a few more bars. > > Now I need to know how to change the key signature in the middle of > a staff. For what it's worth, I attach a patch which works for me; it's essentially just a forward-ported version of my previous work, which means it still suffers from the same problems, arranged in vaguely descending order of seriousness: * while this implementation does cope with layers spanning with multiple staves, such that a key signature on one staff does not affect notes on another staff, it does not cope with multiple layers on the same staff: only the layer with the key signature actually in it will see it. * passing a key signature to DRAW-BEAM-GROUP seems wrong. My hack in DRAW-BEAM-GROUP is a reflection of that. * right-bulge shares an awful lot of code with draw-element (key-signature), which shares an awful lot of code with draw-staff-and-clef. * invalidation of things using the staff in question is asymmetric, for some reason I've forgotten (or never known): things are invalidated in INSERT-KEYSIG, a "user" function, and in REMOVE-ELEMENT :BEFORE, a "protocol" function. Probably it ought to be the same in both cases. * finding the keysignature applicable to an arbitrary cursor doesn't work, as I couldn't work out how to map such a cursor to a staff. Nevertheless, I hope this is a start. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: keysigN.diff URL: -------------- next part -------------- Cheers, Christophe