Re: review of a Mutopia file (why TabStaff gives error here?)
Il 24/11/2012 03:34, Keith OHara ha scritto:
You might not have seen that Nick posted a much nicer formatting for
barre indications.
http://lists.gnu.org/archive/html/lilypond-user/2012-11/msg00570.html
It avoids taking apart LilyPond's internal data structures, which makes
it better for mutopiaproject.
You can adjust Nick's function to use it as \barre 3 { %{ music %} } and
have it set minimumFret=3 so you don't need so many string number
entries. Scheme can convert to Roman numerals.
barre = #(define-music-function (parser location
strg music) (number? ly:music?)
#{
\set TabStaff.minimumFret = $strg
\set TabStaff.restrainOpenStrings = ##t
\once\override TextSpanner #'(bound-details left text)
= #(format #f B ~@r strg)
%{ ... Nick's other style settings ...%}
\startTextSpan
$music
\stopTextSpan
\unset TabStaff.minimumFret
\unset TabStaff.restrainOpenStrings
#})
I've just realized that there's a problem in this command.
I want to comment the TabStaff part of \score, so classical players can
enjoy a clean score while those who can't sight-read music can activate
the tablature.
But if you comment TabStaff the score breaks: a lot of tab staves are
printed,
I see that it's because of the \set TabStaff in the barre command above.
What do you recommend?
Thanks
--
Federico
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: changing staff size in \score context
Oh, that is to combine rests of two choir voices on the same staff, as you can
see I'm using two voices per staff.
If i disable it, it shows no errors.
Is there a better way of combining rests the same without using \revert Rest
#'direction ?.
Eby
- Original Message -
From: David Kastrup d...@gnu.org
To: Eby Mani eby...@yahoo.com
Cc: lilypond-user@gnu.org lilypond-user@gnu.org
Sent: Thursday, November 22, 2012 1:52 PM
Subject: Re: changing staff size in \score context
Eby Mani eby...@yahoo.com writes:
Thanks, the file compiled with multiple warning: cannot resolve rest
collision: rest direction not set errors in vocal part, where SA and
TB rests are combined.
*
global = {
[...]
\revert Rest #'direction
[...]
}
What's the idea here?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: review of a Mutopia file (why TabStaff gives error here?)
Federico Bruni fedel...@gmail.com writes:
Il 24/11/2012 03:34, Keith OHara ha scritto:
You might not have seen that Nick posted a much nicer formatting for
barre indications.
http://lists.gnu.org/archive/html/lilypond-user/2012-11/msg00570.html
It avoids taking apart LilyPond's internal data structures, which makes
it better for mutopiaproject.
You can adjust Nick's function to use it as \barre 3 { %{ music %} } and
have it set minimumFret=3 so you don't need so many string number
entries. Scheme can convert to Roman numerals.
barre = #(define-music-function (parser location
strg music) (number? ly:music?)
#{
\set TabStaff.minimumFret = $strg
\set TabStaff.restrainOpenStrings = ##t
\once\override TextSpanner #'(bound-details left text)
= #(format #f B ~@r strg)
%{ ... Nick's other style settings ...%}
\startTextSpan
$music
\stopTextSpan
\unset TabStaff.minimumFret
\unset TabStaff.restrainOpenStrings
#})
I've just realized that there's a problem in this command.
I want to comment the TabStaff part of \score, so classical players
can enjoy a clean score while those who can't sight-read music can
activate the tablature.
But if you comment TabStaff the score breaks: a lot of tab staves are
printed, I see that it's because of the \set TabStaff in the barre
command above. What do you recommend?
You could use \set Staff... instead. The normal staff will likely just
ignore those settings, and within a tabstaff, Staff is aliased to
TabStaff.
The disadvantage is that if you use \barre outside of any staff, it will
create a default Staff rather than a TabStaff.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: changing staff size in \score context
On 24 November 2012 09:18, Eby Mani eby...@yahoo.com wrote:
Oh, that is to combine rests of two choir voices on the same staff, as you
can see I'm using two voices per staff.
If i disable it, it shows no errors.
Is there a better way of combining rests the same without using \revert Rest
#'direction ?.
You mean like the Merge Rests Engravers developed by
Jay Anderson as solution for bug #1228 ?
http://lists.gnu.org/archive/html/lilypond-user/2012-02/msg00793.html
http://code.google.com/p/lilypond/issues/detail?id=1228
Snippet
\version 2.15.30
%% merge-rests-engraver and merge-mmrests-engraver provided by
%% Jay Anderson
%% http://lists.gnu.org/archive/html/lilypond-user/2012-02/msg00793.html
%% See also issue #1228
%% http://code.google.com/p/lilypond/issues/detail?id=1228
#(define has-one-or-less (lambda (lst) (or (null? lst) (null? (cdr lst)
#(define has-at-least-two (lambda (lst) (not (has-one-or-less lst
#(define (all-equal lst pred)
(or (has-one-or-less lst)
(and (pred (car lst) (cadr lst)) (all-equal (cdr lst) pred
#(define merge-rests-engraver
(lambda (context)
(let ((rest-same-length
(lambda (rest-a rest-b)
(eq? (ly:grob-property rest-a 'duration-log)
(ly:grob-property rest-b 'duration-log
(rests '()))
`((start-translation-timestep . ,(lambda (trans)
(set! rests '(
(stop-translation-timestep . ,(lambda (trans)
(if (and (has-at-least-two
rests) (all-equal rests rest-same-length))
(for-each
(lambda (rest)
(ly:grob-set-property! rest 'Y-offset 0))
rests
(acknowledgers
(rest-interface . ,(lambda (engraver grob source-engraver)
(if (eq? 'Rest (assoc-ref
(ly:grob-property grob 'meta) 'name))
(set! rests (cons grob rests))
#(define merge-mmrests-engraver
(lambda (context)
(let* ((mmrest-same-length
(lambda (rest-a rest-b)
(eq? (ly:grob-property rest-a 'measure-count)
(ly:grob-property rest-b 'measure-count
(merge-mmrests
(lambda (rests)
(if (all-equal rests mmrest-same-length)
(let ((offset (if (eq? (ly:grob-property (car rests)
'measure-count) 1) 1 0)))
(for-each
(lambda (rest) (ly:grob-set-property! rest
'Y-offset offset))
rests)
(curr-rests '())
(rests '()))
`((start-translation-timestep . ,(lambda (trans)
(set! curr-rests '(
(stop-translation-timestep . ,(lambda (trans)
(if (has-at-least-two curr-rests)
(set! rests (cons curr-rests rests)
(finalize . ,(lambda (translator)
(for-each merge-mmrests rests)))
(acknowledgers
(rest-interface . ,(lambda (engraver grob source-engraver)
(if (eq? 'MultiMeasureRest (assoc-ref
(ly:grob-property grob 'meta) 'name))
(set! curr-rests (cons grob curr-rests))
global = {\compressFullBarRests
\override MultiMeasureRest #'expand-limit = #1 }
voixI = \relative c'' {
R1*4 g1 a g
r4 g4 a g
}
voixII = \relative c' {
R1*4 e1 f e
r4 e r e
}
voixIII = \relative c' {
R1*4 c1 ~ c ~ c
c4 r c r
}
voix = \relative c {
R1*4 c1 f c
c4 f c r
}
paroles = \lyricmode {
a b c d
}
\score {
\new ChoirStaff
\new Staff
\new Voice = one {
\voiceOne
\global \voixI
}
\new Voice = two {
\voiceTwo
\global \voixII
}
\new Lyrics \lyricsto one { \paroles }
\new Staff \clef bass
\new Voice = one {
\voiceOne
\global \voixIII
}
\new Voice = two {
\voiceTwo
\global \voix
}
\layout {
\context {
\Staff
\consists #merge-rests-engraver
\consists #merge-mmrests-engraver
}
}
}
End of snippet
--
Xavier Scheuer x.sche...@gmail.com
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: changing staff size in \score context
- Original Message - From: Eby Mani eby...@yahoo.com To: David Kastrup d...@gnu.org Cc: lilypond-user@gnu.org Sent: Saturday, November 24, 2012 8:18 AM Subject: Re: changing staff size in \score context Oh, that is to combine rests of two choir voices on the same staff, as you can see I'm using two voices per staff. If i disable it, it shows no errors. Is there a better way of combining rests the same without using \revert Rest #'direction ?. Eby The best way is to use explicit voices, and where there are only rests, use \voiceOne in one part, and spacer rests in the other. Alternatively http://lsr.dsi.unimi.it/LSR/Snippet?id=336 might do what you want. -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Whole note bracket
Hello everybody! How i can make brackets like on picture? Brackets.bmp http://lilypond.1069038.n5.nabble.com/file/n136785/Brackets.bmp -- View this message in context: http://lilypond.1069038.n5.nabble.com/Whole-note-bracket-tp136785.html Sent from the User mailing list archive at Nabble.com. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Whole note bracket
How i can make brackets like on picture? http://lilypond.1069038.n5.nabble.com/file/n136785/Brackets.bmp It's a bit difficult to produce such ugly brackets with lilypond. If you like more beatiful ones, read this: http://lilypond.org/doc/v2.16/Documentation/notation/expressive-marks-as-lines#arpeggio Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Whole note bracket
- Original Message - From: Rustik r.ala...@mail.ru To: lilypond-user@gnu.org Sent: Saturday, November 24, 2012 11:42 AM Subject: Whole note bracket Hello everybody! How i can make brackets like on picture? Brackets.bmp http://lilypond.1069038.n5.nabble.com/file/n136785/Brackets.bmp http://lilypond.org/doc/v2.17/Documentation/notation/choral#divided-voices -- Phil Holmes ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \repeat volta
It depends. Have struggled with it before.I currently still use the stable release 2.16.0 and this file (with version number changed) compiles correctly AND produces the wanted "|:" at the beginning (also when deleting the extra unnecessary vertical bar in the statement) without any adaption of the breaks alignments.So there is at least a difference in the results produced by different versions. Is that desirable?Output of version 2.16.0 attached. Regards,Wim.inline: Untitled15.png
Untitled15.ly
Description: Binary data
On 24 Nov 2012, at 05:42 , SoundsFromSound wrote:MING TSANG wroteHi, lily user,The following lily code did not produce \bar"|:" at the beginning.\version "2.17.7"\relative c' {\key c \major \time 6/8 \bar"||:" \repeat volta 2 {c4 e4. g8 | e8( d8) d4 r8 c8 | c4 e4. g8 | e2r8 d8 | } \alternative {{ c2. d2. } {d2. d2.}} e4 e8 f4 f8 \bar"|."}The output is attached.Blessing in+,___lilypond-user mailing listlilypond-user@https://lists.gnu.org/mailman/listinfo/lilypond-userIf you really must insert a repeat at the beginning, you can use thissnippet from the documentation:___Printing a repeat sign at the beginning of a pieceA |: bar line can be printed at the beginning of a piece, by overriding therelevant property:\relative c'' { \once \override Score.BreakAlignment #'break-align-orders = #(make-vector 3 '(instrument-name left-edge ambitus span-bar breathing-sign clef key-signature time-signature staff-bar custos span-bar)) \bar "|:" c1 d1 d4 e f g}___At least, I think you can still do this - I know you could in previousversions of LilyPond.Ben-composer | sound designer--View this message in context: http://lilypond.1069038.n5.nabble.com/repeat-volta-tp136766p136768.htmlSent from the User mailing list archive at Nabble.com.___lilypond-user mailing listlilypond-user@gnu.orghttps://lists.gnu.org/mailman/listinfo/lilypond-user___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Expanding bowed arpeggios
Hi all,
Sometimes arpeggios are written as chords to avoid repetitive and lengthy
arpeggio expansions in a written score.
However, is there a way in LilyPond to transform chords into bowed arpeggio
expansions, as illustrated in the example below (first bar = input, 2nd bar
= automatically generated expansion based on input)?
% BEGIN
\version 2.16.1
\score {
\new Staff {
\relative c, {
\key c \major
\time 4/4
\clef bass
\set fingeringOrientations = #'(right)
c-0 g'-0 e'-1 c'-22-\p^\markup{input} c g' f'-2 d'-42 |
c16-0-\p^\markup{output} ( g'-0 e'-1 c'-2 ) c ( e, g, c,)c ( g'
f'-2 d'-4 ) d ( f, g, c,)
}
}
}
% END
Best regards,
Olivier
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: vspace with non-integer argument does not work
On Sat, Nov 24, 2012 at 1:25 AM, Thomas Morley thomasmorle...@googlemail.com wrote: 2012/11/24 Olivier Biot olivier.b...@gmail.com: Hi all, Is it possible to specify non-integer values for vertical spacing with vspace? I read once that it was possible, but apparently not (anymore) in version 2.16.0 or 2.16.1. vspace works with integers: \vspace #1 etc numbers: \vspace #1.23 (even \vspace #(* 4 (atan 1)) is valid input) and fractions: \vspace #1/2 Okay, good to know :-) The following does compile without errors but the non-integer values are apparently silently transformed into 1 No, don't forget that the \center-column-command uses a baseline-skip with value 3 Very little divergations (0.01 or 2/300) will hardly be noticeable. And this is something I was unaware of. I now re-read the documentation of center-column and indeed it states that property baseline-skip is used. I was not aware of the implication of that note in that section. Boxing the texts and setting baseline-skip to zero I'll have to reread the entire documentation now :-) Many thanks again Thomas! Best regards, Olivier ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \repeat volta
2012/11/24 Wim van Dommelen m...@wimvd.nl: It depends. Have struggled with it before. I currently still use the stable release 2.16.0 and this file (with version number changed) compiles correctly AND produces the wanted |: at the beginning (also when deleting the extra unnecessary vertical bar in the statement) without any adaption of the breaks alignments. The barline-interface was changed with the newer devel-versions. Use \bar .|: So there is at least a difference in the results produced by different versions. Is that desirable? Well, different versions will produce different, hopefully better, output. Howelse could it be? It will work, if you run convert-ly against the 2.16.0-file -Harm ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Stem #'stroke-style
Hello dear ponders, can someone explain why the example from http://lsr.dsi.unimi.it/LSR/Item?id=556 doesn't work in 2.16.1? As you can see in the attachment, the override seems to get ignored. Kind regards, Gagi attachment: Screen shot 2012-11-24 at 2.48.08 PM.png___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Stem #'stroke-style
Hi Gagi, On Sat, Nov 24, 2012 at 7:49 AM, Gagi Petrovic m...@gagipetrovic.nl wrote: Hello dear ponders, can someone explain why the example from http://lsr.dsi.unimi.it/LSR/Item?id=556 doesn't work in 2.16.1? As you can see in the attachment, the override seems to get ignored. The flag is now a separate object, and 'stroke-style now belongs to it instead of Stem. So this is the override you need: \override Flag #'stroke-style = #grace -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Stem #'stroke-style
Gagi Petrovic m...@gagipetrovic.nl writes: Hello dear ponders, can someone explain why the example from http://lsr.dsi.unimi.it/LSR/Item?id=556 doesn't work in 2.16.1? As you can see in the attachment, the override seems to get ignored. Try running convert-ly -ed on the LSR item after placing a \version 2.14.0 header before it. This should convert to the currently valid form. In general, that's what you should do when trying to run examples from the current LSR (which is still on 2.14) on 2.16.x. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Aleatoric / modern notation
Hi there, The box construct from this thread is working fine on my machine, but I'd like to know how to add one important feature to it: It's currently the case that the arrow isn't breakable, i. e. if the box's entire duration exceeds the graphic space of the first line, the arrow stops on the first line and you end up with a bunch of blank space on the second line. How can the arrow break and continue on the second line? I know that many spanners have a breakable attribute -- maybe there's a straightforward way to add this ability to the box's arrow? best, Jeff On Thu, Nov 15, 2012 at 2:10 PM, David Nalesnik david.nales...@gmail.comwrote: Hi Jeffrey, On Wed, Nov 14, 2012 at 1:05 AM, Jeffrey Trevino jeffrey.trevi...@gmail.com wrote: Hi David, This is a very help description. Maybe you could describe for me: I see both the box duration as a spacer duration and the line duration as extender length, in what seem to be unitless units. The way it's set up now, the extender length is measured in staff-spaces. Here is an addition -- although I'm not sure if it's an improvement -- that might be important in some cases: It seems that it would be helpful to describe the line length of the arrow in terms of spacers if possible, to more easily describe the duration occupied by the entire frame construct. Yes, that's a good idea. I don't like having to fiddle with numbers to get it to look right. Likewise, I would like to be able to draw a bracket over the frame's graphic duration, with a note duration or series of tied durations above the bracket, centered, to indicate the duration of the frame clearly. I don't know how this would work; maybe it would be possible to use a bracket spanner and then enter durations? This would be doable, but I think markup would be the way to go here. That way, you can specify the duration in clock time (which I've done when I've used this sort of notation). One concern I have here stems from the fact that frame notation isn't standardized, and there are many variants: there's no way everybody's favorite notation could be accommodated. As one example, putting a box around the notes isn't the only way it's done: I have in front of me a piece by Bruce Saylor which puts an ellipse around the notes. So I think the only workable approach is to offer some bare-bones implementation. For more idiosyncratic notations, I guess the answer is to turn to Inkscape and the like. (In any case, I'd like to get something basic working first before adding frills.) -David -- 《〠》】〶【〖〠〗〶〛〷〚 Jeff Treviño PhD Candidate in Music Composition @ the University of California, San Diego 〖〠〗〶〛〷〚《〠》】〶 Skype: jeffreytrevino E-mail: jeffrey.trev...@gmail.com 〚《〠》】〶【〖〠〗〶〛〷 9310H Redwood Dr. La Jolla, CA 92037 USA 〖〠〗〶〛〷〚《〠》】〶【 http://www.jeffreytrevino.com/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Aleatoric / modern notation
Hi Jeffrey, On Sat, Nov 24, 2012 at 9:58 AM, Jeffrey Trevino jeffrey.trevi...@gmail.com wrote: Hi there, The box construct from this thread is working fine on my machine, but I'd like to know how to add one important feature to it: It's currently the case that the arrow isn't breakable, i. e. if the box's entire duration exceeds the graphic space of the first line, the arrow stops on the first line and you end up with a bunch of blank space on the second line. How can the arrow break and continue on the second line? I know that many spanners have a breakable attribute -- maybe there's a straightforward way to add this ability to the box's arrow? Yes, this is something which could be added. It's a problem I've been aware of and wanted to fix. (The issue at the moment is having the time to do it now that the end of the semester is here! The extender line certainly should have this capability, but I'm in doubt about the frame itself. Would it make sense to insist that the frame be confined to a single line? -David ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
[no subject]
What's special about the \clef command in the following:
According to section 2.2.1 of the manual:
To determine the number of staves in a piece, LilyPond looks at the
beginning of the first expression. If there is a single note, there is
one staff; if there is a simultaneous expression, there is more than
one staff.
This would appear to be the case in the following:
{ f a c e }
{ e g b d }
However, if a \clef is specified, the statement doesn't appear to
hold. For example, the following doesn't produce multiple staves
despite the fact that the beginning of the first expression starts
with simultaneous expression like the example above:
{ f a c e }
{ \clef bass e g b d }
In this case, both expressions are placed on one staff beginning with
a bass clef. I infer that there something special about the use of
\clef that causes lilypond to re-examine the multiple staves vs single
staff assessment. When I looked up the \clef command, there was
nothing that indicates the command has side effects.
In order to get the two staves, you must prefix each expression with a
\new Staff as in the following:
\new Staff { f a c e }
\new Staff { \clef bass e g b d }
So my question is why does adding the \clef also require adding the
\new Staff when section 2.2.1 suggests otherwise? What have I
missed?
regards,
eds
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Stem #'stroke-style
Thank you for the tip David and David :) It works fine now.
Unfortunately this (just like acciaccatura) only works on one note instead
grouped notes. Basically i simply need the beam to be stroked. Now i'm
using the following workaround, but the output is not really satisfactory
and i constantly need to adjust the Y-axis.
\version 2.16.1
stroke = {
\once\override Stem #'stencil =
#(lambda (grob)
(let* ((x-parent (ly:grob-parent grob X))
(is-rest? (ly:grob? (ly:grob-object x-parent 'rest
(if is-rest?
empty-stencil
(ly:stencil-combine-at-edge
(ly:stem::print grob)
Y
(- (ly:grob-property grob 'direction))
(grob-interpret-markup grob
(markup #:center-align #:fontsize 2
#:musicglyph flags.ugrace))
-5.2
}
\relative c' {
% \once\override Flag #'stroke-style = #grace
% \teeny d8 \normalsize c4. c2
\teeny\stroke c32[d e f g a b c~] \normalsize c2.
}
It also seems like a lot of work for something quite simple. Any suggestion
would be really helpful and greatly appreciated.
Thank you in advance!
Gagi
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: (unknown)
ed stuckems edstuck...@gmail.com writes:
What's special about the \clef command in the following:
According to section 2.2.1 of the manual:
To determine the number of staves in a piece, LilyPond looks at the
beginning of the first expression. If there is a single note, there is
one staff; if there is a simultaneous expression, there is more than
one staff.
This would appear to be the case in the following:
{ f a c e }
{ e g b d }
However, if a \clef is specified, the statement doesn't appear to
hold. For example, the following doesn't produce multiple staves
despite the fact that the beginning of the first expression starts
with simultaneous expression like the example above:
{ f a c e }
{ \clef bass e g b d }
[...]
So my question is why does adding the \clef also require adding the
\new Staff when section 2.2.1 suggests otherwise? What have I
missed?
Actually, it is not the clef that is special but rather rhythmic
events like f and e. The clef more or less works by just setting a few
Staff properties, and since a Staff already exists at the time of \clef
bass, it just uses that. The following e is no longer in the special
position of being considered a Staff-starter.
Automatically started staffs might not have been the best possible idea,
particularly in parallel music. It is usually least problematic to
explicitly specify all of your staffs.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
newbie: manual 2.2.1, staves, \clef command
Hello everyone. Can someone please explain why the \clef command
seems to override simultaneous music in the following situation?
Before getting to a specific example, I'd like to draw attention to
the following excerpt from section 2.2.1 of the manual:
To determine the number of staves in a piece, LilyPond looks at the
beginning of the first expression. If there is a single note, there is
one staff; if there is a simultaneous expression, there is more than
one staff.
This would appear to be the case in the following:
{ f a c e }
{ e g b d }
However, if a \clef is specified, the statement doesn't appear to
hold. For example, the following doesn't produce multiple staves
despite the fact that the beginning of the first expression starts
with simultaneous expression like the example above:
{ f a c e }
{ \clef bass e g b d }
In this case, both expressions are placed on one staff beginning with
a bass clef. I infer that there something special about the use of
\clef that causes lilypond to re-examine the multiple staves vs single
staff assessment. When I looked up the \clef command, there was
nothing that indicates the command has side effects.
In order to get the two staves, you must prefix each expression with a
\new Staff as in the following:
\new Staff { f a c e }
\new Staff { \clef bass e g b d }
So my question is why does adding the \clef also require adding the
\new Staff when section 2.2.1 suggests otherwise? What have I
missed?
regards,
eds
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: newbie: manual 2.2.1, staves, \clef command
On Sat, Nov 24, 2012 at 12:28 PM, David Kastrup d...@gnu.org wrote:
ed stuckems edstuck...@gmail.com writess:
What's special about the \clef command in the following:
According to section 2.2.1 of the manual:
To determine the number of staves in a piece, LilyPond looks at the
beginning of the first expression. If there is a single note, there is
one staff; if there is a simultaneous expression, there is more than
one staff.
This would appear to be the case in the following:
{ f a c e }
{ e g b d }
However, if a \clef is specified, the statement doesn't appear to
hold. For example, the following doesn't produce multiple staves
despite the fact that the beginning of the first expression starts
with simultaneous expression like the example above:
{ f a c e }
{ \clef bass e g b d }
[...]
So my question is why does adding the \clef also require adding the
\new Staff when section 2.2.1 suggests otherwise? What have I
missed?
Actually, it is not the clef that is special but rather rhythmic
events like f and e. The clef more or less works by just setting a few
Staff properties, and since a Staff already exists at the time of \clef
bass, it just uses that. The following e is no longer in the special
position of being considered a Staff-starter.
From your explanation I would say that the \clef command has the side
effect of removing any special processing of the next rhythmic
event. Then again, this might apply to any command like \clef that
merely set properties of a context.
Automatically started staffs might not have been the best possible idea,
particularly in parallel music. It is usually least problematic to
explicitly specify all of your staffs.
Got you -- alway specify staffs.
BY THE WAY, I made a mistake by not including a subject line with the
posting. I then resent it with a subject causing the same question to
appear in two different posts. I apologize for the extra posting and
I'll more closely scrutinize my posts before hitting the send button
next time. I hope my updating the subject line will fix the problem.
sorry,
eds
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Aleatoric / modern notation
Hi David, Yes, I think it's reasonable to confine the frame to a single line, even though the arrow must be breakable. I'm also having problems using the construct on parallel staffs within a score. It works fine for a single staff, but when I try to use the same construct on two staffs simultaneously, I get, warning: No start to this box. Preprocessing graphical objects...frameEngraver4.ly:124:23: In procedure ly:grob-property in expression (ly:grob-property frame (quote padding)):frameEngraver4.ly:124:23: Wrong type argument in position 1 (expecting Grob): () I don't know how the Scheme is working here, so maybe you can try out two of these in parallel and let me know if it's working for you. best, Jeff On Sat, Nov 24, 2012 at 8:10 AM, David Nalesnik david.nales...@gmail.comwrote: Hi Jeffrey, On Sat, Nov 24, 2012 at 9:58 AM, Jeffrey Trevino jeffrey.trevi...@gmail.com wrote: Hi there, The box construct from this thread is working fine on my machine, but I'd like to know how to add one important feature to it: It's currently the case that the arrow isn't breakable, i. e. if the box's entire duration exceeds the graphic space of the first line, the arrow stops on the first line and you end up with a bunch of blank space on the second line. How can the arrow break and continue on the second line? I know that many spanners have a breakable attribute -- maybe there's a straightforward way to add this ability to the box's arrow? Yes, this is something which could be added. It's a problem I've been aware of and wanted to fix. (The issue at the moment is having the time to do it now that the end of the semester is here! The extender line certainly should have this capability, but I'm in doubt about the frame itself. Would it make sense to insist that the frame be confined to a single line? -David -- 《〠》】〶【〖〠〗〶〛〷〚 Jeff Treviño PhD Candidate in Music Composition @ the University of California, San Diego 〖〠〗〶〛〷〚《〠》】〶 Skype: jeffreytrevino E-mail: jeffrey.trev...@gmail.com 〚《〠》】〶【〖〠〗〶〛〷 9310H Redwood Dr. La Jolla, CA 92037 USA 〖〠〗〶〛〷〚《〠》】〶【 http://www.jeffreytrevino.com/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
newbie: manual 2.2.1, staves, \clef command
What's special about the \clef command in the following:
According to section 2.2.1 of the manual:
To determine the number of staves in a piece, LilyPond looks at the
beginning of the first expression. If there is a single note, there is
one staff; if there is a simultaneous expression, there is more than
one staff.
This would appear to be the case in the following:
{ f a c e }
{ e g b d }
However, if a \clef is specified, the statement doesn't appear to
hold. For example, the following doesn't produce multiple staves
despite the fact that the beginning of the first expression starts
with simultaneous expression like the example above:
{ f a c e }
{ \clef bass e g b d }
In this case, both expressions are placed on one staff beginning with
a bass clef. I infer that there something special about the use of
\clef that causes lilypond to re-examine the multiple staves vs single
staff assessment. When I looked up the \clef command, there was
nothing that indicates the command has side effects.
In order to get the two staves, you must prefix each expression with a
\new Staff as in the following:
\new Staff { f a c e }
\new Staff { \clef bass e g b d }
So my question is why does adding the \clef also require adding the
\new Staff when section 2.2.1 suggests otherwise? What have I
missed?
regards,
eds
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: review of a Mutopia file (why TabStaff gives error here?)
Federico Bruni fedelogy at gmail.com writes: Il 24/11/2012 03:34, Keith OHara ha scritto: Federico Bruni fedelogy at gmail.com writes: I've updated to 2.16 the following piece of Mutopia: http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=636 Can anyone review it? I've also added the right harmonic (fifth fret of third string) in the last bar: \harmonicByFret #5 g,4.\3\fermata^Octav. I could not figure out what the version currently at mutopiaproject was trying to show. (Guitar harmonic notation confuses me; in bowed strings we use the diamond head to show where the string is touched, and/or a normal head at sounding pitch.) What you wrote seems a quite reasonable interpretation of the original, but the Octav. indication is not needed (and probably was wrong in the original). Touching the open G at the fifth fret divides it into fourths, producing a tone two octaves above the open-string G. The \harmonicByFret creates a diamond-head (apparently following the convention for guitar) at sounding pitch so no need for an extra Octav. But if you comment TabStaff the score breaks: a lot of tab staves are printed, I see that it's because of the \set TabStaff in the barre command above. I was going to suggest \tag #'tab \set ..., but David's suggestion seems much better \set Staff.minimumFret = $strg \unset Staff.minimumFret ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: review of a Mutopia file (why TabStaff gives error here?)
On 24/11/12 19:02, Federico Bruni wrote: Il 24/11/2012 03:34, Keith OHara ha scritto: Federico Bruni fedelogy at gmail.com writes: I've updated to 2.16 the following piece of Mutopia: http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=636 Can anyone review it? I made one pass through, and made potential-corrections as I went. (attached) Hopefully you can use a 'diff' program to see the changes. Thanks Keith! I see that you've fixed a lot of fingerings, now it makes sense. You just missed a string number in the second voice of bar 15. I've also added the right harmonic (fifth fret of third string) in the last bar: \harmonicByFret #5 g,4.\3\fermata^Octav. The barré formatting is awesome. BTW, given that guitar right-hand fingering in a score is indicated by the letters p, i, m, and a, I think that the source is easier to read if you define P=\rightHandFinger #1 I=\rightHandFinger #2 M=\rightHandFinger #3 A=\rightHandFinger #4 rather than #(define RH rightHandFinger) and then you can use, for example g-\M to indicate the use of m, rather than g-\RH #3 . Upper case is needed because lower case p and a are already used for a dynamic indication and a note name. Nick ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Centering / Indenting a paragraph?
On November 23, 2012 at 6:17 PM Trevor Daniels t.dani...@treda.co.uk wrote:
Bric, you wrote Friday, November 23, 2012 10:57 PM
Nope. Removed all the \hspaces. The third paragraph (set of \line's) is
still rammed all the way to the left, crossing the gutter.
Actually, changing \column to \center-column shoves the paragraph left,
beyond the absolute margin ( pixel 0)
When it's \column the paragraph is left-aligned, but with a 2-cm or so
left
margin
If you look at the example at the end of section 2.1.3 in the Notation
Reference,
and add the following to the end, it will add a centered sixth verse. You
should be able to work out from this what you need to do. Here's the
extra verse - make sure you get fill-line (which centres a single argument)
and line (which makes a single argument from two) right!
\markup {
\fill-line {
\line {
\bold 6.
\column {
This is verse six.
It has two lines.
}
}
}
}
Trevor
OK. I hadn't checked my version -- it is/was 2.14 . Somewhere between 2.14 and
2.16.1 things like \vspace and other syntax/commands were added...
Since it's developing so fast, it might be a good idea to mention versions to a
newbie. Ubuntu still has nothing newer than 2.14 in its repositories.
Anyhow, I'm trying the most stable now -- 2.16.1 ; let me see how far I can get
with 2.16.1 on my own.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Centering / Indenting a paragraph?
Bric b...@flight.us writes: Since it's developing so fast, it might be a good idea to mention versions to a newbie. Ubuntu still has nothing newer than 2.14 in its repositories. Raring has 2.16.0: URL:https://launchpad.net/ubuntu/+source/lilypond -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Slurs inside beams
Mark Witmer m...@markwitmer.com writes: Hi all, I'm working on typesetting the the attached excerpt, but I can't find a way to place slurs inside of beams. Is this possible? \shape Slur would be one rather awkward way to do it if I weren't using doubleSlurs, but since I am, both the top and bottom slurs get shaped. Starting with 2.17.4, you can use \shape on individual slurs. That allows writing something like c ^\shape ... ( _\shape ... ( I am just mentioning this for completeness: I definitely hope that there is a more convenient solution than that. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
