Re: Changing font of "Table of Contents"
On 4/25/09 5:38 PM, "Nick Payne" wrote:
> I'm putting together a book of pieces, and using a particular font for
> headers, footers, titles, subtitles, etc. The one place where I haven't
> figured out how to get that font used is for the header text for the table
> of contents that Lilypond creates. Each tocItem has the font I want by using
> \override #'(font-name etc, but how do I change the font for the actual text
> "Table of Contents" that Lilypond inserts corresponding to the \markuplines
> \table-of-contents in the ly source.
Ahh, after a bit more looking, I got it now.
In your paper block, define the variable tocTitleMarkup to be whatever you
want it to be.
\paper {
tocTitleMarkup = \markup \huge \override #'(font-name . "Courier")
\column {
\fill-line { \null "Custom Table of Contents" \null}
\hspace #1
}
}
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing font of "Table of Contents"
On 4/25/09 5:38 PM, "Nick Payne" wrote:
> I'm putting together a book of pieces, and using a particular font for
> headers, footers, titles, subtitles, etc. The one place where I haven't
> figured out how to get that font used is for the header text for the table
> of contents that Lilypond creates. Each tocItem has the font I want by using
> \override #'(font-name etc, but how do I change the font for the actual text
> "Table of Contents" that Lilypond inserts corresponding to the \markuplines
> \table-of-contents in the ly source.
>
> I tried using
>
> \markuplines {
> \override #'(font-name . "SpectrumMT SC")
> \table-of-contents
> }
>
> In the same way as inside \markup blocks, but that doesn't parse correctly
> and gives errors.
>
> Nick
If you look at ly/toc-init.ly, you'll see tocTitleMarkup. You'll want to
add font override to that markup.
Unfortunately, I haven't yet found out how to fix it from a lilypond file.
When I make a similar change in the lilypond file, the one in toc-init.ly
seems to override it.
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
table of contents page numbers are all question marks
In using the sample code from NR 3.2.4 Table Of Contents I get all my
page numbers as question marks. Even the example shows all the page
numbers are page 1. There is no info on how to get the page numbers to
increment, or how to manually insert the page numbers. (I did search the
archives and used google but found no answer.) My code is provided below.
Regards,
Chip
--
\version "2.12.2"
\header { tagline = ##f }
\paper {
tocTitleMarkup = \markup \huge \column {
\fill-line { \null "Song List" \null }
\hspace #1
}
%% use larger font size
tocItemMarkup = \markup \large \fill-line {
\fromproperty #'toc:text \fromproperty #'toc:page
}
}
\book {
\markuplines \table-of-contents
\tocItem \markup { Algun Dia (Rudy Palacios) }
\tocItem \markup { Carino Nuevo (Royal Jesters) }
\tocItem \markup { De Que Te Quejas Mi Amor (David Lee Garza) }
\tocItem \markup { El Reganado (Sunny & the Sunliners) }
\tocItem \markup { Intro (Street Player) (Chicago) }
\tocItem \markup { La Que Se Fue (Jimmy Edward) }
\tocItem \markup { Malos Enganos (Rudy Palacios) }
\tocItem \markup { Mi Cumbia, Mi Salsa (Ram Herrera) }
\tocItem \markup { Mi Lupita (Bob Gallarza) }
\tocItem \markup { Mi Qui Quito Mantecon (Rudy Palacios) }
\tocItem \markup { Muchachita Color Canela (Ram Herrera) }
\tocItem \markup { Por Esa Es Calle Vive (Roger Valazquez}
\tocItem \markup { Que Bien Te Miras (Rudy Palacios) }
\tocItem \markup { Que Vivan Los Tejanos (Rudy Palacios) }
\tocItem \markup { Te Regalo El Corazon (Rudy Palacios) }
\tocItem \markup { Todo Dicen (Jimmy Edward) }
\tocItem \markup { Vuela La Paloma (Latin Express) }
}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TextSpanner at Score level?
On 4/25/09 3:38 PM, "-Eluze" wrote: > > > > Carl D. Sorensen wrote: >> >> You use the Internals Reference. You find the object you want engraved >> under 3.1 All layout objects: 3.1.111 TextSpanner. >> >> The IR tells you that TextSpanners are created by Dynamic_engraver, >> New_dynamic_engraver, and Text_spanner_engraver. >> >> So then you look in section 2.2 Engravers and Performers (or you just >> click the link on Text_spanner_engraver. Section 2.2.117 >> Text_spanner_engraver tells you that this is part of all of the Voice >> contexts. So then you know which contexts to remove it from and >> which contexts to add it to. >> > thanks for your answer (and sorry i did not answer before, but i was busy > installing a new computer...) > > it is good to know you can find this information somewhere - but i was > thinking of a procedure listing all the actual or possible engravers or > contexts - maybe something similar to the function "list-all-grobs" which i > found in the snippets repository! I've not seen a "list all contexts" functon, but all of the contexts are listed in the Internals Reference, section 2.1. And all of the engravers are listed in the Internals Reference, Section 2.2. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Changing font of "Table of Contents"
Hi Nick,
On Sat, Apr 25, 2009 at 4:38 PM, Nick Payne wrote:
> I'm putting together a book of pieces, and using a particular font for
> headers, footers, titles, subtitles, etc. The one place where I haven't
> figured out how to get that font used is for the header text for the table
> of contents that Lilypond creates. Each tocItem has the font I want by using
> \override #'(font-name etc, but how do I change the font for the actual text
> "Table of Contents" that Lilypond inserts corresponding to the \markuplines
> \table-of-contents in the ly source.
>
> I tried using
>
> \markuplines {
> \override #'(font-name . "SpectrumMT SC")
> \table-of-contents
> }
You want you change the definition of tocTitleMarkup. The method is
explained here:
http://lilypond.org/doc/v2.12/Documentation/user/lilypond/Table-of-contents
Something like this should work:
%%%
\paper {
tocTitleMarkup =
\markup \override #'(font-name . "SpectrumMT SC") {
\fill-line { \null "Table of Contents" \null }
}
}
\markuplines \table-of-contents
%%%
-Patrick
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Changing font of "Table of Contents"
I'm putting together a book of pieces, and using a particular font for
headers, footers, titles, subtitles, etc. The one place where I haven't
figured out how to get that font used is for the header text for the table
of contents that Lilypond creates. Each tocItem has the font I want by using
\override #'(font-name etc, but how do I change the font for the actual text
"Table of Contents" that Lilypond inserts corresponding to the \markuplines
\table-of-contents in the ly source.
I tried using
\markuplines {
\override #'(font-name . "SpectrumMT SC")
\table-of-contents
}
In the same way as inside \markup blocks, but that doesn't parse correctly
and gives errors.
Nick
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Fingering font size on grace notes
This reduction seems about right to me, comparing the sizes on the normal and
grace notes:
\version "2.12.2"
gfsn = {
\once \override Fingering #'font-size = #-8
\once \override StringNumber #'font-size = #-8
\once \override Fingering #'padding = #0.2
\once \override StringNumber #'padding = #0.2
}
\relative c'
{
\override Fingering #'staff-padding = #'()
\override StringNumber #'staff-padding = #'()
\set fingeringOrientations = #'(left)
\set stringNumberOrientations = #'(down)
\tieDown \set tieWaitForNote = ##t
4 \grace { \gfsn 16[ ~ \gfsn ] } g4
}
Nick
> -Original Message-
> From: Neil Puttock [mailto:n.putt...@gmail.com]
> Sent: Sunday, 26 April 2009 00:30
> To: Nick Payne
> Cc: lilypond-user@gnu.org
> Subject: Re: Fingering font size on grace notes
>
> 2009/4/21 Nick Payne :
> > Fingering indications on grace notes doesn't shrink to be
> proportional to
> > the reduced size of the grace note, and the full size indication
> looks
> > excessively large alongside the note. It's easy enough to override -
> using
> > \override Fingering #'font-size = #-8 seems about right - but perhaps
> this
> > should happen automatically.
>
> You're right, it should be a default setting.
>
> Before I change this, do you have any thoughts about the sizes of
> string numbers and right hand fingerings?
<>___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Bug on markups migrating from 2.10 to 2.12
For guitar scores you might like these as well. Very similar functions for
harmonics and string number indications over multiple notes.
Nick
> -Original Message-
> From: Jonathan Kulp [mailto:jonlancek...@gmail.com]
> Sent: Saturday, 25 April 2009 21:47
> To: Nick Payne
> Cc: 'Allan Spagnol Comar'; lilypond-user@gnu.org
> Subject: Re: Bug on markups migrating from 2.10 to 2.12
>
> Nick Payne wrote:
> > I have attached the barre and half barre functions I use that work
> with
> > 2.12, and your test.ly modified to use them.
> >
> > Nick
> >
>
> Those are nice barre indicators, Nick. Thanks. :)
% usage e.g.:
% \harmonics "harm. 8va " #0 #'(0 . -0.5) #5 #1
% \startTextSpan -> -> g c bf'-> ef, af-> c,\stopTextSpan
harmonics = #(define-music-function (parser location text osp shorten adjBreak adjEnd) (string? number? pair? number? number?) #{
% set osp to 999 if spanner is colliding with another element
% this will position the spanner outside all other elements
% can be normally be set to zero
\once \override TextSpanner #'outside-staff-priority = #$osp
\once \override TextSpanner #'bound-details #'left #'text = \markup { \teeny $text }
% setup dashed line and draw a bracket edge on RHS
\once \override TextSpanner #'dash-period = #1.5
\once \override TextSpanner #'dash-fraction = #0.6
\once \override TextSpanner #'thickness = #0.8
\once \override TextSpanner #'bound-details #'right #'text = \markup { \draw-line #'(0 . -0.5) }
% set alignment of line with reference to left text
\once \override TextSpanner #'bound-details #'left #'stencil-align-dir-y = #CENTER
\once \override TextSpanner #'bound-details #'left #'padding = #(car $shorten)
\once \override TextSpanner #'bound-details #'right #'padding = #(cdr $shorten)
% allow adjustment of line end when it wraps to following stave
\once \override TextSpanner #'bound-details #'right-broken #'padding = #$adjEnd
% adjust LH end of line when it wraps to following stave so that it doesn't
% extend to the left of the notes on the stave
\once \override TextSpanner #'bound-details #'left-broken #'X = #$adjBreak
% optional override to remove text and bracket edge at line breaks
% \once \override TextSpanner #'bound-details #'left-broken #'text = ##f
\once \override TextSpanner #'bound-details #'right-broken #'text = ##f
#})
% usage e.g.:
% \stringUp "2" #0 #'(0 . -0.5) #5 #1
% \startTextSpan -> -> g c bf'-> ef, af-> c,\stopTextSpan
stringUp = #(define-music-function (parser location stringnum osp shorten adjBreak adjEnd) (string? number? pair? number? number?) #{
% set osp to 999 if spanner is colliding with another element
% this will position the spanner outside all other elements
% can be normally be set to zero
\once \override TextSpanner #'outside-staff-priority = #$osp
\once \override TextSpanner #'bound-details #'left #'text = \markup \bold { \teeny \concat { \circle { \finger $stringnum } " " } }
\once \override TextSpanner #'font-shape = #'upright
% setup dashed line and draw a bracket edge on RHS
\once \override TextSpanner #'dash-period = #0.8
\once \override TextSpanner #'dash-fraction = #0.6
\once \override TextSpanner #'thickness = #0.8
\once \override TextSpanner #'bound-details #'right #'text = \markup { \draw-line #'(0 . -0.5) }
% set alignment of line with reference to left text
\once \override TextSpanner #'bound-details #'left #'stencil-align-dir-y = #CENTER
\once \override TextSpanner #'bound-details #'left #'padding = #(car $shorten)
\once \override TextSpanner #'bound-details #'right #'padding = #(cdr $shorten)
% allow adjustment of line end when it wraps to following stave
\once \override TextSpanner #'bound-details #'right-broken #'padding = #$adjEnd
% adjust LH end of line when it wraps to following stave so that it doesn't
% extend to the left of the notes on the stave
\once \override TextSpanner #'bound-details #'left-broken #'X = #$adjBreak
% optional override to remove text and bracket edge at line breaks
% \once \override TextSpanner #'bound-details #'left-broken #'text = ##f
\once \override TextSpanner #'bound-details #'right-broken #'text = ##f
#})
% usage e.g.:
% \stringDn "2" #0 #'(0 . -0.5) #5 #1
% \startTextSpan -> -> g c bf'-> ef, af-> c,\stopTextSpan
stringDn = #(define-music-function (parser location stringnum osp shorten adjBreak adjEnd) (string? number? pair? number? number?) #{
% set osp to 999 if spanner is colliding with another element
% this will position the spanner outside all other elements
% can be normally be set to zero
\once \override TextSpanner #'outside-staff-priority = #$osp
\once \override TextSpanner #'direction = #DOWN
\once \override TextSpanner #'bound-details #'left #'text = \markup \bold { \teeny \concat { \circle { \finger $stringnum } " " } }
\once \override TextSpanner #'font-shape = #'upright
% setup dashed line and draw a bracket edge on RHS
\once \override TextSpanner #'dash-period = #0.8
\once \override Tex
Re: TextSpanner at Score level?
Carl D. Sorensen wrote: > > You use the Internals Reference. You find the object you want engraved > under 3.1 All layout objects: 3.1.111 TextSpanner. > > The IR tells you that TextSpanners are created by Dynamic_engraver, > New_dynamic_engraver, and Text_spanner_engraver. > > So then you look in section 2.2 Engravers and Performers (or you just > click the link on Text_spanner_engraver. Section 2.2.117 > Text_spanner_engraver tells you that this is part of all of the Voice > contexts. So then you know which contexts to remove it from and > which contexts to add it to. > thanks for your answer (and sorry i did not answer before, but i was busy installing a new computer...) it is good to know you can find this information somewhere - but i was thinking of a procedure listing all the actual or possible engravers or contexts - maybe something similar to the function "list-all-grobs" which i found in the snippets repository! -- View this message in context: http://www.nabble.com/TextSpanner-at-Score-level--tp23119922p23236720.html Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New fonts for chords
On 4/25/09 2:36 PM, "Pekka Siponen" wrote: > Indeed it (suffix position) is a personal preference, and not correct > most likely. I find that there is no standard for chord names, they have > been around only for a short time historically, and mostly everything is > based on personal preferences.. as are all traditions when you go back > far enough. :P Usually the suffix is on the baseline, but it is beacause > finale standard layout is that way. The publishers in finland usually > only accept finale based work. For me the suffix is nice when top > aligned. Also more compact. There are certainly plenty of chord names around with raised suffixes. I was just hoping that you had some place you could point to a standard, so we'd improve our understanding. > > Sharps and flats: sorry I can't point you to any authority that would > say so, except basic typographical books. The sharps and flats look like > they don't belong there. They should look like a natural part of the > text, not something added later by a different program. =) No offence > intended. > None taken. And no offense intended by me, either. I agree with you that the chord names should look nice typographically. > Alas, I am only proficient in using fonts, not making them. :( And I am proficient in neither, so you're one up on me! I think that you should post your requests for improved alignment of raised 7 and sharps and flats to bug-lilypond, along with a sample of current LilyPond output and a sample of desired output for each of your cases. It will show up as an enhancement request, and may be an engraving nitpick, with low priority, but it *will* be on the list. > > The override is indeed simple, but for a novice user learning the > override and the things behind it, is a big step (worth taking > perhaps..). Also it is basic typographical thing to keep it simple with > fonts; if there is no need to start mixing fonts, so why do it..? I'm not sure who has the decision authority to change the default chord name font to roman, but if lots of users made that request on lilypond-user, I would guess that it would happen. In the meantime, we could add a snippet to the LSR that shows how to change the chord name font to roman. As a matter of fact, *you* could add that snippet to the LSR, and it would be available for others to use. And you'd be part of LilyPond development team. We'd love to have you come along with us! BTW, the LSR is found at http://lsr.dsi.unimi.it/ > > I tried to make a fairly complex but simple chords-notes(with > alternative repeats)-lyrics score. I found out everything that is > needed, but still failed. One of the reasons was this typographical > dilemma. It was getting too complicated, and I think would soon have > required some programming (and font-making) knowledge. Have you asked for help on the user list? This should be relatively straightforward, except that I don't understand what "complex but simple" means. If you can create a simple example of your score that demonstrates the difficulties, I'm sure you'll get help here. The typographical dilemma for chord names may be able to be resolved (at least temporarily) with some not-so-simple overrides... > > I was very pleased with the spacing with the LilyPond, also some glyphs, > especially the natural, received positive comments from the musicians: > it was easily distinguished from the sharp.. it had a distinctive color. :) > Good -- I'm glad you found the quality desirable! Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: crankiness
Having worked on the docs for 4 years and approximately three thousand hours, you really don't need to convince me. Just convince others -- and perhaps yourself -- that it's worth getting involved. My work at this point is a meta-contributor: I contribute (teach) people how to contribute to lilypond. If nobody steps forward to do the work, then it doesn't get done. Cheers, - Graham I haven't done much beyond the elementary stuff, but I'll look through the snippets pages more closely. I don't what I could contribute but I'm certainly willing. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New fonts for chords
Indeed it (suffix position) is a personal preference, and not correct most likely. I find that there is no standard for chord names, they have been around only for a short time historically, and mostly everything is based on personal preferences.. as are all traditions when you go back far enough. :P Usually the suffix is on the baseline, but it is beacause finale standard layout is that way. The publishers in finland usually only accept finale based work. For me the suffix is nice when top aligned. Also more compact. Sharps and flats: sorry I can't point you to any authority that would say so, except basic typographical books. The sharps and flats look like they don't belong there. They should look like a natural part of the text, not something added later by a different program. =) No offence intended. Alas, I am only proficient in using fonts, not making them. :( The override is indeed simple, but for a novice user learning the override and the things behind it, is a big step (worth taking perhaps..). Also it is basic typographical thing to keep it simple with fonts; if there is no need to start mixing fonts, so why do it..? I tried to make a fairly complex but simple chords-notes(with alternative repeats)-lyrics score. I found out everything that is needed, but still failed. One of the reasons was this typographical dilemma. It was getting too complicated, and I think would soon have required some programming (and font-making) knowledge. I was very pleased with the spacing with the LilyPond, also some glyphs, especially the natural, received positive comments from the musicians: it was easily distinguished from the sharp.. it had a distinctive color. :) Carl D. Sorensen wrote: On 4/25/09 12:52 PM, "Pekka Siponen" wrote: Here are some thoughts about the default chords in LilyPond: 1. The suffixes should not be scaled (see attachment). The weight of the smaller character gets too light if it is simply scaled down from the original font. Thanks for making a pdf that shows what you mean. Perhaps we could make the 7 symbol bold as well as raising it. 2. The suffix should be top-aligned with the preceding characted. Is this an engraving standard or just a personal preference? I'm not disagreeing with you, but we try to make changes to LilyPond only in response to music engraving standards. Every book I've been able to find in my (admittedly limited) collection just keeps everything on the same line -- no raising of suffixes. I've read about different standards in different regions, but have no personal knowledge of that. 3. The sharps should be centered and the flats should be aligned with the baseline. (Or something done in general, the sharps and flats look out of place) Can you point us to an engraving standard that we could use to make this decision? So, maybe (typographically correct) new fonts for chords in the future..? If you're willing to make new fonts for chords, I would guess that you could get them accepted as part of LilyPond, but I don't think there is a current developer who will be spending time doing that. I understand that it is a big job to develop a new font. Also, it seems funny to me that the default font for chords is sans serif, when the default font otherwise is serif. Why not use the default roman font also for chords? I assume (maybe incorrectly) that it's because somebody early on thought that the sans fonts were better for chord names. In my quick review of my books, it appears that the chord names and the lyrics generally share the same type face (sans or serif). It is a *very* simple override to change to the roman font. Put the follwing in your ChordNames context: \override ChordName #'font-family = #'roman and you'll have your roman chord names. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
Looks great, Marc! *Very* nicely done. On 4/25/09 4:06 AM, "Marc Hohl" wrote: > Hello tablature users*, > > > 3) some more tunings are defined: >guitar-seven-string-tuning >guitar-drop-d-tuning >bass-four-string-tuning >bass-drop-d-tuning >bass-five-string-tuning >bass-six-string-tuning >(yes I know, the already defined "bass-tuning" is the same as my > "bass-four-string-tuning", but > as I write music for various basses, this is easier to read at first > glance.) As your comment indicates, you will want to move these to scm/output-lib.scm. When you are up to speed on git, please do so. Once you send me a patch, I'll check it and push to git, and it will become part of LilyPond. Oh, by the way, you will want to make a standard LilyPond comment block at the top of the file -- see existing files for a pattern. > > 4) commandos for palm mute playing and dead notes are supported (palm > mute is not a tablature-specific >issue, but as electric guitar players use tablature and often play > palm mute, I think this is ok). >At first I thought of using \x for dead notes, but in other threads > \x is used for almost everything, >so I leave it to the user to say x = \deadNotes and use \x for faster > typing myriads of dead notes :-) This is exactly the right thing to do. LilyPond defined functions should always be descriptive. If users want the convenience of defining a shortcut, it's quite easy to do so. > > Yet again, I would like to thank Carl for his great help and patience, > and as far as I can see now, > making contributions to lilypond is easier than one might think, there > are a lot of people outside > willing to help you, if you are willing to bring lilypond further on, so > give it a try! > You're very welcome. It's always a pleasure to help somebody who is learning to contribute! Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New fonts for chords
On 4/25/09 12:52 PM, "Pekka Siponen" wrote: > Here are some thoughts about the default chords in LilyPond: > > 1. The suffixes should not be scaled (see attachment). The weight of the > smaller character gets too light if it is simply scaled down from the > original font. Thanks for making a pdf that shows what you mean. Perhaps we could make the 7 symbol bold as well as raising it. > 2. The suffix should be top-aligned with the preceding characted. Is this an engraving standard or just a personal preference? I'm not disagreeing with you, but we try to make changes to LilyPond only in response to music engraving standards. Every book I've been able to find in my (admittedly limited) collection just keeps everything on the same line -- no raising of suffixes. I've read about different standards in different regions, but have no personal knowledge of that. > 3. The sharps should be centered and the flats should be aligned with > the baseline. (Or something done in general, the sharps and flats look > out of place) Can you point us to an engraving standard that we could use to make this decision? > > So, maybe (typographically correct) new fonts for chords in the future..? > If you're willing to make new fonts for chords, I would guess that you could get them accepted as part of LilyPond, but I don't think there is a current developer who will be spending time doing that. I understand that it is a big job to develop a new font. > Also, it seems funny to me that the default font for chords is sans > serif, when the default font otherwise is serif. Why not use the default > roman font also for chords? I assume (maybe incorrectly) that it's because somebody early on thought that the sans fonts were better for chord names. In my quick review of my books, it appears that the chord names and the lyrics generally share the same type face (sans or serif). It is a *very* simple override to change to the roman font. Put the follwing in your ChordNames context: \override ChordName #'font-family = #'roman and you'll have your roman chord names. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
On 4/25/09 1:31 PM, "Neil Puttock" wrote: > Perhaps the point I was trying to make got lost in my slightly > facetious reply: if we're talking about LSR snippets which are in the > docs, the LSR editor must be mindful of the fact that editing such > examples in LSR may have no effect, since they can be shadowed by > revised snippets in input/lsr. I thought makelsr.py got snippets from the lsr and copied them into input/lsr. Is that wrong? Cqrl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
2009/4/25 Neil Puttock : > Perhaps the point I was trying to make got lost in my slightly > facetious reply: if we're talking about LSR snippets which are in the > docs, the LSR editor must be mindful of the fact that editing such > examples in LSR may have no effect, since they can be shadowed by > revised snippets in input/lsr. ...or even `revised snippets in input/new.' :) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
2009/4/25 Graham Percival : > On Sat, Apr 25, 2009 at 11:22:56AM -0600, Carl D. Sorensen wrote: >> >> On 4/25/09 9:37 AM, "Neil Puttock" wrote: >> >> > 2009/4/23 Jonathan Kulp : >> >> Graham Percival wrote: >> >> >> >>> 1. Log in to LSR as an editor. (I remember the discussion now; >> >>> this isn't your fault) >> >>> >> >>> 2. Find the "tags" section for each snippet. >> >>> >> >>> 3. Click on the drop-down menus, and select the relevant tags. >> >>> >> >>> 4. There is no #4. >> >> >> >> Is "save" #4? >> >> >> >> Thanks for the rundown, Graham. As you've said, this is very easy and I >> >> figured it out myself as reported in previous email... >> > >> > 4. Note that one of the snippets isn't tagged as `docs', which means >> > it's in input/new. >> > >> > 5. Find the snippet in input/new, and add the tag there instead. >> > >> > 6. Scratch #5, since the snippet shouldn't be in input/new in the first >> > place. > > Those steps 4-6 are when you're looking at git. My steps 1-4 > (including the "save snippet") are strictly for LSR stuff, which > is all that I'm claiming is trivial. I would *never* claim that > git is trivial. Perhaps the point I was trying to make got lost in my slightly facetious reply: if we're talking about LSR snippets which are in the docs, the LSR editor must be mindful of the fact that editing such examples in LSR may have no effect, since they can be shadowed by revised snippets in input/lsr. There's no point in retagging `Outputting the version number' in LSR if it's going to be ignored when makelsr.py is run. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
New fonts for chords
Here are some thoughts about the default chords in LilyPond: 1. The suffixes should not be scaled (see attachment). The weight of the smaller character gets too light if it is simply scaled down from the original font. 2. The suffix should be top-aligned with the preceding characted. 3. The sharps should be centered and the flats should be aligned with the baseline. (Or something done in general, the sharps and flats look out of place) So, maybe (typographically correct) new fonts for chords in the future..? Also, it seems funny to me that the default font for chords is sans serif, when the default font otherwise is serif. Why not use the default roman font also for chords? Please comment =) chordfonts.pdf Description: Adobe PDF document ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
On Sat, Apr 25, 2009 at 11:22:56AM -0600, Carl D. Sorensen wrote: > > On 4/25/09 9:37 AM, "Neil Puttock" wrote: > > > 2009/4/23 Jonathan Kulp : > >> Graham Percival wrote: > >> > >>> 1. Log in to LSR as an editor. (I remember the discussion now; > >>> this isn't your fault) > >>> > >>> 2. Find the "tags" section for each snippet. > >>> > >>> 3. Click on the drop-down menus, and select the relevant tags. > >>> > >>> 4. There is no #4. > >> > >> Is "save" #4? > >> > >> Thanks for the rundown, Graham. As you've said, this is very easy and I > >> figured it out myself as reported in previous email... > > > > 4. Note that one of the snippets isn't tagged as `docs', which means > > it's in input/new. > > > > 5. Find the snippet in input/new, and add the tag there instead. > > > > 6. Scratch #5, since the snippet shouldn't be in input/new in the first > > place. Those steps 4-6 are when you're looking at git. My steps 1-4 (including the "save snippet") are strictly for LSR stuff, which is all that I'm claiming is trivial. I would *never* claim that git is trivial. If a snippet isn't in LSR, then the LSR editor -- at least, the type of "LSR editor" that I keep on wanting a newbie to be -- doesn't worry about it. People with git access mess around in git; non-developers mess around in LSR. The whole point of LSR was to allow for this division of labour; if developers are using the web interface of LSR, then it means the whole thing was a waste[1]. [1] Again, quite literally. We could have -- and I'm still not convinced that we *shouldn't have* -- junked the idea of LSR, and gone with small files in git. Much simpler for everybody involved. But no, I let myself get talked into the web 2.0 / wiki garbage, and went along with LSR as a compromise. Hundreds of hours of development time later (LSR infrastructure, importing snippet infrastructor, build system stuff, etc etc), we *still* don't have non-developers handling LSR. I will admit that we've started to see submissions from users, which is definitely nice... but I don't think we've passed the break-even point yet. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: crankiness
On Sat, Apr 25, 2009 at 06:22:28PM +0100, Gerard McConnell wrote: > "The current person responsible for LSR also happens to be the most > active patch-reviewer. Do you *really* want me to ask him to stop > working on patches (i.e. new features, bug fixes, etc) and waste > his time playing web-2.0 games that anybody with TWO BLOODY WEEKS > OF LILYPOND EXPERIENCE could do?! > > The critical word in the above quote is waste. Yes, it is. Any time you have an expert doing work that a novice could do, it's an inefficient use of resources -- in other words, a waste. I chose my words carefully, and stand by them. > I came away from that experience with the > conviction that good documentation is critically important. Yes, it is. But we're not talking about learning basic lilypond knowledge here; we're looking at advanced tweaks. People wanting to do fancy stuff should be prepared to spend half an hour looking through the relevant part of the docs. Now, I've wanted somebody to organize these special tweaks for over two years now, but it's not the most important doc work that remains unfulfilled. It *is* the easiest doc work, though -- and when I rank the importance vs. knowledge required to perform the work, this particular task is far ahead of anything else. Hence my annoyance. > I believe that If > Lilypond is to develop the widest possible user base and > get the recognition it deserves the clarity and conciseness of the > documentation is perhaps as important as the application itself. Having worked on the docs for 4 years and approximately three thousand hours, you really don't need to convince me. Just convince others -- and perhaps yourself -- that it's worth getting involved. My work at this point is a meta-contributor: I contribute (teach) people how to contribute to lilypond. If nobody steps forward to do the work, then it doesn't get done. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
On 4/25/09 9:37 AM, "Neil Puttock" wrote: > 2009/4/23 Jonathan Kulp : >> Graham Percival wrote: >> >>> 1. Log in to LSR as an editor. (I remember the discussion now; >>> this isn't your fault) >>> >>> 2. Find the "tags" section for each snippet. >>> >>> 3. Click on the drop-down menus, and select the relevant tags. >>> >>> 4. There is no #4. >> >> Is "save" #4? >> >> Thanks for the rundown, Graham. As you've said, this is very easy and I >> figured it out myself as reported in previous email... > > 4. Note that one of the snippets isn't tagged as `docs', which means > it's in input/new. > > 5. Find the snippet in input/new, and add the tag there instead. > > 6. Scratch #5, since the snippet shouldn't be in input/new in the first place. Unless the snippet is referenced in the docs, and the person who added it to the docs didn't put the tag in it because he didn't know to do so. I which case, the tag should still be added, I think. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
crankiness
I've been looking at the Re: date in footer thread; I can understand how the experts get annoyed. They're doing lots of volunteer work to develop what is a really beautiful (but horrendously difficult to learn) program, and figure that the rest of us should be doing our bit to sort out the documentation and snippets.I'm sure we'd all like to help, but as a new user I think it would be presumptuous of me to start rewriting/reorganizing documentation, don't you think? However, I must dispute one comment that I read in the thread: "The current person responsible for LSR also happens to be the most active patch-reviewer. Do you *really* want me to ask him to stop working on patches (i.e. new features, bug fixes, etc) and waste his time playing web-2.0 games that anybody with TWO BLOODY WEEKS OF LILYPOND EXPERIENCE could do?! The critical word in the above quote is waste. Although I'm not a professional programmer (I'm a piano teacher), at one time I dipped my toes in the water and completed a MSc in multimedia development. I came away from that experience with the conviction that good documentation is critically important. I believe that If Lilypond is to develop the widest possible user base and get the recognition it deserves the clarity and conciseness of the documentation is perhaps as important as the application itself. So, like I said, Lilypond is a really great application, but learning to use it is exceptionally hard work. MUCH harder than learning Music Publisher, Notator, Cubase Score, Finale, etc.Please be patient with the users; we're trying to learn it not just because it's free, but because it's excellent.___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Error in tweak parameter doesn't generate error message
>> I eventually noticed that I had accidentally typed >> >> -\tweak #'extra-ofset >> >> instead of >> >> -\tweak #'extra-offset >> >> but this did not generate any warning. Looks like this is a general >> thing with \tweak, as I tried changing \tweak #'color to \tweak >> #'colon and got no warning there either. > > There may be a good reason why there's no type-checking for \tweak, A typo is a typo is a typo. I can see *any* reason to not emit a warning. > but you can redefine it if you like: Great! Please commit something along this. Werner ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
2009/4/23 Jonathan Kulp : > Graham Percival wrote: > >> 1. Log in to LSR as an editor. (I remember the discussion now; >> this isn't your fault) >> >> 2. Find the "tags" section for each snippet. >> >> 3. Click on the drop-down menus, and select the relevant tags. >> >> 4. There is no #4. > > Is "save" #4? > > Thanks for the rundown, Graham. As you've said, this is very easy and I > figured it out myself as reported in previous email... 4. Note that one of the snippets isn't tagged as `docs', which means it's in input/new. 5. Find the snippet in input/new, and add the tag there instead. 6. Scratch #5, since the snippet shouldn't be in input/new in the first place. ;) Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: TextSpanner at Score level?
2009/4/22 Carl Sorensen : > The IR tells you that TextSpanners are created by Dynamic_engraver, > New_dynamic_engraver, and Text_spanner_engraver. Hmm, it just goes to show that you can't always rely on what the IR says: only the Text_spanner_engraver creates them. :) I'll remove the bogus entries (left over from the old code). Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Error in tweak parameter doesn't generate error message
2009/4/23 Nick Payne :
> I was trying to move a TextSpanner with \tweak and couldn't figure out why
> it wouldn't move. I eventually noticed that I had accidentally typed
>
> -\tweak #'extra-ofset
>
> instead of
>
> -\tweak #'extra-offset
>
> but this did not generate any warning. Looks like this is a general thing
> with \tweak, as I tried changing \tweak #'color to \tweak #'colon and got no
> warning there either.
There may be a good reason why there's no type-checking for \tweak,
but you can redefine it if you like:
tweak =
#(define-music-function (parser location sym val arg)
(symbol? scheme? ly:music?)
(_i "Add @code{sym . val} to the @code{tweaks} property of @var{arg}.")
(if (equal? (object-property sym 'backend-type?) #f)
(ly:warning "cannot find property type-check for: ~a" sym)
(set!
(ly:music-property arg 'tweaks)
(acons sym val
(ly:music-property arg 'tweaks
arg)
Regards,
Neil
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Fingering font size on grace notes
2009/4/21 Nick Payne : > Fingering indications on grace notes doesn't shrink to be proportional to > the reduced size of the grace note, and the full size indication looks > excessively large alongside the note. It's easy enough to override - using > \override Fingering #'font-size = #-8 seems about right - but perhaps this > should happen automatically. You're right, it should be a default setting. Before I change this, do you have any thoughts about the sizes of string numbers and right hand fingerings? Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
Jonathan Kulp schrieb: Jonathan Kulp wrote: octave. I think there were only two examples in tablature.ly that didn't use the "treble_8" clef for guitar. All the other clefs (including the "bass_8" for bass guitar) were correct. Sorry I meant to say in "tablature-test1.ly" Jon Yes, you are right. In the first two lines, I forgot the octaviation sign. But I think, this example will never be played on a guitar ;-) Marc ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
Jonathan Kulp wrote: octave. I think there were only two examples in tablature.ly that didn't use the "treble_8" clef for guitar. All the other clefs (including the "bass_8" for bass guitar) were correct. Sorry I meant to say in "tablature-test1.ly" Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
Grammostola Rosea wrote: Marc Hohl wrote: Hello tablature users*, after some days of struggling with lilypond's internals, I have created a file tablature.ly Wow, I am very happy about this! I'm gonna test it for sure. Thanks Marc and Carl! @David could you make some progress with the bends and stuff? Kind regards, \r Well done, Marc & Carl! I don't use tab either, but I'm a guitarist and appreciate the new features from that standpoint. My only comment would be that whenever traditional staff and tabstaff are presented together, it's best to use the "treble_8" clef for the regular staff so that the notes appear in the right place on the staff, the tab has the correct indications, and the midi output is in the right octave. I think there were only two examples in tablature.ly that didn't use the "treble_8" clef for guitar. All the other clefs (including the "bass_8" for bass guitar) were correct. Thanks for the great work, guys! Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music expression explanation
On Sat, Apr 25, 2009 at 12:31:14PM +0100, Trevor Daniels wrote:
>
> Graham Percival wrote Saturday, April 25, 2009 10:13 AM
>
>> Eh?!?! You want to tell people to put articulation and dynamic
>> marks after the duration, before they've been told how to do
>> articulations and dynamics? Remember that the idea is to give a
>> general:
>> @var{pitch} @var{dur} @var{other}
>
> No, you should. This thread has nothing to do
> with articulation and dynamics. It is to to
> with the relative order of octave marks and
> durations.
Yes, the *initial* concern was over the relative order of octave
marks and durations. My *current* concern is that if it's
possible for people to get confused over
c4'
then surely they could also get confused over
c'\mf4
If so, there's two options:
1) give a general explanation of pitch-dur-other. In addition to
that order, explain that the order of "other" doesn't matter.
2) give an explanation of pitch-dur, then later on explain
pitch-dur-other (or maybe "note-other", or something like that)
I thought that #1 would be best, but if you'd rather go with #2, I
have no objection.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Rotating TextSpanner
Kieren MacMillan wrote: Hi Nick, With that as a model I was able to generalize it to a music function Nice! +1. That's a very cool piece of code! Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bug on markups migrating from 2.10 to 2.12
Nick Payne wrote: I have attached the barre and half barre functions I use that work with 2.12, and your test.ly modified to use them. Nick Those are nice barre indicators, Nick. Thanks. :) Jon -- Jonathan Kulp http://www.jonathankulp.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music expression explanation
Graham Percival wrote Saturday, April 25, 2009 10:13 AM
On Sat, Apr 25, 2009 at 09:41:26AM +0100, Trevor Daniels wrote:
Graham Percival wrote Friday, April 24, 2009 4:42 PM
On Wed, Apr 22, 2009 at 04:10:37PM +0200, Simon Bailey wrote:
Graham Percival wrote:
If you have an idea for a general clarification that the
syntax is
"pitch duration other", then I'm all for it. If it's a simple
"you need to put the ' before the duration", then I'd probably
reject it as being insufficiently general.
That said, this is really Trevor's area now. Let's see what he
says.
Thanks for the prompt! I think the best place is in
2.1.2 Simple notation, in the Durations (rhythms) section.
This is where the entry of a duration is first mentioned,
and it's immediately after introducing the ' and , marks.
Eh?!?! You want to tell people to put articulation and dynamic
marks after the duration, before they've been told how to do
articulations and dynamics? Remember that the idea is to give a
general:
@var{pitch} @var{dur} @var{other}
You might want to take a second look through the rest of this
thread:
http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00737.html
No, you should. This thread has nothing to do
with articulation and dynamics. It is to to
with the relative order of octave marks and
durations.
Trevor
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Rotating TextSpanner
Hi Nick, With that as a model I was able to generalize it to a music function Nice! Even better would be to take the music as a parameter, compute the correct rightY (using the relative position of the endpoints of the first and last stem) and automagically adjust -- that, however, is beyond my current Scheme ability. Regards, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
On Sat, Apr 25, 2009 at 12:06:07PM +0200, Marc Hohl wrote: > after some days of struggling with lilypond's internals, I have created > a file tablature.ly Fantastic work! This is exactly the kind of thing I was hoping would happen. Not from a tab-specific viewpoint, but from a general "getting more people involved in lilypond" standpoint. I know Marc already knows this, but I want to add emphasis: - this is a self-contained file; people who want test/use it just need to download it and add the \include. - this requires ZERO compiling of lilypond. Granted, some additions /will/ require C++ hacking... but a lot of things can be done in scheme only. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
Marc Hohl wrote: Hello tablature users*, after some days of struggling with lilypond's internals, I have created a file tablature.ly Wow, I am very happy about this! I'm gonna test it for sure. Thanks Marc and Carl! @David could you make some progress with the bends and stuff? Kind regards, \r ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
tablature.ly
Hello tablature users*,
after some days of struggling with lilypond's internals, I have created
a file tablature.ly
which supports:
1) two commands to switch between the display style:
\tabNumbersOnly shows only the mubers,
\tabFullNotation shows up everything (as it is the default in
\TabVoice upto now)
2) two commands for the possible clefs:
\calligraphicTabClef #
\sansSerifTabClef #
(I didn't like "modern" or "old" clef, so I used commands which
describe the apperance
of the clefs).
The sans serif clef is available for 4 to 7 strings. It internally sets
\TabStaff.stringTunings to .
3) some more tunings are defined:
guitar-seven-string-tuning
guitar-drop-d-tuning
bass-four-string-tuning
bass-drop-d-tuning
bass-five-string-tuning
bass-six-string-tuning
(yes I know, the already defined "bass-tuning" is the same as my
"bass-four-string-tuning", but
as I write music for various basses, this is easier to read at first
glance.)
4) commandos for palm mute playing and dead notes are supported (palm
mute is not a tablature-specific
issue, but as electric guitar players use tablature and often play
palm mute, I think this is ok).
At first I thought of using \x for dead notes, but in other threads
\x is used for almost everything,
so I leave it to the user to say x = \deadNotes and use \x for faster
typing myriads of dead notes :-)
I post this along with a test file, so you can check this out.
*Carl, which isn't really a tablature user, has given me a lot of
support an insight to lilypond,
and he proposed to include tablature.ly in future releases of lilypond,
so this would be the place to
go for further development (bendings, etc.). Establishing
\tabNumbersOnly as a standard would mean to
break with older versions, but as it is a single command, this should
not be considered as a serious
drawback.
As there are more people invoved in developing tablature extensions for
lilypond, I send tablature.ly
to this list for testing purposes, so changes, corrections etc. could be
discussed before establishing
the file in future versions. As I said before, it is just a starting
point, any suggestions, improvements
etc. are welcome. Are there other tunings we should consider being
defined internally?
Yet again, I would like to thank Carl for his great help and patience,
and as far as I can see now,
making contributions to lilypond is easier than one might think, there
are a lot of people outside
willing to help you, if you are willing to bring lilypond further on, so
give it a try!
Greetings,
Marc
% tablature.ly
% these definitions will be moved to scm/output-lib.scm
#(define-public guitar-seven-string-tuning '(4 -1 -5 -10 -15 -20 -25))
#(define-public guitar-drop-d-tuning '(4 -1 -5 -10 -15 -22))
#(define-public bass-four-string-tuning'(-17 -22 -27 -32))
#(define-public bass-drop-d-tuning '(-17 -22 -27 -34))
#(define-public bass-five-string-tuning'(-17 -22 -27 -32 -37))
#(define-public bass-six-string-tuning '(-12 -17 -22 -27 -32 -37))
% some publications use the triangled note head
% for palm mute, so here we go:
palmMuteOn = { \set shapeNoteStyles = #'#(do do do do do do do ) }
palmMuteOff = { \unset shapeNoteStyles }
% for single notes (or groups of notes within { ...} :
palmMute = #(define-music-function (parser location note) (ly:music?)
#{
\set shapeNoteStyles = #'#(do do do do do do do )
$note
\unset shapeNoteStyles
#})
% x-tab-format uses a "x" instead of the fret number:
#(define (x-tab-format str context event)
(make-whiteout-markup
(make-vcenter-markup
(markup #:musicglyph "noteheads.s2cross"
% dead notes are marked with a cross-shape note head,
% both in normal notation and in tablature:
deadNotesOn = {
\override NoteHead #'style = #'cross
\set tablatureFormat = #x-tab-format
}
deadNotesOff = {
\unset tablatureFormat
\revert NoteHead #'style
}
% for single notes or groups of notes within {...}:
deadNotes = #(define-music-function (parser location notes) (ly:music?)
#{
\override NoteHead #'style = #'cross
\set tablatureFormat = #x-tab-format
$notes
\unset tablatureFormat
\revert NoteHead #'style
#})
% define sans serif-style tab-Clefs according to
% http://lsr.dsi.unimi.it/LSR/Item?id=323
% for 4, 5, 6 and 7 strings
#(define-markup-command (customTabClef layout props tuning) (pair?)
(let* ((num-strings (length tuning))
;; the number of strings has to be in 4...7
(num-strings (cond ((< num-strings 4) 4)
((> num-strings 7) 7)
(else num-strings)))
(raise-value (- (* num-strings 0.4) 0.9))
(font-size (- (* num-strings 1.5) 7))
(base-skip (cond ((= 4 num-strings) 1.55)
((= 5 num-strings) 1.84)
((= 6 num-strin
Re: music expression explanation
trevor, graham, On 25 Apr 2009, at 10:41, Trevor Daniels wrote: Graham Percival wrote Friday, April 24, 2009 4:42 PM Hmm. I was initially thinking of 3.1.2, but that subsection (actually, the entire section) is really talking about *macroscopic* style. I mean, it refers back to the definition of a (compound) "music expression". With that in mind, perhaps 2.3.1 is the best place: add 2-3 sentences and an articulation (or dynamic, or something) to the first paragraph+example. That said, this is really Trevor's area now. Let's see what he says. Thanks for the prompt! I think the best place is in 2.1.2 Simple notation, in the Durations (rhythms) section. This is where the entry of a duration is first mentioned, and it's immediately after introducing the ' and , marks. Perhaps immediately after the example there and before dotted notes are mentioned would be ideal. I'd be happy to receive a patch, Simon. i'll see about getting a patch to you on monday. my non-computer life (i.e. actually playing music) has seriously taken over my time lately. ;) regards, sb ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music expression explanation
On Sat, Apr 25, 2009 at 09:41:26AM +0100, Trevor Daniels wrote:
>
> Graham Percival wrote Friday, April 24, 2009 4:42 PM
>
>> On Wed, Apr 22, 2009 at 04:10:37PM +0200, Simon Bailey wrote:
>>> Graham Percival wrote:
If you have an idea for a general clarification that the syntax is
"pitch duration other", then I'm all for it. If it's a simple
"you need to put the ' before the duration", then I'd probably
reject it as being insufficiently general.
>>>
>> That said, this is really Trevor's area now. Let's see what he
>> says.
>
> Thanks for the prompt! I think the best place is in
> 2.1.2 Simple notation, in the Durations (rhythms) section.
> This is where the entry of a duration is first mentioned,
> and it's immediately after introducing the ' and , marks.
Eh?!?! You want to tell people to put articulation and dynamic
marks after the duration, before they've been told how to do
articulations and dynamics? Remember that the idea is to give a
general:
@var{pitch} @var{dur} @var{other}
You might want to take a second look through the rest of this
thread:
http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00737.html
> ps One of my other hobbies (budgerigar genetics) is
> taking time at the moment, hence my back seat presence.
Colorful!
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music expression explanation
Graham Percival wrote Friday, April 24, 2009 4:42 PM On Wed, Apr 22, 2009 at 04:10:37PM +0200, Simon Bailey wrote: Graham Percival wrote: If you have an idea for a general clarification that the syntax is "pitch duration other", then I'm all for it. If it's a simple "you need to put the ' before the duration", then I'd probably reject it as being insufficiently general. my first idea was something along the lines of your refusal. :) i do have some other ideas about how to explain the syntax, but they depend on where you want to put it in the docs. ... where would you put it in 3.1.? Hmm. I was initially thinking of 3.1.2, but that subsection (actually, the entire section) is really talking about *macroscopic* style. I mean, it refers back to the definition of a (compound) "music expression". With that in mind, perhaps 2.3.1 is the best place: add 2-3 sentences and an articulation (or dynamic, or something) to the first paragraph+example. That said, this is really Trevor's area now. Let's see what he says. Thanks for the prompt! I think the best place is in 2.1.2 Simple notation, in the Durations (rhythms) section. This is where the entry of a duration is first mentioned, and it's immediately after introducing the ' and , marks. Perhaps immediately after the example there and before dotted notes are mentioned would be ideal. I'd be happy to receive a patch, Simon. Trevor ps One of my other hobbies (budgerigar genetics) is taking time at the moment, hence my back seat presence. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
