Re: Directory name of aux is invalid
On Tue, Jan 6, 2009, Trevor Daniels said: > The names are case-insensitive, and they cannot be > used as directory names or the first part of a > filename (the bit before the dot). please note, in DOS (and many of its contemporary file systems), what users think of as the filename is not actually a ten character field but in fact two seperate entitys, the name (6 characters), and a 3 character extension. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sponsoring a full support for footnotes in Lilypond
On Mon, Feb 2, 2009, Han-Wen Nienhuys said: > I stopped doing sponsored work on LilyPond. I'm forwarding your > message to the lilypond-devel forum. Maybe you can someone there can > help you. MS Word, and might even be supported in more robust desktop publishing software such as Quarkexpress, Pagemaker, or Framemaker. Footnotes are not always small citations, sometimes they are many paragraphs long and need to be flowed across several pages in competition with the main flow of prose and ilustrations (music in our case). This might not be a quickie which would be available for this user in a reasonable timeframe, even if someone here cared to work on it at all. Endnotes would be easier to implement, but for generality and our other users we should do both if either, as many journals and some publishers prefer endnotes. Perhaps the user could be content to make illustrations in LP to adorn the pages of the book typeset in MS Word? -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
Historical lute tablature notation had a number of issues to deal with when it came to indication of rhythm. Remember that this was the late renaissance, at a time when the notation was being simplified (see Thomas Morley, _A Plain and Easy Introductiuon to Practical Music_. A Composer then had a choice of what note to assign his tactus to. If the musical form was in any way trinary (eg, a galliard, or a bransle simple) it was considered apropriate to use the longer durations which could be 'perfect' (maxima, longa, breve, semi-breve) one unto another. But if binaria sufficed, the lesser notes could be taken advantage of, semi-breve..semifusa; and these had the advantage (to us) of all being stemed. Thus, the solution lies in 'reduction'; ie, advise users against the use of half notes and longer in new composition; transliterations should employ reduction (eg, half->quarter; quarter->eighth ...). The odd breve is found in some renaissance lute tablature, it has a stem toped by a left-going flag or has a circle (at half-mast). \\| / |. \o | ||| | ___ ___ .. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
On Wed, Mar 4, 2009, Valentin Villenave said: > Ian, Dana, and others: if I may, perhaps this would be the appropriate > time for some scanned samples of ancient or modern scores > demonstrating this use... Sorry, no scanner available except by hire, which I cant afford just now; I have perused the few I have on hand, but all from one source which doesnt have any notes as long as a breve. looking to buy a scanner. I do have semeral facsimile editions out in the car, and will peruse them later today, if I see something I can at least cite the occurance (and note it for myself for when I make that font). Ample fascimiles in the library, for those who will take the trouble to go and look - _New Groves Dictionary of Music and Musicians_, 'Notation', 'Sources-Lute', 'Tablature'. Many facsimle editions of historical lute tablature have been published, Broude Brothers is but one modern publisher. Its not difficult to design suitable glyphs for tablature half-notes - take a headless stem, center a small circle on it and you have one form; take a headless stem and add a tail which goes left for the other; pick one of these to serve for half-notes et voila. Nothing serves for whole notes save avoidance. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
On Fri, Mar 6, 2009, Ricdude said: > Valentin Villenave gmail.com> writes: > The effect I'm going for is similar to the following, only the "flags" on the > half notes should be connected to the stems, go to the right, and probably be > a > little shorter in length... line weight will be what distinguishes them from isolated eighth-notes? The reason for left-going flags as well as shape is to give the musician multiple clues. The length of the leftgoing flag should be short, shorter than a note heads width should be fine. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Proposal for resolving Half/Quarter note ambiguity on pure tablature staves (with partial code mod)
On Sat, Mar 7, 2009, Valentin Villenave said: > 2009/3/7 : > >> The reason for left-going flags as well as shape is to give the musician >> multiple clues. Â The length of the leftgoing flag should be short, shorter >> than a note heads width should be fine. > > Er, could anyone give me a PNG image so that I can open an official request? Er, it needs to be invented, in the style of the flags it will complement, but also distinct from them to the eyes of a musician. I have no idea of what they look like, and no access to a working version of ly, so I bow out. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music Glossary - 1.64 Concert Pitch (2.12.2)
On Fri, Apr 3, 2009, "Anthony W. Youngman" said: > Sorry, reading this was painful agreed. > 1.64 concert pitch Ensembles must agree on a temperament and a pitch standard if they are to be tuned agreeably. Equal temperament is usual for the full orchestra with winds, piano, and strings which plays repertoire in a full range of keys. The pitch of the A above middle C is the conventional reference point. A=440 Hz has been the practice for many orchestras over the past several decades, but in recent years some are creeping sharper, even to A=445; on the theory that it is good to have the violins sound brighter, tho it leaves the woodwind section rather challenged, as it is difficult (and expensive) to adjust some winds sharper. Other reference pitches have been used historically, and sometimes different places had variant practices. Many ensembles specializing in music from historical periods will employ other reference pitches, and may also employ non-equal temperaments. > 1.311 transposing instrument Some instruments play in a range which is awkward to transcribe useing the common G and F clefs, too many ledger lines is challanging to read. Octave-transposing clefs provide one solution to this problem. Some instruments are used in different sizes to accomodate play in particular ranges; the playing techniques are often close enough that skill on one carries over to the others, and so some members of the orchestra will play a variety of instruments which differ in size and fundamental pitch. The challenge of reading for each of several instruments is eased when the parts are written transposed. As an example, the Soprano C clarinet is the reference for the family. Music for it is written a sounding pitch. Music for the lower-pitched Bb clarinet is written transposed upward by a second, the player reads the same as for a 'C' instrument, it plays a second lower than the written pitch. This practice is a great convenience for the orchestral player, but does make for confusion to anyone ignorant of the practice, perhaps while reading the orchestral score. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music Glossary - 1.64 Concert Pitch (2.12.2)
On Sat, Apr 4, 2009, "Anthony W. Youngman" said: > Okay, I think I can modify this to a definitive version now ... sorry for my tactless reply earlier, I should have checked the present text rather than assume you were quoting it. >>>1.64 concert pitch >>> >>>The pitch at which the piano and other non-transposing instruments >>>play the concept of transposing instruments is irrelevant to this entry and should be left in its entirety to 1.311 I think it is both sufficient and correct to state A convention for tuning the instruments of the orchestra. >>> Officially, it is defined by whom? wiki? I suspect there is a cartel of instrument makers who have established the standard for what they will manufacture, but they have no say over how their products will be [ab]used. Each orchestra has an understanding with its players, their union(s), and guest performers. For some it is A=440, others 443,444,445... Some Early music ensembles perform at other reference pitches for a variety of reasons we needed elaborate on (A=395, 415, 435, 460..) but should mention. >>>as "A = 440", meaning that the note A >>>in the treble clef indicates a sound >>>that has a frequency of 440Hz. have we established a standard for pitch notation? A4 is what we are discussing here. >>>There are other standard frequencies, >>>but they have mostly fallen into disuse. HAH!! tell that to the academy of ancient music. Clients of our software are playing in some of those ensembles! >>>Instruments with a single sounding part (woodwind, brass) follow a >>>different convention just one? > Or we can > simply point people at the Wikipedia entry for "concert pitch", wiki is a moving target of varying quality, this topic is not evolving so fast that we cant maintain, and we should be self-contained. >>>1.311 transposing instrument >>> >>>Instruments whose notated pitch is different from concert pitch. mmm, better might be to begin with the reason for the convention. -=-=-=-= Many of the instruments of the orchestra are available in different sizes, each with a differrent fundamental pitch; we speak of them collectivly as a family, and the fundamental pitch is nominative, eg, a Trumpet in Bb, a Horn in F, a C Clarinet. An experienced player with skill on one size of instrument can often play the others with similar skill, but is challenged to read for each of several instruments. One solution is the convention of transposed parts. One instrument of each family is taken as reference, all music for it is written at the sounding pitch. Music for other members of its family is written at a transposed pitch, so that when played as if it was the reference instrument, the notes produced will be as the composer intended, and the musician needs no change in reading skills. As an example, C Clarinets use music written at pitch. Music for a Bb Clarinet is written transposed up by a second so that the note read (and fingered) as 'C' will actually play as the 'Bb' the composer wanted. -=-=-= been a while since I read a list of which instruments employ transposed parts, maybe just simply list em and leave it at that. > the note whose wavelength is equal to the length the mathematical design of instruments is way beyond scope. The stuff of multiple doctoral dissertations when done up properly. End corections and all that. those who doubt me can go look up some of the literature - Benades several tomes of course, but also Cornelius J Nederveen, _Accoustical Aspects of Woodwind Instruments_ rev ed ISBN-13: 9780875805771. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Music Glossary - 1.64 Concert Pitch (2.12.2)
> I think a problem with those sections is that they mix several > different concepts in a jumble. yes. Dont have the OED handy, this library is very small and lacks a copy, but the dictionary in my mac and the larger one from the shelf both give narrow definitions for the entry 'concert pitch', eg, a=440, internationally agreed on, the pitch at which orchestral instruments are tuned. Neither entry discussed the convention of transposed parts. I suppose the 1960 ISO agreement has to be understood in context. Also, please note, ISO standards are not laws, just a formalized understanding of how things can be done. Just because there is a standard for what means 'inch' and another for 'meter', nothing prevents me from working with brunswicke inch when working with the drawings of Hioronymus Praetorius from his Sytagma Musicum. Yes, whatever meanings our documentation uses for the term 'Concert Pitch' should be discussed in this entry. I appologize for not realizeing my own understanding of that term was narrow. > Concert pitch is simply what the non-transposing instruments play, > when presented a notated note. I now see two meanings. First is the absolute pitch meaning, a concept somewhat misleading for predating the early music movement. Secondary usage draws on the first meaning and contrasts the actual sounding pitch with the notated pitch which differ for transposing instruments. FWIW, I recall a recent article in Early Music America (might be posted online, they have a website) discussing the use of varying reference pitches. > Orchestras can adjust on the fly well, they can try, some instruments will have more trouble than others. unfretted strings and brass have the most flexibility as they are always challenged to play in any particular temperament. Some winds can attempt embouchure changes, the horn has his fist, but woodwinds trade off alacrity when having to bend notes by alternate fingerings or embouchure. The crumhorn, serpent, and cornetto all have notorius flexibility. Its the continuo section where we find the least flexible instruments. > Pianos are tuned with > scale stretch in order to compensate for inharmonicity. and how 'best' to do this is subjective, varying with each concert artist and concert tuner. > The transposing instruments play a pitch other than notated. true when the convention is followed. As our trombone player has noted, some players have to get used to multiple notations. Viola and cello players have to cope with floating c-clefs; Alto recorder players have to work from g2 clefs, floating c clefs, and octave-below g clefs. I have a music engraving reference at home (Ross comes to mind as the author) which gives a fairly complete list of transposing instruments, will try to remember to bring it tomorrow. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Off topic, Was: Music Glossary - 1.64 Concert Pitch (2.12.2)
On Sun, Apr 5, 2009, Mats Bengtsson said: > A flute playing friend of mine once demonstrated what happens if you > drink a bear LOL I envision Brutus sitting on a keg, playing the flute and passing gas from both ends. SKOAL! -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Concert Pitch (a second try)
On Sun, Apr 5, 2009, "Anthony W. Youngman"
said:
> Okay, we've got more feedback (isn't this fun :-).
welcome to electronic commiteedom :-)
> 1.64 Concert pitch
>
> The convention (standardised by ISO 16) that A above middle C represents
> the note at 440 Hertz. This is commonly notated by the statement
> "A=440".
slight rewording -
The Convention (formally affirmed in 1975 as ISO 16) that musical
instruments shall be designed and tuned so that A4 ('A' above middle 'C')
sounds at 440HZ, Concisely phrased as "A=440".
> There are many other conventions, such as "diapason normal" which was
> established by French law as "A=435". Many of these conventions have
> fallen into disuse, although there are orchestras which typically tune
> to other pitches (usually pitching A slightly higher in order to sound
> "brighter").
not quite on the mark for me.
Other reference pitches have been informally adopted and even legislated,
most are now disused, but several orchestras and ensembles specializing
in early music adopt other reference pitches better suited to the replica
instruments they use. Some modern orchestras perform at slightly higher
pitch (eg A=445) on the theory that "the violins sound brighter"; to the
consternation of the wind players.
Thinking conservativly, maybe we can leave off this last sentance. Its
true enough, but perhaps inflamatory?
> Regardless of the exact frequency of A, instruments which play the
> standard frequency upon reading the note A
only the note A? h.
Sorry to keep beating this horse, but it aint dead yet. I think the
discussion is much easier to introduce with a little background, something
like this.
Many Orchestral instruments developed as families, varying by fundamental
pitch. Composers will often take advantage of the contrasting tone colors
of these otherwise similar instruments, players have to be capable of
reading for each of them at sight. It is challenging to maintain sight
reading skills on several instruments, eg 'C' Clarinet and 'A' clarinet,
where a particular note, say, D4, has different fingerings on each. The
convention of writing some instruments parts in transposition is employed
to deal with this.
Certain instruments within each family are selected by convention to play
at the pitch that is notated, they are said to be 'in C', or 'at concert
pitch'. Music for the other menbers of each family is written transcribed
by an appropriate interval so that the fingerings, slide position,
valveing or whatever technique is associated with the written notes will
always be the same, and the piches produced will be as the composer
desired. The player reading from a transposed part pretends to be playing
an instrument 'in C'; assuming the part was correctly transposed and the
player has the corresponding instrument in hand it all works out.
> Typically, these are instruments
> with multiple sounding parts such as tuned percussion or strings.
my first thought for 'tuned percussion' is tympani (which jars against the
concept of multiple sounding parts) maybe a more specific example?
... such as Marimba, Harp, Viola.
> These are typically instruments with a single
> sounding part such as brass and woodwind.
Counter examples are Guitar and Lute, both of which have awkward ranges
and use an octave G clef when noted in staff; often employing tablature (a
sortof transposing notation) to facillitate reading when used in families.
Do we need this at all?
> See also: "transposing intruments" and wikipedia entry
for concert pitch 'A440'.
-=-=-=-=-=-
enough in this post
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Concert Pitch (a second try)
On Mon, Apr 6, 2009, "Anthony W. Youngman" said: > Sounds good. one down? !!! > I think it's your use of "informally adopted" that jars - it implies > that they've ignored the Standard, when the standard didn't even exist > at the time. didnt have any one particular standard in mind; when one has church bells ringing hours, and no better standard, one might 'infomrally' use em for a reference, lord only knows how it was done in days of yore; the receipt of a chest of Bassano recorders might well establish a new standard for the players using them (no adjusting them, no joints) whatever strings played with that consort had to conform. There have been regional standards coexisting, the french and the austrian have been mentioned. I simply wanted to imply that it doesnt take an act of legislation, a papal bull, or an internatinoal conference to establish a conventional pitch reference. > What about those families (ie pretty much ALL the brass instruments) > that don't have a member at concert pitch! Perhaps the scribes got tired of writing out parts for them? > Interestingly, nearly all transposing instruments are fairly "new" in > their modern form. The 13 key clarinet is contemporary with Beethoven as I recall, the too-damn-many keyed clarinet is somewhat later. In between we have cases which provided for more changes of body than one sees instruments in the orchestra; each with a need for transposed part music. > I suspect the reason the trombone is such a funny > instrument in that sense is that it is an old instrument (which is why > it's written at concert pitch) some professional Sackbut players were probably musically illiterate, notation being such a mystery then, I know I find Gafurius et all totally baffling in places (proportions described using roman mathematics is indeed mysterious). Others claim that it was common practice to read waits music up a fourth or down a fifth as suited the instruments available. i know I have sometimes had to do the like in informal recorder consorts when the forces did not matchup well to the music available. > The word "tympani" is plural :-) so it is. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Concert Pitch (a second try)
On Tue, Apr 7, 2009, Hans Aberg said: > On 7 Apr 2009, at 08:18, Peter Chubb wrote: > it is transposed twice in opposite > directions: first by the composer who writes the sheet music actually, the composer usually scribbles all the music in score at pitch and leaves part copying (with appropraite transpositions) to a specialist who has a good hand for the job (these days a computer). It is a rare composer who can get away with putting his own scribble on the stand of a union musician. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Concert Pitch (a second try)
On Tue, Apr 7, 2009, "Anthony W. Youngman" said: >>So do we care what reference concert pitch uses? Does it matter if it's >>A=440, or A=445, or A=450? > > It does matter that the reference is accurate. it also matters that the 'Standard' is not always observed; especially for the music of Mozart and earlier, which is very much of interest to us and our users. >>2) Transposing instruments use notation relative to some other frequency >>standard, such that a C in the transposing instrument notation is the same >>frequency as the transposing instrument's note in concert pitch. !?! the concept of transposed notation is never easy to explain, I dont thnk it is possible to do it briefly. Much easier concept to introduce from an historical perspective, given a couple of whys to hang things on makes all much more easily understood. >>It seems to me that all the rest of the information is more than is needed >>for the LilyPond glossary; it's available in some other music dictionary. I tried to find a list of transposing instruments in my home library, nada. If we do it and get it right it will be a service to our users; and to ourselves should we ever create a part extraction from score feature. > But a little extra information always helps. hear! hear! Yes, new concepts sometimes need a bit of dancing around to be fully assimilated. > And, while I don't want to plug my instrument as an example, I've come > across too many cases here with lilypond and elsewhere where people > don't understand how to correctly notate transposing instruments, that I > think a bit of extra information is important. fully agree. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Concert Pitch (a second try)
On Tue, Apr 7, 2009, Peter Chubb said: > Here's my rough try at the three entries: kudos Mr Chubb, trust the son of a son of a scoundrel... I like em all, but as usual, i do have a couple of quibbles. > Notes like a, b, c etc., describe a relationship between themselves, > not an absolute pitch. The nature of the relationship is the > so-called temperament (q.v.). is the above needed at all? > To be in tune, a group instruments must agree > on the relationship between pitches *and* the absolute pitch of one of > the notes. In recent times that pitch, `concert pitch' has been > defined as 440Hz for the A above middle C, with other notes arranged > according to the temperament being used. 'arranged' strikes me as a little off somehow, maybe my confirmed inner batchelor is shivering in fear; perhaps 'disposed', 'tuned' or 'pitched'? we know when and by what body; might as well cite it. 1975, ISO 16, an international standard. Could mention that equal temperament is the common understanding. It doesnt affect the notation, only the tuning. > Temperament: the relationship between different pitches in a scale. > In the simplest case, an *equal-tempered* system has notes whose > frequencies are in the ratio of the twelfth root of two. Such a > system always sounds out-of-tune, because thirds, fourths and fifths > are not exact ratios. However it is widely used because all notes are > equally spaced, regardless of the starting note of a scale. Not sure equal temp is the simplest case, common yes. I would think natural to be the simplest case, and let the a-capella group drift as it will while following it. This is a toughie to do full justice to briefly, and the details are OT for our context (notation). Maybe expand a tad by nameing some of the scheme. > Transposing Instrument: If an instrument is usually notated at a > pitch other than its sounding pitch (whether out of tradition, or for > the convenience of the player) it is said to be a *transposing > instrument.* Bes and A Clarinets, many brass instruments, and some saxophones > are transposing instruments. Usually it the music which is notated? some brass instruments are engraved about the bell, but still :-). perhaps this - An instrument whose music is written transposed from its sounding pitch .. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
On Tue, Apr 7, 2009, Patrick McCarty said: >> Is there an easy way to address this? use a programming editor. tabs were invented at a time when fixed-width was the norm, high-speed printers and teletypes had no other way to put ink on paper. back then, the tab stops were 8 chars apart. Programmers today more often use stops at 4 characters, however todays fonts thro a monkey wrench into all this with proportional fonts. Programming editors are available for both mac and windoze systems, if you dont have one available try a normal text processor and use a mono-spaced font. As to LY not accepting tabs, thats a shame, tabs should be treated as white space, along with and other now-disused characters from the days of teletypes which sometimes find their way into ascii files from odd unix and dos systems; this is done in the postscript language. Except perhaps in lyrics, where they might well be used to demarcate syllables. > I don't know what editor you're using, but with Vim you can search for > `\t' to find them. many editors will have search and replace, some even have grep-like capabilitys. > I've struggled with this in the past until I realized that a normal > tab is equivalent to *eight* spaces. not exactly, each tab is one to 8 spaces, enough to get up to the next tab stop; unless the editor that created the document was set so that tabs are 4 spaces of course, in which case it is 1-4 spaces. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reducing ps file size (please comment)
On Tue, Apr 7, 2009, Mark Polesky said: > Short version: I made some changes to output-ps.scm > that can safely reduce the file size of ps files. In > a simple experiment, I was able to reduce non-binary > ps-code by up to 10%. PS code is notorious for being voluminous. Most of the time the stream volatizes in the printer and noone cares beyond maybe some foot tapping at the printer waiting. binary inclusions such as fonts or illos are usually the biggest cause of bloat. now that so many cheap laser printers sans PS rips are on the market even that is less of an issue as the computer/printserver RIPs the PS code and sends image data to the printer. A significant reduction in actual code can be had with careful use of a private dictionary, sometimes just using shorter names for common operators can help a lot (eg, mt for moveto), but also creating new operators for common operations (such as positioning note heads). -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: reducing ps file size (please comment)
On Wed, Apr 8, 2009, Mark Polesky said: Would reducing ps excess reduce compilation > time? Or would the difference be negligible? PS code is not usually compiled, it is transmitted, parsed, and executed. Adobes manuals make it clear that the defined operators are deliberatly given long spelledout names for clarity of semantics and efficient use would include the use of private suites of operators, even if only to provide concise aliases for the most used operators. Several of the early Macintosh PS-aware applications took advantage of this to some degree, including the Laserwriter print driver. One of my projects used Deluxe Music Construction Set as a WYSIWIG front end to produce EPSF of short musical excerpts for inclusion in a MS Word produced DMA defense document. Printing to disk gave me files of PS code which included several fonts as well as the illustration code. Original files were about a megabyte in length, final EPSF was usualy less than a kilobyte; a good thing because Word had an unadvertised limit (even second echelon TS didnt know about it) for how much PS code you could have on a page. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
On Thu, Apr 9, 2009, Graham Percival said: > I can see it now: CARBON-BASED LIFEFORM WITH A RELATIVELY SHORT > LIFESPAN ON THE COSMIC SCALE/LilyPond. Apple deprecated Carbon development some years back. My vote is BBEdit. Lots of programming editors offer syntax coloration and formatting for a surprising variety of languages. Maybe what is needed is a survey and recomendations? Mac programmers will have certain choices, in my case its the ancient Codewarrior IDE, MPW, BBEdit, and Xcode 2.5. Might well be others. Windoze developers have several more to pick from, CodeWarrior and XCode included as both will do x-platform development. I suppose unixland has emacs, "pity the fools" -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tab characters in the source code
On Thu, Apr 9, 2009, Jan Nieuwenhuizen said: > No, but that's why I propose to first start our Zebra group and > figure out coding standards. It's about time we got some, no? coding standards, yes. But as to animals, we probably should contact O'Reilly publicatinos and ask to be assigned one, pretty sure zebras been assigned, ana I think frogs have been taken tho. AHA, we could consider beasts as drawn on old maps, whales, dolphins, lots of hoary depictions to choose from there, and all old enough to be PD. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lyrics for right-left writing systems such as hebrew or arabic
Dumb question, some (perverse?) writing systems are contrary to western music notation, assuming we allow full unicode lyrics, how does one set hebrew or arabic lyrics to western music? Only way I can think of is to (have the user) transliterate phonetically into the roman alphabet, as in - hava nagila, hava nagila... I realize this presents certain cultural issues, but what is a music typesetting program to do? I suppose it could be rewritten to set the music right-left, but that could be a bit challenging to the members of the band... -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lyrics for right-left writing systems such as hebrew or arabic
On Sun, Apr 19, 2009, Richard Schoeller said: > One common approach when combining a right-to-left language with > left-to-right musical notation is to render each syllable of the lyrics > right-to-left but have the overall flow of the music left-to-right. I > haven't tried this with any of the stuff that I've done (I present the > lyrics in transliteration). So, I can't tell you how well this works in > LilyPond. However it is done, and by whatecer program, there are some pretty hefty issues for position-contextual writing systems such as arabic. Arabic letters have variant shapes when used in different positions (opening, middle, closing); fragmenting a wordd into sylables exposes middle letters; not at all sure the common reader is used to seeing that. Further, when placed correctly under the music they will be presented in backwards order: hava nagilla is shown as ah - av_ an - lig - al_ which is less of a challenge for a markup-based entry system like lilypond than it is for a GUI-based system that attempts WYSIWYG editing of the lyrics in place (of interest here should we someday go for that). The challenge being to re-order the syllables (unnaturally) as the user splits the words for us. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (c) does not equal "copyright"
On Fri, Jul 17, 2009, Mark Polesky said: > > Is this something to address? Depends on how much value is placed on the copyrights, and the legal validity of gnu's viewpoint (which I am not disputing, I have no particular knowledge of copyright law). At issue is the prospect of someone winning a court fight and establishing their copyright over ours to the detriment of the project as a whole. Legal battles such as that are always expensive and sometimes unwinable for the cost. >A lot of LP source files use (c) and not "Copyright"... Shouldnt be too horendous to go over the source using BBEdit or the like looking for first instances of (c); yes, there might be false hits on the variable c being fed to a function, so dont do the replace blindly. Probably should do this with the goal of establishing a standard declaration in every source file that supports comments. Apples XCode 2.5 generates 'empty' project source code files with some initial commented content including the following: // Copyright 2009 __MyCompanyName__. All rights reserved. Note that __MyCompanyName__ is an automatic variable which substitutes text taken from the addressbook if you have made an entry for the logged-in user. The barn door has been open as long as the source has been available for download. Unfortunately, it may be that ly is ported to some system which insists on ascii-7 source code, so we need to go with english prose to be conservative until we are certain of a universal support for unicode in comments. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (c) does not equal "copyright"
On Sat, Jul 18, 2009, Hans Aberg said: > ask them to provide proof that you were the > clicker. can we afford to pay the legal fees associated with the asking of that question in court? Why waste time debateing? find a willing tadpole and turn them loose. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
> If this were strictly a tablature issue, I'd say keep it at "dead notes", > since that is the guitar term. but what of citterns, ukes, banjoes and other modern plucked instruments who would (do) use tablature notation? BTW, its been several decades since I was actively consulting tutors on classical guitar (my first serious instrument), but I do not recall any mention of 'dead' notes, tho from my singing experience I am reminded of 'morire', an instruction to bring the sound volume down to nothing (but not suddenly, not quite the same as damping a string). I should think harp would have terminology for playing dampened; maybe even harpsichord/piano pedaling instructions (or organ swell shade instructions) would be relevant. My druthers would be for 'muted' over 'dead' - more professional, and a better cognate. Also, lots more instruments gonna wanna be using modern tablature than just guitar - bass guitar, uke, cittern, bozouki, banjo. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.
On Wed, Jul 22, 2009, Trevor Daniels said: >> Anyway, I think that it would make a lot more sense if the staff >> were determined by the "average" pitch of the chord. And, I think >> I've solved this in the attached patch. What would make the most sense is to consider the range of the intended instrument. music for a mid-range instrument (eg classical guitar) is conventionally presented on the same suboctave G clef a tenor vocalist uses. Some music for low brass and winds uses c-3, c-4, and f-4 clefs. Hopefully these automatic clef changes are an optional feature, many players find any clef change annoying. > Also being able to specify a lower limit on the > number of notes/chords permitted on the staff > to be switched to, to prevent short runs, would > also be useful. What of music contrasting the extremitys of a pianos keyboard, is it always going to be coded as two strains of polyphony? (left hand vs right). If coded for one hand, no changes at all are apropriate there, just alternation as to which half of the combined staff is employed (allowing some few ledger lines). Look to the earliest publications of Ottaviano Petrucci (Canti C, Canti B, Odhecaton), available in facsimile at the best music libraries (and direct from Broude Brothers if you care to purchase) for examples of how rare clef changes were even when movable C clefs were the norm. Initial clef should be chosen based on overall range, proposed changes should be evaluated in the light of ledger line use. Knowledge of the intended instrument and modern/classical scribal conventions could expand the range of clef choices. Such fun devising heuristics. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] autochange.scm: Use averaged chord pitches to determinestaff.
On Wed, Jul 22, 2009, David Kastrup said: > writes: > >> On Wed, Jul 22, 2009, Trevor Daniels said: > There are instrument-dependent "thresholds of pain" involved: singers' > clefs will just not change in midpiece. ... actually, speaking as a singer with decades experience, they do change for male voices in both historical and choral editions. Altos, tenors, and baritones have to be experienced reading in three clefs, tho changes are avoided, they are found at times. > But today's available clef choice is much smaller. Only when you exclude scholarly editions; those involved in early music must walk both sides of the fence. But when commercial interests enter the picture, yes, challenging the reading ability of the targeted customer is a nono. Thankfully we are talking an option, good to have options. I like the concept of a list of clefs, and a set of penalties for different situations suggesting a switch. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (c) does not equal "copyright"
On Mon, Jul 27, 2009, Graham Percival said: > let's do it. I got busy and left off tracking this thread a while back, agree with you completely, simple, no-brainer to convert present sources. Having done that, there is one issue remaining, getting the standard disclaimer(s) into new sources. Those using apples XCode development tool will have noted that apple has a number of 'templates' with the oilerplate text in it, including some automagic for entering users full name and company name (from login and address book entries). unix hackers could use a shell script to do something akin. dont do development on windoz systems, dunno hat there is there, but even if its just a write-locked file that gets copied, and the ubiquitous readme to be ignored, it would help. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Wed, Aug 5, 2009, Carl Sorensen said: > > > > On 8/5/09 7:22 AM, "Trevor Daniels" wrote: > >>> >>> In the meantime, we can move forward on tablature. >>> >>> As I see it, the current decision causes problems only if we were >>> to change >>> to xHead in the future and eliminate deadNote. And I see no plans >>> in the >>> future to eliminate deadNote. >>> >>> Does this make sense to you? yes, it makes sense, but I perceive it as the wrong decision > I think it was a pity that the groundwork > for a more generic approach was not laid > down right away I concur with that. And I appologize for coming late to this discussion, jobhunting and speculative programming work has distracted me from following threads I should have taken more interest in. If dead-note marking was the only use for a cross-head symbol that would make this academic, but it isnt the only use. Percusion instruments are differentiated in condensed orchestral scores by a variety of note heads for each instrument shown on the common stave, and the cross head is used for that purpose (cymbals in the one illustration I saw online). Please dont rename the cross head, it has a name, predating any usage stemming from rock musicians jargon. That name is further 'blessed' by the unicode standard, "Musical Symbol X Notehead", 1D143. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Wed, Aug 12, 2009, Trevor Daniels said:
> function like all music functions is a prefix
> operator. Applied to a sequence of notes like
>
> \xNote { e f }
>
> it's fine, but
>
> c d\xNote e f
> < g \xNote c f >
Conventions aside (...like all music functions...), my preference would be
for postfix rather than prefix, the space separating the prefix operator
from its argument also distances them visually; as the example points out,
that can be confusing; the postfix operator needs no space and can be
adjacent to its operand; concise and intuitive. Subtle point.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support
On Thu, Aug 13, 2009, Graham Percival said: > On Thu, Aug 13, 2009 at 09:28:02AM +0200, Marc Hohl wrote: >> I mean, we code and read music from left to right, so >> it seems nore natural to me to have the command changing >> the behaviour of a note in front of it. Some like postscript and HP calculators (3 5 7 multiply swap divide), some , especially multi-lingual have trouble with operator precedence is (a & b | c & d). (a&b) | (c&d)) or (a & (b|c) & d) or (((a&b)|c)&d) or... Physical proximity provides an intuitive association that can be false, but is more easily seen than rule-based associativity. The use of '\' to preface both function tokens and operator tokens allows an omission of whitespace before the token, and this allows a left-associative operator to be adjacent to its operand. Both right-associative operators and functions must be setoff by whitespace from their operand(s) for the tokens to be distinguished. a b c d\lefty e f g (above) \lefty has an intuitive association with the d. a b c \righty d e f g (above) \righty is intuitivly ambiguous, (below), \righty has a false intuitive association with the 'c' a b c\righty d If all \foo were right-associative it would be easy to read them. Is it possible to make monadic operators right-associative so as to end this confusion? Yes, i realize this could have a nasty impact; if done at all it would mean devising a new set of right-associative operators and deprecating the old ones (never eliminating them of course, such being the fate of deprecated stuff). BTW, the average user lumps functions and operators together in his mind as thingys with similar syntax (\foo) that 'affect' notes. Unless the documentation stresses this issue with ample illustrations which are commented to this point it will remain a confusing muddle (do you _recall_ which C operator binds more strongly, left-shift, or prefix-increment?). -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Improved tablature support vs email
On Fri, Aug 14, 2009, Mark Polesky said: >> If all \foo were right-associative it would be easy to read them. Is it >> possible to make monadic operators right-associative so as to end this >> confusion? Yes, i realize this could have a nasty impact; if done at all >> it would mean devising a new set of right-associative operators and >> deprecating the old ones (never eliminating them of course, such being the >> fate of deprecated stuff). > > Imagine how convoluted the convert-ly rules would need to be... ugh. In an ideal world someone would have been thinking ahead from the start on how naive users perceptions were, but then, at first there was mainly one user, more concerned with his thesis deadline than anything else :-) > I was thinking about this earlier today, what are LilyPond's > "operators"? What distinguishes a function from an operator in the first place? http://www.answers.com/topic/operator#Operators_versus_functions had a discussion that surprised me. Wouldnt surprise me to find out that ly has implemented a private philosophy here tho. > * there are single and double angle-brackets here. Recently I've > noticed some e-mail clients and/or mailing list archives do > weird things with them (like removing them). thats a problem when we depend on this medium to communicate; ietf-822 etal define the packaging, not the content; leaving the world to its existing conventions and new ones to come. Luckily present email and list usage is for quotation, so only the characters beginning a line are at risk. We could employ MIME attachments and html or xml encoding as a work around. Used to be that signatures beginning a line with '--' was the only content convention, tho when usenet news decided to make quotes with lines prefaced by '>' and the block prefaced by a citation that set a trend which continues. Some client software employs other quotation markers in liu of seas of > some users have personal policys ... -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Breve with double lines on each side
On Mon, Aug 24, 2009, Reinhold Kainhofer said: > Regarding the single- vs. double-line breve: I have not yet found a reference > to the single-line breve. Only the double-lined breve can be found > practically > everywhere: > http://de.wikipedia.org/wiki/Brevis > http://en.wikipedia.org/wiki/Double_whole_note > http://www.music.vt.edu/musicdictionary/textd/Doublewholenote.html > > So, shouldn't we change the default to double-line breves? what, no print references? Ted Ross, (1970) _The art of Music Engraving & Processing_ shows both (also a white-mensural breve) on p A44. His single-lined one seems to me to have a thicker line than the double, but it could be ink spread. another sighting on A57, this time just the single line version. Earlier in the text he uses the whitemensural form (two vertical thin lines joined by a pair of heavy thick ones, the thins making 'ears' above and below; all not quite as tall as a full space). Unicode Music Symbols Page shows the double line at 1D15C. Not sure which should be prefered, but the double is clearly needed, and, at least at some point in the last century, the old form of the breve was clearly acceptable too, making three in all. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Breve with double lines on each side
> Am Montag, 24. August 2009 20:23:01 schrieb Reinhold Kainhofer: > Oh, I also wanted to attach a sample including this breve style, but > forgot. > It's attached now. The semibreve and minim note heads for the neomensural seem too small, compared to the breve and long. Were they reduced, or does this need attention? Further, all the historical fonts I have seen used diamonds for that notehead, ie, narrower than tall (perhaps 4:5 ratio); it was the scribal tradition, expected by the public and so copied by the fontcutters Le Be, Granjon et al. Look to the Notation article in Groves for examples. While in the library, also look for a copy of Mary K Duggan _ Italian Music Incunabula: Printers and Type_. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] Spanish updates to MG
On Wed, Sep 2, 2009, Trevor Daniels said: >> I've found that church modes are not translated >> ... Ionian, Dorian etc ... No need to translate them from Latin/greek into vernacular; just make sure there are entries in the glossary for untranslated terms. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative music font
> it would be nicer if Lilypond itself could centre the digits >> around the 2nd and 4th lines of the stave in the case >> where they're smaller than 2*staff_spacing > > Be sure to consider non-5-line staff situations. Character glyph could be raised above the baseline using a seperate coding point for the musical semantic of a mensural symbol - trick then would be to get ly to use that instead of the other. Leave the numerals alone for use as numerals (ms # and what have you), but clone the glyph (Fontographer had a way to copy the glyph leaving it dynamically linked). -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: final testing for 2.13.6
>>> To the best of my knowledge, nobody is working on the snow leopard >>> issue, so if you're at all interested, please do so. Snow leopard is getting pounded in the cocoa forums, too buggy for development use (typical for an apple .0 release). Maybe better wait for a patch release (or two). -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: developers developers developers
> >> I'm talking about developer tools. For example, some months ago I >> got the advice to use "grep" to browse LilyPond source code. > > BTW, have you found something better? for those working on a mac, XCode and BBEdit have grep-like facilities as well as project-wide search capabilities that report results in a list that is itself a navigation tool for the hits. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: developers developers developers
> Why do you think 99% of MS Word users are aware of only 1% of its > features? Autocad might be a better point of comparison. As to Word, I have been responsible for informal teaching of its use in computer labs, with clients that were on deadlines, many of whom had no patience to learn things that would help them beyond the absolute minimum to get done the work in front of them. I think of that as the myopic user; but it also comes down to a major deficiency in tech-writing. MS Word rovides numerous was of solving many common text layout problems, it is useful for books and grocery lists. Kinata and McComb 'Working with Word' eds 1 and 2 are sadly missed in modern editions; and even they, at some 600+ pp, were not exhaustive (postscript embedment was treated lightly). Frankly I think MS has really worked hard to dumb down Word and by shifting around the menus has even managed to give knowledgeable users (me) a challenge to find features we know are in there. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: developers developers developers
> As does M-x grep RET in Emacs. And it's variants like M-x grep-find RET > and similar. But Emacs can also navigate using tags tables, which is > more direct and makes it easier to find definitions. XCode keeps a table of symbols for all compiled files in the project, users can select the test of a symbol (os suspected symbol) and right-mouse-click it to bring up a context menu, selecting 'Jump to Definition' in that menu will bring up the defining file, be it a header or some code file. When the symbol has multiple definitions you get a menu to pick one. Nice tool, but some caveats to using it - projects under design add and remove files a lot, and this activity leaves stale entries in the table (new symbols are handled well). One can purge the table, clean the cached code, then rebuild clean to keep it up to date. BBEdit is not limited to project-registered files, its global search targets directories and can use grep or not as you like (grep takes longer of course). Well worth the modest cost, if you are using a mac. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: developers developers developers
> Yes, that suffice if you are looking for text.
> But if you are looking for function and class definition, reference,
> exception throwing places, macro expansion as tooltip etc. There are a
> lot of things a good development environment must do for effective work.
XCode does a good job for me of finding objc method invocations and
definitions (even in apples headers files). not using it for C or C++ at
the moment.
-(void) drawEachFoo: (NSArray*) fooList inRect: (NSRect) visibleBounds{...}
is found by typing a comment with the text - drawEachFoo:inRect: select
the whole phrase, right-click and select 'JumpToDefinition' as I mentioned
in a previous posting. Fast, looks up the method definition in a symbol
table kept by the project. Only works for project-registered files tho.
If the symbol is known to be apples (eg, it has an NS prefix) then its
even simp0ler, option-2x click the symbol and apples docs are searched to
produce a list in the doc browser.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code formatter
>> 2) many programmers view code style in a highly personal, >> quasi-religious manner. > ... >> ...Han-Wen and Jan have different views... Foe me its a matter of blocking the whitespace to to present the code in a way that makes it easier to understand. This is not easy to do with any automated tool. A project done by a one-man team sees a limited set of tools and has a limited amount of schizophrenia in esthetic decisions. When the product is ported to as many platforms as ly is you see all the toolsets and more. Fonts make a difference. Screen size and eyestrain influence choice of font and font size. Vendor coding style influences things too. Apple used to be rather cavalier about code namespace, they would use short common words for class, structure, and field symbols. With cocoa things are somewhat improved, NS prefixes everything new, and method names are verbose and attempt to be meaningful. The verbosity has a downside tho, many invocations are multi-line, especially when localized text is involved. > If the standard isn't even completely defined then how could the job of > code janitor be given to an inexperienced Frog? Actually, its a pretty good learning experience. > until an official LilyPond coding standard is > fully set in stone. IMHO that would be a mistake, for example, switch statements have a number of ways of being presented that are effective, no one way serves all code. >> Any automatic tool will have faults, including being unavailable on some platform now in use. I recall a movement sometime ago to mix code and prose commentary, making real tab stops available for the code, and also allowing illustrations. Guess it died a hard death. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Describing instruments
> Mats Bengtsson writes: > >> Graham Percival wrote: > >>> I don't think that lilypond should serve as a crutch to composer who >>> know so little about their craft that they write unplayable notes. >>> But if you want to persue this, feel free to write a music function >>> which checks the ranges (or anything else) and add it to LSR. is ly strictly a composers tool? There are also musicologist editors of editions, arrangers, part-scribes and even performers making private editions to consider as users. speaking as a player, mainly I work with editions of renaissance music, both tablature for plucked strings and mensural for winds and mixed ensembles. Quite a bit of that music was originally published for the marketplace of anyone who would buy it, to be performed on whatever ensemble was available. It is often performed that way today. it is a rare incunabula edition that limited itself to particular arrangements, the 3vv 15c polyphonic music of isaac, josquin, busnois, compere etc had a wide variety of part ranges and is playable on all sorts of winds as well as bowed and plucked strings - ATB, STB, SSA (TTB), AAT... Later music for 4vv, 5vv, 6vv+ and poly-choral settings was less wide ranging, but also remained varied; modern instrumental ensembles do have to consider ambitus at times even there. Some editions are kind and print part ranges so one isnt obliged to scan several pages and can just pick a piece or two for the sunday band to look at; other editions sport penciled showing the omitted information, along with custos and other performers aids. Ambitus information can be useful to the music director and the performer when printed on the TOC, or as a part of an incipit; I dont think it has much use to anyone when left on the console. There are several online references for composers that cover the subject of instrument ranges and capabilities; there is no one proper range for any particular instrument, not even the concert piano (concert grands are made with extended bass ranges). Some instruments are incomplete in fundamental ranges, others are limited in the hands of an ordinary player, but can reliably be taken higher in the hands of a virtuoso; giving different ranges for the section and for the soloist. Use of strict replica instruments for baroque and early romantic music brings problems with certain notes on valve-less and port-less trumpets, horns and trombones; 3-keyed clarinets and oboes (which lack trill keys, and will have a diatonic fundamental octave)). Alto recorders on certain models have nearly the range of a flute, other models only two octaves; this is because the alto size has natural hole placements close to where the players fingers want to be, and also have a wind-force requirement that is well-matched to the human players capability. Other sizes of recorder are not so generous, an octave and a seventh or 6th. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lettered tablature patch
> For example, the third fret on a Baroque > lute is indicated by "r" rather than "c", as "c" can easily be > confused with "e". not quite right. I know none of what I say below is new to you Trevor, just trying to present a clear picture for the other readers here. Baroque tabulature for plucked strings (it was used for cittern and guitar as well as lutes) evolves from the notations invented during the renaissance (before 1500). Three distinct major forms are known, each with subvariants which may have been inspired by commercial interests (circumvention of printing privileges) or are something akin to the folk process. Modernly we speak of German, Italian, and French major forms, with Polish, spanish, and Neapolitan subforms. You are working on the French form, which uses alphabetical symbols to designate frets. Renaissance players used scordatura much as todays guitarists use it, but generally the presumed tuning would have employed the intervals 4,4,3,4,4 on a six course instrument, instruments with 7, 8 or more courses had basses below that set of intervals which were tuned adhoc The tunings for citterns and guitars vary far more than those for lutes, it seems each publication had its own 'new improved' system. Baroque players had other tunings in use (I dont play later music, so I leave you to other sources for that information). Another difference lies in the use of an elaborate set of markings to indicate decorations such as backfalls, trills, mordents, shakes... These began to appear in late renaissance pieces and the markings and their meanings vary by the piece, by the scribe, by the phase of the moon... and are still a subject for interpretation today by musicologists and bewilderment to players. Lots of articles on this topic in EM, JLS, JLSA, LSAQ and other periodicals. The 'hands' used in england, france, and the netherlands at that time had all the letter forms we use today, but some letters were used differently than we are accustomed to today: i and j were not distinguished, readers saw them as graphical variants on the same letter. Miniscule 'c' had a form that modern eyes see as miniscule 'r', but it was understood as the letter c by both those writing and those reading it. The 'r' used then was quite different than it is now, and had several forms, one of which is like a z, others a high-tailed w or u. Lutes were 'short' necked, generally, they had no more than 12 frets with 8 or 9 being tied on, the rest glued. Citterns were longer necked, tabulature for them requires 20+ fret designations. French tab designate frets using a letter sequence that omits your choice of the letter pairs i,j and u,v. Most of the printed tablulature employed special fonts with symbols devised to be distinct; many of these were incomplete, especially my favorite, cut by Granjon and used by Fezandat, Le Roy & Ballard, and others from 1551 on into the 18c. lute - a,b,c,d,e,f,g,h,i,k,l,m,n cittern - a,b,c,d,e,f,g,h,i,k,l,m,n,o,p,q,r,s,t,u A complication remains for citterns which employed fixed frets and had intonation difficulties under the modified 1/6 comma meantone tuning one sees in the few surviving instruments; these difficulties were tackled by omitting frets 4 and 18 altogether and using partial frets in a variety of patterns that was mostly chromatically complete for upper courses, but diatonic for the lower courses. Just to make life interesting, there are also surviving instruments which are fully fretted. [c] (Actually it was originally a Greek gamma...) I wonder if it is fair to make that connection here as if it was a deliberate choice by the inventor of the scheme of french tabulature. The same glyph is seen in court-hand which was the common hand used for prose (not music) from late 15c well into the jacobean era in england, france, and the netherlands. I note that greek preexisted roman, I postulate a much older connection between these two letters, each the third in its alphabet; I think it most likely that the reader simply had eyes used to seeing a gamma-like 'c' Trevor, the following booklet was helpful to me (not expensive either). Google the ISBN and look for the WH Smith link Alf Ison, _A Secretary Hand BC Book_, Berkshire Family history research Centre, Yeomanry House, 161 Castle hill, Reading, RG1 7TJ ISBN 0950836605 It should be noted that the set of symbols used to designate frets often requires ligatures, and will be best served by a list rather than some calculation scheme. Some of the common lists might be predefined and invoked by reference, but the ligetured symbols might not always exist in a unicode font, so reference to a particular font (supplied by user) might be needed. Yes, not for French, altho bass stops will be a challenge (/a, /b,/c.. //a, //b, //c ///a...) as will free bass strings (/11 ..) Italian will need more than numerals when you get around to it. Frets beyond 9 are designated in a variety of ways, dots over an X, or other
Re: Add option to indicate frets by letters in tablature (issue164063)
> I fully agree with your point in general, but we need > to think of a variable name other than "string" for the > string on an instrument. I tried, and failed :(, hence > str. String is only completely correct for instruments like violins that have a single string per course. 'course' is the more general term for a group of strings that are sounded together. > Hhm, I'm not so sure about this. I had envisaged changing > only the c to r, leaving all letters beyond c to default. I dont understand this insistance on misreading gamma as r. It was not written as gamma, the letterform used was always understood as 'c'. It should be read today as c, and is most logically encoded as c. Yes, naive musicologists and new players might take a while to get used to the idea, but no experienced player reads gamma as 'r' to my knowledge. Go this way and you make a nightmare for possible analytical use of music thus encoded. 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. > 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). J Wolf Handbuck der Notationskunde (2vv, ca 1926) and Apel _Notation of Polyphonic Music 900-1600_ are the two standard references. Groves Dictionary of Music and Musicians (22vv or 26vv edition) 'Tabulature' is a lengthy article also worth having a copy of. -- 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)
> 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)
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)
>> 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
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. That is the practice I recall from my time typing others doctoral thesi. Sadly it is not the norm for html or many modern text-setting applications which ruthlessly trim spaces they deem superfluous. I have even seen its use flagged as an error in some cases. I do not know if it is a practice limimted to english publicatinos, perhaps it is only certain publishing houses practice (NYTimes, Chicago, MLA...). -- 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)
> Check out > 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 line above that has a better exemplar, at the text "ac domos" I have no trouble 'seeing' that c as a c; this particular form of blackletter is not as difficult as some others. Besides, the issue is courthand, not blackletter. > The Latin script does not have "j", "u" or "w" IIRC. Which latin? It varies over time. During the periods we are concerned with it had all those forms and more, but was developing the modern semantic we associate with each of what used to be variant forms. Note that there used to be variant forms for certain letters depending on where they occurred in a word - short s and tall s for example. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: midi elapsed time markers
> I was thinking of something as simple as using the number of beats > per minute (\tempo ... ) and the the number of beats per bar to work out > the elapsed time. Obviously this gets more complicated when taking > tempo changes into account and any partial bars and repeat sections, which can get rather elaborate. Dont forget the use of mixed time signatures for many renaissance works and other pieces with complex rhythms (eg, 34/44 some bars are 3/4, others 4/4. Should white mensural notation be supported sometimes in the future you will also have to deal with proportional changes in tempo and both a lack of barlines in general or a casual disregard for where they are placed in original sources. If this is to be done it should be done by consideration of the note durations. Perhaps the midi pass could be done before the printing pass and output a side file. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: tabFullNotation and ottava
>> Actually, thinking about this some more, do ottava >> symbols make any sense in tablature? none at all. tablature tells you where to put your fingers to get the notes, not what notes need playing. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
> But LilyPond already has an extensive code and data structures base. To use
> data structures or code that are not compatible with the LilyPond paradigm
> is not wise.
What is wise is to bow to the users expectations, not twist their mind.
User of tablature is thinking of where to put the fingers, which is
a stream of
{ [flag], {fretlist} }
for italian and french notations, with the fretlist ordered by course
and a stream of
{ [flag], {fretCoursePolyphony-row1, -row2, -row3, ... }
for german, with course implied by the fretglyph encoding.
> I see nothing in this tablature that can't be done in LilyPond. I also see
> that this tablature is much more beautiful than the current LilyPond
> tablature, and can see why you want to improve the LilyPond output. Thanks
> for sharing the vision.
YW, please notice that besides the form differences, there have been a
number of fonts used historically, I have made replicas using
Fontographer, and will be tweaking them to serve Ly use.
> Adding the extra offset from the glyphs automatically should be a relatively
> easy thing to do in LilyPond, and might make an excellent way for you to get
> started on creating the features you want. Looking at this output, I
> suspect that the glyphs have been offset to put them in the spaces of the
> tab
yes, I see where that could leave the stems mispositioned as they are.
The fellow doing that illo has gone on to correct the 1 and 3 lines flags.
Once I get the docs unrolled from their tar balls... (chicken n egg
problem, libraries dont have untar utillities n frown on installs on their
virus-free machines...).
> (which is what the most common popular music
say it, Mel Bay editions :-). I have a couple for banjo.
>>> it would seem to me to be more robust to enter fret, course, and
>>> duration.
right, I was distracted by thoughts of german tab (ugly stuff that).
> You might consider that if you run into difficulty, if you're using the
> standard parser
yes, i see that, and it could work well for 6-course lute tab and cittern
tab (4-6 course instrument); but there will be aspects of the notation
which simply wont have equivalent data, so maybe in stages.
> If you leave the parser alone and write Scheme code
a clue to where 'scheme' code is described would be welcome, unique to Ly?
elsewhere?; in the doc package I have?, somewhere online?
> I'll look forward to seeing how you choose to move forward on this. I
> think it will increase LilyPond's appeal as the premier music engraving
> software.
priced right I think is the major claim to fame you can honestly make, its
got a ways to go before the other is clear to all.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On Tue, Dec 9, 2008, "Carl D. Sorensen" <[EMAIL PROTECTED]> said:
> On 12/9/08 4:37 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> You're confusing users with developers. Code and data structures are
> developer-only items.
yes, but the data structures my code needs are tablature-oriented, not
staff-oriented; for a straight printout I need pretty much what the user
entered. For a translation to staff, or to another tab form I need that
same data.
> Code and data structures should be compatible with existing LilyPond code
> and data structures.
compatible, yes, equivalent, I think not; but I have to take a peek at
what you have, and that should be pretty soon, the untar utility is
downloading now.
Maybe I could have gotten more smaller stuff, but the tarball is what I
saw, it came down in minutes and is there, so no biggie.
>> User of tablature is thinking of where to put the fingers, which is
>> a stream of
>>
>> { [flag], {fretlist} }
>>
>> for italian and french notations, with the fretlist ordered by course
>> and a stream of
>>
>> { [flag], {fretCoursePolyphony-row1, -row2, -row3, ... }
>>
>> for german, with course implied by the fretglyph encoding.
>
> Why isn't "where to put the fingers" a string, fret pair? That's what it
> seems to me. Then a duration would be added as well.
dur is given or implied by flag or most recent flag. It is handy to
seperate the optional glyph from its implicit duration, I do that in my
application, dont know if the like is done in Ly; cant see why it would
be, except perhaps for intermediate notes of a ligatured note in mensural
notation.
German tab is peculiar, unlike french and italian which use a short
alphabet to label the frets, german uses a much extended alphabet to label
all the intersections of fret and course. A single row of german tab
glyphs can do a drunken walk over the whole fretboard.
>> yes, i see that, and it could work well for 6-course lute tab and cittern
>> tab (4-6 course instrument); but there will be aspects of the notation
>> which simply wont have equivalent data, so maybe in stages.
>
> Won't every note you want to put on a tab have a pitch, a duration, a string
> (or course), and a fret number?
yes, but there is more than notes to be displayed. Fingering markup was
used historically, much the same way it is now, pedantically. RH marks
ims with one, two, three dots. LH marks with small letters or small
numerals so as to contrast with the fretglyphs.
> Right now, LilyPond has the built-in functionality to, given a pitch, a set
> of string tunings, and a desired string, automatically calculate a fret.
n, that makes german tab unpossible.
My assumption was that C++ was involved (as it is for me), the data
belonged to a tabStaff object, and it could interpret the glyphs as it
needed to. When asked for midi it would cycle thru the several rows
looking up the display glyphs to get {fret,course} for italian or french
it cycles thru the courses (rows) and looks in a shorter list of fret
labels.
german tab is nasty evil vile stuff to play from, transliterate, do pretty
much anything with except feed it to a computer (both the vast extended
alphabet and the fraktur fonts used by its printers offend every sense of
most players) "bad even for dwarfs"; but without support for it there is
no way to get it transliterated into users preference of italian or
french.
The row content in german tab is arbitrary, not limited to one course as
is french or italian or modern guitar; german mixes all the courses on
each of its display rows. Knowing where the glyph is on the instrument
doesnt tell which of the rows of german tab polyphony it belongs to,
leaving no way to display it. A mapping table associates each glyph to
the pertinent data of {course, fret} I think it is good to allow the user
to define seperate fonts and encodings for input glyphs and display
glyphs, that would be
inputGlyph associates to {outputGlyph, string, fret}
Yes, this implies that each tabStaff needs mapping tables (there would be
defaults, I use asciiTab defaults, not pretty, but sometimes what you want
for email or whatever).
> The first thing you will do is add the Scheme code to the LilyPond input
> file. Eventually, once it's debugged, it can be added to the LilyPond
> distribution.
>
> Since you put 'scheme' in single quotes, I suspect you don't know about
> Scheme programming. Scheme is a Lisp-like programming language.
()()((()))()()(((
I hope not, that kinda stuff leaves me with a headache, thank the gods for
programming editors with () balancing.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
German tabs origins are, like all the forms, obscured by time.
It is reputed to have been invented by Conrad Pauman, mid fifteenth
century, as a way to record music for short-necked lutes having 5 courses.
The notation was extended for lutes having 6 or more courses and more
frets, and we have lots of printed music and ms; but as each publisher and
scribe extended the notation in a personal manner there are variants.
An edition of M Waissel's music printed by J Eichorn in 1573 (Frankfurt an
der oder) shows the fretboard of a 6 course lute with one form of
extension. Note, the fingerboard is viewed from above; intersection of nut
and highest pitched string is labeled 5.
5 e k p v 9 -e -k
4 d j o t 7 -d -j
3 c h n s z -c -h
2 b g m r y -b -g
1 a f l q x -a -f
A B C D E G H -J
another printer (Heckel) and his inheritee (Jobin) uses the following for
6th course
-1 -a -f -l -q -x -aa -ff -ll
>From the first piece in the Waissel edition, "Pass e Mezo" (first row is
flags, giving duration)
1 2 2 1 11 2 2 2 2 2 2 1 2 2 2 2 2 2 ...
5 n 4 5 5 | 5 g 5 o d 4 n | 4 2 o o d 4 n | ...
d d 4 | d 2 | c c 2 | ...
n n h | n | D D | ...
J J A | J | | ...
which might be entered
// preface, 4 row german tab, glyphs detailed...
// hidden time signature common (often ommited, but used)
// ? hidden key signature c (tab lacks key sigs)
{1 {5,d,n,J}}
{2 {n}}
{2 {4}}
{5 {d,n,J}}
{5 {4,h,A}}
{thinbar}
...
While an entirely ascii based input encoding is feasible and protean, the
variety of german systems makes it desireable to allow the user to define
the entry glyphs (which will sometimes be ligatures).
Historical fonts are not always easy to read, typedesigners based their
fonts on the handwriting in use by the presumed readership. Civilte for
french and english tablature, Blackletter for german were common choices.
The results were good for historical readers, less so today when most folk
are accustomed to Roman; this challenges the user entering data from an
historical source.
Such a user can take advantage of a font similar to her source (I make a
few based on historical tablature fonts) when entering data, especially
for blackletter, in which case the encoding of the ligatured glyphs might
need to be specifyable; easy to do, an ordered list of the glyphs gets
typed at the same time as the input; no need to specify font.
I have a list of some more variant glyph lists for 6th and more course
german tab; couldnt find it in a short search at home, hope this is enough
for now.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On Thu, Dec 11, 2008, "Carl D. Sorensen" said:
>> // preface, 4 row german tab, glyphs detailed...
>> // hidden time signature common (often ommited, but used)
>> // ? hidden key signature c (tab lacks key sigs)
>>
>> {1 {5,d,n,J}}
>> {2 {n}}
>> {2 {4}}
>> {5 {d,n,J}}
>> {5 {4,h,A}}
>> {thinbar}
>> ...
> This syntax is
my meta language. Not intended for direct implementation, just for
thinking about the content and general form. Please note the use of
'might'.
> The ideal (in my opinion) would be to put tablature information right in
> with the music input
huh? the tablature _IS_ the music information. No way we should be
asking the user to do any translation from tab glyphs to pitch. Too many
errors, too much time, and, what the hell is the computer for anyway?
, so the exact same music expression can be passed to
> the tablature and the staff (that's how LilyPond currently does it).
IMNSHO it is most unfortunate that Ly is now abusing its users that way.
> it may be a little bit more awkward for the person doing the transcription,
a LITTLE? it is abusive to the person doing the data entry to have to
enter the same information redundantly in different forms.
> it greatly facilitates mixing tablature with staff notation.
if it is that badly needed internally than it can be calculated and used
internally.
> If you have no interest in doing the mixing, then it would seem to me that
> you'd be better off just writing your own tablature program.
Please recall that I have already done that. It doesnt do staff notation
(yet).
> I have a question, and it's meant to be sincere, not flippant.
> Have you ever set a piece using LilyPond?
The short answer is no. But, Liliypond tablature has been discussed on
the lUTE list, and one member has taken a simple example thru a couple
iterations to produce that which I cited here last week (and further); he
posted excerpts from its input encoding; no, I havent studied them in
depth or gone to the docs yet. I will do, but not right this instant, I
know they will be extensive. Understand, I have a life beyond this
project, including a jobhunt.
Turnabout is fair, Do you play from tab, have you ever transcribed from
staff to tab, or the reverse? I find transcription in either direction
needs writen translation aids and is highly error-prone; and that opinion
is shared by many on the LUTE list, including experienced musicologists
and professional players.
> The entry glyphs do not have to be the display glyphs!
true, and that is not what I said was desirable.
First of all, the display glyphs might well be totally different from the
entry glyphs; some users will want a transliterated version.
Data entry includes proofreading. Accuracy is greatly improved when
glyphs on the screen resemble those of the source. I would expect someone
entering greek text to be more facile with a greek font on the screen
rather than a roman one, no?
A common difficulty in reading from civilte-based sources (commonly used
by french and english printers) is confusion between 'c', 'e', and 'r'.
'b', 'k' and 'h' are also easily confused. Blackletter fonts are used for
german tab and are almost totally unfamiliar to many modern readers.
Historical tablature was printed with specially cut fonts, the glyphs are
taken from handschrift examples, with slight modifications, in some cases
vertically squashed, in others, ligatured as in AA, or overstriken,
underlined, overcurved. Glyphs for 'et' and 'con' are used. A specialty
font could be used on screen during input, but its encoding will not
always be supported by unicode (eg, have found 'et', but not 'con').
It the user is to be suffered to us arbitrarily encoded fonts for a visual
editing session, it is humane for us to provide a means for her to tell us
the encoding of those symbols she has typed; not a hugely difficult task
for us to use those lists to interpret the input stream I think, be
surprised if it isnt already supported.
> We don't enter half-note heads for music
no, you dont, (I defer the temptation to suggest you could to another
time). Judging only by a few examples of guitar-tab, I have seen a
numeric description of the duration as in 1,2,4,16... what for Longa or
Maxima? (I know, uncommon outside of scholarly editions); similar to my
enumeration of flag tails (itself limited to b,sb,m,sm,f,sf; all that is
seen in historical tab editions and ms), only slightly less intuitive.
> LilyPond *is* strictly an ASCII/UTF-8 based input format. There is *no*
> facility for changing fonts used for input.
DEFENSIVE you completely misunderstand me.
Not asking for a visual front end.
Not asking for cognizance of input fonts.
Allowing the user to type in whatever font they please leaves the problem
of how to interpret the codes produced. A tagged list provides us with
the keys to map that.
something like this (ordered by position-implicit key)
\flagGlyphList {𝅥, {𝅥 𝅮} , {𝅥
Re: Lilypond problems
On Fri, Dec 12, 2008, Reinhold Kainhofer said: > Should we change \bar "." to create a single > thick barline for reasons of consistency and instead add a new > bar line style \bar "dot" to create a single dot as a bar line? newbies dumb Q - will the switch impact extant user files? is there a way to do a broken barline? (maybe \bar "." ) Historical editions often used vertical rows of dots intermixed with bars to mark sections (not always being repeated) as in |:| or :|: or :||: perhaps an experiment will clarify the useage? -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond problems
On Sat, Dec 13, 2008, Dan Eble said: > I have a hymnal that uses a single thick bar line at a mid-measure > line break that coincides with the end of a line of the poem. I would have expected a hymnal to have been typeset, not engraved; far too much work and lower profit in it to be using engraving. Easy to find all kinds of odd bar usage in typeset music. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
thin bar lines are thinner than Henle...
While browsing the introductory docs I noticed that in those showing 'us' vs 'them' vs 'Henle' thin bars were same line thickness as staff lines in 'us' and 'them', but slightly thicker in 'Henle'. Perhaps some discussion would strengthen our claims. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
code comments (was Re: Scheme function to print out active Voice context during interpretation?)
On Mon, Dec 15, 2008, Francisco Vila said: > I have a question for the few developers that in some degree do > understand the source code and are able to hack it, fix bugs, > implement new features, etc. > > Is the code properly commented, so that (thinking on the future) new > people can learn from it without having to figure out all the time > what does each function, file etc. do? Newbie to the project, but one who has been programming since 1968, this is something I have discussed at length with other experience programmers. I speak in general, have yet to delve into Lp code at all, so please forgive if this is already covered by a project policy or perhaps a gnu policy. Good code commenting is a challenging skill, at its best the comments on archived code should Be accurate, uptodate, not telling lies. Explain why someone would want to invoke the code Describe context for use - arguments in, side effects, value(s) returned. Cite sources for non-trivial algorythms used, if original, publish a white paper to the project which can be cited. In many cases comments will exceed the code itself. Line-by-line comments are sometimes useful but should give information beyond the obvious. In a language like postscript the expected state of the stack is ofen a useful comment. Some projects embed text for documentation and help files with the code itself to encourage parallel maintenance. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: why is Dutch the default language for note-entry?
On Thu, Dec 18, 2008, Hans Aberg said: > If you want to fit all the world languages into one keyboard map, you > might join the Unicode list; there are more than 10 characters > available. Unicode is a good solution for recording the result internally, but as far as I know keyboard layout is still an open issue, with a variety of standards groups at the country level offereing script-specific solutions that are probably irreconcilable to any kind of universal solution. Last I knew (Mac OS 7) Apple had effective script-specific keyboard layouts for simple writing systems that allowed direct entry (once switched to), and employed special typing agents for indirect C J K entry. Could be worse, historical chinese typesetting not only required fluency, but also physical handling of some 60,000 individual 'sorts' of characters; imagine that set of cases. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: why is Dutch the default language for note-entry?
On Thu, Dec 18, 2008, Hans Aberg said:
> On 18 Dec 2008, at 20:40, wrote:
>> Unicode is a good solution for recording the result internally
> Right. So the best one can hope for is a series of keyboard maps that
> perhaps unify groups of characters, that those that so like may use.
The issue is to create a UTF-8 text file with linguistic content from
several writing scripts, right? Choose an OS and a text processor that
supports that and you have whatever you need for lyrics and other
arbitrary text.
Keywords are a different issue. Yes, it is a bit strange that parts of Ly
are english and other parts are not. Ly is the first programming language
I have seen which allows a choice of language for programming keywords.
Macintosh Fonts with unusual encodings (eg, IPA) can include a key-glyph
mapping table (KCHR reseource) that the OS automagically employs when the
typing focus is directed at a field employing that font ('Font' menu has
it checked). The KCHR resource is something human beings can create (with
effort) using ResEdit or Resourcerer; I think Fontographer will also make
one.
Mac, and maybe PC, used to have utillities which would allow you to
program the F-keys so they would execute macros (perhaps typing arbitrary
text). Might be that this is no longer feasible because of improved
memory protection under OS X, dunno. F1-12, hmmm, twelve keys...
> On the other hand, it is easy to switch keyboard maps, on mine it is
> .
Used to be cycled between installed scripts, rotating the
chosen font and associated KCHR. Confusing if you have more than two
installed.
> I do not know what they [chinese] use - check on the Unicode list.
I was refering to historical chinese typesetting, ca 1300 AD; before
computers. OT digression, sorry.
Google on 'Pinyin' gets hits on description of some of the Chinese input
methods for the terminally curious.
--
Dana Emery
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: why is Dutch the default language for note-entry?
On Thu, Dec 18, 2008, Graham Breed said: > 2008/12/19 Hans Aberg : Maybe there's a distinction between a "keyboard map" and "input method" here. definately. Keyboard maps eat multiple keystrokes in a declared sequence intending to emit the encoding of one glyph; all done transparently as you type. input methods are more intrusive, involve one or more windows and sometimes the mouse too; they can emit several glyphs when done. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
