Re: severe chord repetition problem
Op maandag 07 december 2009 schreef David: The editor needs to be suitably clever to have this work properly in \relative mode. Ok, should be sufficient to remove octave indicators from the first chord note, so this is probably not overly hard. Yes Frescobaldi does exactly this :-), and it copies short-hand articulations (like -. etc) Frescobaldi also can read relative music (it can transpose both relative and absolute music fragments, and also convert between relative and absolute input, auto-detecting the pitch language (by looking at the \include statements :-) ) But let it be clear: if LilyPond changes, it is no problem for me to adapt Frescobaldi. If 2.14 ships with 'q' I'll do my best to have Frescobaldi support it. many regards, Wilbert Berendsen -- Frescobaldi, LilyPond editor for KDE: http://www.frescobaldi.org/ Nederlands LilyPond forum: http://www.lilypondforum.nl/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Dana Emery wrote Sunday, December 06, 2009 9:37 PM Let the choice of font display a glyph in the proper shape. Provide the user with a way to display arbitrary glyphs and ligatures for each encoded 'stop'. This will be useful for bass stops (/a /b /c... //a //b //c, ///a) and essential for german tab should we go there. It would be wrong to presume the encoding of the font. The need for glyphs beyond what is used in prose makes necessary special fonts whose encoding has no standard. afm-like information in external files keyed by name to their relevant font would be my suggestion for that. I prefer to leave the whole question of fonts until later, primarily because I know little about them at present. As Carl suggested, if we permit markups then any available font can be used (although even that is not necessary, as simply overriding the font for TabNoteHead works with just characters entered anyway, as my initial lash-up using Fronimo fonts showed.) But markup will permit PostScript or even images to be substituted, so there is an advantage in flexibility to be gained by permitting it. Although if i not j is a general rule I have generally seen i used in preference to j, but I have seen both in the same document albeit this was german tab (same semantic). Note that that edition had large pages and lots of staves, it must have been a challenge to find enough sorts to set the amount of type on each page, several sizes and flavors of each sort were also used interchangeably (both tall and short s for example). You will be able to use either or both. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: severe chord repetition problem
Wilbert Berendsen lily...@xs4all.nl writes: Op maandag 07 december 2009 schreef David: The editor needs to be suitably clever to have this work properly in \relative mode. Ok, should be sufficient to remove octave indicators from the first chord note, so this is probably not overly hard. Yes Frescobaldi does exactly this :-), and it copies short-hand articulations (like -. etc) Actually, if q stands for last _chord_ rather than last note event, then removing octave indicators is not sufficient since intervening notes might have shifted the meaning. but of course what the shortcut in Frescobaldi refers to is not necessarily the same as q. Frescobaldi also can read relative music (it can transpose both relative and absolute music fragments, and also convert between relative and absolute input, auto-detecting the pitch language (by looking at the \include statements :-) ) But let it be clear: if LilyPond changes, it is no problem for me to adapt Frescobaldi. If 2.14 ships with 'q' I'll do my best to have Frescobaldi support it. If the meaning is defined well enough. I mean, one could also go crazy and design, say, an artificial articulation -! that stores the corresponding note event (including duration) in its current state of assembly, and have @ to reproduce this note event (including default duration which can be overridden). Again, one needs to establish how long this memoization is supposed to hold. But at least there would be a clear indication _what_ is remembered, and one could with reasonable accuracy run the stuff through a preprocessor that removes those marks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Carl Sorensen wrote Monday, December 07, 2009 1:51 AM On Dec 6, 2009, at 5:18 PM, Trevor Daniels t.dani...@treda.co.uk wrote: Carl Sorensen wrote Sunday, December 06, 2009 9:59 PM . The fretLabels list wouldn't need to be characters; they could be markups or stencils, so users could define whatever is needed or desired. I quite like the term fretLabels, with the list being of anything that evaluated to a Scheme string. Why a string instead of a string or a markup? As the font can be overridden in TabNoteHead markup isn't required to select a different font. However, I see there might be an advantage in permitting PS or even images to be substituted, or to use a different font for some of the fret labels, and that would need markup in the list. I'll look at implementing that. Thanks for the suggestions. Carl Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: severe chord repetition problem
David Kastrup wrote: Actually, if q stands for last _chord_ rather than last note event, then removing octave indicators is not sufficient since intervening notes might have shifted the meaning. Correct, that's the remaining drawback from the notes-chord-memorization; otherwise, this one perfectly fits /my/ usual needs. But let it be clear: if LilyPond changes, it is no problem for me to adapt Frescobaldi. If 2.14 ships with 'q' I'll do my best to have Frescobaldi support it. If the meaning is defined well enough. I tend to use very simple tools - Emacs that is, in this case, without much sophisticated input shortcuts (like lyqi) - so I could not image where the problem might be to allow exchanging the memorization function, as long as the input is parseable. As most not-too-experienced programmers I tend to be overly self-confident, and say I'm gonna understand this if it's written there. Even when I'm going to read files, especially since I agree with Nicolas in: On the other hand... which ratio of users might ever change the behavior of chord repetition memorization? I don't really think that readability might suffer, as long as the default is the most convenient. For instance, users can also completely change the note names [...] And such a change should catch my eye. But when it comes to editor support, things change. (In particular: a feature I'm desperately missing with my primitive input methods is actually already featured by other editors, so there might not be the need for it that I assume.) Wilbert changed my opinions here - now, it looks like Nicolas' first idea of copying everything (well, perhaps everything but rests) may be what's actually needed more often. And it looks both easier maintainable and more robust than the notes-chord-memorization (see above.) You (especially David i.e., but also Nicolas and Wilbert) certainly proved a clearer mind on such issues than me, and I agree with your concerns. Still, since I'm happy to see that notes-chord-memorization gives me a feature I've been subconsciously craving for, and I'd be sad if it's removed again: Is it okay to have an exchangable policy as long as it is very low-level, i.e. there are no commands inviting to write them every two lines, but only something like the current syntax to replace the repetition-memorization-function? Is it reasonable to have only one of those methods officially supported and recommended, the other deprecated, yet available? (Assuming it's not as prominently advertized as \parallelMusic, of course.) Cheers, Alexander ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
midi elapsed time markers
I was searching for a way to print out midi elapsed time in my score to be able to easily start the midi file at the location I am currently working on. At the moment I write these in by hand but they change as I make changes to the music in other locations. As far as I could see, there is no way of generating these values automatically. I was looking for something like rehearsal marks with the elapsed time for the midi file in minutes and seconds based on the \tempo value, for example. Would this be a useful new feature or does the facility already exist? ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
On 12/6/09 5:18 PM, Trevor Daniels t.dani...@treda.co.uk wrote: I prefer str to course and string, but if no other ideas are forthcoming I'll use string_number. In Scheme files, the variable name should be string-number. In c++ files it would be string_number. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Dana suggests course, which I guess speaks well to lute players. But not to guitar players. 12 course guitar anyone? maybe ts a classical guitar hing, but I also remember tutorials discussing 6-course instruments. I had envisioned that a full set of fretLetters would be given At least that, saving keystrokes is not a good idea here. Wht is really needed is a way to specify degenerated ligatures; as I have said, for german tab the ligatures used by 16c printers (and later) included overstrikes using both curved and straight line segments placed below, thru, and above the main glyph, each positioned differently from others. I began a font for these, but got sidetracked and havent gone back to it. Perhaps we just ought to define lists called fretLabels (instead of fretLetters). And we could then define lists of any kind of glyphs to be used. Flags, mensural symbols (O2, O3, O/...), bars (| || |:| :|: :| |: |||, this last is a common ornamental flourish used for the final bar, the second vertical stroke is repeated several times all connected, the height of it degenerates into, well, a flourish). In some renaissance editions it is clearly a cast type sort, others use various woodcuts chosen to fill available space; perhaps the user will be inconcistant in how it is used, epsf-cum-woodcut or font character. While I use separate dots flags and stems when devising a font, they are pre-compounded and are encoded as one non-combining symbol to the font user. However, other font makers may solve that issue differently, leaving it up to the user to form ligatures from parts like tails, dots, stems. Tabulature flags with dots are usually shown above the staff (Petrucci's editions are an exception), so there is no issue of the dot intersecting a line, as is seen in notes on a mensural staff; mensural notation requires a different placement of the dot of augmentation relative to its note when the note is on a line as opposed to when it is in a space, which is a reason to have them be combining symbols in a mensural font. There could be specific lists for each different style of tablature, that would be very easy to switch to. If ly needs musical semantics to associate with the symbols then there will be an issue to consider as well, the display symbol lists will need coordination with similar lists for the semantic(s). Historical usage varied as to the symbols employed and how they map to duration. The usual set of 5 flags were simply up-stemmed notes (usually, but not always headless) with tails to the right - semibreve, minim, semiminim, fusa, semifusa. Some printers also had a breve - a left-going tail, or a tailless stem with a circle on it. Many polyphonic editions show (by comparing parallel score parts with the tab) that those flags were read in proportion (ie, the written semibreve was read as breve); this to avoid needing 5-flagged stems that would challenge the punchcutter, the player, compositor, and proofreader with weak eyes, and the ink that spreads. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Carl Sorensen wrote Monday, December 07, 2009 4:20 PM On 12/6/09 5:18 PM, Trevor Daniels t.dani...@treda.co.uk wrote: I prefer str to course and string, but if no other ideas are forthcoming I'll use string_number. In Scheme files, the variable name should be string-number. In c++ files it would be string_number. Yes, I realised that when I came to change it. Thanks anyway Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
What I am trying to say comes from my own experiences writing a gui
program to do tab typesetting on macintosh.
My software records {course,fret} data for each note in the score, and
pitch information for each course on the instrument (simplifying courses
with octaves as split play is very rare).
That internal data is mapped using user-selected tables (which can be
user-defined, tho I provide several) for - keybindings (gui input),
musical semantics, and display ligatures.
For ly, you have user-encoded textfiles which roughly correspond to marked
up data using my input keybindings, an Internalization of that data,
musical semantic tables, display tables.
BTW, I found it useful to map the index 0 to blank and 'no semantic' on
all those tables.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Hi Carl, Carl Sorensen wrote: On Dec 6, 2009, at 7:18 PM, Ian Hulin i...@hulin.org.uk wrote: Carl, Trevor, You've discussed the overloading of 'string' in Scheme and what variable name to use, and looked at Dana's suggestion of using 'course' but did you consider the other important point Dana made? I think so. That's why I suggested a list of (string or markup), which I think is completely general. At that point the user can select any glyph from any font available. The possibility of adding the afm-type info that Dana talked about is a separate patch, because it applies to all markups. Is there something else you were thinking of? Well, yes, maybe Dana can explain this better, but it seems to me we may be in danger of perpetuating a sort of urban myth with regard to lettered tablatures. Fret 3 was lettered as ɣ, which was rendered in some contemporary engravings to look a bit like a fancy r, so some modern transcriptions of the tablature turn it into an r. If we're going to re-render ɣ, why not do it as c, and keep the logical letter sequence. I know we want Lily to be flexible and render contemporary engraving as authentically as possible, but using the 'r' for fret 3 is as bogus as this example. Titles like Ye Olde Forge, is a misreading of the Þe Olde Forge: Þ being a letter thorn standing in for Th. The ornate blackface font letter Y looked a bit like Þ so it got substituted in some texts where early printers didn't have the Þ in their type-cases. Cheers, Ian Thanks, Carl snip ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
On 12/7/09 11:00 AM, Ian Hulin i...@hulin.org.uk wrote: Hi Carl, Carl Sorensen wrote: On Dec 6, 2009, at 7:18 PM, Ian Hulin i...@hulin.org.uk mailto:i...@hulin.org.uk wrote: Carl, Trevor, You've discussed the overloading of 'string' in Scheme and what variable name to use, and looked at Dana's suggestion of using 'course' but did you consider the other important point Dana made? I think so. That's why I suggested a list of (string or markup), which I think is completely general. At that point the user can select any glyph from any font available. The possibility of adding the afm-type info that Dana talked about is a separate patch, because it applies to all markups. Is there something else you were thinking of? Well, yes, maybe Dana can explain this better, but it seems to me we may be in danger of perpetuating a sort of urban myth with regard to lettered tablatures. We are perpetuating that urban myth if we provide fretLabels with r. I'm glad you pointed that out. My comments were not about the fretLabels to be provided, but about the architecture that would support various fretLabel lists. Fret 3 was lettered as ɣ, which was rendered in some contemporary engravings to look a bit like a fancy r, so some modern transcriptions of the tablature turn it into an r. If we're going to re-render ɣ, why not do it as c, and keep the logical letter sequence. My preference would be to render it as gamma. Let's do it correctly. Thanks for pointing this out. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
On 12/7/09 9:30 AM, dem...@suffolk.lib.ny.us dem...@suffolk.lib.ny.us wrote: Dana suggests course, which I guess speaks well to lute players. But not to guitar players. 12 course guitar anyone? In my experience we call it a 12-string guitar (but as you correctly point out, there are only 6-courses in a 12-string guitar). maybe ts a classical guitar hing, but I also remember tutorials discussing 6-course instruments. There are some pages on the web that discuss 5- and 6-course guitars, with either single courses (1 string per course) or double courses (2 strings per course). This is not part of the experience in popular guitar playing as far as I can see. But it is apparent that we really do finger courses, rather than strings. I had envisioned that a full set of fretLetters would be given At least that, saving keystrokes is not a good idea here. Wht is really needed is a way to specify degenerated ligatures; as I have said, for german tab the ligatures used by 16c printers (and later) included overstrikes using both curved and straight line segments placed below, thru, and above the main glyph, each positioned differently from others. I began a font for these, but got sidetracked and havent gone back to it. These overstrikes can be accomplished with markups, which is part of the reason I want to have markups available in fretLabels. Perhaps we just ought to define lists called fretLabels (instead of fretLetters). And we could then define lists of any kind of glyphs to be used. Flags, mensural symbols (O2, O3, O/...), bars (| || |:| :|: :| |: |||, this last is a common ornamental flourish used for the final bar, the second vertical stroke is repeated several times all connected, the height of it degenerates into, well, a flourish). In some renaissance editions it is clearly a cast type sort, others use various woodcuts chosen to fill available space; perhaps the user will be inconcistant in how it is used, epsf-cum-woodcut or font character. While I use separate dots flags and stems when devising a font, they are pre-compounded and are encoded as one non-combining symbol to the font user. However, other font makers may solve that issue differently, leaving it up to the user to form ligatures from parts like tails, dots, stems. Tabulature flags with dots are usually shown above the staff (Petrucci's editions are an exception), so there is no issue of the dot intersecting a line, as is seen in notes on a mensural staff; mensural notation requires a different placement of the dot of augmentation relative to its note when the note is on a line as opposed to when it is in a space, which is a reason to have them be combining symbols in a mensural font. Font design is clearly outside the scope of the current effort, although it has been proposed as a future phase. There could be specific lists for each different style of tablature, that would be very easy to switch to. If ly needs musical semantics to associate with the symbols then there will be an issue to consider as well, the display symbol lists will need coordination with similar lists for the semantic(s). Unquestionably we want LilyPond to have correct semantics, and produce output corresponding to those semantics. I think that's at the core of Trevor's implementation. Historical usage varied as to the symbols employed and how they map to duration. The usual set of 5 flags were simply up-stemmed notes (usually, but not always headless) with tails to the right - semibreve, minim, semiminim, fusa, semifusa. Some printers also had a breve - a left-going tail, or a tailless stem with a circle on it. Again, a list that matches a duration to a symbol (and whose symbols can be specified by the user) will allow the matching between semantics and display. Many polyphonic editions show (by comparing parallel score parts with the tab) that those flags were read in proportion (ie, the written semibreve was read as breve); this to avoid needing 5-flagged stems that would challenge the punchcutter, the player, compositor, and proofreader with weak eyes, and the ink that spreads. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: UTF-8 support needs implementing to fix all bidi/rtl/ltr issues
On 2009-12-05, Patrick McCarty wrote: On Thu, Dec 3, 2009 at 12:50 PM, Ted Walther t...@reactor-core.org wrote: Here is the lilypond file: http://hymns.reactor-core.org/HaikVantoura/Shema4.ly It produces this output: http://hymns.reactor-core.org/HaikVantoura/Shema4.pdf But I should be able to use the unicode codes referenced previously to make the output look like this: http://hymns.reactor-core.org/HaikVantoura/Shema4.1.pdf Without looking at the Pango API, I suspect that either (a) Pango supports these characters and LilyPond does not allow Pango to process them correctly, or (b) Pango does not yet support the characters. Just an update on this... I believe that (a) describes the situation. In fact, Pango implements the Unicode bidirectional algorithm internally and abstracts the complications away from the user. So, there is no need for LilyPond to implement the algorithm per se. But, LilyPond is not using these functions -- or possibly not calling the correct functions -- so the Unicode characters in question are not being recognized correctly. Instead LilyPond tries to find a glyph for these characters, but of course none are found. I'll add this to the issue tracker tomorrow sometime, hopefully, unless someone else beats me to it. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Fret 3 was lettered as ɣ, which was rendered in some contemporary engravings to look a bit like a fancy r, so some modern transcriptions of the tablature turn it into an r. If we're going to re-render ɣ, why not do it as c, and keep the logical letter sequence. My preference would be to render it as gamma. Let's do it correctly. Thanks for pointing this out. 'c' marks fret 2 in French tab. Correct is to think of it as 'c', employ that concept internally, and in any documentation. Draw it as a gamma-like glyph in fonts emulating those hands and fonts which do so historically; but encode it in those fonts as the 'c' it is. This list is the first place I have seen mention of the concept of it being a gamma, the citations i gave in an earlier email are the scholarly references for tablature notation, I own Apel and have it open now, but Wolf is hard to come by outside of a good music library. Apel takes time to discuss the development of some symbols, clefs for instance, but not these, no mention of gamma at all in his discussion of the symbols of french tabulature. He illustrates Granjons pretty font in a 1568 publication, the 'c' in that font is a combination of both, the lower curve of a 'c', the upper flattened arm of a gamma. The hand of gaultier as seen in the Hamburg codex is also shown, there the 'c' (as labeled by Apel) is indeed a gamma, very rectilinear modern 'r'. But, my point here is that Apel labels it 'c', and says nothing about it resembling a gamma. The omission of j will be curious to anyone writing analytical software, but that is enough strangeness (gotta have at least one point of strangeness). Please note that Pierre Attaignant (first printer of french tabulature notation) used ROMAN MAJISCULE letter forms in his 1528 and 1530 editions, C was a C for his readers. I wish I had the material from my survey of french tab printers fonts handy, I am sure there are others whose letter forms were more italianate than courthand. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Thanks for this, Dana. We're some way off implementing fonts, or whatever means we select for rendering specific lettering, but I shall carefully file all this information away and draw on it at the appropriate time. For now I'm more concerned with understanding the internal mechanisms of LilyPond and implementing some rather basic facilities. Trevor - Original Message - From: dem...@suffolk.lib.ny.us To: Carl Sorensen c_soren...@byu.edu Cc: Ian Hulin i...@hulin.org.uk; Trevor Daniels t.dani...@treda.co.uk; lilypond-devel@gnu.org; re...@codereview.appspotmail.com; tdanielsmu...@googlemail.com; carl.d.soren...@gmail.com Sent: Tuesday, December 08, 2009 12:23 AM Subject: Re: Add option to indicate frets by letters in tablature (issue164063) Fret 3 was lettered as ɣ, which was rendered in some contemporary engravings to look a bit like a fancy r, so some modern transcriptions of the tablature turn it into an r. If we're going to re-render ɣ, why not do it as c, and keep the logical letter sequence. My preference would be to render it as gamma. Let's do it correctly. Thanks for pointing this out. 'c' marks fret 2 in French tab. Correct is to think of it as 'c', employ that concept internally, and in any documentation. Draw it as a gamma-like glyph in fonts emulating those hands and fonts which do so historically; but encode it in those fonts as the 'c' it is. This list is the first place I have seen mention of the concept of it being a gamma, the citations i gave in an earlier email are the scholarly references for tablature notation, I own Apel and have it open now, but Wolf is hard to come by outside of a good music library. Apel takes time to discuss the development of some symbols, clefs for instance, but not these, no mention of gamma at all in his discussion of the symbols of french tabulature. He illustrates Granjons pretty font in a 1568 publication, the 'c' in that font is a combination of both, the lower curve of a 'c', the upper flattened arm of a gamma. The hand of gaultier as seen in the Hamburg codex is also shown, there the 'c' (as labeled by Apel) is indeed a gamma, very rectilinear modern 'r'. But, my point here is that Apel labels it 'c', and says nothing about it resembling a gamma. The omission of j will be curious to anyone writing analytical software, but that is enough strangeness (gotta have at least one point of strangeness). Please note that Pierre Attaignant (first printer of french tabulature notation) used ROMAN MAJISCULE letter forms in his 1528 and 1530 editions, C was a C for his readers. I wish I had the material from my survey of french tab printers fonts handy, I am sure there are others whose letter forms were more italianate than courthand. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
Thanks for this, Dana. We're some way off implementing fonts, or whatever means we select for rendering specific lettering I realize that, what i was concerned with is that the technology for flexibility be in place. When the time comes, you will want to have done some surveying of originals. J Wolf Handbuch der Notationskunde and W. Apel Polyphonic Notation 900-1600 are a beginning, there are many more interesting publications that illustrate musical incuabulae, including tabulature. New Groves 'Tabulature' is dated, but has lots of good illustrations. 'Sources' is another source that touches on some of the Ms. If you are a member of the LSA you have access to microfilms, and being in the UK you have the BM, Oxford, and Cambridge, with Paris and other continental sources a pleasant journey away. It is not easy finding exemplars for the whole alphabet in actual music, if a note isnt played you have no glyph. With all the interest nowadays in geneology, as well as past years interest in typography and caligraphy there are many tangential resources to draw on. There are also many modern musicologists who have written articles on the grace markups in EM, LSAJ, LSJ, EMA etc, all of those need some time in library pour les musiques baroque. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
the guide for contributors, or the guide for a contributor?
I was amused by the recent punctuation fix commit: I've always considered the CG to be the guide for contributors, or the contributors's [sic] guide. In modern English, the latter is abbreviated (condensed?) into the contributors' guide. I don't mind it being the guide for a contributor instead, so I have no objection to the contributor's guide. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
TextSpanners don't work in Dynamics context
See issue #926. This makes the Dynamics context quite useless. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the guide for contributors, or the guide for a contributor?
I was amused by the recent punctuation fix commit: [...] BTW, may I remind to have TWO spaces after a full stop, exclamation mark and question mark at the end of a sentence. This is both useful for certain editors (like Emacs), and it helps the text-mode info browser to break lines. IIRC, this is mentioned somewhere in the guidelines but gets constantly ignored. Someone should walk over the docs and fix that eventually. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add option to indicate frets by letters in tablature (issue164063)
dem...@suffolk.lib.ny.us writes: 'c' marks fret 2 in French tab. Correct is to think of it as 'c', employ that concept internally, and in any documentation. Draw it as a gamma-like glyph in fonts emulating those hands and fonts which do so historically; but encode it in those fonts as the 'c' it is. This list is the first place I have seen mention of the concept of it being a gamma, the citations i gave in an earlier email are the scholarly references for tablature notation, I own Apel and have it open now, but Wolf is hard to come by outside of a good music library. Apel takes time to discuss the development of some symbols, clefs for instance, but not these, no mention of gamma at all in his discussion of the symbols of french tabulature. He illustrates Granjons pretty font in a 1568 publication, the 'c' in that font is a combination of both, the lower curve of a 'c', the upper flattened arm of a gamma. The hand of gaultier as seen in the Hamburg codex is also shown, there the 'c' (as labeled by Apel) is indeed a gamma, very rectilinear modern 'r'. But, my point here is that Apel labels it 'c', and says nothing about it resembling a gamma. Check out URL:http://en.wikipedia.org/wiki/File:Calligraphy.malmesbury.bible.arp.jpg, first letter in the next to last line. cognationum starts with a c. You'll see where the confusion about blackletter c being either r or gamma arises. The omission of j will be curious to anyone writing analytical software, but that is enough strangeness (gotta have at least one point of strangeness). The Latin script does not have j, u or w IIRC. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
