Re: Translation string problem
2008/12/10 Carl D. Sorensen [EMAIL PROTECTED]: On 12/9/08 6:12 PM, Francisco Vila [EMAIL PROTECTED] wrote: Yes, because the problem is that explicitly created staves have to be given English names 'up' and 'down' if they are to be used for the autochange feature. This is illustrated with a single example in NR 2.2.1 after the warning Trevor wrote yesterday. Seems to me that to avoid this problem we should never have LilyPond names that are standard English words. I think we should change the defined names up and down to upperStaff and lowerStaff or something like that. Those names would be less confusing than up and down, and wouldn't be subject to translation, because they're not English words. Translation is not automatic, we translators do it. Any names you can imagine would be subject to translation as long as they are variables, comments, or context names and they go to the PO file. I must add that the mechanism implemented by John to translate everything inside the snippets works like a charm and gives to the docs a true localized feeling. -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
On 10 Dec 2008, at 07:40, Graham Breed wrote: Not using key signatures will not solve that problem. I didn't say anything about not using them -- although, as it happens, they are trouble in microtonal music. What I said is that they lead to confusion. The main point is that learning contradictory meanings for existing symbols has a higher cognitive load than learning new symbols. The advice is to check with the intended musicians and typeset what is good for them. Rather which accidentals do you use? It depends on what system you use, doesn't it? Relative Pythagorean E53 is easy. If one lets the letters C ... B stand for C Just major, then when changing to D Just major, then if one does not change the meaning of the letters, there will be a lot of funny accidentals. Then it is the question if musicians can work out such a thing - music is about playing notes, not frequencies. Incidentally, JI notations won't usually work with the Lilypond model because it only allows a single glyph for each alteration. Pure sagittal can still go a long way though. With the model I suggested, one can introduce a number of neutrals, and give them the same symbol. This might be useful when retuning. There is a principle of gravity http://www.maqamworld.com/maqamat.html Scale degrees could be used to create such a retuning effect. If transposition calls for say a comma below an m, and that m is computed not against E53, but E12, I think there might be an error. I leave it to you figure out. By contrast, if it is in E53, then I know it is right, and I do not have to do that exercise. Transpositions aren't computed against any equal temperament. If you transpose by a comma, then a comma will be added or subtracted from the previous alterations. The resulting alterations will be calculated according to the grid you specified. If you defined accidentals for them, those accidentals will be shown. Maybe there's an error -- if you find it, report it as a bug. I did it for E53 - it did not work. I attach a file. The difficult case is the most common one where a transposition moves from one scale degree to another. In this case it can be separated into a microtonal transposition -- specified according to the alterations -- and a diatonic transposition -- where Lilypond will use chromatic scale steps. A diatonic transposition will only lead to a change of alteration of M-m. (I hope this is obvious.) Lilypond will identify this interval as a half step and add or subtract 1/2 from the alterations. As long as you defined your alterations so that M-m=1/2 then all will be well. So then one must be able to have different values here. Since the name diesis has many uses, you will have to elaborate. Since even the name enharmonic diesis has more then one use even in a meantone context, I did elaborate. I got the definition wrong though, because I said it was 1 step from 50. It should be 2 steps so maybe that's what confused you. It's 1 step from 19, 31, 43, 55, and so on adding 12 each time. In M and m it would be 2m-M I think. Perhaps you mean the between a sharp and a flattened M, like between F# and Gb, which may be positive or negative. Since I do not impose any such relations, those are not confused. I'm not writing it. If I did I'd probably use Pythagorean notation with a comma accidental. So that would then work with the method I gave. I didn't say it wouldn't. But, in fact, it wouldn't. Your Pythagorean notation would make the comma below E indistinguishable from Fb. Why would that be: m and M generate the Pythagorean system, and it already contains a comma if you so like, but if the comma has different musical function, introduce a netral second to describe it. maqam53.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
On 10 Dec 2008, at 07:55, Graham Breed wrote:
I attach an example file.
I don't see any transpositions.
From what I recall, if one uncomments the key signature, lilypond
complains that it cannot handle the rational numbers. So one does not
get as far as doing transpositions. Otherwise, one could have written
\key b \bayati
I think it is the commented out part (long time ago), which for
some reason
only works with E24. Therefore, the keys must be written explicitly.
There's a key signature specification which does look like a bug to
me. I get the same result in 2.11.65. Have you reported it as a bug?
I think the reason is that key signature only work in E24. Then on
top of that, an non-transposable model for Turkish music was added.
But it isn't really transposed, so it is not a problem.
Some other things from your comments:
The maqamGlyphs list needed ratios because it's quoted, and so the
accidental lookup wasn't doing the correct match against the quoted
pair. I'm not sure exactly what the right hand side of a variable
assignment is, but this seems to work:
maqamGlyphs = #(list
(cons FLATFLAT accidentals.flatflat)
(cons FLATHALFFLAT accidentals.mirroredflat.flat)
(cons FLAT accidentals.flat)
(cons HALFFLAT accidentals.mirroredflat)
(cons NATURAL accidentals.natural)
(cons HALFSHARP accidentals.sharp.slashslash.stem)
(cons SHARP accidentals.sharp)
(cons SHARPHALFSHARP
accidentals.sharp.slashslash.stemstemstem)
(cons SHARPSHARP accidentals.doublesharp)
)
You say:
%{ Causes error in lilypond/current/scm/lily-library.scm:135:5:
In procedure ly:book-process in expression (process-procedure
book paper ...)
Wrong type (expecting exact integer): -5/3
%}
I don't see this error. Looks like a bug's been fixed.
It could have been fixed - it was in the beginning of this year.
Basically, the limitation on key signatures needed to be lifted by
admitting arbitrary numbers. Must try again some time.
Let me know how to do E53.
I'll look into it.
You can have a look at the attachment.
I have not asked for changes, have I?
What is the purpose of your being on the development list?
I wanted to drop off the model I gave to some developer, so that they
could think it was useful to them. The changes run too deep for it
making sense on any other list.
But you are not developing LilyPond either, right? - so my attempt
failed.
Then don't use E24 for Arabic music.
You already do.
I didn't think I used either Arabic music or E24 but I'll yield to
your superior insight.
A guy already implemented an official E24 version, so that what
people is gonna use. The accidentals derive from E24 notation, but
that is jut about it. In the sound examples I measured on
maqamworld.com, both Persian E53 and E12 is played.
Hans
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation string problem
On 12/10/08 1:37 AM, Francisco Vila [EMAIL PROTECTED] wrote: 2008/12/10 Carl D. Sorensen [EMAIL PROTECTED]: On 12/9/08 6:12 PM, Francisco Vila [EMAIL PROTECTED] wrote: Yes, because the problem is that explicitly created staves have to be given English names 'up' and 'down' if they are to be used for the autochange feature. This is illustrated with a single example in NR 2.2.1 after the warning Trevor wrote yesterday. Seems to me that to avoid this problem we should never have LilyPond names that are standard English words. I think we should change the defined names up and down to upperStaff and lowerStaff or something like that. Those names would be less confusing than up and down, and wouldn't be subject to translation, because they're not English words. Translation is not automatic, we translators do it. Any names you can imagine would be subject to translation as long as they are variables, comments, or context names and they go to the PO file. Then I imagine the problem must be that sometimes you want up and down to be translated, but not in the autochange snippet. So perhaps my suggestion should just be to change the defined names for autochange staves to upperStaff and lowerStaff so those words could be left out of the PO file. Or, we could just get the @KEEP LY working properly, which John has promised to do. So maybe my suggestion is not the right one. At any rate, I think we should have some system which does not require *any* exceptions to the documentation standards -- not even one, localized, commented one. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
On 12/9/08 9:51 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
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.
I hope you're not thinking about a separate input mode for each form of
tablature. I suppose you could be, but that seems like a nightmare to me.
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.
But this is still an *output* issue, not an input issue. Let the single row
of german tab glyphs do a drunken walk over the whole fretboard. Each glyph
has a meaning of (string+fret), does it not? And therefore if you have a
(string+fret) data structure (which LilyPond does), you have the information
necessary to recreate the drunken walk.
If your objective is to have the user type the tablature in directly (i.e.
some form of representing the exact output), then that's essentially the
equivalent of a graphical input for music, which LilyPond explicitly avoids.
LilyPond wants to have the input represent the minimum information necessary
to uniquely specify the content of the music (see
http://lilypond.org/web/about/automated-engraving/input-format). In my
mind, that is (string, fret or pitch, [finger], duration). Everything else
related to the output (german, french, italian, or modern style; sets of
flags to use, desired fonts, etc.) are not characteristics of the music
itself, but characteristics of the desired engraving, and are hence entered
separately from the music.
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.
LilyPond supports both right hand and left hand fingerings.
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.
Why?
You need to understand that when I say string, I mean string on the
instrument, not line on a tab staff.
But, if you don't want to use the automatic fret calculation, you don't need
to.
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.
Sort of. Music is parsed from the input into events. The events are passed
to engravers which produce the output.
The fundamental events for a tablature are notes. Notes have a pitch and
duration (which are used to create MIDI) and can have associated strings (on
the instrument, not lines on the tab), frets (on the instrument, not on the
tab), left hand fingers, and right hand fingers.
The tabStaff engraver will take the note data (pitch, durations, [string],
[fret], [LH finger], [RH finger]) and calculate what grobs (graphic objects;
glyphs occur in fonts, grobs can include glyphs but are more general) are to
be placed where. It can be written (although it currently isn't) to know
the different kinds of tablature and make the appropriate choices depending
on the
Re: Diatonic notation system
2008/12/10 Hans Aberg [EMAIL PROTECTED]: On 10 Dec 2008, at 07:40, Graham Breed wrote: Transpositions aren't computed against any equal temperament. If you transpose by a comma, then a comma will be added or subtracted from the previous alterations. The resulting alterations will be calculated according to the grid you specified. If you defined accidentals for them, those accidentals will be shown. Maybe there's an error -- if you find it, report it as a bug. I did it for E53 - it did not work. I attach a file. No you didn't. You did something else in E53 and that didn't work. There are still no transpositions. There are some attempts to get the MIDI output to work. Did it? It looks like you're on the right track. I wouldn't expect transpositions to work with this file because you've defined your flat according to an equal temperament -- exactly what I told you not to do. You've also specified fine tunings and not included them in the accidental lookup table so I wouldn't expect printed output to work even without the transpositions. Maybe these problems can be fixed but it will still mean different init files for printing and MIDI. Define the flat as a half step (-1/2) and the other accidentals relative to it. Then transpositions might work. Since the name diesis has many uses, you will have to elaborate. Since even the name enharmonic diesis has more then one use even in a meantone context, I did elaborate. I got the definition wrong though, because I said it was 1 step from 50. It should be 2 steps so maybe that's what confused you. It's 1 step from 19, 31, 43, 55, and so on adding 12 each time. In M and m it would be 2m-M I think. Perhaps you mean the between a sharp and a flattened M, like between F# and Gb, which may be positive or negative. Since I do not impose any such relations, those are not confused. Yes, that's the one. If you only record pitches with M and m they will be confused because m=m. The diesis above C# (let's call it C#^) will come out the same as Db. If I asked for C#^ maybe you'll give me Db. I'm not writing it. If I did I'd probably use Pythagorean notation with a comma accidental. So that would then work with the method I gave. I didn't say it wouldn't. But, in fact, it wouldn't. Your Pythagorean notation would make the comma below E indistinguishable from Fb. Why would that be: m and M generate the Pythagorean system, and it already contains a comma if you so like, but if the comma has different musical function, introduce a netral second to describe it. Yes, and a comma below E is the same as an M-m below F. If all you're doing to record pitches is storing values for M and m there's no way to distinguish E lowered by a comma (call it E\) and Fb. So my score might end up with Fb when I wanted E\. If you're doing something else you haven't specified it. I could define a new alteration (not a neutral second) for the comma to make it distinct from M-2m (or whatever) but then I'd be lying to Lilypond in exactly the way you don't seem to like with the existing system. Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippet formatting in the Glossary
On Tue, Dec 09, 2008 at 07:35:41PM +, Neil Puttock wrote: I've tweaked the examples for `Clef' in the Glossary, and they seem to be the only examples which use [quote]. Shouldn't this apply to all the snippets? Ideally yes, but the glossary is very low priority and we haven't been too picky about applying the doc policy to it. As long as it compiles ok, I don't care what happens there. If the LM and NR 1-4 were finished, and we still had 6 months left in GDP with 10 helpers sitting on their hands, of course I'd want the glossary to follow the doc policies, but as it is, I suggest that you leave it alone. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: major feature request (tablature)
2008/12/10 Werner LEMBERG [EMAIL PROTECTED]: 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. Much more important is proper indenting. Very true. Also, Scheme code is _not_ read by looking at the parentheses. Instead, you read it by looking at the indention (which tells you at which 'level' of the code you are). You'll realize that pretty soon you entirely forget about the parentheses. Scheme's parentheses are rather easy to handle if you write code like this during development: (foo (bla ... bla ) ) and fold it later to (foo (bla ... bla)) In fact, I personally find it just as easy to write/read the latter form directly, again because it is the _indentation_ which tells me how a particular piece of code is related to the rest. BTW, you can quickly become addicted to the way you start thinking when programming in Scheme. It's offers you a wholly new paradigm which breaks down a couple of walls you have built yourself up by programming in other languages. I highly recommend giving it a try (especially if you're an experienced programmer). There are excellent tutorials and books out there (although unfortunately I don't have any web addresses at hand). Coming from the Lisp side, I can highly recommend Paul Graham's books ANSI Common Lisp and On Lisp which IMHO are fluent to read and didactically excellent. But as I said, there are plentiful other resources. Also, keep in mind that Scheme is only a Lisp dialect which means that a couple of things behave differently, so in your case it's probably good to dive into Scheme directly. Good luck and especially: have fun! Max ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
On 10 Dec 2008, at 12:47, Graham Breed wrote: I did it for E53 - it did not work. I attach a file. No you didn't. You did something else in E53 and that didn't work. There are still no transpositions. There are some attempts to get the MIDI output to work. Did it? It looks like you're on the right track. I wouldn't expect transpositions to work with this file because you've defined your flat according to an equal temperament -- exactly what I told you not to do. E53 is an ET. You've also specified fine tunings and not included them in the accidental lookup table so I wouldn't expect printed output to work even without the transpositions. Maybe these problems can be fixed but it will still mean different init files for printing and MIDI. Define the flat as a half step (-1/2) and the other accidentals relative to it. Then transpositions might work. That is already done in the Turkish files. And I do not thing transpositions will work when pushed over an m, get of by an 1/18 of an M. Let's leave this topic. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
2008/12/10 Hans Aberg [EMAIL PROTECTED]: On 10 Dec 2008, at 07:55, Graham Breed wrote: I attach an example file. I don't see any transpositions. From what I recall, if one uncomments the key signature, lilypond complains that it cannot handle the rational numbers. So one does not get as far as doing transpositions. Otherwise, one could have written \key b \bayati Say what? You're talking about key signatures again, not transpositions. You can uncomment anything you like now because the rational numbers are accepted. I've checked the documentation for key signatures and see no indication that \key b \bayati could possible work though. I think the reason is that key signature only work in E24. Then on top of that, an non-transposable model for Turkish music was added. But it isn't really transposed, so it is not a problem. If the key signature works with quarter-tones but not sixth-tones there must surely be a bug. So report it. Don't bury this in a huge thread that the developers have probably given up on reading. This, incidentally, will give you the key signature in terms of generic intervals instead of fractions: \set Staff.keySignature = #(list (cons 2 HALFFLAT) (cons 6 FLAT)) I wanted to drop off the model I gave to some developer, so that they could think it was useful to them. The changes run too deep for it making sense on any other list. I doubt they could have understood it if I hadn't been here. But you are not developing LilyPond either, right? - so my attempt failed. I can read C++ and Scheme. I think support for retuning the nominals would be entirely reasonable. So if I can get a patch maybe it would be accepted. It isn't a priority though because I'm mainly looking at the printed output and we can surely hack the init files for now. Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
On 10 Dec 2008, at 12:47, Graham Breed wrote: Perhaps you mean the between a sharp and a flattened M, like between F# and Gb, which may be positive or negative. Since I do not impose any such relations, those are not confused. Yes, that's the one. If you only record pitches with M and m they will be confused because m=m. The diesis above C# (let's call it C#^) will come out the same as Db. If I asked for C#^ maybe you'll give me Db. This is because you do not know how to work out the diatonic values. C to C# is M - m, and C to Db is m, so C# - Db = M - 2m, the same as the definition of a comma in Pythagorean tuning. One can see this by computing the scale degree d, which are unchanged by accidentals. So d(C#) = d(C), and d(Db) = d(D), so d(C# - Db) = 0 - 1 = -1. Since this is nonzero, commas are nit confused. In fact, it is the other way around, for example E12 confuses scale degrees, because F# = Gb. This is however not a problem, as the Western notation system is diatonic, forcing one to write one of them. Then one can confuse them if called for. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
On 10 Dec 2008, at 13:01, Graham Breed wrote: doing transpositions. Otherwise, one could have written \key b \bayati Say what? You're talking about key signatures again, not transpositions. I just assume the system for transposing key signatures is synced with that. You can uncomment anything you like now because the rational numbers are accepted. Fine. I've checked the documentation for key signatures and see no indication that \key b \bayati could possible work though. In E12, I use key signatures like hitzaz = #`( (0 . 0) (1 . ,FLAT) (2 . 0) (3 . 0) (4 . 0) (5 . ,FLAT) (6 . ,FLAT) ) ... \tempo 4 = 144 \key b \hitzaz \time 7/16 and they work just fine. It would be the same, but for intermediate pitches. In Turkish and Arab music they may give a transposition a new name, but in Farhat had transpositions in Persian music. I think the reason is that key signature only work in E24. Then on top of that, an non-transposable model for Turkish music was added. But it isn't really transposed, so it is not a problem. If the key signature works with quarter-tones but not sixth-tones there must surely be a bug. So report it. Don't bury this in a huge thread that the developers have probably given up on reading. I keep saying that it was a feature, not a bug, due to the development history. You keep returning to it, creating noise. This, incidentally, will give you the key signature in terms of generic intervals instead of fractions: \set Staff.keySignature = #(list (cons 2 HALFFLAT) (cons 6 FLAT)) Fine, I may try it someday. I wanted to drop off the model I gave to some developer, so that they could think it was useful to them. The changes run too deep for it making sense on any other list. I doubt they could have understood it if I hadn't been here. It is probably good if you and other microtonalists help out. - If you can learn my system, i don't have to worry about it. :-) But you are not developing LilyPond either, right? - so my attempt failed. I can read C++ and Scheme. I think support for retuning the nominals would be entirely reasonable. So if I can get a patch maybe it would be accepted. It isn't a priority though because I'm mainly looking at the printed output and we can surely hack the init files for now. I have found Haskell http://haskell.org/ useful, using the interpreter Hugs http://haskell.org/hugs/ or compiler GHC http:// haskell.org/ghc/. Hugs is good as a programmable calculator, but with a full typed functional language in the back. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: small caps
On Sat, Dec 6, 2008 at 8:24 PM, Till Rettig [EMAIL PROTECTED] wrote: Thanks I know. Actually I just discovered that Century Schoolbook is to blame: indeed it doesn't include small caps. Didn't check how pango/lilypond handles a font that includes them. It will try to substitute small caps from another font. I think the substitution strategies come from fontconfig. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
(attn doc team) Re: Diatonic notation system
On Wed, Dec 10, 2008 at 08:01:08PM +0800, Graham Breed wrote: I've checked the documentation for key signatures and see no indication that \key b \bayati could possible work though. Say what? http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Arabic-music#Arabic-key-signatures Doc team: I must admit that a link from NR 1.1.3 Key signatures to that page would help. Also, how the Mao did I let the Arabic key signatures get added without a working example there?!?! I suck. So report it. Don't bury this in a huge thread that the developers have probably given up on reading. Yeah, pretty much. I wanted to drop off the model I gave to some developer, so that they could think it was useful to them. The changes run too deep for it making sense on any other list. I doubt they could have understood it if I hadn't been here. I have no clue (beyond microtones) what you two have been talking about, but perhaps Hans should take a serious look at what is ALREADY WORKING in 2.11.65 before discussing new features. You'll want to pay special attention to ly/arabic.ly, and make sure you understand everything that's happening in there. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
On 10 Dec 2008, at 15:04, Graham Percival wrote: I have no clue (beyond microtones) what you two have been talking about, but perhaps Hans should take a serious look at what is ALREADY WORKING in 2.11.65 before discussing new features. The guy set it in E24, which is obviously wrong. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
On 10 Dec 2008, at 15:04, Graham Percival wrote: You'll want to pay special attention to ly/arabic.ly, and make sure you understand everything that's happening in there. Have you looked it into yourself? - It goes on like bayati = #`( (0 . 0) (1 . ,SEMI-FLAT) (2 . ,FLAT) (3 . 0) (4 . 0) (5 . ,FLAT) (6 . ,FLAT) ) Now, everyone agrees that in Arab music, the intermediate pitch isn't that - in fact the guy who write it said he was taught to lower it, which agree with the values Farhat uses in Persian music (using koron and sori; see below). In addition, Arab music may not even be played in a micro-toning of E12, but E53 or Pythagorean tuning. In that case for example F# and Gb no longer agree, since M = 9, m = 4, and this accidentals alter with M - m = 5 commas (or E53 tonesteps). For example C to C# is 5 commas, and C to Db is 4 commas. In Persian music, the intermediate pitch is described by Farhat using a neutral second n, which in E53 gets the value 6 commas. There result a koron p that lowers 3 commas, and a sori that raises 2 commas. Note the asymmetry: the sum of the p and intervals is 5 commas = M - m. This so in general. There are two problems: does the E24 setting in transposing (or choosing a key) risk say E- (half-flat) be confused with D#+ (sharp and half-flat). - This I do not know, because it depends on how LilyPond computes it. If there is no risk for such confusion, then E24 is just fine, except for that the MIDI files will not sound good. So in order to lessen the risk for such confusion, I suggested using E36. The motivation comes from Persian music, where one suggestion is that Farhat's neutral second n has the value 27/25. If I keep that value, then E36 approximates it well, and it also sounds good to me when trying it in Scala. Of course, that is all attempts to find a workaround in LilyPond, which requires explicit number values plugged in for intervals. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Diatonic notation system
2008/12/10 Hans Aberg [EMAIL PROTECTED]: On 10 Dec 2008, at 13:01, Graham Breed wrote: You can uncomment anything you like now because the rational numbers are accepted. Fine. But if you try and do \key d \bayati you'll get that error. I've checked the documentation for key signatures and see no indication that \key b \bayati could possible work though. In E12, I use key signatures like hitzaz = #`( (0 . 0) (1 . ,FLAT) (2 . 0) (3 . 0) (4 . 0) (5 . ,FLAT) (6 . ,FLAT) ) ... \tempo 4 = 144 \key b \hitzaz \time 7/16 and they work just fine. That's nice. But the documentation clearly says To create non-standard key signatures, set this property directly. Surprisingly enough an undocumented alternative doesn't work. It would be the same, but for intermediate pitches. In Turkish and Arab music they may give a transposition a new name, but in Farhat had transpositions in Persian music. What? If the key signature works with quarter-tones but not sixth-tones there must surely be a bug. So report it. Don't bury this in a huge thread that the developers have probably given up on reading. I keep saying that it was a feature, not a bug, due to the development history. You keep returning to it, creating noise. You haven't said it was a feature before. Why do you say it's a feature now? One interesting thing is that if I make the key signature \set Staff.keySignature = #`( (2 . ,HALFFLAT) ((0 . 6) . ,FLAT)) then a spurious flat gets added instead of a spurious half-flat. And if I set the half-flat to actually be a half-flat, the spurious accidentals still get added. And even if I change the half-flat to be a full-flat, the spurious accidentals are still added. So are you sure this is a bug to do with the sixth-tones? Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problems with ly:font-load
2008/12/9 Werner LEMBERG [EMAIL PROTECTED]:
I've just added ly:font-config-add-directory and
ly:font-config-add-font. Please test.
Hi Werner,
for some reason I can't figure out how to make it work. Would you have
an example file to send me?
I've tried
#(ly:font-config-add-font ./Documents/chemoelectric_-_Goudy_Bookletter_1.otf)
or
#(ly:font-config-add-directory ./Documents/)
and then
c-\markup{ \override #'(font-name . Goudy Bookletter) text }
But this doesn't work (more surprisingly, it doesn't display any
message during the compilation??). Before you ask, I have also removed
the fontconfig cache before compiling the .ly file.
Looking forward to making it work! :-)
Cheers,
Valentin
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
2008/12/10 Graham Percival [EMAIL PROTECTED]: On Wed, Dec 10, 2008 at 08:01:08PM +0800, Graham Breed wrote: I've checked the documentation for key signatures and see no indication that \key b \bayati could possible work though. Say what? http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Arabic-music#Arabic-key-signatures Ah, sorry. I was looking at the documentation for an earlier build for which I don't have an arabic.ly. Hans was using is own \bayati which may have been defined differently. I have no clue (beyond microtones) what you two have been talking about, but perhaps Hans should take a serious look at what is ALREADY WORKING in 2.11.65 before discussing new features. It looks like there is something weird with the non-standard key signatures. If you specify an alteration as (octave . step) then it only applies the first time a note of that pitch is written. You'll want to pay special attention to ly/arabic.ly, and make sure you understand everything that's happening in there. Okay, I'll have a look tomorrow. Where do I find it in a Linux installer? t'other Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FretBoards
On 12/10/08 4:41 AM, Richard Schoeller [EMAIL PROTECTED] wrote: I'd like to represent the capo point as a straight barre, but then still indicate the unfingered strings with 'x' or 'o'. I think that you can do it in standard form as well, just not in terse. Better still for the capo, would be to show a straight barre without the dots. But that's for another day. Since the capo is not going to be moved very often during playing, and will always cover all of the strings, would it make sense just to add a (capo fret) setting to the verbose string? The capo fret would become the lowest fret on the diagram, and a solid bar would be drawn across the strings at that point. Since the capo is not part of the fingering, we could perhaps add the capo as part of the fret-diagram-details properties. But as I think more about it, the fret diagram depends on the capo setting, so it should be part of the diagram definition. It's probably the right thing to do to add a verbose interface to storePredefinedFretBoard, so things like scales can be added if desired, with the idea of moving all fret diagrams to the FretBoards context. I think that your request is doable. I'll try to do it over the next couple of weeks. Carl Carl D. Sorensen wrote: On 12/9/08 10:22 PM, Richard Schoeller [EMAIL PROTECTED] wrote: Is there any way to build a chord diagram using the verbose syntax and use it FretBoards? I didn't see anything in the docs for this. There are few things that I'd like to try for showing the use of a capo that I can't do with terse. As of now, there is no way to use the verbose syntax with FretBoards. However, it could potentially be added. Can you tell me more about what you'd like to do? Perhaps show me the diagram you'd like to use as a markup? I've avoided using verbose as the primary syntax for fret diagrams because it's so user unfriendly. But now that I think about it, I could make verbose syntax the primary form, and create a terse_to_verbose function that would still allow users to specify the fret diagram with a terse string. The only thing I can think of that verbose allows but terse doesn't is multiple dots on a single string. Thanks, Carl Sorensen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problems with ly:font-load
for some reason I can't figure out how to make it work. Would you
have an example file to send me?
I've tried
#(ly:font-config-add-font
./Documents/chemoelectric_-_Goudy_Bookletter_1.otf)
or
#(ly:font-config-add-directory ./Documents/)
and then
c-\markup{ \override #'(font-name . Goudy Bookletter) text }
But this doesn't work (more surprisingly, it doesn't display any
message during the compilation??).
What message do you expect? You get something if you add command line
option `-V' to lilypond.
Before you ask, I have also removed the fontconfig cache before
compiling the .ly file.
This is irrelevant. Fonts added by the two new functions are not
cached in the cache file.
Let's assume that you have a subdirectory `f', and the font in this
directory is `pala.ttf'. Try this (in file `f.ly'):
#(ly:font-config-add-directory ./f)
#(ly:font-config-display-fonts)
\relative {
c-\markup{ \override #'(font-name . Palatino) text }
}
with
lilypond f.ly 2 f.log
Hmm, this doesn't work; it's not the right font. Looking into the log
file, I see that this font is not called `Palatino' but `Palatino
Linotype'. Fixing this, I get the desired result.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problems with ly:font-load
2008/12/10 Werner LEMBERG [EMAIL PROTECTED]: for some reason I can't figure out how to make it work. Would you have an example file to send me? But this doesn't work (more surprisingly, it doesn't display any message during the compilation??). What message do you expect? You get something if you add command line option `-V' to lilypond. I expected to see the messages you added in font-config-scheme.cc :-) This is irrelevant. Fonts added by the two new functions are not cached in the cache file. Neat. Let's assume that you have a subdirectory `f', and the font in this directory is `pala.ttf'. Try this (in file `f.ly'): Oh, I didn't think TTF fonts would work (of course, I should have guessed that any file recognized by fontconfig could do the trick). Hmm, this doesn't work; it's not the right font. Looking into the log file, I see that this font is not called `Palatino' but `Palatino Linotype'. Fixing this, I get the desired result. Indeed. Actually, I was mixing up the font-family name with the actual font-name; now it works! Wooohoo, this will make Lilypond even more exciting! Thanks a lot, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Arrowed accidentals for microtone notation
On Tue, Dec 9, 2008 at 10:50 PM, Werner LEMBERG [EMAIL PROTECTED] wrote: Still a buglet: The stemwidth of the down arrow in the `natural.arrowboth' glyph is too thick if compared to the other arrowed natural signs. Everything else looks fine. Finally one with an instantaneous fix. :-) Indeed I used to check for up- XOR down-arrow before I added the accidentals with arrows in both direction. The attached version of the patches corrects this. Hehe, it's still not perfect. Sorry for being a PITA :-) Compile with FONTFORGE=foo mf2pt1 --rounding=0.0001 feta20 and magnify into the connection point between the down-arrow and the vertical bar: The `natural.arrowdown' glyph correctly extends the vertical bar outlines into exactly the same direction, while the `natural.arrowboth' extends the stem into a slightly different direction, which is not correct. Additionally, the upper left point of the lower horizontal bar `jumps' if compared between natural glyphs with and without an up-arrow. The same is true for the lower right point of the upper horizontal bar for glyphs with and without a down-arrow. lilypond-devel@gnu.orghttp://lists.gnu.org/mailman/listinfo/lilypond-devel (Thank you guys both for the continued tweaks to the arrowed accidentals!) Trevor. -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
Graham Percival wrote Wednesday, December 10, 2008 2:04 PM
On Wed, Dec 10, 2008 at 08:01:08PM +0800, Graham Breed wrote:
I've checked the documentation for key signatures and see no
indication that \key b \bayati could possible work though.
Say what?
http://lilypond.org/doc/v2.11/Documentation/user/lilypond/Arabic-music#Arabic-key-signatures
Doc team: I must admit that a link from NR 1.1.3 Key signatures to
that page would help. Also, how the Mao did I let the Arabic key
signatures get added without a working example there?!?! I suck.
Happy to add the link, but I'm not sure non-standard
key signatures are working properly. Try this:
\relative c' {
\set Staff.keySignature = #`(((0 . 3) . ,SHARP)
((0 . 5) . ,FLAT)
((0 . 6) . ,FLAT))
fis fis aes bes
fis aes aes bes
fis aes aes bes
}
It seems the keySignature is set for just one bar.
Or have I missed something? Either way it seems the docs
need more than just a link.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation string problem
Le mercredi 10 décembre 2008 à 03:07 -0700, Carl D. Sorensen a écrit : Then I imagine the problem must be that sometimes you want up and down to be translated, but not in the autochange snippet. So perhaps my suggestion should just be to change the defined names for autochange staves to upperStaff and lowerStaff so those words could be left out of the PO file. Francisco already explained why this is a bad idea, as this would probably break sooner or later. Or, we could just get the @KEEP LY working properly, which John has promised to do. I've never promised to do exactly this; not gettexting a verbatim snippet is a different issue from keeping a snippet from being overwritten by snippet-update, so I added a fragment option 'nogettext'. Francisco, Jean-Charles, can one of you try it? Thanks in advance John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problems with ly:font-load
Oh, I didn't think TTF fonts would work (of course, I should have guessed that any file recognized by fontconfig could do the trick). This is not correct. Lilypond can't handle bitmap fonts (which FontConfig will also find if it is configured to do so -- we have to implement something to reject them), and it currently can't handle TTCs; the latter is something I would like to change as soon as time permits. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
On 10 Dec 2008, at 20:14, Trevor Daniels wrote:
Happy to add the link, but I'm not sure non-standard
key signatures are working properly. Try this:
\relative c' {
\set Staff.keySignature = #`(((0 . 3) . ,SHARP)
((0 . 5) . ,FLAT)
((0 . 6) . ,FLAT))
fis fis aes bes
fis aes aes bes
fis aes aes bes
}
It seems the keySignature is set for just one bar.
Or have I missed something?
It works if I change it too:
\relative c' {
\set Staff.keySignature = #`((3 . ,SHARP)
(5 . ,FLAT)
(6 . ,FLAT))
fis fis aes bes
fis aes aes bes
fis aes aes bes
}
Hans
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Malformed g++ flags
Le mercredi 10 décembre 2008 à 02:38 -0200, Han-Wen Nienhuys a écrit : LGTM Done (with the correct sed regexp). John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
INSTALL.txt missing ?
Hi, I just git-pulled lily to take a look, but got side-tracked by configure problems: $ ./configure ... ERROR: Please install required programs: mpost See INSTALL.txt for more information on how to build LilyPond but there's no INSTALL.txt ? Since I'm at it... what I wanted to look INSTALL.txt for was tips on where to find the required 'mpost'. TIA --strk; ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Snippet formatting in the Glossary
2008/12/10 Graham Percival [EMAIL PROTECTED]: If the LM and NR 1-4 were finished, and we still had 6 months left in GDP with 10 helpers sitting on their hands, of course I'd want the glossary to follow the doc policies, but as it is, I suggest that you leave it alone. Well, as I've already gone though the majority of the snippets tidying them up, it won't be a great burden to convert them all to [quote]. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
typo in localization guidelines web page
http://lilypond.org/web/devel/participating/localization Messages to be localised must be encapsulated in `_ (STRING)' or `_f (FORMAT, ...)'. Eg: warning (_need music in a score); error (_f (cannot open file: `%s', file_name)); I guess the warning should look like this ? warning ( _(need music in a score) ); --strk; GIS Flash consultant/developer () ASCII Ribbon Campaign http://foo.keybit.net/~strk /\ Keep it simple! ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: INSTALL.txt missing ?
Hi strk, Le mercredi 10 décembre 2008 à 22:36 +0100, strk a écrit : Hi, I just git-pulled lily to take a look, but got side-tracked by configure problems: $ ./configure ... ERROR: Please install required programs: mpost See INSTALL.txt for more information on how to build LilyPond but there's no INSTALL.txt ? It's built from Documentation/user/install.itely and included in the distributed tarball. If you're not comfortable with reading the source in Texinfo, just look at http://lilypond.org/doc/v2.11/Documentation/user/lilypond-program/Requirements Since I'm at it... what I wanted to look INSTALL.txt for was tips on where to find the required 'mpost'. You have to install a TeX system, e.g. TeXlive. Good luck with installing all dependencies John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Using [line-width] with [quote]
Hi everybody, This combination is disabled in lilypond-book, but there are several places in the docs where it's used, resulting in no quote block. I've just reworked a snippet in the Glossary which would benefit from this; it's currently a bit too long for the pdf output (the final snippet here: http://kainhofer.com/~lilypond/Documentation/user/music-glossary/clef.html#clef). Though it doesn't run off the right hand side, there's an ugly vertical bar in the right margin. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Fix for bug #218 (center staccato over stem instead of notehead)
2008/12/8 Maximilian Albert [EMAIL PROTECTED]: Awesome to hear and thanks for testing! What do you guys think, should a default value be set, and if so which one? I guess something between 0.5 and 0.75 would be sensible, according to Reinholds findings. Though I much prefer the centred-on-stem look (which seems to be favoured by French publishers), if I had to choose an off-centre position, I'd plump for 0.5. Great! With what you had written in your last email, something along these lines should have crossed my mind... Could it be worthwhile to wire this function into lilypond itself, since I suppose that most people would want to change the property only for specific scripts? Or is it sufficient to put it into the docs somewhere (perhaps in the corresponding LSR snippet itself)? I think it's a bit too limited to be included in the source, since it only allows you to override one articulation at a time; furthermore, if a particular script has a default in scripts.scm (as suggested for staccato), it will ignore any override. Including it in an LSR snippet probably wouldn't do any harm though. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: typo in localization guidelines web page
Le mercredi 10 décembre 2008 à 23:21 +0100, strk a écrit : http://lilypond.org/web/devel/participating/localization I guess the warning should look like this ? warning ( _(need music in a score) ); Yes, the unescaped double quotes confused Firefox and possibly othe browsers. This should be fixed now. Thanks for the report, John ___ 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: horizontally centering denominator in compound time signatures
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Sonntag, 30. November 2008 16:07:39 schrieb Graham Percival: Incidentally*2, I think there's enough interest in compound time signatures that we should add it to the main lilypond. I have now found a nice workaround for my problems with the center-column- markup: Simply wrap a left-column-markup around to offset the shifted reference point... Here is my current version, where only the proper auto-beaming settings are missing. What do you think is the best way to add something like this directly to lilypond? http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.pdf http://www.fam.tuwien.ac.at/~reinhold/temp/time_sigs.ly Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJQGo/TqjEwhXvPN0RAtYnAJ4vS/6CdwKzFjJAXSKkXlQc8ySXAwCgzkAA 1sH0K2aqBxGJ0WRMfjw6eW0= =5idc -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
2008/12/10 Hans Aberg [EMAIL PROTECTED]: Now, everyone agrees that in Arab music, the intermediate pitch isn't that - in fact the guy who write it said he was taught to lower it, which agree with the values Farhat uses in Persian music (using koron and sori; see below). Yes, but nobody agrees on what that intermediate pitch *is* do they? And Arab pop music really does use equally tempered synthesizers however much the purists may object. There are two problems: does the E24 setting in transposing (or choosing a key) risk say E- (half-flat) be confused with D#+ (sharp and half-flat). - This I do not know, because it depends on how LilyPond computes it. Let's assume it works fine because otherwise standard notation would break as well. Now, my question is, why is that clever workaround for the Arabic half-flat symbol in there when it could be replaced globally? The documentation doesn't give any case where you'd want to use the Tartini half-flat. In my impetuosity I've created a new init file with code modeled on makam.ly, and attached it to this message. Graham arabic24.ly Description: Binary data ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Erroneous changes to staff.itely
Hi Carl, Your recent commit with Ralph changes (DOC -- Index editorial...) seems to be based on a *very* old version of staff.itely. I had completely rewritten this section a few months ago, so the diff for this file immediately stood out to me. :-) Can you revert this commit and include only the indexing changes, which is what I assume Ralph meant to do? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Erroneous changes to staff.itely
Patrick, I've reverted the commit, and committed only pitches and editorial. I will investigate what went on with staff. I'm sorry about the mistake. Thanks for catching it. Carl On 12/10/08 9:49 PM, Patrick McCarty [EMAIL PROTECTED] wrote: Hi Carl, Your recent commit with Ralph changes (DOC -- Index editorial...) seems to be based on a *very* old version of staff.itely. I had completely rewritten this section a few months ago, so the diff for this file immediately stood out to me. :-) Can you revert this commit and include only the indexing changes, which is what I assume Ralph meant to do? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Erroneous changes to staff.itely
Hi Carl, On Wed, Dec 10, 2008 at 10:05:26PM -0700, Carl D. Sorensen wrote: I've reverted the commit, and committed only pitches and editorial. I will investigate what went on with staff. I'm sorry about the mistake. Thanks for catching it. That's no problem. Thanks for fixing this so fast! -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation string problem
2008/12/10 John Mandereau [EMAIL PROTECTED]: I've never promised to do exactly this; not gettexting a verbatim snippet is a different issue from keeping a snippet from being overwritten by snippet-update, so I added a fragment option 'nogettext'. Francisco, Jean-Charles, can one of you try it? Tested, it works, thank you! I have kept the KEEP LY so I can still translate the other translatable name, right? -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translation string problem
Le jeudi 11 décembre 2008 à 07:59 +0100, Francisco Vila a écrit : Tested, it works, thank you! I have kept the KEEP LY so I can still translate the other translatable name, right? If you like. John ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: (attn doc team) Re: Diatonic notation system
On 11 Dec 2008, at 04:47, Graham Breed wrote: Now, everyone agrees that in Arab music, the intermediate pitch isn't that - in fact the guy who write it said he was taught to lower it, which agree with the values Farhat uses in Persian music (using koron and sori; see below). Yes, but nobody agrees on what that intermediate pitch *is* do they? Right. That is also true about Persian music. Farhat just gave some approximate values; E53 and Pythagorean interpretations are just that. And Arab pop music really does use equally tempered synthesizers however much the purists may object. Yes, and at Maqamworld, they seem wholly unaware of that it may be played in Pythagorean tuning, only comparing against E12 (0r so was my impression). I measured some of their sound files: the maqam Ajam (major scale) buzuq by Tareq Abboushi, F down is close to E12, and Bb close to E53. There are two problems: does the E24 setting in transposing (or choosing a key) risk say E- (half-flat) be confused with D#+ (sharp and half- flat). - This I do not know, because it depends on how LilyPond computes it. Let's assume it works fine because otherwise standard notation would break as well. Now, my question is, why is that clever workaround for the Arabic half-flat symbol in there when it could be replaced globally? The documentation doesn't give any case where you'd want to use the Tartini half-flat. In my impetuosity I've created a new init file with code modeled on makam.ly, and attached it to this message. I am not sure what you mean here - is this a question of symbols? - Then I have a vague memory that in LilyPond some symbols are (or were) hard-wired to the transposable key signatures. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
