Re: jazz chords
--- Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > > Kenneth Teh wrote: > > It seems to me that based on these observations, > what > > Lilypond needs is a context for creating chord > names > > that > > > > (1) does not try to actually build chords, ie, the > > MIDI output produces nothing. This way you avoid > all > > the problems associated with trying to describe a > > voicing which a jazz player is free to change > anyway. > > > > (2) treats only the chord root (and duration) as > > significant, thus allowing one to transpose the > chord > > names. > > > > (3) leaves the chord alterations as pure text > markup. > > Most chord alterations are pitch indepedent > anyway. > > That is, you say m7 for a minor 7th chord, 5- to > flat > > the fifth, and so on. > > > > Comments? > > > > I suppose you want > > (4) base/inversion to be transposabl > > too. > > I agree that it would be a good idea. I guess one > reason for our > resistance has been that this would effectively make > our own code > superfluous, and perpetuates the lack of standards > in chord naming. But > such is life, I guess. > > Would it be useful to be able to mix standard Lily > chords with these > free form ones, or is it better to have a separate > (possibly more > ergonomic mode?) > > I could add this as a sponsored feature for 130 EUR > (inc VAT for EU > individuals). > > -- > > Han-Wen Nienhuys - [EMAIL PROTECTED] - > http://www.xs4all.nl/~hanwen > > LilyPond Software Design > -- Code for Music Notation > http://www.lilypond-design.com > > I actually thought about adding your item 4 in my post, but decided against it. Yes, a transposable inversion would be nice. And for another 20 EUR, would you do transposable bass notes since not all bass notes are inversions. Then, there is the matter of polychords... Seriously though, I think a separate context would be easier than trying to merge Lily's existing structure. I must admit that I have found it useful to generate MIDI for both melody and chords to verify my input. So it is not superfluous. But, this is only something I do at the beginning. And, of the two, verifying the melody input is more important than the chords since the chance of making a wrong entry is greater with notes. The MIDI chords are pretty horrible. If I wanted a specific voicing, I would code the voicing note-wise instead of with a chord name. The lack of a standard chord notation will exist till you and I are no longer around. I would not worry about it. When I write g:7, I don't mean . It is only a indication. If I played with a bass player and saw a G7, I'd probably do . Not very g:7, is it? The whole point of jazz is improvisation and that includes improvising the harmony as well. With respect to David Arnold comments, I will defer to his greater knowledge about chord notation. I was merely thinking that it would be more practical to add a context instead of reworking an existing context that would probably break a lot of people's stuff. You have a mechanism for defining new contexts. Would it be possible to use this mechanism for this purpose? Ken ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Invisible notes, Scheme contexts, Syntax
Han-Wen Nienhuys writes: > I wonder whether this should be changed too. This would mean that > >\clef alto >\clef "alto" > > becomes > >\clef #"alto" > > or > >\clef #'alto > > > This will simplify the syntax a bit, at the expense ease of entry. > > What do you think? As a frequent user of lilypond with a certain need of quick music entry and thus looking at it from a strictly practical view would strongly prefer to keep the old short version. Although I understand your desire for a consequent system of syntax iwould personally see '\clef #"alto"' as being too many keystrokes and (sorry) ugly... Or am I the only one who uses lilypond since (with some practice) i am usually quicker than my collegues setting music with those famous commercial music softwares? just my two cents... > regs, and (of course) thanks for this really marvelous program! Indeed! yours, Arno -- http://www.arnowaschk.de ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Controlled aleatorism" notation
Andrzej Kopec wrote: Han-Wen Nienhuys writes: > > > > // \\ > > ||--|---|||- > > ||.-|---|--.|||- > > ||.-|---|--.|||- > > ||--o---|---|||- > > ||--o---|||- > > \\ // > > > > 1. is there any more suitable grob for this purpose? > > for what? Brackets or the wavy line? Sorry for lack of clearness. I meant brackets. I was looking for some graphical object which can be aligned to edges of StaffSymbol independently to duration of current note/rest/space. Rest seems to shift slightly to left if previous note-duration is longer. some non-rhythmical object would suit here better, i think. Your best bet would be the barline, I guess. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: jazz chords
On Wednesday 14 December 2005 09:39 pm, Kenneth Teh wrote:
> I know this is an old topic and various folks have
> discussed this at length on this list. Nonetheless,
> I'd like to throw in a few more remarks on the
> subject.
>
> It's true that the jazz chord names printed by
> lilypond are weird from a jazz perspective and it is
> also true that there is a mechanism via
> chordNameExceptions to tweak the output or one could
> always use text markup to do it exactly as one wishes.
> However, some observations:
>
> (1) Text markup for chords don't allow you to
> transpose chords. So, when I am writing out parts,
> the chordmode has a clear advantage since you can
> transpose the chord names via \tranpose.
>
> (2) \chordmode actually tries to build chords from its
> input. So, when you produce MIDI output, you will
> actually hear the chords played.
>
> (3) Chords on jazz charts are really indications. The
> actual voicing of a chord is left to the player.
>
> It seems to me that based on these observations, what
> Lilypond needs is a context for creating chord names
> that
>
> (1) does not try to actually build chords, ie, the
> MIDI output produces nothing.
Good as an option, but defeatist. If only lilypond used the standard
jazz chord indications of the 50's, with the sole addition of the
/bassnote from the 60's, and simply built the chord from the root
without concern for nonsense like avoiding doubling or including other
voices, it would work fine as long as you could easily define your own
chords. If chords were defined with a "g" assumed as root, any
similar chord names could simply be transpositions. In the 50's there
was a reform to eliminate all but \flat, \sharp, (, and ), from chord
names, and the only thing worth adding is / for bass note. By using
that system, there is no reason for special syntax for chord names.
Bob van der Poel does without special syntax in his 'mma'. I think a
'g' root assuming key of C is a much easier way than numbering half
steps. It would be nice to be able to have chord names simply print
the way they are typed, and using 'b' for flat and 's' or '#' for
sharp, that would be very easy to do.
This way you avoid all
> the problems associated with trying to describe a
> voicing which a jazz player is free to change anyway.
A jazz player is concerned with grabbing something right away.
Defaults exist, but a chord name doesn't describe an exact
voicing to change.
>
> (2) treats only the chord root (and duration) as
> significant, thus allowing one to transpose the chord
> names.
for example \chorddef {{ G7 = g, g b d' f' }{ G7(b5) = etc.}{...}}
would define D7, Eb7b5 or Eb7(b5), etc. also. Basses would be
transposed
with the other notes, and they would be lower case. Parentheses
optional for the definitions would be printed if present, otherwise not.
There is no ambiguity there at all. There is no such thing as a b7,
it's
dim7.
>
> (3) leaves the chord alterations as pure text markup.
> Most chord alterations are pitch indepedent anyway.
> That is, you say m7 for a minor 7th chord, 5-
b5 is flat 5th. Minuses are unacceptable in chord names. daveA
--
Free download of technical exercises worth a lifetime of practice:
"Dynamic Guitar Technique": http://www.openguitar.com/instruction.html
email: "David Raleigh Arnold" <[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>
(Full name in address field is needed to pass filter)
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Controlled aleatorism" notation
Han-Wen Nienhuys writes: > > > > // \\ > > ||--|---|||- > > ||.-|---|--.|||- > > ||.-|---|--.|||- > > ||--o---|---|||- > > ||--o---|||- > > \\ // > > > > 1. is there any more suitable grob for this purpose? > > for what? Brackets or the wavy line? Sorry for lack of clearness. I meant brackets. I was looking for some graphical object which can be aligned to edges of StaffSymbol independently to duration of current note/rest/space. Rest seems to shift slightly to left if previous note-duration is longer. some non-rhythmical object would suit here better, i think. Of course - all these things can be done with extra-offset for every grob. But I want to avoid that. > > > > > 2. Is there any way to typeset spanner exactly from one place to another, > > in manner that > >it starts at \stopStaff and stops at \startStaff ? > > why don't you change the number of stafflines to 1 and start a new > staff? Sounds reasonable > Another option is to override the stencil callback for StaffSymbol. this too > > If you have problems with this, I can cook up a sponsored aleatoric > example .ly , but I guess there will be lots of people eager to > demonstrate their elite L1l33P0nd ski11z :) They are my only hope. PEOPLE WITH ELITE LILY-SKILZ, where are you!!??! ;) TB: > At least in the US, the popularity was due, IMO, to the fact that this > sort of thing can get you (at least the appearance of) some rhythmic > complexity without having to scatter a bunch of tuplets everywhere. I would rather think of it as a coloristic effect than rhythmic complexity. On the other hand why to write lots of (strange) tuplets which would be performed approximately? and on the other other hand - very few people "unfold" trills... :) And at last: I believe this is available in lilypond? Thanks for response, Regards, /ak/ ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Invisible notes, Scheme contexts
Mats Bengtsson <[EMAIL PROTECTED]> writes: >>>I see some cases where this would be clearly a win. Few weeks ago, a >>>singer asked me to change all alto clefs to treble clefs in a >>>voice+piano reduction score. Just redefining the \clef music function >>>would have made that really easy and quick. >>> >>> >>> > A query replace alto -> treble is probably quicker than redefining the > function, at least if your name is not Nicolas Sceaux. :-) This score was really big. $ find ?-* -name "*ly" | wc -l 882 $ find ?-* -name "*ly" | xargs cat | wc -l 31446 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: autopackage 2.7.19 website link broken
Paul Scott <[EMAIL PROTECTED]> writes: > The change just made it to the website. The text and link point to > 2.7.19.1 but the actual version at > http://lilypond.org/download/binaries/autopackage/ is 2.7.19 so the > link doesn't work. my mistake, I just corrected it. thanks. Pedro Kröger ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 37, Issue 44
It's true that the jazz chord names printed by
lilypond are weird from a jazz perspective and it is
also true that there is a mechanism via
chordNameExceptions to tweak the output or one could
always use text markup to do it exactly as one wishes.
true
(1) Text markup for chords don't allow you to
transpose chords. So, when I am writing out parts,
the chordmode has a clear advantage since you can
transpose the chord names via \tranpose.
no, if you use chordNameExtensions, the name of chord root is
not affected with your text markup, only the chord "modifiers".
you still have to use \chordmode so you can also transpose chords
and play them in the midi file.
see "chord-name-exceptions.ly" in the regression tests, and change
the root of the chords inside theMusic block to e.g "d:7sus4" instead of
"c:7sus4". then you'll see D7wahh at the output :)
although it may be a bit misleading, in:
chExceptionMusic = {
1-\markup { \super "7" "wahh" }}
is not implicitly related to the "c" based chord, but
to the relative intervals inside the chord, in this case to all the
7sus4 chords, regardless of the root.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Controlled aleatorism" notation
Andrzej Kopec wrote: // \\ ||--|---|||- ||.-|---|--.|||- ||.-|---|--.|||- ||--o---|---|||- ||--o---|||- \\ // This notation was broadly used by Witold Lutosławski and Kazimierz Serocki (the greatest XX-cent. polish composers), and I suppose, that it isn't something strange to many other western Europe composers) To achieve that I've prepared stencils (as callbacks for print function, BTW method seen on this list) repOn-callback and repOff-callback. And then I insert them to Rest's print-function. Why rest? maybe because I couldn't find any better object. But rest isn't perfect frame for such things. Nevertheless this works in limited range, but works. Difficulties start if there is more than one voice/instrument. Also wavy line made with TrillSpanner, and it is very hard to exactly determine start and stop points, and exact vertical positioning in consecutive systems. So I have some questions: 1. is there any more suitable grob for this purpose? for what? Brackets or the wavy line? this means: some object which don't take place in "musical time" but can be ideally vertically and horizontally (in latter rests used to have obstacles) positioned to staff. This is similar to BarLine, and in past I had used BarLines (ie. |: and :|, with Timing_engraver in Staff context) for that, but if I put patterns with a little shift in subsequent staves I get lots of empty spaces on each staff (place for barlines in other staffs). Ideal would be some object with no X-extent. Any ideas? 2. Is there any way to typeset spanner exactly from one place to another, in manner that it starts at \stopStaff and stops at \startStaff ? why don't you change the number of stafflines to 1 and start a new staff? ie. \stopStaff \override Staff.StaffSymbol #'line-count = #1 \startStaff ... \stopStaff \revert Staff.StaffSymbol #'line-count \startStaff ... Another option is to override the stencil callback for StaffSymbol. If you have problems with this, I can cook up a sponsored aleatoric example .ly , but I guess there will be lots of people eager to demonstrate their elite L1l33P0nd ski11z :) -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: jazz chords
Kenneth Teh wrote: It seems to me that based on these observations, what Lilypond needs is a context for creating chord names that (1) does not try to actually build chords, ie, the MIDI output produces nothing. This way you avoid all the problems associated with trying to describe a voicing which a jazz player is free to change anyway. (2) treats only the chord root (and duration) as significant, thus allowing one to transpose the chord names. (3) leaves the chord alterations as pure text markup. Most chord alterations are pitch indepedent anyway. That is, you say m7 for a minor 7th chord, 5- to flat the fifth, and so on. Comments? I suppose you want (4) base/inversion to be transposabl too. I agree that it would be a good idea. I guess one reason for our resistance has been that this would effectively make our own code superfluous, and perpetuates the lack of standards in chord naming. But such is life, I guess. Would it be useful to be able to mix standard Lily chords with these free form ones, or is it better to have a separate (possibly more ergonomic mode?) I could add this as a sponsored feature for 130 EUR (inc VAT for EU individuals). -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen LilyPond Software Design -- Code for Music Notation http://www.lilypond-design.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Controlled aleatorism" notation
On 12/14/05, Andrzej Kopec <[EMAIL PROTECTED]> wrote: > Hello, > > I want to ask if there is (better) method of utilizing Lilypond to typeset > aleatoric > music. For these not familiar with subject: > http://en.wikipedia.org/wiki/Aleatoric_music > This notation was broadly used by Witold Lutosławski and Kazimierz > Serocki (the greatest XX-cent. polish composers), and I suppose, that > it isn't something strange to many other western Europe composers) FWIW, this sort of thing, also known as "box notation" (since there's frequently a square or rectangular black box enclosing the trigger material) was also quite a favorite of certain American composers during (primarily) the 60s and 70s. Jacob Druckman, for example. At least in the US, the popularity was due, IMO, to the fact that this sort of thing can get you (at least the appearance of) some rhythmic complexity without having to scatter a bunch of tuplets everywhere. The popularity in the US has since died off; Poland seems to be another story given that this sort of thing made in appearance in the hands of the Polish composers in Darmstadt at least as recently as last year. -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Umlaute" in \header
It's certainly no surprise that your "problems" started when you changed from 2.4 to 2.6, since in version 2.4 you could only use latin1 encoding (or plain ASCII), which means that LilyPond could only handle western European text, whereas in verson 2.6 you can "only" use UTF-8 encoding, which means that LilyPond can handle almost any language in the world. Maybe you have some setting in your .emacs file that prevents the multi-language support (MULE) to work correctly. For example, in my .emacs, I had a setting (setq-default enable-multibyte-characters nil) which prevented MULE from working correctly. Uncommenting that line solved the problem. An easy way to see if your .emacs is a problem is to run Emacs using 'emacs -q myfile.ly'. If you add the following lines to the end of your file, then Emacs will automatically use the correct UTF-8 encoding: %%% Local variables: %%% coding: utf-8 %%% End: /Mats Wolfgang Mechsner wrote: Indeed I use emacs in Linux. But it is very strange: 1. It worked always fine with Lilypond 2.4.6 and the following versions. Now I have 2.6.4.3. and the problem started. 2. And: it does not work with jedit! I love Lilypond but each upgrade serves a new surprise :-) Thank you, Wolfgang PS: Mats, sorry about this email to you without the list address! Am Mittwoch, 14. Dezember 2005 11:57 schrieb Mats Bengtsson: You haven't told us what operating system you use. However, if you use Windows, I have experienced exactly the same problem with saving UTF-8 from Emacs. It works in Linux, but I haven't tried to investigate what the problem is in Windows. Maybe someone else on the mailing list have been more successful with Emacs on Windows? One nice alternative that should work on all platforms is to use jedit, which has very convenient LilyPond support, see http://web.interware.hu/fodber/lilytut/ The simple solution I have used occasionally is to use notepad to enter the Unicode and save as UTF-8. /Mats Wolfgang Mechsner wrote: If I run my emacs in utf-8 mode, it does not work either! ??? Wolfgang Are you able to enter text as utf-8 (Unicode)? That's all that should be required; I have umlauted text in both headers and lyrics under 2.6.4. Quoth Wolfgang Mechsner: How can I get german Umlaute in \header! Lilypond Version 2.6.4.3 ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user -- = Mats Bengtsson Signal Processing Signals, Sensors and Systems Royal Institute of Technology SE-100 44 STOCKHOLM Sweden Phone: (+46) 8 790 8463 Fax: (+46) 8 790 7260 Email: [EMAIL PROTECTED] WWW: http://www.s3.kth.se/~mabe = ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Umlaute" in \header
The mystery was indeed in the .emacs file. The following setting (standard-display-european t) (set-language-environment 'Latin-1) contradicted the utf-8 setting: (custom-set-variables ... '(current-language-environment "UTF-8") '(default-input-method "rfc1345") '(global-font-lock-mode t nil (font-lock)) ... Thank you a lot for your solution! Wolfgang. Am Donnerstag, 15. Dezember 2005 12:27 schrieb Mats Bengtsson: > It's certainly no surprise that your "problems" started when you changed > from 2.4 to 2.6, since in version 2.4 you could only use latin1 encoding > (or plain ASCII), which means that LilyPond could only handle western > European text, whereas in verson 2.6 you can "only" use UTF-8 encoding, > which means that LilyPond can handle almost any language in the world. > > Maybe you have some setting in your .emacs file that prevents the > multi-language support (MULE) to work correctly. For example, in my > .emacs, I had a setting > (setq-default enable-multibyte-characters nil) > which prevented MULE from working correctly. Uncommenting that > line solved the problem. An easy way to see if your .emacs is a problem > is to run Emacs using 'emacs -q myfile.ly'. > If you add the following lines to the end of your file, then Emacs will > automatically use the correct UTF-8 encoding: > %%% Local variables: > %%% coding: utf-8 > %%% End: > >/Mats > > Wolfgang Mechsner wrote: > >Indeed I use emacs in Linux. But it is very strange: > > > >1. It worked always fine with Lilypond 2.4.6 and the following versions. > > Now I have 2.6.4.3. and the problem started. > > > >2. And: it does not work with jedit! > > > >I love Lilypond but each upgrade serves a new surprise :-) > > > >Thank you, > >Wolfgang > > > >PS: Mats, sorry about this email to you without the list address! > > > >Am Mittwoch, 14. Dezember 2005 11:57 schrieb Mats Bengtsson: > >>You haven't told us what operating system you use. However, if you > >>use Windows, I have experienced exactly the same problem with > >>saving UTF-8 from Emacs. It works in Linux, but I haven't tried > >>to investigate what the problem is in Windows. Maybe someone > >>else on the mailing list have been more successful with Emacs on > >>Windows? > >> > >>One nice alternative that should work on all platforms is to use > >>jedit, which has very convenient LilyPond support, see > >>http://web.interware.hu/fodber/lilytut/ > >> > >>The simple solution I have used occasionally is to use notepad > >>to enter the Unicode and save as UTF-8. > >> > >> /Mats > >> > >>Wolfgang Mechsner wrote: > >>>If I run my emacs in utf-8 mode, it does not work either! > >>> > >>>??? > >>> > >>>Wolfgang > >>> > Are you able to enter text as utf-8 (Unicode)? That's all that should > be required; I have umlauted text in both headers and lyrics under > 2.6.4. > > Quoth Wolfgang Mechsner: > >How can I get german Umlaute in \header! > >Lilypond Version 2.6.4.3 > >>> > >>>___ > >>>lilypond-user mailing list > >>>lilypond-user@gnu.org > >>>http://lists.gnu.org/mailman/listinfo/lilypond-user -- Wolfgang Mechsner Goebenstr. 3 49076 Osnabrück Telefon: 05 41 / 2 05 20 90 Mobil: 01 79 / 9 09 66 84 http://www.wolfgang-mechsner.de http://wolfsfundstuecke.blog.de Email: [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Invisible notes, Scheme contexts
I see some cases where this would be clearly a win. Few weeks ago, a singer asked me to change all alto clefs to treble clefs in a voice+piano reduction score. Just redefining the \clef music function would have made that really easy and quick. A query replace alto -> treble is probably quicker than redefining the function, at least if your name is not Nicolas Sceaux. :-) The more music functions there are, and the less hardcoded syntax is, the more extensible and flexible LilyPond is. Ideally, even \include should be some kind of (not only-)music function, so that users could define their own \include version (for including different files depending on some parameters for instance, or adding a path). I agree, it sounds like a good idea. As long as the added flexibility doesn't mean too much added confusion for the average user. Han-Wen's change to allow "string" instead of #"string" is clearly a change in the right direction. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: example of including lyrics into seperate files
On Thu, 2005-12-15 at 11:07 +0100, Mats Bengtsson wrote: > However, if you want the lyrics included also in the separate part for > guitar 2, it's a bit more tricky, at least if the rhythm of the second > guitar part does not match the lyrics, since then you don't have anything > in the score that the lyrics could get its rhythm from. I can think of > some more or less ugly hacks to include also guitar one but hide it so > it isn't printed, but maybe someone else on the list have a nice working > solution to propose. > >/Mats I do want the lyrics for guitar 2 but I luck out this time that the timing is the same but different notes. So I can use the lyrics in guitar2.ly. Thanks for the information. Stephen signature.asc Description: This is a digitally signed message part ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: example of including lyrics into seperate files
Just give an explicit name to the Voice of the first guitar:
firstGuitar = \context Voice GuitarOne {
then your commented lines should work directly.
For the separate parts, you could mark the lyrics with tags. A simple
alternative is to write out the full \score block for each separate version:
-- score.ly --
\version "2.6.5"
\include "piece.ly"
\score {
<<
\new Staff { << \global \firstGuitar >> }
\lyricsto "GuitarOne" \new Lyrics \firstVerse
\lyricsto "GuitarOne" \new Lyrics \secondVerse
\lyricsto "GuitarOne" \new Lyrics \thirdVerse
\lyricsto "GuitarOne" \new Lyrics \fourthVerse
\new Staff { << \global \secondGuitar >> }
>>
}
--- guitar1.ly --
\version "2.6.5"
\include "piece.ly"
\score {
<<
\new Staff { << \global \firstGuitar >> }
\lyricsto "GuitarOne" \new Lyrics \firstVerse
\lyricsto "GuitarOne" \new Lyrics \secondVerse
\lyricsto "GuitarOne" \new Lyrics \thirdVerse
\lyricsto "GuitarOne" \new Lyrics \fourthVerse
>>
}
However, if you want the lyrics included also in the separate part for
guitar 2, it's a bit more tricky, at least if the rhythm of the second
guitar part does not match the lyrics, since then you don't have anything
in the score that the lyrics could get its rhythm from. I can think of
some more or less ugly hacks to include also guitar one but hide it so
it isn't printed, but maybe someone else on the list have a nice working
solution to propose.
/Mats
Stephen Torri wrote:
I am playing around with the tag feature so that I can print out a
master score for a piece and the individual instrument music. In order
to follow along on the hymn I want to include the lyrics for all four
verses in the master score and the individual instrument music. Below is
the master lilypond file (piece.ly) and a instrument file (guitar1.ly).
I can print out the master score using score.ly and an instrument using
guitar1.ly.
Any idea of how to insert the lyrics into the score.ly and guitar1.ly
respectively"?
Stephen
piece.ly
\version "2.6.5"
global= {
\time 2/2
}
\header {
title = "Let All Mortal Flesh Keep Silence"
subtitle = \markup \normal-text \italic "The Lord is in his holy
temple; let all the earth be silent before him. Hab. 2:20"
arranger = "Arr. by Stephen Torri"
}
%---
% First guitar (regular)
%--
firstGuitar = \new Voice {
\set Staff.instrument = \markup {
...
%---
% Score
%---
music = {
<<
\tag #'(score guitar1) \new Staff { << \global \firstGuitar >> }
%\lyricsto "GuitarOne" \new Lyrics \firstVerse
%\lyricsto "GuitarOne" \new Lyrics \secondVerse
%\lyricsto "GuitarOne" \new Lyrics \thirdVerse
%\lyricsto "GuitarOne" \new Lyrics \fourthVerse
\tag #'(score guitar2) \new Staff { << \global \secondGuitar >> }
>>
}
-- score.ly --
%% guitar1.ly
\version "2.6.5"
\include "piece.ly"
\score {
\new StaffGroup \keepWithTag #'score \music
\layout{}
}
-- guitar1.ly
%% guitar1.ly
\version "2.6.5"
\include "piece.ly"
\score {
\keepWithTag #'guitar1 \music
\layout{}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: ignore \break \noBreak \noPageBreak commands for the score
A third alternative is to define an extra "line of music" that only
contains the break commands (and other differences between the
instrumental part and the score):
scorespecifics = { \skip 1*24 \break \skip 1*35 \break }
violinpartspecifics = { \skip 1*18 \break }
and then include these in the respective score blocks:
% Instrumental part:
\score{
\new Staff << \violinpartspecifics \violinmusic >>
}
% Score:
\score{
<<
\new Staff << \scorespecifics \violinmusic >>
\new Staff { \violamusic }
...
However, the \tag feature is probably the most convenient solution.
/Mats
Felix Hammer wrote:
Am Mittwoch, 14. Dezember 2005 19:33 schrieb Graham Percival:
On 14-Dec-05, at 3:33 AM, Felix Hammer wrote:
Is there an option to ignore \break ... commands from the violin-part
to print
the score?
Use \tag. See "multiple editions from the same source".
Cheers,
- Graham
much thx. that was what i'am looking for.
greetings
felix
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 2 questions concerning skips and dynamics
I would recommend you to first typeset your dynamics in a normal
stave attached to normal notes and make sure that you understand
exactly how they are positioned relative to the notes. Then, you can
simply replace the notes by skips and use them in the Dynamics
context instead. A good starting point, corresponding to what you
now have in your dynamics is:
\relative c'{
\time 2/4
c8\mf c4. \setTextCresc c\< c2 c4\f c\> c4\!
}
The misplaced text version crescendo is just one of several indications
that the template is a quick hack that would need polishing or an
complete redesign to work fully. It's really strange that nobody has
taken the time to revise it, since it apparently is used fairly often.
However, I wouldn't be surprised if the text version crescendi is
handled better by the alternative approach I referenced below.
/Mats
Thomas Ruedas wrote:
On Wednesday 14 December 2005 12:47, Mats Bengtsson wrote:
The duration of the skips is handled exactly as the duration of
ordinary notes. If you insert some bar checks, you will see that
the durations are probably not what you want:
Ok, thanks for confirming that.
Since the last duration specified above the dynamics is the d'8,
the duration of the first s is also an 8th note.
I don't think so: when I change the initial s into e.g. s2, the mf is
still placed at the beginning, but the subsequent stuff is moved to
the right. If things worked the way you say, this would imply that
the automatic propagation of durations has a scope larger than the
staff. I can't imagine that the developers would implement such a
design flaw.
In fact, I didn't find a way to move the mf further to the right.
You should note that the full template is a fairly ugly hack. There
[...]
http://lists.gnu.org/archive/html/bug-lilypond/2005-08/msg00130.htm
Thanks again for the pointer, I'll try it out as an alternative later.
However, it seems to me that the other problem I had, namely the
ill-positioned text-version crescendo is not solved by that either.
Is there a solution to that or is it a bug?
Sorry if these questions are quite basic, but I am still new to
lilypond and with little time, I make only slow progress.
Thomas
--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44 STOCKHOLM
Sweden
Phone: (+46) 8 790 8463
Fax: (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Invisible notes, Scheme contexts
Nicolas Sceaux <[EMAIL PROTECTED]> wrote: > Han-Wen Nienhuys <[EMAIL PROTECTED]> writes: > > > I wonder whether this should be changed too. This would mean that > > > >\clef alto > >\clef "alto" > > > > becomes > > > >\clef #"alto" > > > > or > > > >\clef #'alto > > > > This will simplify the syntax a bit, at the expense ease of entry. > > > > What do you think? > > I see some cases where this would be clearly a win. Few weeks ago, a > singer asked me to change all alto clefs to treble clefs in a > voice+piano reduction score. Just redefining the \clef music function > would have made that really easy and quick. > > The more music functions there are, and the less hardcoded syntax is, > the more extensible and flexible LilyPond is. Ideally, even \include > should be some kind of (not only-)music function, so that users could > define their own \include version (for including different files > depending on some parameters for instance, or adding a path). > I agree, it sounds like a good idea. /Henrik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scordature
Tomasz Bojczuk wrote: Concretly i need something like this (in apendix) Is it possibile ?? but exactliy, i can put only text Of course it's possible, it's LilyPond, right! ;-) If you browse through section "8.1.7 Overview of text markup commands", you will learn how to do the circled numbers and all other kind of stuff. /Mats ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: autopackage 2.7.19 website link broken
Paul Scott wrote: Pedro Kröger wrote: Paul Scott <[EMAIL PROTECTED]> writes: Is the web site behind or is 2.7.14.1 the latest safe version? the web is behind, I just updated it. The change just made it to the website. The text and link point to 2.7.19.1 but the actual version at http://lilypond.org/download/binaries/autopackage/ is 2.7.19 so the link doesn't work. Any reason I shouldn't install 2.7.19 for testing purposes? none I can think of. Thanks. 2.7.19 may have a problem that RemoveEmptyStaffContext triggers. I'll go back to 2.7.14.1 if that's the case. I this a version of this problem has been posted to LilyPond bugs. I will need to use 2.6.x for those projects until an autopackage with that problem fixed appears. Thanks, Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: autopackage 2.7.19
Pedro Kröger wrote: Paul Scott <[EMAIL PROTECTED]> writes: Is the web site behind or is 2.7.14.1 the latest safe version? the web is behind, I just updated it. Any reason I shouldn't install 2.7.19 for testing purposes? none I can think of. Thanks. 2.7.19 may have a problem that RemoveEmptyStaffContext triggers. I'll go back to 2.7.14.1 if that's the case. Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: "Umlaute" in \header
Indeed I use emacs in Linux. But it is very strange: 1. It worked always fine with Lilypond 2.4.6 and the following versions. Now I have 2.6.4.3. and the problem started. 2. And: it does not work with jedit! I love Lilypond but each upgrade serves a new surprise :-) Thank you, Wolfgang PS: Mats, sorry about this email to you without the list address! Am Mittwoch, 14. Dezember 2005 11:57 schrieb Mats Bengtsson: > You haven't told us what operating system you use. However, if you > use Windows, I have experienced exactly the same problem with > saving UTF-8 from Emacs. It works in Linux, but I haven't tried > to investigate what the problem is in Windows. Maybe someone > else on the mailing list have been more successful with Emacs on > Windows? > > One nice alternative that should work on all platforms is to use > jedit, which has very convenient LilyPond support, see > http://web.interware.hu/fodber/lilytut/ > > The simple solution I have used occasionally is to use notepad > to enter the Unicode and save as UTF-8. > >/Mats > > Wolfgang Mechsner wrote: > >If I run my emacs in utf-8 mode, it does not work either! > > > >??? > > > >Wolfgang > > > >>Are you able to enter text as utf-8 (Unicode)? That's all that should > >>be required; I have umlauted text in both headers and lyrics under > >>2.6.4. > >> > >>Quoth Wolfgang Mechsner: > >>>How can I get german Umlaute in \header! > >>>Lilypond Version 2.6.4.3 > > > >___ > >lilypond-user mailing list > >lilypond-user@gnu.org > >http://lists.gnu.org/mailman/listinfo/lilypond-user -- Wolfgang Mechsner Goebenstr. 3 49076 Osnabrück Telefon: 05 41 / 2 05 20 90 Mobil: 01 79 / 9 09 66 84 http://www.wolfgang-mechsner.de http://wolfsfundstuecke.blog.de Email: [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
