missing feature? piano hand brackets
Hi, from the German LilyPond-Forum (at http://www.lilypondforum.de/index.php?topic=234.0): In Piano music it is some times important to indicat that a note written in one staff should be played by the hand of the other staff. This is mostly done by a l-shaped bracket pointing towards the staff where the note should belong to. See the attached pictures (first is hand drawn, second from Scriabin Sonate 10. Greetings Till -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 attachment: piano-l.jpegattachment: IMSLP_01956.png___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: missing feature? piano hand brackets
Yes indeed, but it should be wrapped so you could write c2\leftHand and it would automatically collect notes from polyphonic voices and put the bracked around them and place it at proper distance to the note... Who takes the challenge? :-) Greetings Till Original-Nachricht Datum: Tue, 10 Mar 2009 11:10:55 +0100 Von: Bertalan Fodor (LilyPondTool) lilypondt...@organum.hu An: till Rettig till.ret...@gmx.de CC: lilypond-user@gnu.org Betreff: Re: missing feature? piano hand brackets First can be easily achieved with a postscript markup. (Two straight lines) till Rettig wrote: Hi, from the German LilyPond-Forum (at http://www.lilypondforum.de/index.php?topic=234.0): In Piano music it is some times important to indicat that a note written in one staff should be played by the hand of the other staff. This is mostly done by a l-shaped bracket pointing towards the staff where the note should belong to. See the attached pictures (first is hand drawn, second from Scriabin Sonate 10. Greetings Till -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
lilypond on Windows ME
Hello lilypond list! I report a problem by a user on the German forum: He installed LilyPond 2.12 on Windows ME and invoked the program from the command line. He got the following errors: 3 times: Fontconfig warning: no cachedir found (Dann folgt ein Ordnername und Pfad) adding cachedir. fontconfig/cachedir error: out of memory LILYPOND-WINDOWS verursachte einen Fehler durch eine ungültige Seite in Modul (LILYPOND-WINDOWS created a mistake with a bad page in module) LILYPOND-WINDOWS.EXE bei 0187:005d388e. Register: EAX= CS=0187 EIP=005d388e EFLGS=00010246 EBX=00e08d2c SS=018f ESP=00c19f80 EBP=00c1a4a8 ECX= DS=018f ESI= FS=30bf EDX=00c1a340 ES=018f EDI= GS= Bytes bei CS:EIP: 8b 7f 0c 89 85 44 fb ff ff 31 c0 89 85 30 ff ff Stapelwerte: 46a0eb00 3f017b3b 40c4 4090 40ca 7800cffa 0004 0008 00d2de38 0100 This is really cryptical to me and seems like a real error. I tried installing the program more than once. When run from the Desktop by drag an drop he gets some complaints about pango in the log file: # -*-compilation-*- »C:/WINDOWS/Desktop/Neuer Ordner/test.ly« wird verarbeitet Analysieren... Interpretation der Musik... Vorverarbeitung der grafischen Elemente... (process:4294321031): Pango-WARNING **: error opening config file 'pangorc': Bad file descriptor (process:4294321031): Pango-WARNING **: error opening config file 'C:\.pangorc': Bad file descriptor (process:4294321031): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: 'pango.modules' You should create this file by running: pango-querymodules 'pango.modules' (process:4294321031): Pango-WARNING **: failed to find shape engine, expect ugly output. engine-type='PangoRenderFc', script='common' (process:4294321031): Pango-CRITICAL **: pango_fc_font_lock_face: assertion `PANGO_IS_FC_FONT (font)' failed The discussion is at this address: http://www.lilypondforum.de/index.php?topic=210.0 Can anybody try an installation on ME and check if this is a problem of the Windows version or only in this specific case? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Web-layout: Examples in the documentation
Hi, just saw that the examples page doesn't have yet the new layout. It would be nice if there would also a contents where it would be much easier to see what examples are available. I hope this is no big work. Also it appeared to me that it would be nice to have some examples of ancient music. At least the headword from the ancient section could be here, when the spacing issue is solved. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Formatting of lyric syllables
Hi all, is there a way to change only part of a lyric syllable? The issue is, that when having 4 repeats with 2 voltas, the fourth stanza (in the second volta) is on the same level as the third in the first volta. I would like to indicate that the text belongs to the fourth stanza, though. Ideally I could shift the level of the text down, so it would appear as the fourth stanza, but so far I just added: (4.) syllable, the first part indicates the stanza. Now I would like the number to appear bold. Is there any chance? markup commands won't work inside of quoted text... Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Formatting of lyric syllables
Bailey James E. schrieb:
Aha! this one I know.
music = \new Voice = stimme \relative {
c4 d e f
g a h c
}
lyrik = \new Lyrics \lyricsto stimme {
do \override Score . LyricText #'font-shape = #'italic re \revert
Score . LyricText #'font-shape mi fa
sol la \override Score . LyricText #'font-series = #'bold ti
\revert Score . LyricText #'font-series do
}
\score {
\music
\lyrik
}
In end effect, I always have to consult the font-interface to know
where the bold or italic is, but it's not so difficult.
Thanks, this is about what I figured out also, but what I need would be
\override Score . LyricText #'font-shape = #'italic re \revert Score .
LyricText #'font-shape mi
that is: both syllables to one note! And as you can try, it just prints
everything verbatim.
I add a longer example as an indication.
Till
test.ly
Description: application/extension-ly
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Formatting of lyric syllables
Thank you for all that fast help, this is really the best list I know!
Dominic Neumann schrieb:
I updated your file a bit and hope that it is what you wanted.
I added at the end of the lyrics of stanza 3. This shifts the
fourth verse to the place you wanted.
This gives a programming error cannot align... in your file.
In my original with four voices, though, it doesn't show any influence,
the spacing is ok without it.
Additionally I replaced the first underline in the fourth verse by
for layout reasons. If you keep the underline, the syllable before is
placed too much to the right (here in 2.11.51).
Yes, I noticed also, for me it doesn't work with a normal space, but a
n-quad space works. thanks for the hint.
Then I replaced (4.) by the \set stanza command I already mentioned.
I didn't check how to put into braces, so I used the version stated down.
Trevor Daniels schrieb:
Hi Till
This gets close to what you want, I think:
...
%Skip zu Klammer vier
_ _ _ _ _ _ _ _ _ _
\markup {\concat { \bold (4.) rak }} -- ka -- ut -- ta suu -- rin
-- ta kat -- so -- maan.
}
...
Trevor
Thanks, I use this one now -- I noticed also that when long enough it
also pushes the last line under further down so it is like the fourth
line. The syllable becomes to long that it makes strange spacing of the
first 8th, but I can live with that.
Thanks for you help.
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: What to do when \ and \ produce text
Original-Nachricht Datum: Thu, 30 Oct 2008 12:29:12 +0200 Von: Risto Vääräniemi [EMAIL PROTECTED] An: Trevor Daniels [EMAIL PROTECTED] CC: lilypond-user@gnu.org, LilyPond Development [EMAIL PROTECTED], Mats Bengtsson [EMAIL PROTECTED] Betreff: Re: What to do when \\ and \\ produce text 2008/10/30 Trevor Daniels [EMAIL PROTECTED]: In my experience (vocal music), cresc and dim without a dashed line is used almost universally. Hairpins are used when an extent is being indicated. I have the same impression (choir music). ok, one more from me :-) till -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New doc website development
Patrick McCarty schrieb: By `text div', you mean the div with the main docs, right? If you would like the maximum line width to be 80em, what sort of page layout would you propose? I am having trouble visualizing how this would work. I was thinking about bigger screens, so they could somehow center the whole content so a fixed width, where the content has a fixed max width and the contents also. Min width should of course change according to the resolution so you don't have to scroll horizontally. I'll consider your suggestion for the blockquoted sections. I don't think it's possible to have the musical examples adjust to the page width, since the maximum widths are hardcoded when the docs are compiled. What if we set the max width in the hardcoded scripts smaller? I also discovered afterwards already mentioned issures with the appendices in NR: eg the feta font list is a picture 600px wide so it would render bad in lower resolutions. It was also mentioned that blind people don't understand the picture. The scrollbars: I think the scrollbar for the contents div should always be on, don't remember how to achive this, something like setting height to 101%? So there won't be the switch when some subsections get opened. This is a very interesting suggestion! I'll think about it. nice On my 1024x768 there is also a scrollbar on the bottom but it is useless because it is always 100% long. Does this have to be there? On this small screen it eats up a relatively big space. Are you using Firefox 2 (or a browser that uses Gecko 1.8)? Because this is a known issue for those browsers. Ok, so that's the reason, indeed under Firefox 3 it doesn't happen. Happy to switch this year, hopefully... Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
New doc website development
Hi, sporadically following the discussion about the ongoing work on the new documentation web site. It is improving every day and looks really really good. Great job! I have a couple of things I thought you might (re)consider: first the width of the text div: I know this has been discussed earlier, but I just want to vote also for a version that makes the lines being not longer than 80em. I also think the picture boxes which are empty for most of their space look a bit funny, I guess they would also shrink automatically with something like that. Don't know if there are examples extenting over this border, sure it depends on the current screen size. Maybe lilypond could be also told a pagewidth number (if it doesn't yet) The scrollbars: I think the scrollbar for the contents div should always be on, don't remember how to achive this, something like setting height to 101%? So there won't be the switch when some subsections get opened. On my 1024x768 there is also a scrollbar on the bottom but it is useless because it is always 100% long. Does this have to be there? On this small screen it eats up a relatively big space. Otherwise I have been told you should make a site for a resolution of 800x600 still readable, I guess you would really need much scrolling with this kind of screen. (this is a bit ot for me since I don't have such a screen, though) This observation I made on kainhofer.com today. Thanks for you big work so far! Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Question about inserting a bracket: snippet Bracketed passages
Hi a user on the German Lilypond-Forum would like to insert several brackets one after the other in his score, as indicated with the snippet bracketed passages. But the use of the \breathe obviously prevents to be put more than one time without anything in between. Does anybody have a quick idea how to improve the snippet to allow multiple bracketed passages? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 65, Issue 34
Trevor Daniels schrieb: OK, draft 8 will say: .6 Editorial markings .1 Annotational accidentals (was Musica ficta accidentals) (2.8.4) .2 Ligature brackets (was Ligatures) (2.8.2.4) .3 Baroque rhythmic notation (new) (new - KH) Ok, so as I understand in 8.3 there will be White mensural ligatures and then in 8.6 the Ligature brackets? Sounds good to me. Many thanks to you and Karl. Thanks for your work as well! Karl - if you meant something different by slurs, let me know and I'll add it. Till Trevor D ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 65, Issue 34
Trevor Daniels schrieb: OK, draft 8 will say: .6 Editorial markings .1 Annotational accidentals (was Musica ficta accidentals) (2.8.4) .2 Ligature brackets (was Ligatures) (2.8.2.4) .3 Baroque rhythmic notation (new) Karl: We don't have lilypond examples of this. I have seen this in a Novello score for Purcells Dido. So I suggest we drop this for the moment. (Though an ossia section might show what the editor want.) We actually do have some in the list somewhere, I remember (was it Nicolas) somthing about using empty note heads for quarter notes or something like that -- that's what I am referring to. I would still put the ligature brackets here, as they are an issue of modern editions and not of ancient notation. And about slurs and the like: they are not specific to ancient notation, so they are covered somewhere else in the NR. Actually Graham has pronounced that we should not have a task-orientated structure, but just tell about the issues not referring to the context they are used to. But maybe it is still ok in this case. Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 65, Issue 34
Hi Karl Hammar wrote Trevor Daniels wrote Karl Hammar wrote Till: 8.5 Transcription of ancient music Why not call it Editing or Making an edition, but transcription is also fine. I think we'll stick with Transcription - it seems closer to the action being performed by those working with ancient music, who usually want to preserve the original as faithfully as possible, rather than editing it. Ohh, I might have misunderstood the word (transcription) but I thought it ment converting to modern notation. Maybe transliteration is closer to what I meant, although transcription means changing the medium while preserving the content. It was editing I didn't like - which implies a change to the original content, rather than its representation. I still like transcription, that's what I call an edition with modern notes. Well, I agree, its edition and transcription, but still. Or then, Transcribing, as it is now. 5.2 Incipits and Mensurstriche-layout Theese are different beasts, should they not be in seperate sections. The incipit is an pre part showing the clefs, mensuration signs, the first few notes etc. so we can get a fealing of the transcriptions source, but still read on in modern notation. Mensurstriche is a way to include (or a substitute for) bar lines for sources that didn't contain them, but without splitting the notes and/or rests that are syncopated over the bar lines the editor wants. OK, thanks. I'll split that section into two Yes, I also go for that, now, even though I am afraid the mensurstriche section will be really short. Instead of Musica ficta, which are notes not in the regular hexachords, I suggests a section for editorial markings. Which includes suggested accidentals, slurs, different rhythmic (like french barock) interpretation. Happy to add Editorial markings for ancient music as an additional section, incorporating 5.4, if someone volunteers to send me suitable text for it, but I can't write this stuff myself :( I would be happy to help, but I'm kind of busy. Please hand me something to work on in that case. Thanks. Might not be for a week or two, as all NR 2 will have to be re-arranged first. So in Draft 8 of NR 2 headings let's change to .5 Transcribing ancient music (new) .1 Ancient and modern from one source [Here among others the snippets about reducing note length] .2 Incipits (new) (clefs, mensuration signs etc from lsr and -user) .3 Mensurstriche-layout (new) (lsr and -user) .4 Transcribing Gregorian chant (new) (extract from 1.6.1.1) .6 Editorial markings .1 Suggested accidentals (2.8.4) .2 Suggested slurs (new) (new - KH?) .3 Suggested rhythmic interpretation (new) (new - KH) How does this look? I don't know, what these slurs mean, I came up with the following editiorial items: 1. annotational accidentals 2. ligature brackets [I think they should be here, and not together with the ligatures] 3. Barock rhythm indication 1 is the same as 6.1, maybe 2 is the same as 6.2 (?), and by the topic 3 is the same as 6.3 . Suggested accidentals sounds good, but the others I wouldn't call suggested, since they are about how to interpret the notes, not an addition/suggestion by the editor as the accidentals are. So I would go for: 6.2 Brackets indicating ligatures or Ligature brackets 6.3 Rhythmic Barock notation -- or something the like. Hopefully this doesn't get now too complicated - I guess issues will clear up when we are actualy working on that section. Greetings Till /Karl Trevor D -- Message: 4 Date: Tue, 8 Apr 2008 10:55:08 -0300 From: luis jure [EMAIL PROTECTED] Subject: vertical text To: lilypond-user lilypond-user@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii hello list, i'd like to add vertical text after the final bar line, like in the image attached. i guess i can do that using postscript code, but i'd like to know if there is a property in LP to control that. i haven't been able to find one in the manual so far. best, lj -- next part -- A non-text attachment was scrubbed... Name: bartok.png Type: image/png Size: 15125 bytes Desc: not available Url : http://lists.gnu.org/pipermail/lilypond-user/attachments/20080408/fdf05186/bartok.png -- ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user End of lilypond-user Digest, Vol 65, Issue 34 * ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Re: GDP: Reorganisation of NR 2 - Final call for comments
Hi, this would be my suggestion for the ancient section: 8.5 Transcription of ancient music 5.1 using the same source for the original and the transcription [Here among others the snippets about reducing note length] 5.2 Incipits and Mensurstriche-layout 5.3 Transcription of Gregorian chant 5.4 Musica ficta 5.4.1 Suggested accidentals (new) (2.8.4) Something like that, please reformulate as you like, I am really bad in creating headings. Greetings Till - Ursprüngliche Nachricht - Von: Trevor Daniels Gesendet: 06.04.08 21:59 Uhr An: Till, lilypond-user@gnu.org Betreff: Re: GDP: Reorganisation of NR 2 - Final call for comments Till Rettig wrote: I like this new layout of the second chapter! I hope, though, you can still consider my suggestions... :) Of course ... I could think of a section on how to center lyrics between staves -- I would remember this was recently more than once topic on -user. Or would this go to hymn? I didn't check the templates, though, is it already there? Added as 2.1.3.5 Centering lyrics between staves I could take over the ancient rewrite, when finished which the staff section (taken that nobody else wants it). Sounds good to me, but Graham will need to allocate the work based on his priorities. I would suggest a subsection like transcribing ancient music where there could be some tricks recently shown by Carl, the incipit thing that is in the lsr and on -user, also the Gregorian-transcription-staff or how it was called which is nowhere mentioned in the documentation so far (I included it in staff, but it doesn't really belong there). Might think of still some more issues, like the mensurstriche-layout which is now also as a snippet in staff. Difficult for me to know where best to put these. Could you please suggest how these might fit in to the existing structure - or maybe how the existing structure (ie in Draft 5) might be improved? Thanks. Till Trevor D -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: Reorganisation of NR 2 - Final call for comments
Trevor Daniels schrieb: Till Rettig wrote Hi, this would be my suggestion for the ancient section: 8.5 Transcription of ancient music 5.1 using the same source for the original and the transcription [Here among others the snippets about reducing note length] 5.2 Incipits and Mensurstriche-layout 5.3 Transcription of Gregorian chant 5.4 Musica ficta 5.4.1 Suggested accidentals (new) (2.8.4) Something like that, please reformulate as you like, I am really bad in creating headings. Many thanks. I've changed your suggestion slightly to: 2.8.5 Transcribing ancient music (new) .1 using the same source for the original and the transcription [Here among others the snippets about reducing note length] .2 Incipits and Mensurstriche-layout (new) (lsr and -user) .3 Transcribing Gregorian chant (new) (extract from 1.6.1.1) .4 Musica ficta accidentals (2.8.4) There aren't enough levels to go to 2.8.5.4.1 for your Suggested sccidentals, so I put them all at one level, as they are now in 2.8.4. Sorry for replying so late, I just now read the last part of your message... Yes, I just copied from your suggestion, maybe I mixed the levels. I was also wondering that there are too much levels... I don't understand what the heading to 2.8.5.1 means, so I've not been able to come up with a better one. Can you please explain? Would it mean Transcribing verbatim? Ok, I mean: You write the notes only one time, and from the same notes you can print the mensural notation (as a copy of the original score) by modifying the shapes of the notes and so on, then you would from still the same notes print also the score in modern notation (possibly the first version is not a score but only parts for each voice, the modern score then is a normal choral score). See http://aspodata.se/noter/palestrina/dies_sanctificatus/all.pdf for an example by Carl Hammar (here he did the parts as well as a score in mensural notation and then as the last piece the same notes as a modern score.) Hope you can make up a good sectioning title if this is accepted for the NR. Till Till Trevor D ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: Reorganisation of NR 2 - Final call for comments
Trevor Daniels schrieb: Thanks Till Would Ancient and modern from one source cover it. I can't think of anything shorter. I am fine with that one. Anyone else any better suggestions? Trevor - Original Message - From: Till Rettig [EMAIL PROTECTED] To: Trevor Daniels [EMAIL PROTECTED] Cc: lilypond-user@gnu.org Sent: Monday, April 07, 2008 7:32 PM Subject: Re: GDP: Reorganisation of NR 2 - Final call for comments Trevor Daniels schrieb: Till Rettig wrote Hi, this would be my suggestion for the ancient section: 8.5 Transcription of ancient music 5.1 using the same source for the original and the transcription [Here among others the snippets about reducing note length] 5.2 Incipits and Mensurstriche-layout 5.3 Transcription of Gregorian chant 5.4 Musica ficta 5.4.1 Suggested accidentals (new) (2.8.4) Something like that, please reformulate as you like, I am really bad in creating headings. Many thanks. I've changed your suggestion slightly to: 2.8.5 Transcribing ancient music (new) .1 using the same source for the original and the transcription [Here among others the snippets about reducing note length] .2 Incipits and Mensurstriche-layout (new) (lsr and -user) .3 Transcribing Gregorian chant (new) (extract from 1.6.1.1) .4 Musica ficta accidentals (2.8.4) There aren't enough levels to go to 2.8.5.4.1 for your Suggested sccidentals, so I put them all at one level, as they are now in 2.8.4. Sorry for replying so late, I just now read the last part of your message... Yes, I just copied from your suggestion, maybe I mixed the levels. I was also wondering that there are too much levels... I don't understand what the heading to 2.8.5.1 means, so I've not been able to come up with a better one. Can you please explain? Would it mean Transcribing verbatim? Ok, I mean: You write the notes only one time, and from the same notes you can print the mensural notation (as a copy of the original score) by modifying the shapes of the notes and so on, then you would from still the same notes print also the score in modern notation (possibly the first version is not a score but only parts for each voice, the modern score then is a normal choral score). See http://aspodata.se/noter/palestrina/dies_sanctificatus/all.pdf for an example by Carl Hammar (here he did the parts as well as a score in mensural notation and then as the last piece the same notes as a modern score.) Hope you can make up a good sectioning title if this is accepted for the NR. Till Till Trevor D ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: StaffSymbol: behaviour of ledger-line-thickness
thanks for the quick answer. I tried now to figure out how to apply changes to StaffSymbol properties. It seems they work only as \with \override for a new staff or inside the layout block. That would mean that they cannot be changed on the fly but are preset for every score. Is this correct? Till Original-Nachricht Datum: Mon, 31 Mar 2008 18:32:51 +0200 Von: Reinhold Kainhofer [EMAIL PROTECTED] An: lilypond-user@gnu.org, till Rettig [EMAIL PROTECTED] Betreff: Re: StaffSymbol: behaviour of ledger-line-thickness Am Montag, 31. März 2008 schrieb till Rettig: Hi, could somebody explain me how ledger-line-thickness behaves? The IR states that it should be a pair: ledger-line-thickness (pair of numbers) The thickness of ledger lines. It is the sum of 2 numbers: The first is the factor for line thickness, and the second for staff space. Both contributions are added. But I cannot get the staff space bigger (the second number), instead the first number influences the thickness of the ledger line a bit, the second quite much, that is it becomes so heavy that the spaces almost disappear. Yes, because they use different units: -) The first one is a multiplier for the default thickness (quite small, ~ staff-space/10 ) -) The second one is an explicit width (in staff spaces, i.e. the default distance between two staff lines or ledger lines) The final distance is then: ( thickness * line-thickness * #1 ) + #2 Since the default thickness is quite small, of course the first number influences the width only a little bit, while the second (measured in different units!) increases it a lot. Actually, the following two settings produce roughly the same (i.e. ledger lines so thick that they touch each other: \override StaffSymbol #'ledger-line-thickness = #'( 10 . 0 ) \override StaffSymbol #'ledger-line-thickness = #'( 0 . 1 ) And, yes, even Han-Wen agrees that this is confusing. See his comment in lily/staff-symbol.cc: /* For raggedright without ragged staves, simply set width to the linewidth. (ok -- lousy UI, since width is in staff spaces) --hwn. */ the second quite much, that is it becomes so heavy that the spaces almost disappear. Please compare the example: Things work as expected: The default line width is quite small and the first number is a multiplier for the default line width. The second one gives an additional width in staff space (i.e. the distance between each of the five lines of a standard staff). \override StaffSymbol #' ledger-line-thickness = #' ( 1 . .1 ) This uses the default line width + 1/10 of the staff space = 1/5 staff space \override StaffSymbol #' ledger-line-thickness = #' ( .1 . 1 ) This decreases the line with to 1/10 of its default (1/100 staff space!), but adds a full staff space (=distance between two ledger lines!), so of course all ledger lines touch each other. 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/ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
StaffSymbol: line-positions
How does the line-position property of the StaffSymbol work correctly? I get it
set to different positions only if the staff is empty or the notes are on
ledger lines. Is this behaviour implied? And does the list of the positions
need a specific order? It obviously takes only as much arguments (positions) as
there are staff lines defined, is that correct?
code with which I played:
\score{
\new Staff \with {
\override StaffSymbol #' line-positions = #' ( 18 12 2 0 -2 -4 )
}{
d d d d
} }
\score{
\new Staff \with {
\override StaffSymbol #' line-position = #' ( 6 3 0 -3 -6 )
}{
d' e' f' g' c''
} }
In my idea the second example should print wider spaces and set the notes
somhow off the lines, but it just prints the standard lines 4 2 0 -2 -4. Why is
this so?
Thanks
Till
--
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: StaffSymbol: line-positions
Oops, yeah, you are right, it works as thought; I just didn't understand
the warning. Thanks!
Till
Mats Bengtsson schrieb:
If you check the warning printouts from LilyPond when processing the
second example, you will notice that you have misspelled the property
name!
Otherwise, both of the examples seem to do what I would expect them to
do.
I don't understand exactly what you mean by only if the staff is
empty or the
notes are on ledger lines..
/Mats
till Rettig wrote:
How does the line-position property of the StaffSymbol work
correctly? I get it set to different positions only if the staff is
empty or the notes are on ledger lines. Is this behaviour implied?
And does the list of the positions need a specific order? It
obviously takes only as much arguments (positions) as there are staff
lines defined, is that correct?
code with which I played:
\score{
\new Staff \with {
\override StaffSymbol #' line-positions = #' ( 18 12 2 0 -2 -4 )
}{
d d d d
} }
\score{
\new Staff \with {
\override StaffSymbol #' line-position = #' ( 6 3 0 -3 -6 )
}{
d' e' f' g' c''
} }
In my idea the second example should print wider spaces and set the
notes somhow off the lines, but it just prints the standard lines 4 2
0 -2 -4. Why is this so?
Thanks
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: StaffSymbol: behaviour of ledger-line-thickness
Oh, that's true, I will write this in the staff section of the Docu. Thanks for all the help! Greetings Till Mats Bengtsson schrieb: The properties of a layout object are only read when the object is created, so for StaffSymbol, for example, this means that you have to do the setting at the top of the score. However, if you want to change it in the middle of a score, you can insert \stopStaff \startStaff which finishes the previous StaffSymbol object and creates a new one which reads the new property setting. /Mats till Rettig wrote: thanks for the quick answer. I tried now to figure out how to apply changes to StaffSymbol properties. It seems they work only as \with \override for a new staff or inside the layout block. That would mean that they cannot be changed on the fly but are preset for every score. Is this correct? Till Original-Nachricht Datum: Mon, 31 Mar 2008 18:32:51 +0200 Von: Reinhold Kainhofer [EMAIL PROTECTED] An: lilypond-user@gnu.org, till Rettig [EMAIL PROTECTED] Betreff: Re: StaffSymbol: behaviour of ledger-line-thickness Am Montag, 31. März 2008 schrieb till Rettig: Hi, could somebody explain me how ledger-line-thickness behaves? The IR states that it should be a pair: ledger-line-thickness (pair of numbers) The thickness of ledger lines. It is the sum of 2 numbers: The first is the factor for line thickness, and the second for staff space. Both contributions are added. But I cannot get the staff space bigger (the second number), instead the first number influences the thickness of the ledger line a bit, the second quite much, that is it becomes so heavy that the spaces almost disappear. Yes, because they use different units: -) The first one is a multiplier for the default thickness (quite small, ~ staff-space/10 ) -) The second one is an explicit width (in staff spaces, i.e. the default distance between two staff lines or ledger lines) The final distance is then: ( thickness * line-thickness * #1 ) + #2 Since the default thickness is quite small, of course the first number influences the width only a little bit, while the second (measured in different units!) increases it a lot. Actually, the following two settings produce roughly the same (i.e. ledger lines so thick that they touch each other: \override StaffSymbol #'ledger-line-thickness = #'( 10 . 0 ) \override StaffSymbol #'ledger-line-thickness = #'( 0 . 1 ) And, yes, even Han-Wen agrees that this is confusing. See his comment in lily/staff-symbol.cc: /* For raggedright without ragged staves, simply set width to the linewidth. (ok -- lousy UI, since width is in staff spaces) --hwn. */ the second quite much, that is it becomes so heavy that the spaces almost disappear. Please compare the example: Things work as expected: The default line width is quite small and the first number is a multiplier for the default line width. The second one gives an additional width in staff space (i.e. the distance between each of the five lines of a standard staff). \override StaffSymbol #' ledger-line-thickness = #' ( 1 . .1 ) This uses the default line width + 1/10 of the staff space = 1/5 staff space \override StaffSymbol #' ledger-line-thickness = #' ( .1 . 1 ) This decreases the line with to 1/10 of its default (1/100 staff space!), but adds a full staff space (=distance between two ledger lines!), so of course all ledger lines touch each other. 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/ ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: StaffSymbol: line-positions
\score{
\new Staff \with {
\override StaffSymbol #' line-position = #' ( 6 3 0 -3 -6 )
}{
d' e' f' g' c''
} }
In my idea the second example should print wider spaces and set the notes
somhow off the lines, but it just prints the standard lines 4 2 0 -2 -4.
Why is this so?
Have you read the output produced by lilypond:
Warnung: Eigenschafts-Typprüfung für »line-position« (backend-type?) kann
nicht gefunden werden. vielleicht ein Tippfehler?
And indeed, you forgot the final s in line-position*s*...
BTW, your example shows a nasty bug with bar lines: They are drawn centered
around 0, so if the staff lines are placed asymmetric, the bar line is off..
Cheers,
Reinhold
Yeah, I tried it on a finnish Windows, and the messages get messed up
because the command line doesn't support utf8 -- and I obviously didn't
understand the message, either. But thanks to Mats I got it.
About the bug: I thought I would write: this works only with symmetrical
staff lines. As I understand everything is built around symmetrical
staves, but when thinking about it there could be a need for having the
staves positioned on an even number of half staff space positions, so it
would'nt be anymore symmetrical.
Can you add it to the bug tracker?
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: StaffSymbol: line-positions
The bar line should go from the uppermost staff line to the downmost
staff line, but now it gets centered on the middle position, so if the
upper or lower half of the staff extends more than the other (from the
middle counted) the bar line is misplaced.
Look at the example:
\new Staff \with {
\override StaffSymbol #' line-positions = #' ( 18 12 2 0 -2 -4 )
}{
d d d d
}
Thanks
Till
Valentin Villenave schrieb:
2008/4/1, Till Rettig [EMAIL PROTECTED]:
About the bug: I thought I would write: this works only with symmetrical
staff lines. As I understand everything is built around symmetrical staves,
but when thinking about it there could be a need for having the staves
positioned on an even number of half staff space positions, so it would'nt
be anymore symmetrical.
...
Can you add it to the bug tracker?
... As soon as I understand what this is about :)
Cheers,
Valentin
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
StaffSymbol: behaviour of ledger-line-thickness
Hi,
could somebody explain me how ledger-line-thickness behaves? The IR states that
it should be a pair:
ledger-line-thickness (pair of numbers)
The thickness of ledger lines. It is the sum of 2 numbers: The first is the
factor for line thickness, and the second for staff space. Both contributions
are added.
But I cannot get the staff space bigger (the second number), instead the first
number influences the thickness of the ledger line a bit, the second quite
much, that is it becomes so heavy that the spaces almost disappear.
Please compare the example:
\score{
\new Staff \with {
\override StaffSymbol #' ledger-line-thickness = #' ( 1 . .1 )
}{
d d d d
} }
\score{
\new Staff \with {
\override StaffSymbol #' ledger-line-thickness = #' ( .1 . 1 )
}{
d d d d
} }
\score{
\new Staff \with {
\override StaffSymbol #' ledger-line-thickness = #' ( .1 . .1 )
}{
d d d d
} }
\score{
\new Staff \with {
\override StaffSymbol #' ledger-line-thickness = #' ( 1 . 1 )
}{
d d d d
} }
What am I missing here? How is this supposed to work?
I was on 2.11.34, if it matters.
Thanks
Till
--
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games!
http://games.entertainment.gmx.net/de/entertainment/games/free
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Starting a new staff in the same line
Thanks, I remember this discussion, it also appeared to me that there might be some solution, but I thought maybe there would be another easier way like just letting the following score begin in the same line. I will check out the incipit issue. Greetings Till Mats Bengtsson schrieb: As far as I know, there's no easy way to insert a system start delimiter in the middle of a score. There was recently a long discussion on the mailing list, related to incipits, you may want to look there and see if any of the solutions discussed there may be useful. /Mats Till wrote: Ok, maybe I should rephrase the question to make it easier to understand: The first idea was to have a new score starting in the same line as the first one stops, but this seems not to work. Here's an image the user provided: http://www.nabble.com/file/p16323349/graphic.png Is there a workaround for that? Like stopping the staves, inserting white space, calling possibly staff brackets/braces again and start the staves again? Till wrote: Hi all, a user at lilypondforum.de asked how to stop a staff group and start a new one after a short white space with a new system start delimiter bracket. I couldn't really help, I pointed to the \startStaff and \stopStaff commands, but they won't produce the starting bracket. Also when making a new staff the first one gets continued and the second one aligned vertically under it. As a workaround I also gave the incipit workaround that is putting the score in the instrument name engraver. But this is not really working with staff groups: the vertical alignment is bad. And he also has incipits longer than one line so I don't know how they would behave -- I guess this is not possible. There is probably an easy solution, who knows it? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user - * * * * * * * * * * * * * * * * * * * * * * * * * LilyPond-Hilfe auch auf deutsch im LilyPond-Forum . - * * * * * * * * * * * * * * * * * * * * * * * * * LilyPond-Hilfe auch auf deutsch im http://www.lilypondforum.de/index.php LilyPond-Forum . ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Starting a new staff in the same line
Hi all, a user at lilypondforum.de asked how to stop a staff group and start a new one after a short white space with a new system start delimiter bracket. I couldn't really help, I pointed to the \startStaff and \stopStaff commands, but they won't produce the starting bracket. Also when making a new staff the first one gets continued and the second one aligned vertically under it. As a workaround I also gave the incipit workaround that is putting the score in the instrument name engraver. But this is not really working with staff groups: the vertical alignment is bad. And he also has incipits longer than one line so I don't know how they would behave -- I guess this is not possible. There is probably an easy solution, who knows it? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Snippet/template how to use lilypond-book with xelatex
Hi,
I was writing about this already some time ago, now I prepared a small
file that demonstrates how to use xelatex (and its advanced font
selection features) whith lilypond-book. This is only a workaround since
it pretends to lilypond-book to use pdflatex instead. But something like
this could be nice in the template section of the LM. I only cannot add
it myself to lsr, because it is not a lilypond snippet.
How are the lilypond-book templates handled, are they added also from lsr?
Greetings
Till
\documentclass{article}
\usepackage{ifxetex}
\ifxetex
%xetex specific stuff
\usepackage{xunicode,fontspec,xltxtra}
\setmainfont[Numbers=OldStyle]{Times New Roman}
\setsansfont{Arial}
\else
%This can be empty if you are not going to use pdftex
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{mathptmx}%Times
\usepackage{helvet}%Helvetica
\fi
%Here you can insert all packages that pdftex also understands
\usepackage[ngerman,finnish,english]{babel}
\usepackage{graphicx}
\begin{document}
\title{A short document with lilypond and xelatex}
\maketitle
Normal \textbf{font} commands inside the \emph{text} work,
because they \textsf{are supported by \LaTeX{} and XeteX.}
If you want to use specific commands like \verb+\XeTeX+, you
should include them again in a \verb+\ifxetex+ environment.
You can use this to print the \ifxetex \XeTeX{} command \else
XeTeX command \fi which is not known to normal \LaTeX .
In normal text you can easily use lilypond commands, like this:
\begin{lilypond}
{a2 b c'8 c' c' c'}
\end{lilypond}
\noindent
and so on.
The fonts of snippets set with lilypond will have to be set from inside
of the snippet. For this you should read the AU on how to use lilypond-book.
\selectlanguage{ngerman}
Auch Umlaute funktionieren ohne die \LaTeX -Befehle, wie auch alle anderen
seltsamen Zeichen: à ÄÄÅ, wenn sie von der Schriftart unterstützt werden.
\end{document}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
LSR how to move clefs on uneven staff lines?
Hi, I tried to get the clef right for this example from lsr:
upper = \relative c'' {
c1 d e f
}
lower = \relative c {
c1 b a g
}
\score {
\context PianoStaff
\new Staff
\upper
\new Staff {
\override Staff.StaffSymbol #'line-count = #4
\set Staff.clefGlyph = #clefs.F
\set Staff.middleCPosition = #6
\set Staff.clefPosition = #2
\set Staff.clefOctavation = #0
%\clef bass
\lower
}
}
But it doesn't change the position of the notes or the clefs. What is
here wrong? I tried as in NR 1.1.3.1
Greetings
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LSR how to move clefs on uneven staff lines?
OK, yes, it does work... :-) what I meant was with the settings of
middleC =7 and clef position =1. But: When I set the clef settings and
let the clef print explicitly with \clef bass it is again at the wrong
position (middleCPosition 6 and ClefPosition 2) even though I had said
it should be 7 and 1.
so you can't obviously use the \clef command with setting that way? Does
it read the defaults from engraver-init.ly?
Till
Trevor Daniels schrieb:
I'm not sure what you mean. It works as expected when
I try this in 2.11.34. You ask for a staff of four
lines, with middle C 6 half-staff-spaces above the center.
So the lower C will be 1 half-staff-space below the center,
which it is. The clef is 2 half-staff-spaces above the
center, also as specified. So what do you think is wrong?
Trevor D
-Original Message-
From: [EMAIL PROTECTED]
[mailto:lilypond-user-bounces+t.daniels=treda.co.u
[EMAIL PROTECTED] Behalf Of
Till Rettig
Sent: 01 March 2008 14:52
To: lilypond-user Mailinglist
Subject: LSR how to move clefs on uneven staff lines?
Hi, I tried to get the clef right for this
example from lsr:
upper = \relative c'' {
c1 d e f
}
lower = \relative c {
c1 b a g
}
\score {
\context PianoStaff
\new Staff
\upper
\new Staff {
\override Staff.StaffSymbol #'line-count = #4
\set Staff.clefGlyph = #clefs.F
\set Staff.middleCPosition = #6
\set Staff.clefPosition = #2
\set Staff.clefOctavation = #0
%\clef bass
\lower
}
}
But it doesn't change the position of the notes
or the clefs. What is
here wrong? I tried as in NR 1.1.3.1
Greetings
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: What term do you use?
Original-Nachricht Datum: Fri, 29 Feb 2008 09:46:42 +0200 Von: Risto Vääräniemi [EMAIL PROTECTED] An: till [EMAIL PROTECTED] CC: lilypond-user@gnu.org Betreff: Re: GDP: What term do you use? On 28/02/2008, till wrote: I just checked Felix Krohn again (well it is a bit outdated book but the best I could find here in the library) and he calls it oktaava : Thanks, Till, for checking this up. I asked my friend but he didn't remember any special name for it - he plays piano and organs and that kind of markings are probably not common in that kind on music. Korkeimmalla sävelalueella käytetään 8va (oktaava) merkintää viivaston yläpuolella... I think we could just put it oktaava merkintä. Note that he does a distinction in this way between oktaavi (Octave) and oktaava (Ocatvation ?). I guess the word is taken from the italian/latin origin. Did the book suggest using that as a common term for all octave changes (8va, 8vb, 15...)? 8va is easily translated as oktaava and it sounds pretty Finnish - 8vb and consecutively oktaavb on the other hand... :-) If we choose to use that then I'd loose the space and write it oktaavamerkintä (octava marking) or oktaavamerkki (octava mark). I think the normal use would be to call all of them oktaavamerkki, and say then something about one octave down or something like that. I mean, 8va obviously is an abbreviation, and 8vb even more, since the b means an own word (bassa). so yes, let's just have it oktaavamerkki (I actually would prefer -merkintä, since it applies to a longer section and consists also of the dottet line). till Greetings from Rovaniemi The same from Oulu. -Risto -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: NR 1.1 comment
Mats Bengtsson schrieb: Quoting Till Rettig [EMAIL PROTECTED]: Hi, I just noticed that the staff contexts of the examples in 1.1.3.5 are PianoStaff. In 1.6 there is only mentioned GrandStaff. Which one is the preferred one to be used? I would mention both in 1.6, but I think we should develop guidelines which context names to use. Maybe the PianoStaff is (at least to others than English native speakers) more understandable? So the context would be called PianoStaff in 1.6.1 but I would also mention that there is a GrandStaff context? So far I have understood that they are both equal. Is this true? In version 2.11, the only difference between the two is that PianoStaff contains the instrument name engraver. In version 2.10 and earlier, there were more differences. The PianoStaff then produced a fixed distance between the staves, since the cross-staff slurs and beams didn't work otherwise. This limitation has been fixed in 2.11. Ok, good to know. So PianoStaff should maybe be the default, so nobody will be wondering why the instrument name won't show up... What for is the GrandStaff then? Till /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: staff section
Trevor Daniels schrieb: Hi Till Might the tempo indication and metronome marks be better placed in the Rhythm section? If you think so let me know, as I'm working on Rhythms right now. Trevor D Hi, I think we should leave it as it is, after all it is nothing to do with _rythms_ specifically to indicate the tempo. I think it relates more with markup questions so I will see how to link to that section and explain only the relevant stuff directly related to the placement of context elements to a staff (as I would see tempo and instrument name...) Till -Original Message- From: [EMAIL PROTECTED] [mailto:lilypond-user-bounces+t.daniels=treda.co.u [EMAIL PROTECTED] Behalf Of Till Rettig Sent: 24 February 2008 13:19 To: lilypond-user Mailinglist Subject: GDP: staff section Hi GDP-helpers! I started now finally with the staff section of NR1. As with the repeat section, I would also suggest some new grouping. The order of the section is now the following: # 1.6 Staff notation * 1.6.1 Displaying staves o 1.6.1.1 System start delimiters o 1.6.1.2 Staff symbol o 1.6.1.3 Hiding staves * 1.6.2 Writing parts o 1.6.2.1 Metronome marks o 1.6.2.2 Instrument names o 1.6.2.3 Quoting other voices o 1.6.2.4 Formatting cue notes I was first wondering why writing parts is here at all, but I guess this should not be discussed too broad now, because it had been discuessed when we decided about the GDP chapter order. I was just thinking that combining parts and writing parts would be together something like a orchestral chapter -- even though you use it also in chamber music and the like. So I hope this grouping as it now is is intuitive enough to a new user that he figures out where to look for. The 1.6.1 section is really unevenly distributed over the three subsubsections, I was thinking of introducing a new subsection: modifying staves which would contain most of 6.1.1 and 6.1.2 So the new section model could be: 1.6 Staff notation 1.6.1 Displaying/writing/setting staves 1.6.1.1 Initiating a new staff (short basics, also one sentence about \new and \context, here should also go the example about starting stopping additional staves) 1.6.1.2 Grouping staves (about system start delimiters (maybe: 1.6.1.3: Deeper nesting of staff groups) 1.6.2 Modifying staves 1.6.2.1 Staff symbol, (and how to modify the different parameters) 1.6.2.2 Ossia staves 1.6.2.3 Hiding staves 1.6.3 Writing parts ... I have concentrated for now on this part leaving the parts section alone, I want to come back to it only when the first part is in better condition. There are still some general questions for the parts section for which I would like to hear some feedback: -Why is the metronome mark described here? It applies as well to a whole score (where it would be agreedly on the top stave...), and I think it should go together with a general description on how to write tempo indications (and also with a workaround to align the indication with the key or the meter, not with the first note of the first bar). Where could this section go? It is currently discussed in text marks, 1.8.1.4, but meant to write rehearsal marks, not tempo indications. -I think it is actually almost a bug in lilypond that there is no easy way to center the beginning of a tempo indictation on the key symbol, so I think it is important to provide at least an workaround clearly marked as such for this purpose. -We see the parts section as the sections that explains everything general about single parts -- so in this sense the metronome mark belongs here and also the tempo indication. But to me (and my German ears) the section caption points at preparing parts for each instrument of a bigger score. So I think we should change this section's caption. Ideas? -To me there is a distinction between the two first subsubsections (metronome marks and instrument names) and the two last (quoting voices and cue notes): the first two I would see more generally apllying to staves for each instrument/voice, the two last are what I understand by the word part, mainly concerned about the case where one has only one's own part and needs to get some context into it. So I could even imagine still a new subsection: 1.6.3 Additions to specific staves 1.6.3.1 tempo indication 1.6.3.2 metronome mark 1.6.3.3 instrument name 1.6.4 Adding context to a single part 1.6.4.1 quoting 1.6.4.2 cue notes But this is only a first thought. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman
GDP: staff section
Hi GDP-helpers! I started now finally with the staff section of NR1. As with the repeat section, I would also suggest some new grouping. The order of the section is now the following: # 1.6 Staff notation * 1.6.1 Displaying staves o 1.6.1.1 System start delimiters o 1.6.1.2 Staff symbol o 1.6.1.3 Hiding staves * 1.6.2 Writing parts o 1.6.2.1 Metronome marks o 1.6.2.2 Instrument names o 1.6.2.3 Quoting other voices o 1.6.2.4 Formatting cue notes I was first wondering why writing parts is here at all, but I guess this should not be discussed too broad now, because it had been discuessed when we decided about the GDP chapter order. I was just thinking that combining parts and writing parts would be together something like a orchestral chapter -- even though you use it also in chamber music and the like. So I hope this grouping as it now is is intuitive enough to a new user that he figures out where to look for. The 1.6.1 section is really unevenly distributed over the three subsubsections, I was thinking of introducing a new subsection: modifying staves which would contain most of 6.1.1 and 6.1.2 So the new section model could be: 1.6 Staff notation 1.6.1 Displaying/writing/setting staves 1.6.1.1 Initiating a new staff (short basics, also one sentence about \new and \context, here should also go the example about starting stopping additional staves) 1.6.1.2 Grouping staves (about system start delimiters (maybe: 1.6.1.3: Deeper nesting of staff groups) 1.6.2 Modifying staves 1.6.2.1 Staff symbol, (and how to modify the different parameters) 1.6.2.2 Ossia staves 1.6.2.3 Hiding staves 1.6.3 Writing parts ... I have concentrated for now on this part leaving the parts section alone, I want to come back to it only when the first part is in better condition. There are still some general questions for the parts section for which I would like to hear some feedback: -Why is the metronome mark described here? It applies as well to a whole score (where it would be agreedly on the top stave...), and I think it should go together with a general description on how to write tempo indications (and also with a workaround to align the indication with the key or the meter, not with the first note of the first bar). Where could this section go? It is currently discussed in text marks, 1.8.1.4, but meant to write rehearsal marks, not tempo indications. -I think it is actually almost a bug in lilypond that there is no easy way to center the beginning of a tempo indictation on the key symbol, so I think it is important to provide at least an workaround clearly marked as such for this purpose. -We see the parts section as the sections that explains everything general about single parts -- so in this sense the metronome mark belongs here and also the tempo indication. But to me (and my German ears) the section caption points at preparing parts for each instrument of a bigger score. So I think we should change this section's caption. Ideas? -To me there is a distinction between the two first subsubsections (metronome marks and instrument names) and the two last (quoting voices and cue notes): the first two I would see more generally apllying to staves for each instrument/voice, the two last are what I understand by the word part, mainly concerned about the case where one has only one's own part and needs to get some context into it. So I could even imagine still a new subsection: 1.6.3 Additions to specific staves 1.6.3.1 tempo indication 1.6.3.2 metronome mark 1.6.3.3 instrument name 1.6.4 Adding context to a single part 1.6.4.1 quoting 1.6.4.2 cue notes But this is only a first thought. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
GDP: NR 1.1 comment
Hi, I just noticed that the staff contexts of the examples in 1.1.3.5 are PianoStaff. In 1.6 there is only mentioned GrandStaff. Which one is the preferred one to be used? I would mention both in 1.6, but I think we should develop guidelines which context names to use. Maybe the PianoStaff is (at least to others than English native speakers) more understandable? So the context would be called PianoStaff in 1.6.1 but I would also mention that there is a GrandStaff context? So far I have understood that they are both equal. Is this true? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Several issues transcribing ancient notation (clefs, noteheads, spacing)
Benedict Singer schrieb: Oh wow, this looks even easier than the scheme function I was going to write to scale everything. Is this in the lsr? No, I didn't yet do anything, I send an example of tight spacing to the list some times. If not, perhaps the cadenza settings could be put in and it could be added. If you'd like a real example I can submit one of the transcriptions I'm doing when I finish. That would be great. Will they be on mutopia, by the way? Ben Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Align of Staff.instrumentName
Hi,
this is what I thought also, but yes, you will probably have to count it
for each score again (and also when scaling the notes?).
Copied also to user.
Greetings
Till
Stefan Slapeta schrieb:
Two first approaches (\context {\Staff ... } ):
\override InstrumentName #'self-alignment-Y = #0.31
and
\override InstrumentName #'Y-offset = #-1.9
- both not very smart (because hard coded)
Stefan
Till Rettig wrote:
Hello,
I am trying to have an incipit as part of the instrument name for
each staff. The example explains how it should look.
This goes to far well if there are no lyrics, the systems get
aligned. But if I add lyrics as in the example, there is obviously
added so much additional vertical space, that the new system gets too
wide. It is vertically centered, and that way the
staff is too high. Is there a way to say that the instrumentName
should be aligned at top?
Greetings
Till
___
lilypond-devel mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Help on changing staff sizes
Trevor Daniels schrieb:
As I said yesterday, I've already added this to the learning manual.
Maybe it needs to go somewhere in the Notation Reference too?
Sorry, thanks for adding to the LM, I meant this additional sentence to
go to the NR, chapter 5.2.1,
which is about spacing and page layout. It would then also be possible
to refer to that chapter from the LM.
Till
Trevor D
-Original Message-
From: [EMAIL PROTECTED]
[mailto:lilypond-user-bounces+t.daniels=treda.co.u
[EMAIL PROTECTED] Behalf Of
Till Rettig
Sent: 05 December 2007 16:49
To: Graham Percival
Cc: lilypond-devel; lilypond-user@gnu.org
Subject: Re: Help on changing staff sizes
Sorry, I try to say it in a way that it might be
added to the docs.
In 5.2.1 the @refbugs (line 495 in spacing.itely
on master) it states:
@code{layout-set-staff-size} does not change the
distance between the
staff lines.
Could we add a sentence:
Use instead the pair
fontSize = [EMAIL PROTECTED]
\override StaffSymbol #'staff-space
= #(magstep @var{N})
inside the Staff context to change the size of
the font and the distance
between
staff lines accordingly.
Actually I found, that the
@internalsref{StaffSymbol} at line 481 sends
to an uncomplete
documentation. The property staff-space is not
explained here. I thought
Y-extent might be of
help, but it is in turn explained by x-space
which again is missing from
the list. Who has the
knowledge to fix this?
Greetings
Till
Graham Percival schrieb:
What are we supposed to remember for the docs?
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Help on changing staff sizes
Sorry, I try to say it in a way that it might be added to the docs.
In 5.2.1 the @refbugs (line 495 in spacing.itely on master) it states:
@code{layout-set-staff-size} does not change the distance between the
staff lines.
Could we add a sentence:
Use instead the pair
fontSize = [EMAIL PROTECTED]
\override StaffSymbol #'staff-space = #(magstep @var{N})
inside the Staff context to change the size of the font and the distance
between
staff lines accordingly.
Actually I found, that the @internalsref{StaffSymbol} at line 481 sends
to an uncomplete
documentation. The property staff-space is not explained here. I thought
Y-extent might be of
help, but it is in turn explained by x-space which again is missing from
the list. Who has the
knowledge to fix this?
Greetings
Till
Graham Percival schrieb:
What are we supposed to remember for the docs?
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Help on changing staff sizes
thanks for this, it took me my time to figure out into which context to put it... Lilypond is not really userfriendly in many things... But well, there are some issues with that: The horizontal spacing doesn't get changed, like the space between a thick and a hair barline. Is there now chance to get everything with one command. We promise correct spacing and optical fontsizes, but if it is not possible to get them easily for part of your score only, I think this should be considered a bug. I would hope somebody could also add the missing information to the StaffSymbol documentation. Greetings Till Trevor Daniels schrieb: Hi Till Here's a clue that might help: % Reduce notes and staff fontSize = #-2 \override StaffSymbol #'staff-space = #(magstep -2) This reduces the size of the notes and the distance between the staff lines to match the reduced note size. Change the two -2s to suit your needs, but keep them the same value. Trevor D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Till Rettig Sent: 01 December 2007 16:29 To: lilypond-user Mailinglist Subject: [Norton AntiSpam] Help on changing staff sizes Hi, I need some help about changing the distance of staff lines: in NR 5.2.1 it says The context property fontSize and the layout property staff-space (in StaffSymbol) can be used to tune the size for individual staves. The sizes of individual staves are relative to the global size. and Known issues and warnings: layout-set-staff-size does not change the distance between the staff lines. If I click on the link to the StaffSymbol documentation, there is no staff-space property mentioned, well, it seems to be hidden in this y-extent, which is then explained by x-extent. But x-extent is missing. I would really much like to know the numbers that are used for the default so I can increase/decrease them accordingly. Why is the lyout-set-staff-size by the way changing only font size, while global-layout-set-staff-size works correctly? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Help on changing staff sizes
Hi, I need some help about changing the distance of staff lines: in NR 5.2.1 it says "The context property fontSize and the layout property staff-space (in StaffSymbol) can be used to tune the size for individual staves. The sizes of individual staves are relative to the global size." and "Known issues and warnings: layout-set-staff-size does not change the distance between the staff lines." If I click on the link to the StaffSymbol documentation, there is no staff-space property mentioned, well, it seems to be hidden in this y-extent, which is then explained by x-extent. But x-extent is missing. I would really much like to know the numbers that are used for the default so I can increase/decrease them accordingly. Why is the lyout-set-staff-size by the way changing only font size, while global-layout-set-staff-size works correctly? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Better vertical spacing in 2.11 adversely affects lyric spacing
Is there any possibility to make the spacing algorithm behave differently for Lyrics contexts that are included in a ChoirStaff compared to those that are not? That's the only way I could think of to deduce from the information available in the .ly file if the lyrics should be centered between staves or should be kept close to a single stave. I think its not that easy. I would use ChoirStaff as well for polyphonic music with only one voice per system, but as well I do songs, like the SATB example in de appendix, but with only one voice in the middle. It appeared somehow logical to me to use ChoirStaff for that two. But if we have it well enough documentated, we could have a VocalStaff and a ChoirStaff with different spacing. Till /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 59, Issue 78
Monk Panteleimon wrote: I think its not that easy. I would use ChoirStaff as well for polyphonic music with only one voice per system, but as well I do songs, like the SATB example in de appendix, but with only one voice in the middle. It appeared somehow logical to me to use ChoirStaff for that two. But if we have it well enough documentated, we could have a VocalStaff and a ChoirStaff with different spacing. I am curious to know whether anyone who does a lot of vocal music (of any variety) actually thinks that the current (2.10) vertical lyric spacing is problematic. Was it changed on its own merit or as part of other changes? Even with the keep-fixed-while-stretching set to ##t to fix the distance from the lower staff, I still altered my engraver-init.ly in 2.11 to match 2.10's, since some of the systems wound up too heavy on the bottom. I actually LIKE the 2.11 system! But I don't set that much music on the other hand, so maybe there are some situations, that I just don't encounter. But the peace I had begun some time ago on 2.10 and now finished on 2.11 got really enhanced! I am only missing a centered align for piano staves (to put dynamics into) and likewise one for choral music (for the lyrics). Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Problem with \markup
Hi, what is happening here? The first bar shows the version that a want,
the second then adds some markup text -- and screws the rest totally up!
Greetings
Till
%%
%EXAMPLE
%%
\version 2.11.33
u = { \change Staff = upper \stemDown \slurDown }
m = { \change Staff = lower \stemUp \slurUp }
sdown = {\stemUp \slurDown }
sup = {\stemUp \slurUp }
smid = {\stemDown \slurDown }
bass= \relative c {
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\set subdivideBeams = ##t
\set Voice.beatLength = #(ly:make-moment 1 8)
\times 2/3 {\stemUp r16 e,[\( b' g' \u b e] a[ g e\) \m \clef violin
ais\( b e] \u fis g b } e8\) \m
\clef bass
\times 2/3 {\stemUp r16 e_\markup{ \small \italic m. g.}[\( b' g'
\u b^\markup{ \small \italic m. d.} e] a[ g e\) \m \clef violin
ais_\markup{ \small \italic m. g.}\( b e] \u fis^\markup{ \small
\italic m. d.} g b } e8\) \m }
\score {
\new PianoStaff { \new Staff = upper \new Voice { \clef treble
\time 6/8 s4 s s s s}
\new Staff = lower \new Voice {\clef bass \bass }
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: add extender line to the glossary?
At least for the German translation I had really problems finding a word for that -- I think it is still untranslated... Is there any real term for this that could then also be translated easily? On the other hand -- so far we have this term, so it really should show up in the glossary if translations are not too difficult to find (in the other languages...). If some German speaking has ideas on the translation I will see to intergrate them... Greetings Till Graham Percival wrote: Should we add extender line to the glossary? Is this a real musical term, or a made-up lilypond term? Any vocalists want to comment? Cheers, - Graham ___ lilypond-devel mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplets (was: GDP for kids :)
2007/9/24, Henning Hraban Ramm [EMAIL PROTECTED]: As Mark Knoop wrote, (indeed das) Tupel is normally a vector and as a musical term seems to be as common as tuplet. For the German tuplets named Duole, Triole, Quartole, Quintole/Pentole etc. the neologism would have to be die Tupole, but I guess that's silly. In French, no generic term exist; when we translated the documentation we had to create a rather ugly mathematical word: since the terms we use are triolet == meaning triplet quartolet quintolet etc... We created the n-olet which is a neologism I haven't seen anywhere in French. But when I'll translate the comic into French, I think I'll just use triolet since it's by far the most common word. Valentin In order to also participate in this discussion, which also seems to confer to me ;-). The German translator, being me, has decided to use as well the N-tole construct which I remember having heard from my music theacher in high school. On other places in the manual I used rhythmische Konstruktionen, because the N-tole seemed to be so mathematical to me. Actually it wasn't hard guessing the tuplet meaning, probably being used to it from the Finale manual some years ago... but I hadn't heard of the word Tuplet before. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tuplets
Cześć Michał, fajnie, że ktoś chce tłumaczyć LP na język polski, bardzo się cieszę. michał poręba wrote: It seems to be a big problem for all of as. I am wanna-be polish translator and I have to admit that in my mother language people use tuplet, but only those who know Finale. None of encyclopedias, none of dictionaries I have mention that word. So what should I do? What should we do? Shell we use the Finale word? Use rhytmische Konstruktionen orkonstrukcje rytmiczne? rhythmic group, figure? I think, every translator can really think about what is the best possibility for their language. I don't see a problem that these translations differ from each other. This is also the case for other parts of the manual. I don't speak Polish so well, but konstrukcje rytmiczne sounds good to me... Or you might go the way in creating a new word... Should we find out a new LP name for that thing? I am fine with the English name of the thing, as it is intuitiv (at least to me) and somewhat spread among English speakers. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: GDP: rearrangement
Hello, from what so far has been discussed I catched somewhat the need is to group the issues more into single topic sections of subsections. For the discussion about the format of the html-docu: I would rather like to have whole subsections downloading than those tiny pages -- I also get lost on them and always have to go at least three steps up until I come again to the contents where I look for another promising section's name. So actually for me also a link to the toc would be sufficient, maybe also one to the index, to be on *every* page. I personally dislike the system that for going from a subsection to the next section demands climbing up one level -- I am probably too much used to reading real books where this kind of strange behaviour doesn't happen. But it might be a texinfo issue that we cannot incluence... About rearranging: I would suggest breaking up chapters (with only one number, like 6, 7, and so on) into smaller chapters in some cases, that is being more specific on the lowest level. For instance I could imagine a chapter Ancient music, and one on educational subjects. At least I don't see why Ancient is instrument specific, so why not put it in 7 from the current suggestion, right after educational and special noteheads. I didn't check the situation now but from the discussion about aligning cadenzas -- I would look for cadenzas either in grace notes (being something additional) or at rhythmic issues. From there we could have a link to a general chapter about aligning... I am also somewhat unpleasant with the current string section in the instrument specific chapter: I would like to see here all those \bowdown, \bowup, \flageolet, \thumb and so on that are in articulations so far -- or at least a link to them. Well, that's already about contents, not only rearranging. I like the text-section, that is a good idea. But going the same way for other stuff as well... Name of chapter 7 should maybe be changed, not everything is about decoration, there are some really important things. Would it be something like polishing, finishing or the like? Sorry for writing so confused, I hope it is still understandable. It's mainly just some thoughts... Greetings Till * 6 Basic musical notation o 6.1 Pitches + 6.1.1 Normal pitches + 6.1.2 Accidentals + 6.1.3 Cautionary accidentals + 6.1.4 Micro tones + 6.1.5 Note names in other languages + 6.1.6 Relative octaves + 6.1.7 Octave check + 6.1.8 Rests + 6.1.9 Skips o 6.2 Affecting multiple pitches + 6.2.1 Clef + 6.2.2 Key signature + 6.2.3 Transpose + 6.2.4 Instrument transpositions + 6.2.5 Ottava brackets o 6.3 Rhythms + 6.3.1 Durations + 6.3.2 Augmentation dots + 6.3.3 Tuplets + 6.3.4 Scaling durations + 6.3.5 Automatic note splitting + 6.3.6 Aligning to cadenzas o 6.4 Meter + 6.4.1 Time signature + 6.4.2 Partial measures + 6.4.3 Unmetered music + 6.4.4 Polymetric notation (alternating) + 6.4.5 Polymetric notation (simultaneous) + 6.4.6 Time administration + 6.4.7 Proportional notation (introduction) + 6.4.8 Automatic beams + 6.4.9 Manual beams + 6.4.10 Feathered beams o 6.5 Bars + 6.5.1 Bar check + 6.5.2 Barnumber check + 6.5.3 Multi measure rests + 6.5.4 Bar lines + 6.5.5 Bar numbers + 6.5.6 Rehearsal marks o 6.6 Polyphony + 6.6.1 Chords + 6.6.2 Stems + 6.6.3 Basic polyphony + 6.6.4 Explicitly instantiating voices + 6.6.5 Collision resolution + 6.6.6 Clusters + 6.6.7 Automatic part combining + 6.6.8 Writing music in parallel * 7 Decorating musical notation o 7.1 Connecting notes + 7.1.1 Ties + 7.1.2 Slurs + 7.1.3 Phrasing slurs + 7.1.4 Laissez vibrer ties + 7.1.5 Grace notes + 7.1.6 Analysis brackets o 7.2 Expressive marks + 7.2.1 Articulations + 7.2.2 Dynamics (absolute) + 7.2.3 Dynamics (crescendi) + 7.2.4 Breath marks + 7.2.5 Trills + 7.2.6 Glissando + 7.2.7 Arpeggio + 7.2.8 Falls and doits o 7.3 Staff notation + 7.3.1 System start delimiters + 7.3.2 Staff symbol + 7.3.3 Hiding staves + 7.3.4 Metronome marks
Subject: Deutsches Lilypond Forum
Hi Thomas, das sieht schön aus, ich werd mal schaun ob ich es schaffe, da aktiv dabei zu sein. :-) Habe auch schon eine Weile nachgedacht... Eigentlich ist die Idee von einem Forum fast besser als eine Mailing-Liste, jedenfalls ist die Hemmschwelle kleiner. Wie wäre es mit einer Notiz auf die LilyPond-Homepage? What do you think about putting a message into the news on the lilypond home page about this new German user space? Best, Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: example directories, was: ancient accidentals won't show
Graham Percival wrote: input/test/ is being removed; you'll find this file on LSR and in the snippets section. Ok, so this is a bug! In the whole documentation Example: -links link to input/test/ and not to lsr. This should be fixed. Is there any way to do is automatically? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
problems with repeats-doc, was: afterGrace
John Mandereau wrote: What about Chapter 9 Changing defaults? It's very practical, and it deals in detail with \tweak, \set and \override. Chapter 5 is only an introduction to tweaking, for beginners. Yes, I see, this is really good enough. If we give working examples in the sections before chapter 9 this won't be an issue, I guess. As always, don't fear asking other questions about unclear docs details like the afterGraceFraction thing. ;-) Yes, here is another one! I don't understand the logic behind the second example with volta repetition in 6.7.2. In my understanding the first fourth in the second volta (that is fourth repeat time) doesn't belong here. I would repeat the first part three times, and thus the upbeat fills the gap left by in the first volta which contains only three beats. But then I would skip the first volta and go directly to the second, and suddenly I have one beat too much in my music. What kind of convention is this meant to be? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
ancient accidentals won't show
Hi, what has happened to the file input/test/ancient-accidentals.ly http://lilypond.org/doc/v2.10/Documentation/user/source/input/test/collated-files#ancient-accidentals.ly (as referenced from chapter 7.7.2) in the development version? I find it only in the 2.10 branch. And taking the definitions from there, e.g. \override Staff.Accidental #'style = #'vaticana or mensural or medicaea or hufnagel doesn't show any effect. I don't even get any warning that some property is not found or anything like that. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with repeats-doc, was: afterGrace
I would prefer the second one as being more norm -- though the first
one is also completely understandable.
If we would choose the second one I would suggest to replace the
paragraph before with something like:
The next example shows a volta repeat with a partial measure. Note that
the upbeat is excluded from the repeat
but present inside the first volta bracket. The second volta bracket
contains a complete measure, but the last
measure of the piece is shortened due to the partial measure at the
beginning. See also @ref{Partial measures}
for this convention. The partial measure doesn't affect the repeat.
But then -- as I wrote this it appeared to me that this is nothing new
nor extra, so would it be better to skip the whole
example, because it doesn't introduce anything new?
Till
John Mandereau wrote:
Le samedi 19 mai 2007 à 12:18 +0300, Till Rettig a écrit :
John Mandereau wrote:
As always, don't fear asking other questions about unclear docs details
like the afterGraceFraction thing.
;-) Yes, here is another one! I don't understand the logic behind the
second example
with volta repetition in 6.7.2. In my understanding the first fourth
in the second volta (that
is fourth repeat time) doesn't belong here. I would repeat the first
part three times, and thus
the upbeat fills the gap left by in the first volta which contains
only three beats. But then
I would skip the first volta and go directly to the second, and
suddenly I have one beat too much
in my music. What kind of convention is this meant to be?
I assume the word you mean by 'fourth' is 'quarter (note)' in American
English, isn't it?
Well, I agree with you the first quarter a is extraneous, it should be
dropped:
\new Staff {
\partial 4
\repeat volta 4 { e | c2 d2 | e2 f2 | }
\alternative { { g4 g g } { \set Timing.measurePosition =
#(ly:make-moment 0 4) a a a a | b2. } }
}
but there is also a cleaner solution:
\new Staff {
\partial 4 e4
\repeat volta 4 { c2 d2 | e2 f2 | }
\alternative { { g4 g g e } { a a a a | b2. } }
}
IIRC I have already seen the second solution in printed scores, but not
the first. Which one should we put in the manual?
Cheers
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with afterGrace
John Mandereau wrote:
Le jeudi 17 mai 2007 à 16:42 +0300, Till Rettig a écrit :
this is my minimal example:
\version 2.11.23
\relative c'' { c1 {
Why do you use a brace after c1? It is more confusing than useful.
Yes, you are right, i wanted to create a single music expression,
thought this would bring the setting to work...
\set afterGraceFraction = #(cons 2 4)
afterGraceFraction is not listed in the Tunable context properties
(Program reference), and the manual doesn't tell you to use \set. Why
not try to set afterGraceFraction as a variable, like showLastLength for
example? It's better to set it not at toplevel, so you should use this
syntax:
#(define afterGraceFraction '(1 . 2))
where you can also use (cons 1 2) instead of '(1 . 2)
I didn't yet read anything deeper about scheme, you have to see me as
the average user (or maybe the straight reader) who
has read from the beginning of the whole documentation throughout this
chapter. Should we include a special chapter about syntax of tweaks (the
question about to which layer they can belong and with what syntax they
have to be defined)? This is somehow very shortly mentioned in chapter
5, but not really clear: I would think about something like the
differences between \override, \set, \tweak and then those scheme syntax
examples. This might be a introduction to the Notation reference part.
Unfortunately I don't know the differences myself, so I cannot really
help here. i am aware that chapter 12 gives a very deep view into the
matter, but what about just something very practical for the start?
Thanks for the help, this part is now much more clearer to me.
Greetings
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: problems with afterGrace
Well, I would like to, but I don't get this working yet. The line
\set afterGraceFraction = #(cons 2 4)
is obviously not correct in this form.
Graham Percival wrote:
I'm always willing to replace examples in the documentation; please
send me a better example.
Cheers,
- Graham
Till Rettig wrote:
Hello all,
I just tried to apply the example from the docs for 2.11, chapter
6.5.7 for changing the distance from afterGrace notes.
But I get always a warning that the right context cannot be found.
Would it be good to add a better example to the docs?
this is my minimal example:
\version 2.11.23
\relative c'' { c1 {
\set afterGraceFraction = #(cons 2 4)
\afterGrace d1 { c16[ d] } c4} }
\layout {
ragged-right = ##t
}
Greetings
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: question about the documentation
ok, this sounds resonable, I just didn't understand the passage. So to say: within a fifth means that it can be a second, third, and fourth, but not a fifth. Thanks for the explanations. Till Valentin Villenave wrote: 2007/5/12, Till Rettig [EMAIL PROTECTED]: Hi, while translating I found this sentence in the Docs Version 2.11.23 chapter 6.1.7: What does the fifth do here? Wouldn't it be better to say: inside the same octave or something like this? It seems I don't understand this passage. Why is it suddenly a fifth and not a fourth anymore? In French, we translated within a fifth by moins d'une quinte (less than a fifth in English) , which is maybe more easily understandable... Valentin Villenave ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
question about the documentation
Hi, while translating I found this sentence in the Docs Version 2.11.23 chapter 6.1.7: In the example below, the first check passes without incident, since the |e| (in |relative| mode) is within a fifth of |a'|. However, the second check produces a warning, since the |e| is not within a fifth of |b'|. The warning message is printed, and the octave is adjusted so that the following notes are in the correct octave once again. What does the fifth do here? Wouldn't it be better to say: inside the same octave or something like this? It seems I don't understand this passage. Why is it suddenly a fifth and not a fourth anymore? Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tex backend
Message: 9
Date: Mon, 12 Feb 2007 00:14:55 +0100
From: Dr. Johannes Zellner [EMAIL PROTECTED]
Subject: Re: tex backend
To: lilypond-user@gnu.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=utf-8
You wrote:
See also my other post from today where I ask how I could get a font
like (in latex)
\newfont{\lyfontFont}{texnansi-anttr scaled 1440}
for the lilypond lyrics.
I guess lilypond-book would perfectly do the job if I could manage to
get this font for the font lyrics.
I tried
\override Score . LyricText #'font-name = #texnansi-anttr
but this didn't work.
As far as I have understood this it is fairly easy to use otf fonts with
lilypond, there is a part in the documentation, I don't just remember the exact
part but you will find it, it is about using other fonts (in the example times
and arial, I think). Just insert this kind of line into the head of your files
and you will get the font globally converted.
With #(ly:font-config-display-fonts) you get all fonts that can be used by
lilypond in an easy way of inserting the line:
\override #'(font-name . Warnock Pro -- change the name to something you
have. Lilypond is looking for fonts in the fonts direcotry via pango, so the normal way
you install fonts on your debian should do it.
Since you use Antykwa torunska (is that right) they distribution also includes
otf fonts of the same font. Just pick them from there tex path and copy them to
the font directory, run the font update mechanism and it should show in the
list given from the first command in my mail.
hope this helpes you.
Greetings
Till
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sprechgesang
Hi, definitely interesting might be, that the autographs from Schönberg himself doen't contain this special symbols, but he set a cross instead of a notehead. Confer to http://www.schoenberg.at/6_archiv/music/works/op/compositions_op21_sources_e.htm# for instance page 12 of the cathegory B. I remember some explanations though that his intention was to keep the specified singing voice level, so the printed version might match his intention more. Greetings Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Some more German cathegory two)
We translated all testimonials excepted the ones from Chris Cannam (too difficult to translate) and Vaylor Trucks (easy to understand). Till, you're certainly right, we should also add the testimonials in English. Jan, shall I go ahead for French translation? Cheers -- John Mandereau [EMAIL PROTECTED] I don't know it myself. I also checked the french page then, but myself decided to just translate anything. I mean what's the difference? We don't mean to be scientifically correct in our statements, I interpret them as this angloamerican way of convincing users. I'm no thinking that it looks more beautiful if they are only in one language. greetings till -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: German translation update
Ok, I checked again the wiki pages and made a new version of my local git repository, and finally I got the right commitish and could add changes! Here is the patch! Till From 86c0ec8106a4fb525c95e6c24ff173952f76e823 Mon Sep 17 00:00:00 2001 From: Till Rettig [EMAIL PROTECTED](none) Date: Mon, 1 Jan 2007 19:10:25 +0200 Subject: [PATCH] addition and update of german translation --- de/about/automated-engraving/index.html |4 - de/about/thanks.html|6 + de/install/cygwin.html | 183 +++ de/install/using.html |4 - de/switch/testimonials.html | 175 ++ 5 files changed, 367 insertions(+), 5 deletions(-) diff --git a/de/about/automated-engraving/index.html b/de/about/automated-engraving/index.html index 18dee8a..6afc7ba 100644 --- a/de/about/automated-engraving/index.html +++ b/de/about/automated-engraving/index.html @@ -1,5 +1,5 @@ !-- -Translation of GIT committish: 670e5bd4d2077903e6a428e83c9af8d9dc16baab +Translation of GIT committish: 858ca3ce90eb63c0914e2766a1ffb59d2c115224 When revising a translation, copy the HEAD committish of the version that you are working on. Use @@ -14,7 +14,7 @@ read. this is not. maybe just scrap this menu and introduction to index? !-- -h1bdquo;Besessen damit, mit Tinte auf dem Papier zu zeichnenldquo;/h1 +h1bdquo;Besessen davon, mit Tinte auf dem Papier zu zeichnenldquo;/h1 a name=index/a h2Was steckt hinter LilyPond?/h2 diff --git a/de/about/thanks.html b/de/about/thanks.html index 1f29283..15709b2 100644 --- a/de/about/thanks.html +++ b/de/about/thanks.html @@ -1,5 +1,5 @@ !-- -Translation of GIT committish: 74f7ad76a984df5ed29fe9f11aa793b44eaaca5d +Translation of GIT committish: 858ca3ce90eb63c0914e2766a1ffb59d2c115224 When revising a translation, copy the HEAD committish of the version that you are working on. Use @@ -70,6 +70,10 @@ Freizeit spielt er Bratsche oder program liJean-Charles Malahieude, Gauvain Pocentek and John Mandereau, auf franzouml;sisch +/li + liFrancisco Vila und Daniel Tonda Castillo auf spanisch/li + liTill Rettig auf deutsch/li + p zur Verfuuml;gung gestellt. diff --git a/de/install/cygwin.html b/de/install/cygwin.html new file mode 100644 index 000..725ae11 --- /dev/null +++ b/de/install/cygwin.html @@ -0,0 +1,183 @@ +!-- +Translation of GIT committish: 858ca3ce90eb63c0914e2766a1ffb59d2c115224 + +When revising a translation, copy the HEAD committish of the +version that you are working on. Use + + git-rev-list HEAD | head -1 + +to discover that. +!-- + +titleLilyPond - mit Cygwin/title + +h1LilyPond mit Cygwin/h1 + +a name=installing/a +h2Installieren/h2 + +img src=@[EMAIL PROTECTED] align=right + +ul + li +Laden Sie sich ttsetup.exe/tt auf Ihren Computer, indem Sie +a href=http://cygwin.com/setup.exe;hier/a klicken. + /li + li +Wenn Sie Windows NT, 2000 and XP benutzen, muuml;ssen Sie evtl. zuerst Administrator werden + /li + + li +Starten Sie codesetup.exe/code + /li + + li +und klicken Sie bdquo;nextldquo;, bis Sie zum + /li + + li +strongPackage View/strong-Dialog kommen. Wauml;hlen Sie +LilyPond aus, es befindet sich im Abschnitt +strongPublishing/strong. + /li + + li +Jetzt wird LilyPond mit allen Unterstuuml;tzungsprogrammen installiert. +Dazu muuml;ssen 66 Mb heruntergeladen werden, die gesamte Installation +wird 260 Mb auf Ihrer Festplatte einnehmen. + /li + +/ul + +p + Wenn Sie sich nicht sicher sind, was von ttsetup.exe/tt abgefragt wird, + verauml;ndern Sie nicht die urspruuml;nglichen Einstellungen. +strongAuf keinen Fall/strong den voreingestellten Installationsordner + (codec:/cygwin/code) verauml;ndern und auch die Texteinstellungen + strongbei ihrem Originalwert/strong (UNIX muss als Typ benutzt werden) + strongbelassen/strong. +/p + + +h2Uuml;berpruuml;fung/h2 + +ul + li +a href=test.lyHier/a kouml;nnen Sie eine Testdatei herunterladen. + /li + + li +Speichern Sie sie auf Ihrem Desktop unter dem Namen tttest.ly/tt (und versichern +Sie sich, dass es strongnicht/strong +tttest.lyem.TXT/em/tt heiszlig;t). + /li + + li +Doppelklicken Sie auf die Datei. + /li +/ul + +Jetzt wird die Datei verarbeitet und das Ergibnis in einem Pdf-Betrachter angezeigt. + +h4Hurra, es klappt!/h4 + +p + Gut! Fahren Sie fort mit der a href=using.htmlBenutzung von LilyPond/a. +/p + +h4Hmm, ich weiszlig; wirklich nicht, was ich machen soll. Helft mir!/h4 + +p + Fragen und Bitte um Unterstuuml;tzung kouml;nnen Sie an die Mailingliste a + href=mailto:lilypond-user@gnu.org;lilypond-user@gnu.org/a schicken. +/p + +h4Mist, es klappt nicht!/h4 + +p + Versuchen Sie, nocheinmal ttsetup.exe/tt aufzurufen; dadurch werden etwa + 90% der Probleme gelouml;st. Versichern Sie
German translation help file
Hello, because it caused me some difficulties to understand how the git conventions for commting patches worked I wrote a small helper file so far called README.de in the web/ directory. Could somebody check it, proof read it and maybe also change something if I made mistakes? I add it in the patch form and another time the file itself so it is more easy to read. Thank you! Till From 0f876dc707a47267b40da3b9453c8f6d2ba29973 Mon Sep 17 00:00:00 2001 From: Till Rettig [EMAIL PROTECTED](none) Date: Mon, 1 Jan 2007 19:41:57 +0200 Subject: [PATCH] README.de added --- README.de | 56 1 files changed, 56 insertions(+), 0 deletions(-) diff --git a/README.de b/README.de new file mode 100644 index 000..c28cacb --- /dev/null +++ b/README.de @@ -0,0 +1,56 @@ +Dies ist eine Hilfsdatei für die Handhabung von der GIT-Repository +Verwaltung und für die Ãbersetzung der deutschsprachigen Internetseiten. +Auf jeden Fall muss die Datei README gelesen werden! + +Der normale Ablauf für die Erstellung/Bearbeitungen einer Ãbersetzung +geht wie folgt: + +Es muss git (und evtl. cogito) installiert sein, das letztere Vereinfacht +die Handhabung. Weitere Informationen finden sich auch noch im +LilyPond-Wiki (http://lilypondwiki.tuxfamily.org/index.php?title=Translations_HOWTO). + + +Mit + +cg clone git://git.sv.gnu.org/lilypond.git#web/master + +oder + +git pull git://git.sv.gnu.org/lilypond.git/ web/master: + +(die erste Methode scheint besser zu funktionieren) + +ein neues Verzeichnis erstellen, in dem sich die Quelle der +Webseite befindet. Dann können Dateien übersetzt werden und +in der Verzeichnisstruktur von de/... an der richtigen Stelle abgelegt werden. +Es ist dabei wichtig, dass die erste Zeile das commitish enthält, +eine eindeutige Identifikationsnummer, mit der nachverfolgt werden +kann, wer wann welche Veränderungen durchgenommen hat. Diese Nummer +lässt man sich wie folgt anzeichen: + +git-rev-list HEAD | head -1 + +Darauf müssen die veränderten Dateien registriert werden. +Wenn man nur Veränderungen vorgenommen hat, geschieht dies +folgendermaÃen: + +git-update-index Dateiname + +wenn man eine neue Datei übersetzt hat und sie abgespeichert hat, +muss man sie dem GIT-Verzeichnis erst hinzufügen mit + +git-add Dateiname + +Wenn alle Arbeit getan ist, teilt man dem System mit, dass jetzt eine +Revision stattgefunden hat: + +git commit -a -m 'Eine Nachricht, die die Veränderungen beschreibt' + +SchlieÃlich kann man aus den Veränderungen einen Patch erstellen: + +git format-patch committish^ + +wobei committish wiederum die Nummer ist, die man vorher herausgefunden hat. +Dabei werden einige Dateien erstellt, u.A. auch die Datei, die den Namen +hat, mit dem man git commit ausgeführt hat. Diese Datei wird dann per +E-Mail an lilypond-devel oder lilypond-user eingeschickt. -- 1.4.1 Dies ist eine Hilfsdatei für die Handhabung von der GIT-Repository Verwaltung und für die Ãbersetzung der deutschsprachigen Internetseiten. Auf jeden Fall muss die Datei README gelesen werden! Der normale Ablauf für die Erstellung/Bearbeitungen einer Ãbersetzung geht wie folgt: Es muss git (und evtl. cogito) installiert sein, das letztere Vereinfacht die Handhabung. Weitere Informationen finden sich auch noch im LilyPond-Wiki (http://lilypondwiki.tuxfamily.org/index.php?title=Translations_HOWTO). Mit cg clone git://git.sv.gnu.org/lilypond.git#web/master oder git pull git://git.sv.gnu.org/lilypond.git/ web/master: (die erste Methode scheint besser zu funktionieren) ein neues Verzeichnis erstellen, in dem sich die Quelle der Webseite befindet. Dann können Dateien übersetzt werden und in der Verzeichnisstruktur von de/... an der richtigen Stelle abgelegt werden. Es ist dabei wichtig, dass die erste Zeile das commitish enthält, eine eindeutige Identifikationsnummer, mit der nachverfolgt werden kann, wer wann welche Veränderungen durchgenommen hat. Diese Nummer lässt man sich wie folgt anzeichen: git-rev-list HEAD | head -1 Darauf müssen die veränderten Dateien registriert werden. Wenn man nur Veränderungen vorgenommen hat, geschieht dies folgendermaÃen: git-update-index Dateiname wenn man eine neue Datei übersetzt hat und sie abgespeichert hat, muss man sie dem GIT-Verzeichnis erst hinzufügen mit git-add Dateiname Wenn alle Arbeit getan ist, teilt man dem System mit, dass jetzt eine Revision stattgefunden hat: git commit -a -m 'Eine Nachricht, die die Veränderungen beschreibt' SchlieÃlich kann man aus den Veränderungen einen Patch erstellen: git format-patch committish^ wobei committish wiederum die Nummer ist, die man vorher herausgefunden hat. Dabei werden einige Dateien erstellt, u.A. auch die Datei, die den Namen hat, mit dem man git commit ausgeführt hat. Diese Datei wird dann per E-Mail an lilypond-devel oder lilypond-user eingeschickt. ___ lilypond-user
Re: German translation Part 2 3
Yes, I wrote a short message, but I don't now get the git to work out this patch, forgot how to update an already existing file, so I will send it this time directly. I just addes the message to the site/news.html file, hope that was right. Here ist the message also alone: /dd dtbttlilypond.org/tt auf deutsch/b - em31. Dezember 2006/em dd Die LilyPond-Webseiten sind jetzt auch auf deutsch uuml;bersetzt! /dd Hope this is sufficient. Thank you! Till PS: I got a lot of unresolved messages about all the files I sent in the patches: they got somehow saved with another name and the new version came from git with the original name. Is this about the commitish number or why could they not be merged? Jan Nieuwenhuizen wrote Thanks, this is great. Can you pull from GIT, add an entry for the news page, similar to the Spanish one, and send it in a new patch? Jan. lilypond.org auf deutsch - 31. Dezember 2006 Die LilyPond-Webseiten sind jetzt auch auf deutsch bersetzt! LilyPond 2.11.6 available - December 30, 2006 This release supports arbitrary fractional alterations, allowing music with different microtonal conventions to be typeset. (Bugfixes, Changes, Download) LilyPond 2.10.6 available - December 30, 2006 New! Improved! With even more bugfixes! (Bugfixes, Changes, Download) lilypond.org en español - December 29, 2006 ¡Ya está disponible la versión en español del sitio web de LilyPond! ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: German po-file and contact.ihtml
I am sorry, I don't get this git so far. I tried now some times git pull (Git-addresse) and another time git-pull (address). The file de.po got updated, but still I find for instance the file site/about/features.html to miss some things (eg. the mention of canorus at the bottom). I added them nevertheless to the translated file de/about/features.html. Then I did this git-add command. But again, when trying to get the commitish (do I now have to change them or not; I have no clue) I get the failure notice: there are no rules for make. But the least clear to me is this patch function: after doing: git-format-patch MY-FIRST-CHANGE^.. where my-first-change ist the commitish number found in my file on the top, there appears a lot of 000Number-some-description files, each time some new, but they are clearly old (their date is 21. of december) and show the diffs (additions and removals) done to the website's pages. How do I then get *my* patch file that I can send you? Because this didn't work so far, I will again send the corrected files po/de.po and de/contact.ihtml. I hope you can somehow merge them with the old ones. The new files that I added today with this git-add and git commit -- should I make a tarball mirroring the directory-structure, but only containing the new files or how is it best to send them? I'm really sorry that I make things so complicated. Hope I will understand this git sometimes, so I can then really use it... Greetings Till Jan Nieuwenhuizen wrote: Also, please pull the latest version from git and translate all entries. I removed some dutch translations, now the top menu on lilypond.org http://lilypond.org/web/index.de.html is not fully translated Home Introduction About Download Dokumentation Entwicklung Greetings, Jan. Diese Mailinglisten werden alle in englischer Sprache gefhrt. Wenn Sie etwas Englisch sprechen, sollten Sie ihre Frage auf englisch stellen. Wenn Sie kein Englisch knnen, schreiben Sie auf deutsch, es kann aber sein, dass weniger Antworten kommen. Fragen oder Kommentare? Hier knnen Sie direkt fragen. Das ist die lilypond-user@gnu.org-Mailingliste (Info (An- oder Abmeldung), Archiv) Fehler gefunden? Hier kann ein Fehlerbericht abgeschickt werden. Das ist die bug-lilypond@gnu.org-Fehler-Mailingliste (Info, Archiv) Benachrichtigung bei neuen Versionen Eine Benachrichtigung kann von der info-lilypond@gnu.org-Mailingliste abonniert werden. (Info, Archiv) Kommentare zum Internetauftritt? Kommentare knnen hier direkt gesendet werden. Oder eine E-Mail an die bug-lilypond@gnu.org-Fehler-Mailingliste schicken (Info, Archiv) Kontakt zu den Entwicklern? Hier kann direkt Kontakt aufgenommen werden. Hier ist die lilypond-devel@gnu.org-Entwickler-Mailingliste (Info, Archiv) Direkter Kontakt zu den Autoren? Siehe die Liste der Autoren. (Bitte ausschlielich bei persnlichem Kontakt!) # de.po -- LilyPond German website language file # Copyright (C) 2006 Till Rettig # This file is distributed under the same license as the LilyPond package. # #, fuzzy msgid msgstr Project-Id-Version: PACKAGE VERSION\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2006-11-27 17:43+0100\n PO-Revision-Date: 2006-12-31 09:50+0200\n Last-Translator: Till Rettig\n Language-Team: LANGUAGE [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #: scripts/old-page.py:196 scripts/new-page.py:197 scripts/format-page.py:221 #: site/menu-entries.py:4 scripts/format-page.py:216 #: scripts/format-page.py:230 scripts/format-page.py:234 #: scripts/format-page.py:235 scripts/format-page.py:240 #: scripts/format-page.py:231 scripts/format-page.py:241 #: scripts/format-page.py:242 scripts/format-page.py:243 #: scripts/format-page.py:247 scripts/format-page.py:248 #: scripts/format-page.py:252 scripts/format-page.py:255 #: scripts/format-page.py:251 scripts/format-page.py:250 msgid Home msgstr Startseite #: scripts/format-page.py:87 scripts/format-page.py:82 #: scripts/format-page.py:83 scripts/format-page.py:84 #: scripts/format-page.py:85 #, python-format msgid Other languages: %s. msgstr Andere Sprachen: %s. #: scripts/format-page.py:88 scripts/format-page.py:83 #, python-format msgid Using A HREF='%s'automatic language selection/A. msgstr Benutzung der A HREF='%s'automatischen Sprachauswahl/A. #: site/about/menu-entries.py:2 msgid Features msgstr Eigenschaften #: site/about/menu-entries.py:3 msgid FAQ msgstr FAQ #: site/about/menu-entries.py:4 msgid Essay msgstr Aufsatz #: site/about/menu-entries.py:5 msgid Publications msgstr Publikationen #: site/about/menu-entries.py:6 msgid Donate msgstr Spenden #: site/about/menu-entries.py:7 site/about/menu-entries.py:6 msgid Acknowledgements msgstr Danksagungen
German translation
Ok, so here comes the de.po-file (which is yet not compatible with my translation, since that is called new-de) Till # nl.po -- LilyPond Dutch website language file # Copyright (C) 2005 Jan Nieuwenhuizen [EMAIL PROTECTED], Tineke de munnik [EMAIL PROTECTED]. # Jan Nieuwenhuizen [EMAIL PROTECTED], 2005. # This file is distributed under the same license as the LilyPond package. # #, fuzzy msgid msgstr Project-Id-Version: PACKAGE VERSION\n Report-Msgid-Bugs-To: \n POT-Creation-Date: 2006-11-27 17:43+0100\n PO-Revision-Date: 2005-06-16 09:50+0200\n Last-Translator: Tineke de Munnik [EMAIL PROTECTED]\n Language-Team: LANGUAGE [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #: scripts/old-page.py:196 scripts/new-page.py:197 scripts/format-page.py:221 #: site/menu-entries.py:4 scripts/format-page.py:216 #: scripts/format-page.py:230 scripts/format-page.py:234 #: scripts/format-page.py:235 scripts/format-page.py:240 #: scripts/format-page.py:231 scripts/format-page.py:241 #: scripts/format-page.py:242 scripts/format-page.py:243 #: scripts/format-page.py:247 scripts/format-page.py:248 #: scripts/format-page.py:252 scripts/format-page.py:255 #: scripts/format-page.py:251 scripts/format-page.py:250 msgid Home msgstr Startpagina #: scripts/format-page.py:87 scripts/format-page.py:82 #: scripts/format-page.py:83 scripts/format-page.py:84 #: scripts/format-page.py:85 #, python-format msgid Other languages: %s. msgstr Andere talen: %s. #: scripts/format-page.py:88 scripts/format-page.py:83 #, python-format msgid Using A HREF='%s'automatic language selection/A. msgstr Gebruik van A HREF='%s'automatische taalkeuze/A. #: site/about/menu-entries.py:2 msgid Features msgstr Eigenschappen #: site/about/menu-entries.py:3 msgid FAQ msgstr FAQ #: site/about/menu-entries.py:4 msgid Essay msgstr Essay #: site/about/menu-entries.py:5 msgid Publications msgstr Publicaties #: site/about/menu-entries.py:6 msgid Donate msgstr Donaties #: site/about/menu-entries.py:7 site/about/menu-entries.py:6 msgid Acknowledgements msgstr Dankbetuigingen #: site/about/news/menu-entries.py:2 msgid Older news msgstr Oud nieuws #: site/menu-entries.py:5 msgid Introduction msgstr Introductie #: site/menu-entries.py:6 msgid About msgstr Over LilyPond #: site/menu-entries.py:7 site/install/devel.ihtml:36 #: site/install/devel.ihtml:81 site/install/devel.ihtml:127 #: site/install/stable.ihtml:152 site/install/stable.ihtml:253 #: site/install/old.ihtml:114 site/install/old.ihtml:218 #: site/install/devel.ihtml:116 site/install/stable.ihtml:150 #: site/install/stable.ihtml:251 site/install/old.ihtml:216 #: site/install/old.ihtml:219 site/install/devel.ihtml:85 #: site/install/stable.ihtml:151 site/install/stable.ihtml:252 #: site/install/old.ihtml:231 site/install/old.ihtml:232 #: site/install/old.ihtml:235 msgid Download msgstr Download #: site/menu-entries.py:8 site/devel/participating/menu-entries.py:3 #: site/install/devel.ihtml:139 site/install/stable.ihtml:139 #: site/install/stable.ihtml:147 site/install/devel.ihtml:138 #: site/install/stable.ihtml:152 site/install/stable.ihtml:154 #: site/install/install-2.10.ihtml:160 site/install/install-2.9.ihtml:160 #: site/install/install-2.8.ihtml:154 site/install/install-2.11.ihtml:160 msgid Documentation msgstr Dokumentation #: site/menu-entries.py:9 msgid Development msgstr Entwicklung #: site/devel/menu-entries.py:2 msgid Participate msgstr Mitarbeit #: site/devel/menu-entries.py:3 msgid Packaging msgstr Pakete-Erstellung #: site/devel/misc/menu-entries.py:2 msgid Finale ETF format msgstr Finales ETF-Format #: site/devel/misc/menu-entries.py:3 msgid Conferences relevant to LilyPond msgstr Konferenzen zum Thema LilyPond #: site/devel/misc/menu-entries.py:4 msgid Related online resources msgstr Verwandte Webseiten #: site/devel/notation/menu-entries.py:2 msgid appogiatura msgstr Vorschlag #: site/devel/notation/menu-entries.py:3 msgid Basso Continuo msgstr Basso Continuo #: site/devel/notation/menu-entries.py:4 msgid Color msgstr Farbe #: site/devel/notation/menu-entries.py:5 msgid Ligature msgstr Ligatur #: site/devel/participating/menu-entries.py:2 msgid Help wanted! msgstr Hilfe erwuuml;nscht! #: site/devel/participating/menu-entries.py:3 #: site/devel/participating/menu-entries.py:4 msgid Localization msgstr Lokalisierung #: site/devel/participating/menu-entries.py:4 #: site/devel/participating/menu-entries.py:5 msgid Standards msgstr Standarde #: site/download/windows/menu-entries.py:2 msgid Cygwin msgstr Cygwin #: site/download/windows/menu-entries.py:3 msgid Troubleshooting msgstr Problemlouml;sung #: site/download/menu-entries.py:2 site/install/menu-entries.py:2 msgid MacOS X msgstr MacOS X #: site/download/menu-entries.py:3 site/install/menu-entries.py:3 msgid Windows msgstr Windows #: site/download/menu-entries.py:4 site/install/menu-entries.py:4 #: site/install/menu-entries.py:2 msgid First use
Some more German cathegory two)
So here come the files that are marked with cathegory two. I will send them alone, so they would replace those with the same names in the tarball I sent earlier today. Now I started with the engraving-text, which is really quite a lot of work. I was just asking myself if it wouldn't be wiser to also first translate the introduction for very new novices from the documentation. What do you think? About the essay also some general ideas: I just tried to read it and was quite unhappy -- the text itself is agains all typographical rules concerning the length of lines. Would it be easy to change that by eg. putting the text into a (centered) table so there would be some 60 signs per line? The pictures of coure should take the whole browser window so you would see them in all detail. I guess this wouldn't demand much html-code. With testimonials.html I was not sure -- would it be clever to leave the original and translate it. And how about statements from Germans -- were they sent in English or are they already translations? Greetings Till Benutzung der automatischen Sprachauswahl Damit die Sprache automatisch ausgewhlt wird, muss die Standardsprache vorher im Browser festgelegt werden. Die Einstellung hngt von dem Browser ab. Mozilla Firefox Version 0.9 und neuer GNU/Linux Bearbeiten - Einstellungen - Erweitert - Allgemein - Sprachen - whlen Microsoft Windows Extras - Einstellungen - Erweitert - Allgemein - Sprachen - whlen In lteren Versionen muss in der Adresszeile about:config aufgrufen werden und der Wert von intl.accept_languages verndert werden. Mozilla / Netscape 4.x und neuer Bearbeiten - Einstellungen - Navigator - Sprachen Anmerkung: mit Netscape 4.x muss die Sprache unbedingt aus der vorhandenen Auswahl gewhlt werden. Es kann Probleme geben, wenn die Sprache selber eingegeben wird. Microsoft Internet Explorer Microsoft Windows Extras - Internetoptionen - (Allgemein) Sprachen MacOS Safari - Einstellungen - Web Browser - Sprachen/Schriftarten Diese Seite wurde bersetzt, das englische Original stammt von Debian, alle Rechte vorbehalten, 1997-2005 SPI; Siehe die Lizenzbedingungen. Debian is a registered trademark of Software in the Public Interest, Inc. Eigenschaften von LilyPond Eingabe der Musiksprache. Die Noten werden durch eine textuelle Musiksprache eingegeben. Die Eingabe kann mit jedem beliebigen Texteditor erfolgen, und es knnen verschiedene (National-)Sprachen verwendet werden. Die ASCII-Eingabesprache kann in (La)TeX, HTML und Texinfo integriert werden, so dass musikwissenschaftliche Arbeiten in einer einzigen Quelle geschrieben werden knnen. Musik und Layout sind strikt voneinander getrennt. Deshalb knnen etwa Partitur und Stimmen (durchaus auch in unterschiedlichem Layout) von der selben Quelle erstellt werden, und auch nderungen wirken sich immer gleichzeitig auf beide aus. Der Notensatz verbessert sich mit jeder (kostenlosen!) Programmaktualisierung. Noten knnen in verschiedenen typographischen Stilen bzw. nach unterschiedlichen Notationskonventionen gesetzt werden. Automatisierter qualitativ hochwertiger Satz. Automatische Notenabstnde, Zeilen- und Seitenumbrche. Vermeiden von Noten-, Punkt- und Pausenkollision im polyphonen Satz. Automatische Anordnung von Vorzeichen, Balken und Bgen. Der Benutzer braucht kein typographisches Fachwissen, um einen guten Notensatz zu erstellen. Während des Satzes ist keine Interaktion ntig, der Einsatz des Programmes kann automatisiert werden, wodurch besonders gut groÃe Datenbanken an digitalisierter Musik konvertiert oder algorythmische Musik gedruck werden werden knnen. Die Feta-Schriftart ist speziell für LilyPond designt. Ihre Notationssymbole ahmen getreu die schnen Symbole des Handgravursatzes nach. Es gibt sie als skalierbare Schriftart, aber auch als ein Metafont. Untersttzung fr viele Notationskonstruktionen. Spezielle Notation: Akkordbezeichnungen. Schlagzeugnotation. Bezifferter Bass. Vorschlge und Verzierungen. Gitarren-Notation. Grundlegende Tabulatur-Notation. Notation von Clustern und rhythmischen Gruppierungszeichen. Tremolos, sowohl fr einzelne Noten als auch Akkorde. n-tolen in allen denkbaren Verhltnissen. Polymetrische Notation. Mensuralnotation. Automatische Stichnoten. Automatisches Zusammenfgen von Orchesterstimmen. Vierteltonvorzeichen. Anzeige des Ambitus. Metronome-Bezeichnungen. Flageolet. Taktwiederholungen(Prozent-Stil). EasyNotation-Notenkpfe. Verstecken von beliebigen Notationselementen. Arpeggio-Zeichen. Ottava-Klammern. Verschachtelte Analyseklammern. Pedalnotation für Klaviermusik.
Re: German translation
Wow this worked fast -- this is actually my first bit of work for the great community, so quite happy that results are coming so quick. Jan Nieuwenhuizen wrote: For the next batch of files, please use this method. Please make sure that you only add files to the git archive that you are actually working on, so that you do not submit untranslated files. I had to remove a number of english and some empty files from the new-de tree. Yes, I will now try to do this update and from now on continue on the de directory. Will try to follow also the advices of the spanish translation thread to get this right. This cathegory two is now ready, I will look, how I send it in a better way. I am otherwise on my best way through the essay on engraving. So this might then come some time later on. How would you think, shouldn't also all the other files that are linked translated, like about the name and stuff like this? Is there some list or overview to see all the files that have links from the pages? And then about the tutorial (that part in the documentation): Because it is so directly linked from the main page, wouldn't it be usefull to even put this tutorial only online in the other language, even though there would be some strange language shift if going to the next chapter? Well, so far Cheers, Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Getting involved
Thank you Jan. So I tried now to get the diff with git (this is how I understand the command below. It seems there is quite a lot of addition, especially at the windows installation pages. Is there a way of applying them automatically to the already translated files so they would at least be up to date and then I could start correcting the new parts of English that were added. Second the translation so far is in my opinion too familiar -- I think it should be more polite, as to demonstrate that lilypond is really capable of doing demanding work with good typography and that it might really (and in my opinion also *should*) be used in commercial notation work. So for instance I would change forms into passive or then from second singular to second plural. This might reduce the coolness of the product, but adds a lot of trust in my opinion. greetings Till Jan Nieuwenhuizen wrote: That part needs to be checked using make check-translation LANG=de and updated, as well as proofread. Greetings, Jan. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Getting involved
This sounds like a good start. Does the translation so far only concern the webpage, or is there also some (of course now older) documentation translated? Well I will try to sort out my way on this... Greetings Till Till Rettig [EMAIL PROTECTED] writes: Hi Till, a while ago I thought i might put my own bit into the lilypond work. So I checked the stuff on the development pages and ended up that a German translation for the web page and the documentation would be a nice thing. But first I thought of asking here if there is this kind of project already under progress (like the similar case recently with the French docu). There was a project started by Marc Weber (Cc). Marc made an initial translation in July 2005. We then had discussions with a lot of suggestions going until 2006, but did not receive an update. Because of your post, I have just added Marc's last effort to the GIT repository. It would be up to you (and Marc) to see if this is helpful, or if you would want to start fresh. If we do not hear from Marc, I will try to add make the changes that Werner and I suggested to GIT. Marc, are you there? Do you have an updated version available? See http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=README;hb=web/master and http://git.sv.gnu.org/gitweb/?p=lilypond.git;a=blob_plain;f=TRANSLATION;hb=web/master for how to get started. See also the discussion about french documentation http://lists.gnu.org/archive/html/lilypond-devel/2005-04/msg00233.html that has lead to the french website. Greetings, Jan. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Getting involved
Hi everybody, a while ago I thought i might put my own bit into the lilypond work. So I checked the stuff on the development pages and ended up that a German translation for the web page and the documentation would be a nice thing. But first I thought of asking here if there is this kind of project already under progress (like the similar case recently with the French docu). I know that in the end i should move to the developer's list but for now it seems this list is bigger. Sure this would be quite a big project, so it would be interesting to hear if people like/need this and if there would be possible co-workers. First information about the process itself I got from the lilypondwiki, but it seems to be quite old information, and when I translated a page of the 2.11 docu according to this how-to and opened it in my browser, no pics where shown (wile being in their correct folders) -- is this then a problem that will only be fixed after the translation or is it the bug about the links that I encountered here? Another point is the support for ancient notation, especially the mensural or renaissance engravers. I think there should still be some work done, and I would be happy if I could also help here -- though I don't know will I actually be able to write some code; so far I have no experiences in programming. For instance the spacing of this music should be done quite differently to modern music, especially the ligatures leave as much space as the according durations would take by themselves, and this is not the way this notations was written. Another point are the symbols themselves, which look quite decently, but have not the same perfectness as the default notation symbols. Also I think there should be support for Black mensural notation, used until the 15th century in central Europe. I don't have much knowledge about font design at the moment, but would be glad if someone could point out where I could find some basics so I could start some drawing if this feature is welcomed. Greetings from Finland Till ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Bar numbering -- tweaking staves?
Hello,
I started putting a ChoirStaff together with multimetre mesures. Because
the score context calculates the bar numbering, it cannot gather anymore
information on all staves, since they appear to have different measure
numbers. One possibility is to add the bar_number_engraver to the staff
context, but this invokes ugly numbers for every single staff. I still
would prefer bar numbers on the top of the system, thus being valid only
for the upper voice.
So how can i seperate one staff (or voice) to which i can apply then the
bar_number_engraver, not affecting the other staves?
Greetings
Till
Example-file:
%%%Lily-file%%%
\version 2.8.4
sopran = { \time 4/4 a b a c f g fis e d c g a d2 c e c }
alt = { \time 3/4 a4 b a c f g \time 4/4 e2 b d f \time 3/4 a4 b a c g f }
\score {
\new ChoirStaff = Chor
\relative
\context Voice = sopran {\sopran \sopran}
\context Voice = alt {\alt \alt}
}
\layout{
\context { \Score
\remove Timing_translator
%\consists Bar_number_engraver%doesn't show any effect
}
\context {\Staff
\consists Timing_translator
\consists Default_bar_line_engraver
\consists Bar_number_engraver
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
midi-instrument problem
Hello,
does somebody have any idea, why I get only drum set as a midi
instrument for the following score:
\version 2.6.3
\include deutsch.ly
alt = {\relative c''
{
\time 4/4
\set Staff.midiInstrument = choir aahs
%\key g \minor
\clef treble
a2 c e1 d4 c h a
}}
tenor = {
\time 4/4
\set Staff.midiInstrument = choir aahs
%\key g \minor
% main
\clef treble_8
e2 c a1 h4 c d e
}
\score{
\context StaffGroup = choirStaff
\context Voice = alt \alt
\context Voice = tenor \tenor
\midi {\tempo 4=60 }
\layout {
}
}
It doesn't happen, when I don't make this predefinition of the voices
but insert one after the other into the \score directly via \new Staff
-command. But I actually would like to keep this definition as it makes
files much clearer.
Thank you
Till Rettig
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: midi-instrument problem
Thank you, that helped immedeately!
Greetings
Till
Mats Bengtsson schrieb:
First of all, I would recommend you to upgrade to the latest stable
version, 2.8. There are installation packages available for download
at www.lilypond.org for almost all operating systems.
I just tried your example with version 2.8 and it seems to work fine.
Possibly, it might help to explicitly instantiate the Staff contexts in
your \score, i.e. to replace
\context Voice =
by
\context Staff =
in your example.
/Mats
Till Rettig wrote:
Hello,
does somebody have any idea, why I get only drum set as a midi
instrument for the following score:
\version 2.6.3
\include deutsch.ly
alt = {\relative c''
{
\time 4/4
\set Staff.midiInstrument = choir aahs
%\key g \minor
\clef treble
a2 c e1 d4 c h a
}}
tenor = {
\time 4/4
\set Staff.midiInstrument = choir aahs
%\key g \minor
% main
\clef treble_8
e2 c a1 h4 c d e
}
\score{
\context StaffGroup = choirStaff
\context Voice = alt \alt
\context Voice = tenor \tenor
\midi {\tempo 4=60 }
\layout {
}
}
It doesn't happen, when I don't make this predefinition of the voices
but insert one after the other into the \score directly via \new
Staff -command. But I actually would like to keep this definition as
it makes files much clearer.
Thank you
Till Rettig
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
