Re: website draft 4, help wanted
On 7/8/09 6:27 PM, Graham Percival gra...@percival-music.ca wrote: Now for *my* rant. As I've said before, I stopped using lilypond 4-5 years ago. Last Fall, I briefly got back into improving the engraving of my old compositions, but that stopped when I went to Singapore. So why am I still around? I'm really bugged by inefficiency. Users ask questions, Mats gives the same answers over and over again: inefficient. So I improved the docs. I decide to leave, but remember that it took me two weeks to get my first patch, it was horribly frustrating, and it was horribly inefficient. So I started GDP to train my replacements. Potential contributors can't figure out git, ask questions, we have the same confused discussion over and over again: inefficient. So I started the CG. Potential programmers can't figure out how to get started, and the existing programmers have learned that most well-intentioned offers of programing never pan out when they have to actually do work, so they ignore all those requests about getting started: inefficient. Another reason to start the CG, and to continually nag people to dump instructions in the CG. (we direct new contributors to the CG, so that they can demonstrate their willingness and ability to do work. Then we know that it's worth spending hours helping and training them, rather than hoping that an unknown contributor will be in the 25-40% of new contributors who will actually stick around) You know what kind of website I think we should have? I think we should have whatever website the community is willing to make. So far, the community that's willing to make a website consists of me, Patrick, Jonathan, and Francisco. Plus many others who give suggestions... but when it comes to actually sitting down and writing the content, hacking the perl, and whatnot, it's just us. Which, in itself, is a horrible waste. Every hour that I spend working on the website is an hour that I'm not working on writing instructions about how to make releases. Whenever I retire from building releases, I don't want my replacement to spend *another* 5 months trying to figure out how to build the regtests correctly or run the upload script. Every hour I spend on the website is an hour that I'm not rearranging LM 1 and the AU. You know, we had a sincere offer to help write docs for alternate editors, 2 or 3 weeks ago. But *that* can't be done until I've made the space for that in LM 1. Every hour I spend on the website is an hour that I'm not investigating+discussing Reinhold's ajax-search stuff, which I *promised* that I'd do in 1 week on June 23. Every hour I spend on the website is an hour that I'm not checking over the CG, which needs to be done before we can start GOP, which is a (the?) prime time to gather more contributors. Every hour I spend on the website is an hour that I'm not writing another column for the LilyPond Report, which may or may not be holding up the next issue. Every hour I spend on the website is an hour that I'm not dealing with the 58 emails containing material which should be added or fixed in the docs. (and yes, all your GDP graduates reading this, I _am_ slightly miffed at you. I spent a lot of time training you 21 people so that I wouldn't have to deal with this stuff any more) Every hour I spend on the website is an hour that I'm not starting my own Tadpole stuff, which is particularly annoying since I was really hoping to start doing programming bugfixes myself, this summer. Given all those tasks... and all the potential contributor effort that's waiting for me to finish those tasks... it really doesn't make sense for me to be gathering a list of productions and nagging famous lilypond users to send pictures. Which, thankfully, I've offloaded to Jonathan. But it also doesn't make sense for me to be rewriting the Old News from the current website into texinfo to add to the new website, but I'll probably end up doing that. In some ways, I actually cringe more when I see Patrick working on the website. Not because he doesn't do a great job of the CSS and perl hacking (he *does* do a great job of this), but because he could be working on so many other things. CSS isn't hard; there's dozens of users that _could_ be doing it. But improving the SVG backend of lilypond _is_ hard. Nobody else is doing _that_. Fixing build bugs in GUB is hard; you and he are the only people currently working on that. Frankly, if the really annoying lilypond bugs like #34 (grace notes) ever get fixed, there's a good chance it'll be done by Patrick. So why the bloody mao is he the main person working on the CSS? We should get a relatively inexperienced contributor / web-savvy user to do that stuff. *That* is why I'm not going to spend (significant) time screwing around with the appearance. If somebody is seriously interested in this task, I'll gladly
Re: Chordnames and added Bassnotes
On 7/7/09 5:38 AM, Werner mey@web.de wrote: Hello, is there a possibility to print e.g. F _ C instead of F/C ??? As far as I know, this is not easily done right now. The chord naming code is currently under revision; I think that it will be more easily done in the future. If you were to use Tao Cumplido's techniques for writing chord names as Lyrics, it would be pretty straightforward to create a markup like you want. Hope this is helpful, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: chordChanges true, but certain cautionary chordnames wanted
On 7/7/09 6:44 AM, Werner mey@web.de wrote: Hello. For accidentals there is the possibility to obtain them also if not needed by adding an exclamation mark ! How to get a chordsymbol if \set chordChanges = ##t ? Is there a hint? (Would be nice with the exclamation mark too.) This is not available. You could make this request on the the bugs-lilypond list, where it would be added as an enhancement request. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bass clarinet fingering chart
Mike, great work! I have some comments below On 7/7/09 2:46 PM, Mike Solomon mike...@ufl.edu wrote: Hey lilypond-users, Before I put this on the LSR, please play around with this. Specifically, please 1) Make it less sprawling. Decrease your tab settings. Follow the indentation suggestions given in the Contributors' Guide, section 7.2 http://lilypond.org/doc/v2.12/Documentation/devel/contrib-guide/Programming -without-compiling#Programming-without-compiling They'll help you make it less sprawling. 2) Find anything that's broken (the below examples work). 3) Change layout to better-suit your wind-playing needs. 4) Make any and all layout or coding suggestions. THANK YOU!!! ~Mike General comment -- LilyPond coding style is to not use variable names like fsize. What is f? font-size would be better. Similarly, what is val? \version 2.13.0 #(define (make-number-bcl layout props fsize stretch offset val) (ly:stencil-translate (ly:text-interface::interpret-markup layout props (make-general-align-markup X RIGHT (make-general-align-markup Y DOWN ( markup #:abs-fontsize fsize val (cons (* -0.5 stretch ) (* offset stretch) ) ) ) inl, outmk? bcl, as well Oh, I finally see. inl is input-list, outmk is output-markup #(define (make-named-bcl inl outmk biglist) (if (eqv? 0 (length inl)) outmk (begin (set! outmk (append outmk (if (list-ref inl 0) (list-ref biglist 0) (list (markup #:null))) )) (make-named-bcl (cdr inl) outmk (cdr biglist)) ) ) ) #(define-markup-command (multiphonic layout props inl) (list?) multiphonic doesn't make much sense to me. bassClarinetDiagram? (let* (;radius of the circles (radius (list-ref inl 0)) ;font size, grows and shrinks with radius (fsize (* radius 12)) ;degree of stretch of the holes as a function of radius size. Make 0.0 to 0.5 for good results. (spread (list-ref inl 1)) (stretch (+ (* 2 radius) (* spread radius)) ) ;more or less the approximation from the bible (PI 3.14159265) No need to make PI this many digits; 4 decimal places is sufficient. ;list of left keys (lbiglist left-key-list instead of lbiglist (then the comment isn't needed, the code is self-documenting). (list (list (markup #:abs-fontsize fsize B)) (list (markup #:abs-fontsize fsize F) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:sharp)) Note that I stacked the two arguments to the (list ) procedure to deal better with line breaking. (list (markup #:abs-fontsize fsize E)) (list (markup #:abs-fontsize fsize E) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:flat)) (list (markup #:abs-fontsize fsize G) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:sharp)) (list (markup #:abs-fontsize fsize F)) ) ) ;list of right keys (rbiglist (list (list (markup #:abs-fontsize fsize A)) (list (markup #:abs-fontsize fsize G) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:sharp)) (list (markup #:abs-fontsize fsize E) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:flat)) (list (markup #:abs-fontsize fsize C) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:sharp)) (list (markup #:abs-fontsize fsize F)) (list (markup #:abs-fontsize fsize E)) (list (markup #:abs-fontsize fsize F) (markup #:abs-fontsize fsize #:raise 1 #:fontsize -2 #:sharp)) ) ) ;bools for the fill/non-fill holes (h0 (list-ref inl 2)) (h1 (list-ref inl 3)) (h2 (list-ref inl 4)) (h3 (list-ref inl 5)) (h4 (list-ref inl 6)) (h5 (list-ref inl 7)) (h6 (list-ref inl 8)) (rkey (list-ref inl 9)) I'd put these each on a separate line, rather than dumping them all into one line. My rule for (let ) is that every variable definition needs to start at the exact same column. ;necessary schtuff for the left named keys Use stuff, not schtuff. Non-native-english speakers may not catch the meaning, and be unable to find the word in a dictionary. (lkeyl (list-ref inl 10)) (lkeymkp (list (markup #:null))) (lkeymkp (make-named-bcl lkeyl lkeymkp lbiglist)) ;necessary schtuff for the right named keys (rkeyl (list-ref inl 11)) (rkeymkp (list (markup #:null))) (rkeymkp (make-named-bcl rkeyl rkeymkp rbiglist)) ;values to draw the R hole (halfbase (* radius (cos (/ PI 10))) ) (height (* halfbase (/ (sin (/ (* 4
Re: new website: draft 3
On 7/2/09 1:41 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, Jul 01, 2009 at 03:50:14PM +0200, Mats Bengtsson wrote: Graham Percival wrote: where is the gui is unfortunately still common, but the new website and the 10.5 GUI work should fix that. Actually, I beg to differ. Since the rewriting of the website last January, where is the gui is virtually gone. The remaining GUI question is Why doesn't the Mac GUI work. And the running 10.5 GUI should resolve that. If the right approach to FAQ is followed, then I think Graham is right. But this means that docs *must* be rewritten in response to FAQ. If the only response to the FAQ is RTM in section X.Y.Z, we're not meeting the need. There's some reason why the use is not finding that, and we need to be aggressive about fixing that problem. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond-user Digest, Vol 79, Issue 104
On 6/25/09 8:37 AM, Hajo Dezelski dl1...@googlemail.com wrote: Possibly we should also think of - a better slogan? it seems to me that Sibelius 6 - Perfect scores is more attractive than music notation for everyone. possibly something vaguely like: ... Jan. Lilypond - Keep up with tradition - Engrave like the masters LilyPond -- Masterful Music Engraving LilyPond -- Your personal master engraver Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Header title problem or convert-ly problem
On 6/25/09 2:37 PM, Jay Hamilton jay...@linuxquestions.net wrote: A: I have tried over and over to follow the docs. AND I have copy and pasted both Mats suggestions and now Simon's . Mats has never worked. Yes the version info is in the file. No it did not work. Simon's suggestion, I renamed the file without the space and in fact after that copy/pasted his version into run and it can't find convert-ly so I browsed to my applications file (on my desktop which is where I install lily from) and convert-ly flashes and there is no new version or file that I can find anywhere and the problem continues to exist. So I need more hints as either 1] how to change the header so it works the way it did in 2.10 or 2] how to get convert-ly to work on my machine. Thanks Go to Start menu, select Run.., and type cmd in the box. This will open a command window. Then change directory to the directory containing your .ly file. You change directory with the cd command. It's hard to give you exact instructions, because I don't know where things are. But to use the cd command, you type cd c:\Documents and Settings\Frybyte\Desktop\Hamilton\ You'll know you're in the right directory when you type dir and you can see your .ly file in the resulting list. Then you want to type convert-ly which should give you a help message about convert-ly. Then you will type convert-ly --from=2.10.25 --to=2.12.2 my template.ly template2.12.2.ly That should make it work. You may also be able to make it work by typing in the run box under the start menu convert-ly --from=2.10.25 --to=2.12.2 C:\Documents and Settings\Frybyte\Desktop\Hamilton\mytemplate.ly C:\Documents and Settings\Frybyte\Desktop\Hamilton\mytemplate-new.ly The format of a convert-ly command is convert-ly --from=FROM-VERSION --to=TO-VERSION FROM-FILE-NAME TO-FILE-NAME The command you typed in was not in this format, if what you reported below is correct. HTH, Carl Unfortunately, I have never been able to get convert-ly to work. It's mostly my computer ignorance. My files don't seem to be in simple places and I never get the parameters correct. so I have the file in C:\Documents and Settings\Frybyte\Desktop\Hamilton it's called my template.ly it's version 2.10.25 I just tried to follow the instructions from the docs here's what I think it says to do in run under xp convert-ly --from C:\Documents and Settings\Frybyte\Desktop\Hamilton\ mytemplate.ly\version 2.10.25 --to C:\Documents and Settings\Frybyte\Desktop\Hamilton\my template.ly version 2.12.2 That didn't work so what am I not understanding? ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/23/09 9:16 AM, Grammostola Rosea rosea.grammost...@gmail.com wrote: Tim McNamara wrote: On Jun 15, 2009, at 2:00 PM, Kieren MacMillan wrote: Wol et al: Would it be reasonable to separate the functions of putting notes on the staff and chord names above the staff, and let the user spell out the chord names separately from the notes on the staff? Doing so might really simplify this discussion and result in better control of the final output. To me (but I'm not a real experienced jazz musician or lilypond user) I agree with this comment. Keep things simple!? But this facility a) doesn't exist in LilyPond b) would require changes to the parser, and c) has nobody who is willing to pursue doing it. So, although it may seem simple to the user (things usually seem simple when they are sketched out without full details), implementing this is not simple at all. The simple approach requires both notes (which are transposable) and modifiers (which are not). We currently have what I think will be a really good chord naming facility being put together by Thomas; I expect it to be part of the development version in about 10 days. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/23/09 5:19 PM, Tim McNamara tim...@bitstream.net wrote:
On Jun 23, 2009, at 12:24 PM, Carl D. Sorensen wrote:
On 6/23/09 9:16 AM, Grammostola Rosea
rosea.grammost...@gmail.com wrote:
Tim McNamara wrote:
On Jun 15, 2009, at 2:00 PM, Kieren MacMillan wrote:
Wol et al:
Would it be reasonable to separate the functions of putting notes on
the staff and chord names above the staff, and let the user spell
out
the chord names separately from the notes on the staff? Doing so
might really simplify this discussion and result in better
control of
the final output.
To me (but I'm not a real experienced jazz musician or lilypond
user) I
agree with this comment.
Keep things simple!?
But this facility
a) doesn't exist in LilyPond
b) would require changes to the parser, and
c) has nobody who is willing to pursue doing it.
I think I may have written my comment poorly. What I meant was
having LilyPond *not* parse c e g b into a Cmaj7 chord name above
the staff at all. The parser is just going to run into trouble
trying to interpret something like e c e ges bes d as C9b5/E
because it can't read the intent of the user, only the notes in the
bracket about which it can only make its best guess. It would
probably come up with Em7b5sus4 or something which is not the same
thing in terms of musical intent, and musical intent is what the
musician playing the piece wants to know.
I think I understood your intent. The problem is that the *only* way we
have to input chords is in formats that enter notes (either e c' e ges bes
d or \chordmode {c:9.5-/e}). There is *no* facility in LilyPond for
entering chords as text.
The parsing of c:9.5-/e converts that string into a set of pitches, along
with a bass and an inversion (at least I think it does; I haven't reviewed
it carefully for a while, and when I did review it I wasn't as familiar with
LilyPond as I am now).
The project that Thomas is working on is making sure that when the output of
\chordmode{c:9.5-/e} is passed to the chordnames context, it will give bag
c9b5/E in the appropriate format.
I would recommend requiring the user to write the chord names out in
a text entry format (e.g., c1:9.5-/e or something like that) *if*
they want chord names above the staff and not parsing note entry to
get chord names (if indeed LilyPond can do this at all, I've never
looked into it). This makes the most sense to me (and I hope my
intent is clearer).
Right now, the ChordNames context works much better with chords entered in
\chordmode, because it knows the root and the inversion, rather than having
to try to guess the chord.
I suspect that there won't be a lot of effort right now trying to deal with
inversions or added basses, but that may come in the future.
In my opinion, the biggest problem we currently have is that we don't always
get good chord names out of \chordmode chords. But I think Thomas will have
that fixed shortly
Thanks,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: subdivideBeams broken?
On 6/21/09 9:49 AM, Hans Aberg hab...@math.su.se wrote: On 21 Jun 2009, at 16:47, Trevor Daniels wrote: SubdivideBeams will break beams at intervals defined by beatLength, which by default is set to 1 over the denominator of the time signature. Yes, but this is what goes wrong, as my time signature is 7/16, and then I use \set beatGrouping = #'(2 2 2 1) So they should be the same. I think you need to set beatLength explicitly with \set beatLength = #(ly:make-moment 1 8) However this works. If I, however set \set beatLength = #(ly:make-moment 1 16) then I get the error. So it seems that this one is set properly by the time signature, but then beatGrouping expects it to be set to 8ths. I think you misunderstand how beatGrouping works. In previous versions of LilyPond (2.10, and less than 2.11.x, where I don't remember what x is -- it was about August 2008), beatGrouping didn't work for autoBeaming. beatGrouping sets the points at which autobeams end, unless there are explicitly set rules. beatLength sets the points at which beams are automatically subdivided. By default, beatLength is the numerator of the time signature. By default, beatGrouping is set according to the time signature for standard time signatures (you can see the defaults in scm/music-functions.scm). In your case, LilyPond was doing exactly what you asked it to. subdivideBeams set to ##f, the beams were not subdivided. And the beatGrouping of (2 2 2 1) was overridden by your explicit rule to break beams at 4/16. With subdivideBeams set to ##f, beams were broken at 4/16 (according to your rule), and subdivided every 1/16 note, since that's the beatLength you had by default. If you want beams to be subdivided at (2 2 2 1), then just set beatLength to 1/8, and you'll get what you want. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
FW: [frogs] Re: Patching the output file naming code (Was: thanks to whomever put this in the LSR...)
I've forwarded Ian's message from the Frogs mailing list, because I don't
know how to answer his question. I'm sure somebody on -devel will.
Thanks,
Carl
-- Forwarded Message
From: Ian Hulin i...@hulin.org.uk
Reply-To: fr...@lilynet.net
Date: Sat, 20 Jun 2009 17:25:42 -0600
To: Reinhold Kainhofer reinh...@kainhofer.com, fr...@lilynet.net
Conversation: [frogs] Re: Patching the output file naming code (Was: thanks
to whomever put this in the LSR...)
Subject: [frogs] Re: Patching the output file naming code (Was: thanks to
whomever put this in the LSR...)
Hi Reinhold,
I've now started doing some work on this, and the big disadvantage with the
current use of #(define output-suffix whatever) et al. is that they affect
all the files in all \score or \bookpart sections. What I would like to do
is pick up a value of the property from something like a \paper block within
the current \score or \bookpart. Is \paper the right place to put
properties relating to output filenames, or should it be property of \score
itself?
Either
\bookpart {
\header {
blah...
}
\score \with {output-suffix=Allegro}{
blah...
}
}
Or
\bookpart {
\header {
blah...
}
\score {
\paper {
output-suffix= Allegro}
}
blah...
}
}
Now how do I pick up a property value from a specific currently active
lilypond block in Scheme? I can pick up the results of #(define
output-suffix Allegro) by calling ly:parser-lookup. What do I use for
lily property? Below is my latest attempt
(define (get-outfile-name parser base )
(let*
((output-suffix (ly:parser-lookup parser 'output-suffix))
(counter-alist (ly:parser-lookup parser 'counter-alist))
(alist-key '())
(result '())
(output-count (assoc-ref counter-alist output-suffix)) )
(if (string? output-suffix)
(set! alist-key (format ~a-~a base (string-regexp-substitute
[^a-zA-Z0-9-] _ output-suffix)))
(set! alist-key base))
(set! result alist-key)
;; must be careful: output-count is under user control.
(if (not (integer? output-count))
(set! output-count 0))
(if ( output-count 0)
(set! result (format #f ~a-~a alist-key output-count)))
(ly:parser-define!
parser 'counter-alist (assoc-set! counter-alist alist-key (1+
output-count)))
result)
)
(define (print-book-with parser book process-procedure)
(let*
((paper (ly:parser-lookup parser '$defaultpaper))
(layout (ly:parser-lookup parser '$defaultlayout))
(base (ly:parser-output-name parser))
(outfile-name (get-outfile-name parser base)) )
(process-procedure book paper layout outfile-name)
))
Cheers,
Ian
}
Reinhold Kainhofer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am Dienstag, 9. Juni 2009 23:29:34 schrieb Ian Hulin:
Hi Reinhold,
I'm having a look at seeing if I can pick up the work Marek Klein did on
-devel. It covered amending the coded generating output file suffixes
to allow users to code user-specified names as the suffix. It changes
the function print-with-book in file lily-library.scm so one of the
internal variables uses a Scheme alist.
How much more work would it be to implement Patrick's suggestion below?
Almost none, see below for a consistent proposal.
But it would be nice to have an option to override the file-name for
any arbitrary book. Something like
\book {
\paper {
output-file-name = Blah
}
\score {
...
}
}
.
.
.
As I understand it, the above would allow allow you to have a file
called something like mozsym40.ly and use
\paper {
output-file-name=SinfoniaK550
}
to generated SinfoniaK550.pdf, .png, .mid, .midi or whatever.
That would not be hard to implement (if you look at the print-with-book code,
you'll see that currently the file name is concatenated from base and suffix.
You'd have to add another check and not use the base name for this). However,
it will be a little harder to make this system consistent and easy to use.
Currently, we have:
basename-suffix(-nr)
where the number will become optional with the patch.
Of course, one can add another layout variable 'output-basename, which will be
used instead of the basename (so the suffix will still be used), however, in
this case the numbering within suffixes will not be ideal. You can then get:
mybase1-suffix
mybase1-suffix-2
mybase2-othersuffix
mybase2-suffix-3
I.e. the numbering will be only within each suffix, even if it is for a
different
basename...
The alternative is to use the basename-suffix combination as the key in the
alist to look up the naming. This would probably be the ideal way.
So, if you really want to generalize the naming even further, I would propose:
- -) A layout variable 'output-basename (default: the input file name,
Re: subdivideBeams broken?
On 6/21/09 3:27 PM, Hans Aberg hab...@math.su.se wrote: Yes, beatLength will do a (2+2)+(2+1) beaming. Though this is one possible beaming for what I am writing now, my problem is that I have bunch of different meters. For example, I may want (2+2)+3, (2+2)+3+(2+2) and so on. I have looked at the stuff you describe above (Sub-dividing beams, page 60/70 in the manual). It seems that beatLength assumes that subdivisions should happen on multiples of this time values. This does not work with a meter beaming like 3+(2+2) or (2+1)+(2+2). See code below - it seems that this 3 causes problems. Yes, this is a known limitation of the beam subdividing. It is only implemented for beatLength adjustments. Personally, I don't like using beatLength for beam subdivision. To me, beatLength should have one meaning only -- the numerator of the time signature. The auto-beaming model is perhaps too crude for subbeaming all these meters - in some, a trick might do. It's not the auto-beaming model, but the beam-subdividing model that is too crude. And that is unfortunate, because I know of no way to do a manual beam subdivision. But there has been a proposal floated to fix this, so maybe it will be improved Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: subdivideBeams broken?
On 6/21/09 4:25 PM, Mark Polesky markpole...@yahoo.com wrote: Carl D. Sorensen wrote: By default, beatLength is the numerator of the time signature. Don't you mean denominator? I would call the numerator beatCount or something. Haven't followed this thread, just wanted to make sure a misunderstanding wasn't being propagated. Yes, that's what I mean. Thanks for clarifying. Sometimes I engage my fingers before my brain works properly, if that's possible Carl - Mark ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Petrucci-like spacing?
On 6/18/09 8:45 AM, Laura Conrad lcon...@laymusic.org wrote:
Carl == Carl D Sorensen c_soren...@byu.edu writes:
Carl Does this seem at all promising?
Yes, but there's still the problem of extra space at the barline. I
tried Michael's solutions and doing nothing at all and there's still
extra space after the 4th whole note.
Carl How about this?
Carl \relative c'' {
Carl \key f \major
Carl \cadenzaOn
Carl g1*1/4 bes1*1/4 a1*1/4 g1*1/4 g1.*1/6 c4 bes4 c1*1/4
Carl }
Carl I think that gets rid of the extra space.
Yes, it does.
Here's the code defining petrucciSpacing:
petrucciSpacing =
#(define-music-function (parser location music) (ly:music?)
Set effective spacing of all notes to 1/4
(music-map (lambda (m)
(if (eq? (ly:music-property m 'name) 'NoteEvent)
(let*
((current-duration (ly:music-property m 'duration))
(current-log (ly:duration-log current-duration))
(current-length (ly:duration-length current-duration))
(current-dotcount
(ly:duration-dot-count current-duration))
(new-factor (ly:moment-div
(ly:make-moment 1 4)
current-length))
(new-numerator (ly:moment-main-numerator new-factor))
(new-denominator
(ly:moment-main-denominator new-factor)))
(set! (ly:music-property m 'duration)
(ly:make-duration
current-log
current-dotcount
new-numerator
new-denominator))
m)
m))
music))
\relative c'' {
\key f \major
\cadenzaOn
\petrucciSpacing {
g1 bes 1 a1 g1 g1. c4 bes4 c1 \bar ||
}
}
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: RFC: new vertical layout engine
On 6/15/09 2:37 PM, Jonathan Kulp jonlancek...@gmail.com wrote: Joe Neeman wrote: I've started working on a new system for doing vertical layout in one pass (ie. positioning and stretching the systems simultaneously). This should give better default behaviour than the current code and it should also allow easier and more useful overrides. I plan to merge the code after 2.14 is released, so it should appear in the 2.16 stable version. The code is currently in the dev/jneeman git branch. It basically works (I hope), but it is missing a lot of previously existing functionality. Thanks so much for working on this, Joe! I'd like to try it out, but I've never dealt with other branches of the source code. Can I have this branch exist alongside the master branch, and compile it separately, creating a different binary that includes your new stuff? I could also set up a new virtual machine and just get your code without the master. Jon -- Jonathan Kulp http://www.jonathankulp.com jon, you can checkout any branch you want, build it, and work with it. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems regarding figured bass
On 6/14/09 3:38 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm running into several problems with figured bass while writing another large orchestral piece. Attached is a sample file highlighting these issues: 1) How can I add a figure above a rest? It works for skips, but a figure assigned to a rest simply isn't printed at all... (see first vs. second measure, where the same figured bass input is used!) It works if I use \new FiguredBass for the figured bass, but I need the figures in the staff, since otherwise they are printed below and they align vertically, causing them to be too far away from the staff in most places. Have you tried ignoreFiguredBassRest? 2) The figures don't collide with the notes themselves, but they collide with the articulations (trills, accents, staccati, etc.) How can I avoid this? Extra-offset? 3) How can I draw a figure extender without an explicit starting figure (I think this means that the normal default triad should be held)? If I'm using s4 _ _ _ then I only get a warning message: Programmierfehler: must have Item for spanner bound of BassFigureContinuation Make an explicit starting triad with 'transparent = ##t ? I haven't tried any of these, but based on my earlier playing with figured bass, this is where I'd go. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/12/09 9:10 AM, Tim McNamara tim...@bitstream.net wrote: On Jun 12, 2009, at 1:28 AM, Tao Cumplido wrote: I think it's great that you did this. Have you put this on LSR? Thanks. I haven't put this on LSR yet because the function hasn't been much tested yet. Maybe I should have done anyway. When the function is updated I will upload it there. Perhaps we should consider adding this to the distribution. What exactly do you mean? To which part yould you add it? Ummm. Here is a question of software philosophy. Should there, like some computers languages, be many ways to do something or should there only be one? In my opinion, in the long run it makes it harder to learn to use something like LilyPond if there are six ways to do the same thing. The documentation becomes more difficult to write and to maintain, it becomes harder for new users to learn how to use the software, and as the software accretes ways to do things the package gets bigger and easier to break. LilyPond .ly syntax is a programming language itself and the clearer and more specific the rules are for its operation, the simpler and more reliable its use. I think that there should be only two ways to enter chords (at least in Western music notation systems): by putting in the notes to be placed on the staff or by entering the text name of the chord in a single standardized, sensible way. Once we start adding ways to engrave chords using the markup or lyric functions we are heading towards chaos IMHO. I agree with you, if what is wanted is chord entry. But Tao doesn't care about chords, he only cares about chord names. And so a new type of entity can be created, which isn't a chord, but instead a lyricChordName. lyricChordNames can be treated in a separate section of the documentation. They are displayed in a Lyrics context, not a ChordNames context. And they give the user tremendous flexibility to display whatever the user wants to display for chord names. Personally, I would never use lyricChordNames. I agree with you that chords are groups of notes, and we should not lose sight of that. And with your help, we should be able to rewrite the chordmode and ChordNames functionality to support that usage. But there is a (to me) surprisingly large contingent of users who claim that there is no well-defined connection between chord names and chord notes, and that they want total control over the symbols to be displayed. And the lyricChordNames functionality is a way to get transposable chord names for people who are in that camp. I don't think it's a problem to have multiple clearly-defined modes. That's why I think it may be feasible to implement Tao's suggestion. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Petrucci-like spacing?
On 6/8/09 6:15 PM, Laura Conrad lcon...@laymusic.org wrote:
Carl == Carl D Sorensen c_soren...@byu.edu writes:
Carl Here's my attempt to get the spacing you're looking for. I've
Carl done it manually, but if you like it, I think that I can write
Carl a music function \petrucciSpacing{} that will generate it
Carl automatically.
Carl What I've done is to multiply each note by a value necessary
Carl to make its final duration equal a 1/4 note.
Carl \relative c'' {
Carl \key f \major g1*1/4 bes1*1/4 a1*1/4 g1*1/4 d'1.*1/6 c4 bes4
c1*1/4
Carl }
Carl Does this seem at all promising?
Yes, but there's still the problem of extra space at the barline. I
tried Michael's solutions and doing nothing at all and there's still
extra space after the 4th whole note.
How about this?
\relative c'' {
\key f \major
\cadenzaOn
g1*1/4 bes1*1/4 a1*1/4 g1*1/4 g1.*1/6 c4 bes4 c1*1/4
}
I think that gets rid of the extra space.
Carl
petrucci-test-2.png
Description: petrucci-test-2.png
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/12/09 12:28 AM, Tao Cumplido tao_lilypondu...@gmx.net wrote: I think it's great that you did this. Have you put this on LSR? Thanks. I haven't put this on LSR yet because the function hasn't been much tested yet. Maybe I should have done anyway. When the function is updated I will upload it there. Perhaps we should consider adding this to the distribution. What exactly do you mean? To which part yould you add it? We could possibly add a lyric-chordnames.ly file that would include the functions necessary to create chordnames according to your scheme. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Trouble with convert-ly
On 6/11/09 4:36 PM, Father Gordon Gilbert fatherg...@gmail.com wrote: Hi Bertalan, Looking in jEdit plugin options, the line which shows were the program and convert-ly are shows /usr/bin . And Lily fires up just fine, so you'd think convert-ly should work as well. I did 'which convert-ly' and it showed /usr/bin as well. Have you done 'which convert-ly.py', or 'which convert-ly'? Maybe there shouldn't be a .py extension for convert-ly in /usr/bin? And Jedit has the .py extension in it. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/10/09 2:03 AM, Tao Cumplido tao_lilypondu...@gmx.net wrote: But as I said before, if anybody wants to create a chordname input mode that takes a root, and arbitrary name string, and an optional added bass, they're welcome to do so. http://lists.gnu.org/archive/html/lilypond-user/2009-02/msg00293.html The input-mode is a little constructed but it works. Right, but this input mode gives chords as lyrics, not as ChordNames. It's certainly a way to accomplish what you want, and I don't want to minimize the benefit of your work. I think it's great that you did this. Have you put this on LSR? Perhaps we should consider adding this to the distribution. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Issues compiling multiple voice drum midi
On 6/10/09 8:16 PM, hendr...@umn.edu hendr...@umn.edu wrote:
This issue may be too elementary for this mailing list or may have already
been addressed, however I cannot find answers in digging through the
archives and am not sure where to ask more basic questions. If I need to be
re-directed to another area please don't feel afraid to tell me to go away,
i'd just appreciate a little push in the right direction.
No, this is the right place. You'll find the -user group is very helpful, I
think.
The issue I'm having is making a midi out of a piece of drum music that
contains two voices. I'm quite sure that the problem would persist in
non-percussion music but I don't have experience trying that. I can compile
a midi file from code that contains no voice voice tags, but once I make 2
voices it compiles a midi file with no sound. To use the example in the
manual:
\score {
\new DrumStaff
\new DrumVoice = 1 { s1 *2 }
\new DrumVoice = 2 { s1 *2 }
\drummode {
bd4 sn4 bd4 sn4
{ \repeat unfold 16 hh16 }
\\
{ bd4 sn4 bd4 sn4 }
}
\midi { }
}
When compiled as a PDF it will correctly make two measures of drum music
one being: \drummode { bd4 sn4 bd4 sn4 .. }
and the next:
{ \repeat unfold 16 hh16 } \\ { bd4 sn4 bd4 sn4 }
However, when compiled as a midi it will only make the first measure of
music bd4 sn4 bd4 sn4. It does not leave empty space where the next
measure would be, it simply does not compile it. Is there something I'm
missing or is this a bug?
Looks like a bug to me, and it still exists in 2.13.1. And it's
problematic, since the example is still in the manual...
However, you can use the explicit polyphony, and it will work.
up = \drummode { \repeat unfold 16 hh16}
down = \drummode { bd4 sn4 bd4 sn4 }
\score {
\new DrumStaff
\new DrumVoice { \voiceOne {
\drummode { s1 }
\up
}
}
\new DrumVoice { \voiceTwo {
\down
\down
}
}
\layout{}
\midi{}
}
I am currently using lilypond version 2.10.33 as the manual for 2.10 is the
only one I can find instructions for entering percussion in. Perhaps this
has been changed in the updates of the language, does it compile for any
one else?
Please use 2.12 (or 2.13). Both the code and the docs are better. You can
read about percussion in 2.12 at
http:://lilypond.org/doc/v2.12/Documentation/user/lilypond/Percussion
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/9/09 9:16 AM, Jean-Alexis Montignies j...@sente.ch wrote: You can find an example of a chord notated as 'phrygian' (well it's more a modal indication, but that's what the composer Gary Peacock intended) in the lead sheet for Vignette. More arguments for using names: Alt is much more easy to write and read, less error prone than: 7.3-.5-.9-.11-.13- So if Alt is always (or primarily) 7.3-.5-.9-.11-.13- we should add an alt modifier to LilyPond. Then, we could say c:alt, and get just what the composer intends. And then we should have the ChordNames context generate CAlt. I'm not arguing that the list of modifiers is currently complete or sufficient. Certainly we could add modifiers to make things easier. I haven't pursued that idea yet, because I haven't needed it for my work. But as I said before, if anybody wants to create a chordname input mode that takes a root, and arbitrary name string, and an optional added bass, they're welcome to do so. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Missing jazz chord modifiers
In our discussion about chord names, Jean-Alexis pointed out that we are probably missing some modifiers in our chord mode input. He pointed out one example: alt: 7.3-.5-.9-.11-.13- What are some other modifiers that should be added, in your opinion? Remember that m7b5 doesn't qualify as a modifier, because modifiers must be only alphabetic. halfdim could qualify as a modifier. Please let me know what modifiers you'd like to have, as well as the pitches that the modifier should produce, and we'll see if they can be added. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Missing jazz chord modifiers
On 6/9/09 11:16 AM, lasconic lasco...@gmail.com wrote: maybe bass ? for removing third and fifth and keeping the root only? Does this mean that you'd like to have a one-note chord? I've never seen this before in notation (but that doesn't mean too much). If you do want a one-note chord, I'd prefer to use root instead of bass; we already have a modifier for changing the bass note of a chord (/), and I think having two different bass modifiers would be confusing. Under this notation, c2:root would produce a chord whose notes were only C, and whose name is what? Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: translation of the doc into italian
On 6/9/09 10:39 AM, Federico Bruni brunol...@gmx.com wrote: Hi all, as far as I can see there is not an italian documentation for lilypond. I'd like to help with that, could you please tell me how can I contribute? If other italians want to join, either for just proofreading or translating also, please speak up. I can imagine that it's a demanding work, but I'm enthusiast about lilypond and really motivated to contribute. Great! John Mandereau is the translation meister. I've copied him on this reply. The first step toward developing a translation is to read the Translation section of the Contributors' Guide. You'll find that here: http://lilypond.org/doc/v2.13/Documentation/devel/contrib-guide/Translating -the-documentation It gives you the instructions necessary to start translating. If the instructions aren't clear, ask questions on the lilypond-devel list; this will help us update our Contributors' Guide. I hope this helps you get started. Welcome to LilyPond contribution! Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/2/09 3:55 AM, Jean-Alexis Montignies j...@sente.ch wrote: Hi there, as a jazz player I would like to share my input. Thanks for sharing, Jean-Alexis. What I need in scores is really chord names. The chord name denotes the intent of the composer and is much subject to interpretation. Some examples: If you have a dominant chord, you write G7. Most of the time, the pianist will not play the 5th and depending on the context will play a 9th or a flattened 9th. If you write G7b9, it just means that if you play a 9th, you should play a flattened one (probably the melody have a flattened 9th). In the real book, most 7b5 chords should really be written 7#11, but this is another story. I found a score where a chord was named 'phrygian'. The problem I ran when i wrote chords in Lilypond: 1) I had some difficulties to write the Alt chords (for me it's based on the superlocrian scale 1 2- 2+ 3 4+ 6- (or 5+) 7-) because the scale has two seconds. (Note that the diminished scale cannot be written for now with the chord notation, if you ever want to write a 8 note chord ;) ). This an issue in chord input mode, and should be reported to bug-lilypond as an enhancement request. For you, the limitation of only one instance of each step in a chord is a limitation. 2) There no way to write N.C. : no chord (wouldn't the use of R, r and s make sense in the chord mode?) N.C. is implemented for r in chordNames context starting with 2.13.1. It will be available in the next development version. Support for generating N.C. with R is planned. I don't think that s should generate N.C.; s means don't output anything. 3) I had to use some tricks for chords that last on several measures for the symbol not to repeat on each measure. \set ChordChanges = ##t is all that it takes. 4) I would have liked to use parenthesis around the column for chord extensions like in most jazz charts. I used brackets instead. I hope we'll be able to implement this, but if we don't, remind us again. Lilypond of other programs will never be able to interpret notes as chords (even humans can't do that because there are always ambiguities). I think the more sensitive approach for pop and jazz is a chord library with a string as input (maj7) and as output a notation as markup for chord symbol, optionally as a realisation as notes or chord diagram (could even have options to select or override the realisation). That's what we have in essence with our current chordmode. The string has some specific syntax, and it provides realization as notes, chord diagrams, and chord names. But the chord names functionality isn't what we want right now. I myself need only the chord symbol. Such a simple model is in my opinion simple to use, customizable and extends easily to other musics. For me the chord name is more semantics than just notes. You'll find my current chord exception list below, note that i've used the unicode chars for the flat and sharp before the extensions as it gives a very natural layout in this case. Thank you for this exception list. It provides a nice reference. The major problem with an exception list is that it doesn't handle slash chords; I hope to be able fix that. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/1/09 12:50 PM, Grammostola Rosea rosea.grammost...@gmail.com wrote: Tim McNamara wrote: On Jun 1, 2009, at 4:13 AM, Tim Rowe wrote: 2009/6/1 Carl D. Sorensen c_soren...@byu.edu: You are welcome to pursue this, if you are interested in it. It is not my interest. I think it shows the impossibility of what you are trying to achieve, at least in the completely general case, although pushing the boundaries closer to that general case is valuable of course. Beyond trivial cases, a combination of notes does not have /a/ name, it has many names depending on the musical context. For jazz chords, the chord notes and the chord names really need to be separated (perhaps an optional name following the notes) unless the software can understand the musical context better than a lot of musicians. Or just stick with chord mode. Particularly when entering the notes and the root is not the chord name. For example, a chord I saw in a Pat Martino chart would have included: d des fes aes which was written as Dbmin/D. I have no idea how one would make LilyPond properly interpret slash chords or compound chords from note entries. As far as I can see, there is very little hope for LilyPond making the right decision about this chord entered in note mode. The first note is not the root of the chord, so it would require substantial computation time to try to identify the chord properly (and there's no guarantee that the proper chord identification is unique, based upon just the set of notes). I'm not even proposing to *try* to attack this problem. As far as my current plan goes, this chord would be identified as a D chord of some type, as is the current practice in LilyPond. If the root and inversion have not been identified (which they will not be when chords are entered in note mode), then the first note in the chord is identified as the root, which gives weird chord names. Rendering chords written as chord names (des2:m5/d) would of course be simpler. Yes, and that functionality is not currently as strong as we'd like it to be, I think. That's what I'm proposing to rework, when I get the chance. I agree with this. Couldn't there be an 'automatic chord mode' and an 'mode which just display the chord names', not the notes? What do you mean by 'automatic chord mode', and 'mode which just displays the chord names'? We currently have a context which just displays the chord names. It's called ChordNames. We *don't* have a mode which just *accepts* chord names. We have a mode (chord mode) that accepts a root, a modifier, a maximum chord step, and can add, remove, and modify chord steps, including moving a pitch to the bass or adding a pitch to the bass. This mode does not use chord names per se, because chord names tend to be ambiguous (all one needs to do is look at the variety of names for a given chord as defined by a set of pitches to see this). Parsers tend not to deal well with ambiguities, so what we have is a completely non-ambiguous input format. Someone who understands the chordmode input format can look at a chordmode expression and determine exactly what pitches are intended to be included in the chord. A chordnamemode *input* mode has been proposed a couple of times. This mode would take only a root (and optionally, a slash or alternate bass note), and everything else about the chord would be in the form of a markup. For american jazz chords, this functionality seems to be feasible (but it couldn't handle the german practice of making minor chords have a lower case root name, instead of an upper case root name for a major chord). But I do not have the expertise to implement such a mode, and I'm not really interested in spending my time to develop such a mode. For somebody who is familiar with the parser, it may not be a huge deal to implement such an input mode. If we had such a mode, we could add properties to a ChordEvent, I think we could add the necessary properties to store the chord name information that was generated by the input. And the ChordNames context could be modified to display those (except that I'm not sure how slash notes would be handled; but I would guess it's possible to do so). I guess that the bottom line to this ongoing request for a chord name *input* mode may be able to be implemented, but it will likely take somebody who is interested in it deciding to put in the time to make it happen, like Marc has done with tablature. Discussions about how it might work, what the input syntax should be, etc. can be held, but they will remain just interesting reference material until somebody decides to do something about it. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Problems with Piano Staff Template
On 6/1/09 1:38 PM, Jonathan Kulp jonlancek...@gmail.com wrote:
Mats Bengtsson wrote:
Mark Austin wrote:
Thanks James. Works a treat now. However, this means the error is in
the template in the Learning Manual, since I copied it straight over.
The first few lines of the first \score block should be:
\score {
\new PianoStaff = PianoStaff_pf
\new Staff = Staff_pfUpper \global \upper
\new Dynamics = Dynamics_pf \dynamics
\new Staff = Staff_pfLower \global \lower
\new Dynamics = pedal \pedal
Yes of course! Carl or John, could you fix this in LSR and in the GIT copy?
A subsidiary question. What does the second \score block do?
Ok I fixed this in LSR. Does that mean it will show up properly in the
docs next time they're recompiled, or do I need to fix it somewhere else
as well?
By fixing it in LSR, when makelsr.py is run, the new versions will get into
the docs, IIUC.
Thanks,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/1/09 8:56 PM, Tim McNamara tim...@bitstream.net wrote: On Jun 1, 2009, at 2:33 PM, Carl D. Sorensen wrote: A chordnamemode *input* mode has been proposed a couple of times. This mode would take only a root (and optionally, a slash or alternate bass note), and everything else about the chord would be in the form of a markup. For american jazz chords, this functionality seems to be feasible (but it couldn't handle the german practice of making minor chords have a lower case root name, instead of an upper case root name for a major chord). Carl succinctly illuminates another problem, which is that LilyPond works with many different musical systems. I am only familiar with what he calls American jazz chords and would be out to sea if a German chart was placed in front of me- or one of the many other notation systems with which I am unfamiliar. Heck, I am out to sea often enough with American jazz charts! Any changes to the chordname function would need to be context-sensitive to the needs of many musical systems. Would it be feasible to make differences in chord naming conventions part of language-specific files, like \include english.ly or \include german.ly etc.? Or does that just end up resulting in multiple exceptions and complicating things immensely? I think this idea is interesting, but I would be opposed to it. I use nederlands (default) note names, but I want American chord names. As long as we have a relatively simple command to change chord name modes, I think we're OK. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Better MIDI
On 6/1/09 5:29 PM, Peter Chubb lily.u...@chubb.wattle.id.au wrote: Hi, I've put up a page on how to get more realistic sounding MIDI output from current LilyPond, along with the scripts and scheme code used, at http://www.nicta.com.au/people/chubbp/articulate Peter, I haven't had a chance to look at your code, since I don't have a login to your server, and it wasn't attached to your email to the list. The improved MIDI sounded good to me. I'd like to get it into the distribution. As a first step, it could be included in an optional add-in. The way to make it work is probably to first split your scheme and lilypond code. I'd recommend that you put your scheme code in a new file that could be placed in the scm/ directory, perhaps something like articulation.scm. And then you'll have your lilypond syntax stuff in articulation.ly file that can be placed in the ly/ directory and included in a lilypond file. Then, you can post your articulation.scm and articulation.ly files on the lilypond-devel list, where it will be reviewed by the experts. It has before-and-after MIDI samples to listen to, and a full description of what the script does and how to use it. Is there any way that the scheme code can be distributed with LilyPond? It's fairly useful now, but could do with going over by some real experts for improvement. In particular I'd like to get rid of the double pass over all the notes (first to find out what to do then to do it), and the hacked up communication between the two passes. I'd also like to do something about trills and turns with alterations, and do a better calculation for trill duration. Sounds great. The best way to get a review is to post code on -devel. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 6/1/09 1:45 PM, lasconic lasco...@gmail.com wrote: Hi, Just in case it can be helpful, someone (Karl) post a pdf he wrote on MuseScore (http://www.musescore.org) mailing list about chord name display. Musescore is a free GPL WYSIWYG scorewriter (with lilypond export capabilities) Maybe it can be helpful to your current and future work on chord names engraving for light music. Here is the discussion thread: http://n2.nabble.com/Setting-file-associations-for-Windows-td2729864i20.html#a 2859233 Here is the link to the pdf : http://www.njonjo.net/chordfonts/chordfonts.pdf Thank your for this link. It is always helpful to see what other people propose for standards. Personally, I don't like the look of this proposed standard. I'm sure it could be implemented in LilyPond, but I have seen other layouts that I find more pleasing than this one. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/30/09 10:55 PM, Brett Duncan bdd1...@bigpond.net.au wrote:
Carl D. Sorensen wrote:
I assume that there would still have to be some means of creating
exceptions. If someone wants chords named mainly in the Real Book style,
but with minors notated slightly differently ( Cm / Cmi / C- ) for
example, would they find themselves having to put together a large list
of exceptions to get their preferred style? Or would there be some other
way of 'tweaking' just that aspect of how chord names are displayed?
I haven't done it yet, so I don't know.
But I imagine we can have a property minorSymbol which could have values
like \markup {m}, \markup {mi}, \markup {-}, or 'lowerCaseRootName
Then a user could specify the markup to be used to indicate a minor, etc.
Sounds good.
Right now we have a naming problem, separate from the display problem. If
we can get the code to recognize that we have a Ebmaj7b5, then we can figure
out how to display it in a way that the users will like. Right now, we
haven't had much luck with anything but exceptions in terms of getting chord
names.
Given that I have only ever used \chordmode with ChordNames, I hadn't
noticed the problem, but having done a little test, I can see what you
mean. The chord d f aes c produces a chord name of Cb6/sus4/sus2!?
Bizarre!
Which scheme file processes the chord to produce the name?
scm/chord-names.scm, IIRC.
CarL
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/31/09 7:34 AM, Johannes Schöpfer j...@schoepfer.info wrote: Hi, As I already said some time ago when I made my own chordnames functions, I still believe chordnames should be seperated from chords, or at least chords shouldn't produce chordnames since it'll never be clear. And the other way round there can also occur problems, i.e. with C7alt., how should Lilypond know which chord to display then. Another thing is the exceptions list. I think instead of defining some standards (\realbook, etc.) it would be easier to just type what you mean, maybe something like c:m7, c:mi7, c:-7 That way everyone could just type each chordname as they want it to be displayed instead of selecting an exception for each from a list. I have an idea that goes in that direction. It would simplify both entry and interpretation: Basenotes are the only thing really needed to be recognized as note to make a chord(meaning just the basenote) transposeable and to get the duration. Anything else may be added without interpretation. Syntax proposal for \chordName: Basenote[:optional text] [optional anyextension] [ optional / for slash-chords [Basenote ...]] You are welcome to pursue this, if you are interested in it. It is not my interest. This would require changes to the parser. I do not have the ability to make these changes, and I'm not interested in developing this capability. But if you, or somebody else you can find, is interested in doing this, we can have the discussion. Right now there is not chordName input mode. There is note mode, where we input chords using the chord construct, and chord mode, where we input chords with the root plus modifiers. chord mode is well defined, logical, and unambiguous, so I don't see a need (or desire, IMO) to change chord mode. Right now chordName is strictly an *output* characteristic; a context that displays chord names based on notes it receives. It relates notes to chord names. That's what I'll be working on. I'm interested in that, because it works well with midi, and fretboards, etc. This would remove any exeptions for chordentry as anything is dispalyed as it was entered. Displaying the whole chord(es g bes d) interpreted as notes would not be possible, but i personally never needed that. My interest is in getting the notes correct, and being able to generate the names from the notes. I realize that there are some (like Tao) who just want names. I can see that it might be a great contribution to LilyPond to create a chordname input mode, which could do what you want to have done. I'd be happy to provide whatever help I could provide to somebody who wants to do this. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/30/09 3:21 AM, Brett Duncan bdd1...@bigpond.net.au wrote: Grammostola Rosea wrote: Do we have an Jazz/pop chord expert on the list (I'm sure he/she exist)? And who wants to help with this? I don't consider myself an expert, but after 20 years of playing with various pop, rock and jazz groups, I've got a pretty good idea of what's out there as far as chord notation goes, and I'm willing to be part of the discussion. I'm also willing to help on the programming side _if_ I can get my head around Scheme. Brett On 5/30/09 3:32 AM, Tao Cumplido tao_lilypondu...@gmx.net wrote: Original-Nachricht Do we have an Jazz/pop chord expert on the list (I'm sure he/she exist)? And who wants to help with this? I wouldn't call myself an expert but I do know some display methods for chords. I don't know if pop chords differ much from jazz though but if it's for sharing knowledge on jazz chords count me in. I could make a table with a rough overview of the variations for chord names I am aware of and maybe some information on different typographical approaches I know of. My currently-planned starting point for chord naming is http://www.dolmetsch.com/musictheory17.htm#namechords If you have any disagreement with this reference, please let me know. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/30/09 9:53 AM, Grammostola Rosea rosea.grammost...@gmail.com wrote: Tim McNamara wrote: On May 30, 2009, at 9:50 AM, Carl D. Sorensen wrote: On 5/30/09 3:21 AM, Brett Duncan bdd1...@bigpond.net.au wrote: Grammostola Rosea wrote: Do we have an Jazz/pop chord expert on the list (I'm sure he/she exist)? And who wants to help with this? I don't consider myself an expert, but after 20 years of playing with various pop, rock and jazz groups, I've got a pretty good idea of what's out there as far as chord notation goes, and I'm willing to be part of the discussion. I'm also willing to help on the programming side _if_ I can get my head around Scheme. Brett On 5/30/09 3:32 AM, Tao Cumplido tao_lilypondu...@gmx.net wrote: Original-Nachricht Do we have an Jazz/pop chord expert on the list (I'm sure he/she exist)? And who wants to help with this? I wouldn't call myself an expert but I do know some display methods for chords. I don't know if pop chords differ much from jazz though but if it's for sharing knowledge on jazz chords count me in. I could make a table with a rough overview of the variations for chord names I am aware of and maybe some information on different typographical approaches I know of. My currently-planned starting point for chord naming is http://www.dolmetsch.com/musictheory17.htm#namechords If you have any disagreement with this reference, please let me know. The problem with this sort of thing is that there is really no standardized nomenclature and there is a lot of personal preference. For example, some people like Fmaj7 and others like F-delta (F with a triangle), or Dm7b5 versus DØ, etc. Satisfying all personal preferences might be impossible. However, that reference table looks reasonable to my eyes. My preferences were pretty strongly formed by the old Real Book 5th Edition. F-delta and Fmaj7 are two different ways of displaying a chord named F major seventh. On the other hand, Dm7b5 and D0 are two different names for the same set of notes. (But both of those names are listed in the Dolmetsch reference for that set of notes). There are some chord name exception files that have been written by other LilyPond users. Two of them were generously sent to me by James Hammons and B Duncan. These could be good references to look at, since the chord names look pretty good to me, and might be more easily incorporated without a lot of extra work. Let me know if you want me to post them. That may be a possibility. However, I think that the exceptions method is a workaround, rather than a solid means of naming chords. In particular, I don't think that the exceptions method will work for slash chords. Isn't it possible to give more options and be able to choose an way of noticing? For example \europe \vs \Berklee \realbook \fakebook Yes. That is why I want to separate naming from displaying, as much as possible. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/30/09 5:15 PM, Brett Duncan bdd1...@bigpond.net.au wrote:
Carl D. Sorensen wrote:
My currently-planned starting point for chord naming is
http://www.dolmetsch.com/musictheory17.htm#namechords
If you have any disagreement with this reference, please let me know.
It looks like a good starting point to me - there are a couple of things
that don't appear that I have seen in published music (stacked
additions, for example) - I'll make a list.
Isn't it possible to give more options and be able to choose an way of
noticing?
For example
\europe
\vs
\Berklee
\realbook
\fakebook
Yes. That is why I want to separate naming from displaying, as much as
possible.
Makes sense, but I wonder at how many options would needed - the
problem, as stated before, is that there is no standard, and every
publishing house seems to do its own thing, even to the point of having
different conventions used within the same publishing house.
I have in front of me right now three pieces which I'm currently
performing with my jazz ensemble, from two different publishers, all
bought in the last twelve months. While at first glance they appear
similar (partly because the same ugly font has been used in all three),
a closer look reveals that there are differences in the way chords are
named in all three pieces. Whether this comes from the original
composer, the arranger or the typesetter is not clear.
I assume that there would still have to be some means of creating
exceptions. If someone wants chords named mainly in the Real Book style,
but with minors notated slightly differently ( Cm / Cmi / C- ) for
example, would they find themselves having to put together a large list
of exceptions to get their preferred style? Or would there be some other
way of 'tweaking' just that aspect of how chord names are displayed?
I haven't done it yet, so I don't know.
But I imagine we can have a property minorSymbol which could have values
like \markup {m}, \markup {mi}, \markup {-}, or 'lowerCaseRootName
Then a user could specify the markup to be used to indicate a minor, etc.
Right now we have a naming problem, separate from the display problem. If
we can get the code to recognize that we have a Ebmaj7b5, then we can figure
out how to display it in a way that the users will like. Right now, we
haven't had much luck with anything but exceptions in terms of getting chord
names.
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/30/09 7:16 PM, Carl D. Sorensen c_soren...@byu.edu wrote: Right now we have a naming problem, separate from the display problem. If we can get the code to recognize that we have a Ebmaj7b5, then we can figure out how to display it in a way that the users will like. Right now, we haven't had much luck with anything but exceptions in terms of getting chord names. Oops -- obviously I meant Ebm7b5. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/29/09 2:05 AM, Marc Hohl m...@hohlart.de wrote:
Carl D. Sorensen schrieb:
[...]
Here's one way to do it:
deadNote =
#(define-music-function (parser location note) (ly:music?)
(set! (ly:music-property note 'tweaks)
(acons 'stencil ly:note-head::print
(acons 'glyph-name 2cross
(acons 'style 'special (ly:music-property note 'tweaks)
note)
{
f\4 \deadNote f'\1
}
There is some drawback/difference: the crosses are drawn without
whiteout, so they look different. Is there a way to change this?
Yes. Change the stencil so that it is a composite stencil.
Marc, feel free to add this to tablature.ly if you want to.
How should we call this? It should be clear that
\deadNotes works as expected, and the new function is meant
to be used inside chord constructs only.
\chordNoteDeadNote sounds a bit strange ...
I would recommend \deadNote, since it only applies to the next note.
The matching case for \palmMute, namely
\chordNotePalmMute seems to be ok for me.
I haven't reviewed the code carefully, but I think that \palmMute should
apply only to the next note, and \palmMuteOn should change all notes to palm
mute notes, or \palmMuteNotes could apply to a whole music expression.
Or just simply use \chordDeadNote / \chordPalmMute ?
I don't like the \chord* notation because they aren't limited to use in
chords. They will work for any single note, won't they?
Thanks,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond and Jazz chords
On 5/29/09 6:10 AM, Grammostola Rosea rosea.grammost...@gmail.com wrote: Hi, In the last months there where some questions about Jazz/pop chords. About the notation of the default chords but also about chords with an E in the bass, A/E, sus4 etc. Some people even posted ways to do it right. If I remember well, Carl has said that he was planning to work on the chords improvement. How far is this process? Not at all started. It's still floating around in the back of my head. I'm flying to England in June, with a long layover in New York City, so I may try to make it happen then. Maybe it's an idea to brainstorm a bit about how we want Jazz chords to be displayed? Maybe some interested people can form a group like the 'tablature group' does? I'd welcome people creating documents that describe how chord naming should work. I think that there is a two-step process: 1) Get the chord naming right (it's currently broken) 2) Make sure we have sufficient flexibility to accommodate anybody's desired method of displaying chords (I think this is pretty close right now, although it may need some tweaking). Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/29/09 1:56 AM, Marc Hohl m...@hohlart.de wrote: David Stocker schrieb: If I may chime in... This may just be a matter of editorial taste, but would it be possible to make it so the 'X' on in the Tab staff is not the musical glyph from Feta, but rather the character 'capital X' from the same font set being used for tab numbers? For example, instead of #'glyph-name #2cross, use whatever command would call the capital X from whichever font tab numbers are set to? I believe that this looks better on the page than mixing music glyphs and text glyphs in the tab staff, particularly where tab numbers and muted strings are part of the same chord. Hm, in my opinion, this looks not very convincing. I defined #(define (xx-tab-format str context event) (make-whiteout-markup (make-vcenter-markup (markup X so the X matches the font and font-size of the numbers. I have attached an example. Have you tried a sans-serif font for both the numbers and the X? Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/29/09 9:20 AM, Marc Hohl m...@hohlart.de wrote:
Carl D. Sorensen schrieb:
On 5/29/09 2:05 AM, Marc Hohl m...@hohlart.de wrote:
Carl D. Sorensen schrieb:
[...]
There is some drawback/difference: the crosses are drawn without
whiteout, so they look different. Is there a way to change this?
Yes. Change the stencil so that it is a composite stencil.
But how can I find out whether the tweak is called within a normal or a
tab staff? Within a normal staff, a whiteout should surely be avoided ...
I think you have to do this within the callback, where the context is
available. Once you have a context, you can see if it's a Voice context or
a TabVoice context. I'm sure Neil can help with this better than I can.
But if you do a git grep for context, you'll see lots of examples of how to
get information about contexts
Marc, feel free to add this to tablature.ly if you want to.
How should we call this? It should be clear that
\deadNotes works as expected, and the new function is meant
to be used inside chord constructs only.
\chordNoteDeadNote sounds a bit strange ...
I would recommend \deadNote, since it only applies to the next note.
The matching case for \palmMute, namely
\chordNotePalmMute seems to be ok for me.
I haven't reviewed the code carefully, but I think that \palmMute should
apply only to the next note, and \palmMuteOn should change all notes to palm
mute notes, or \palmMuteNotes could apply to a whole music expression.
Yes, that's how it works now (you can use \palmMute { ... } to treat
several notes at once, or \palmMuteOn ... \palmMuteOff).
Or just simply use \chordDeadNote / \chordPalmMute ?
I don't like the \chord* notation because they aren't limited to use in
chords. They will work for any single note, won't they?
No, the tweaks will work only in chord constructs
as far as I know, so I should have a pair of functions
for each feature, i.e.
c4 d \palmMute e f
c \chordPalmMute e g 4
c4 d \deadNotes e f
c \chordDeadNotes e g 4
Oh, I wasn't expecting that the new function wouldn't work outside of chord
constructs.
How about using the same function both inside and outside of the chord
constructs, and just including a check to see if the argument is a
NoteEvent. If it is, use the \tweak method, and if it's not, use the
existing method?
I haven't tried this out, but I think it could be made to work, and if it
could, then it would greatly simplify things for the users.
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/28/09 1:21 AM, Marc Hohl m...@hohlart.de wrote:
Carl D. Sorensen schrieb:
[...]
I think it's better to have the duplication and the ability to switch
between \tabNumbersOnly and \tabFullNotation, than to avoid the duplication,
and have \tabFullNotation be a non-undoable setting.
As you can see, \tabFullNotation works only locally when included in a
score:
\version 2.13.0
\include tablature.ly
test = \relative c { c4 d e f g a b c }
\score { \new TabStaff { \clef tab \test } }
\score { \new TabStaff { \clef tab \tabFullNotation \test } }
\score { \new TabStaff { \clef tab \test } }
So according to Neil's proposals, I got rid of the \tabNumbersOnly for
sake of clarity.
OK, I guess. I still don't like having a command that is not undoable. I
can't think of a reasonable application where this would cause a problem,
but LilyPond users regularly try things that I don't consider reasonable.
I guess that we can deal with the problem later if it ever shows up.
I'll publish the patch to rietveld and obtain comments.
Thanks,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/28/09 7:22 AM, Julian jul...@casadesus.com.ar wrote:
But still not within the tablature staff
At the moment, I don't know how to manage this.
I found it,
% Dead Note
\tweak #'stencil #ly:note-head::print
\tweak #'glyph-name #2cross
\tweak #'style #'special
f'\1
% End of Dead Note
f\4
4
Dead note is applied only to f'\1 as we expect, and X is displayed on
both,
staff and tabStaff.
Now i don't have idea how to make it in a lilypond function :) to use
\chordNoteDead instead of add all tweaks lines...
however it don't matters, now we know that it is possible to show X in tab too
by notes instead of chord.
Here's one way to do it:
deadNote =
#(define-music-function (parser location note) (ly:music?)
(set! (ly:music-property note 'tweaks)
(acons 'stencil ly:note-head::print
(acons 'glyph-name 2cross
(acons 'style 'special (ly:music-property note 'tweaks)
note)
{
f\4 \deadNote f'\1
}
Marc, feel free to add this to tablature.ly if you want to.
HTH,
Carl
Thanks for your patience.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/28/09 6:28 PM, David Stocker dstoc...@thenotesetter.com wrote: If I may chime in... This may just be a matter of editorial taste, but would it be possible to make it so the 'X' on in the Tab staff is not the musical glyph from Feta, but rather the character 'capital X' from the same font set being used for tab numbers? For example, instead of #'glyph-name #2cross, use whatever command would call the capital X from whichever font tab numbers are set to? Getting an X from the number font is not hard. The only challenge would come in setting the cross notehead for the Staff context, and the number notehead for the TabStaff context. But this shouldn't be too hard to do, I think. Marc is certainly good enough at programming to make it happen now, I'm sure. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Tweaking end-of-line time signature?
On 5/26/09 4:03 PM, Trevor Bača trevorb...@gmail.com wrote:
Snip some good comments about this code
%%% BEGIN #3 PROPORTIONAL SPACING WITHOUT STRICT NOTE SPACING AND WITH EOL
ADJUSTMENT %%%
adjustEOLMeterBarlineExtraOffset = #(define-music-function (parser location)
()
#{
#(define (foo grob)
(if (= (ly:item-break-dir grob) 0)
(ly:grob-set-property! grob 'extra-offset (cons 2.8 0)) '() ))
#(define (bar grob)
(if (= (ly:item-break-dir grob) 0)
(ly:grob-set-property! grob 'extra-offset (cons 2.8 0)) '() ))
\once \override Score.TimeSignature #'after-line-breaking = #foo
\once \override Staff.BarLine #'after-line-breaking = #bar
#})
As a stylistic matter, I don't like this definition , because foo and bar
are redefined globally every time adjustEOLMeterBarlineExtraOffset is
called.
I prefer to have foo and bar defined locally:
adjustEOLMeterBarlineExtraOffset =
#(define-music-function (parser location) ()
(define (foo grob)
(if (= (ly:item-break-dir grob) 0)
(ly:grob-set-property! grob 'extra-offset (cons 2.8 0)) '() ))
(define (bar grob)
(if (= (ly:item-break-dir grob) 0)
(ly:grob-set-property! grob 'extra-offset (cons 2.8 0)) '() ))
#{
\once \override Score.TimeSignature #'after-line-breaking = $foo
\once \override Staff.BarLine #'after-line-breaking = $bar
#})
Note that in this implementation, we use $foo and $bar inside the #{ #}
construct to refer to a local scheme variable.
Furthermore, it seems to me that writing a function like this that has
embedded constants is less than desirable, because if some different offset
were desired, a new function would need to be written. I think it would be
better to have
adjustEOLMeterBarlineExtraOffset =
#(define-music-function (parser location offset) (pair?)
(define (foo grob)
(if (= (ly:item-break-dir grob) 0)
(ly:grob-set-property! grob 'extra-offset offset) '() ))
(define (bar grob)
(if (= (ly:item-break-dir grob) 0)
(ly:grob-set-property! grob 'extra-offset offset) '() ))
#{
\once \override Score.TimeSignature #'after-line-breaking = $foo
\once \override Staff.BarLine #'after-line-breaking = $bar
#})
and call it with
\adjustEOLMeterBarlineExtraOffset #'(2.8 . 0)
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/27/09 2:50 PM, Neil Puttock n.putt...@gmail.com wrote: 2009/5/23 Marc Hohl m...@hohlart.de: Neil Puttock schrieb: Since none of this works properly (I suspect it will require more than Scheme hacking to get everything working), I don't think it's suitable for inclusion. Hm, I guess you're right - but as a compromise, how about letting the \clearTabTieBreaks as a default, because it is working most of the time, and when someone needs a more sophisticated tab staff, he has to write a separate score for the tablature? I would propose to rename it as #(define (tie::handle-tied-fret-numbers grob) (let* ((tied-fret-nr (ly:spanner-bound grob RIGHT))) (ly:grob-set-property! tied-fret-nr 'transparent #t))) make it default by \override Tie #'after-line-breaking = #tie::handle-tied-fret-numbers and use this as a kind of starting point for future improvements? Oh go on then. As long as you promise to leave out \markTabTieBreaks. :) I'm concerned about the amount of duplication here; this basically repeats all the code in \tabNumbersOnly, which is really something we should try to avoid in included files. But how to avoid this? One possibility would be to just get rid of the \tabNumbersOnly, because I don't think that tablatures with and without stems will ever be mixed together in a file, and when someone wants to do so, he can \override everything manually. I think that's the only option available, since there's no way of inserting identifiers into a context definition. I think it's better to have the duplication and the ability to switch between \tabNumbersOnly and \tabFullNotation, than to avoid the duplication, and have \tabFullNotation be a non-undoable setting. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Confused about asterisk notation
On 5/26/09 7:33 AM, David Bobroff bobr...@centrum.is wrote:
Brandon Olivares wrote:
Hi,
One of the tracks starts with this:
s16*259 a' b 16 e' d 16 a, b 16 s16 a b 16 e' d 16
The * is a multiplication sign. s16*259 means skip (i.e. invisible
rest) a 16th note 259 times.
I'd actually say it a bit different.
s16*259 means create an invisible 16th note rest, with a duration of 259
16th notes.
To my way of thinking, to skip a 16th note 259 times you'd do
\repeat unfold 259 {s16}
It probably doesn't make any difference for a skip, since it produces not
output. But if you replace s with r, the first construct will produce
one 16th rest, and and second will produce 259 of them.
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/25/09 12:13 PM, Julian jul...@casadesus.com.ar wrote:
Hello Marc,
Well at first, english is no my native lang, so sorry for don't speak it well.
I'm the admin of tuxguitar (a tablature editor) project and now i'm trying to
implement some of these features to the lilypond exporter plugin.
But i'm having some problems, when i try to apply them on only 1 note of a
beat
that have more notes.
I'll try to explain them with some examples:
* Dead Notes
I was able to build examples like:
c4 \deadNotes{ c, c4 } c4 c4
But if i try to set the dead to only 1 note of the beat:
c4 c, \deadNotes{ c } 4 c4 c4
lilypond throw me:
---
test.ly:324:20: error: syntax error, unexpected '{', expecting DRUM_PITCH or
MUSIC_FUNCTION or NOTENAME_PITCH
c4 c, \deadNotes
{ c } 4 c4 c4
test.ly:324:26: error: syntax error, unexpected
c4 c, \deadNotes{ c }
4 c4 c4
test.ly:330:3: error: errors found, ignoring music expression
---
So, am i doing something wrong with my sintax, or it is just a non supported
feature ?
( Same thing is happening with palmMute )
I think you can make this work with parallel music, instead of chords.
c, \deadNotes{ c ]
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Petrucci-like spacing?
On 5/25/09 10:57 AM, Henning Plumeyer h.plume...@web.de wrote: Am 25.05.2009, 02:13 Uhr, schrieb Carl D. Sorensen c_soren...@byu.edu: There are some issues though - not with Laura's example where no bar lines are needed. But when you want bar lines the bars are too full. You can manually add bars, if you'd like. Use the \bar | command every place you would like a bar. But there should probably be a better way to do it. What are you trying to achieve? Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Line lengths in NR [was Petrucci-like spacing?]
On 5/25/09 4:43 PM, Patrick McCarty pnor...@gmail.com wrote: On Mon, May 25, 2009 at 03:26:42PM -0700, Patrick McCarty wrote: On Mon, May 25, 2009 at 2:49 PM, Trevor Daniels t.dani...@treda.co.uk wrote: It looks like a whole note but has the duration of a quarter note, when LilyPond determines the spacing. If you don't want to add *1/4 for every single note, there is a command \scaleDurations to apply this kind of scaling for a whole section of music. All this is well described in Subsection Scaling durations in 1.2.1 Writing Rhythms in the Notation Reference. The lines in the html version of this section of the Notation Reference are significantly longer than any other, so long I have to scroll horizontally to read them. Does anyone else see this, or is it some subtle problem with IE? IIRC, if the line lengths for any pre section are too wide, IE recalculates the width of the div to accomodate the longest line on the page. Other browsers don't behave this way (as far as I remember). I suspect the snippet Non-default tuplet numbers in the Tuplets section is the culprit. If the values of #'text are moved to separate lines, that should solve the problem. And here is a patch. I tried to apply your patch, but I got the following: sorensen2:lilypond-working Carl$ git am 0001-Docs-Shorten-line-lengths-for-a-snippet.patch error: cannot read mbox 0001-Docs-Shorten-line-lengths-for-a-snippet.patch error: cannot split patches from 0001-Docs-Shorten-line-lengths-for-a-snippet.patch Then I checked out the file 0001-Docs-Shorten-line-lengths-for-a-snippet.patch It was zero length. Then I tried saving your email [PATCH] Docs: Shorten line lengths for a snippet to a file test.patch. When I did that, it had MacOS line endings (I'm using Entourage on the Mac for my email client) So I copied the text, and cat it to a file. cat test2.patch Now I have unix line endings, so I tried to apply. Carl$ git am test2.patch Patch does not have a valid e-mail address. However the files are modified, so I can commit them and push, but then it will be my commit, not Patrick's. So what am I doing wrong, or how should I do it different? Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Petrucci-like spacing?
On 5/24/09 8:56 AM, Laura Conrad lcon...@laymusic.org wrote:
I think so. There's a lot of stuff where modern transcribers typically
halve or even quarter the note values, and I'd prefer not to but it's
problematic with the normal lilypond spacing. (One reason it probably
became common is that the same is true of other printing based on 19th
century engraving practices.)
Whether it makes my website as beautiful as I'm hoping remains to be
seen, but I'll let you know.
You can see the spacing with Michael's layout on my blog entry for
today: http://laymusic.org/wordpress/?p=974
Laura,
Here's my attempt to get the spacing you're looking for. I've done it
manually, but if you like it, I think that I can write a music function
\petrucciSpacing{} that will generate it automatically.
What I've done is to multiply each note by a value necessary to make its
final duration equal a 1/4 note.
\relative c'' {
\key f \major g1*1/4 bes1*1/4 a1*1/4 g1*1/4 d'1.*1/6 c4 bes4 c1*1/4
}
Does this seem at all promising?
Thanks,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly - please test and comment
On 5/23/09 1:09 AM, Marc Hohl m...@hohlart.de wrote: Neil Puttock schrieb: 2009/5/22 Marc Hohl m...@hohlart.de: % for ties in tablature, fret numbers that are tied to should be invisible % or -after a line break - put in parentheses. Since this is not (easily?) % possible in lilypond, we offer three commands: #(define (tie::tab-mark-tied-fret-numbers grob) (let* ((original (ly:grob-original grob)) (tied-fret-nr (ly:spanner-bound grob RIGHT)) (siblings (if (ly:grob? original) (ly:spanner-broken-into original) '() ))) (if (and (= (length siblings) 2) (eq? (car (last-pair siblings)) grob)) ;; tie is split - change fret number color to red and print a message (begin (display \nSplit tie appears in tablature.) (display \nAffected fret number is marked red.\n) (ly:grob-set-property! tied-fret-nr 'color red)) ;; tie is not split - make fret number invisible Since none of this works properly (I suspect it will require more than Scheme hacking to get everything working), I don't think it's suitable for inclusion. Hm, I guess you're right - but as a compromise, how about letting the \clearTabTieBreaks as a default, because it is working most of the time, and when someone needs a more sophisticated tab staff, he has to write a separate score for the tablature? I would propose to rename it as #(define (tie::handle-tied-fret-numbers grob) (let* ((tied-fret-nr (ly:spanner-bound grob RIGHT))) (ly:grob-set-property! tied-fret-nr 'transparent #t))) make it default by \override Tie #'after-line-breaking = #tie::handle-tied-fret-numbers and use this as a kind of starting point for future improvements? Marc, Have you explored the possibility of calling parentheses-item::print on your tied fret number? I don't know if it will work, but it appears it may be possible. It may need to be defined public in order to call it. It's found in scm/output-lib.scm. I haven't tried it, but it looks to me like it takes a grob and adds parentheses around it. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \partial at start, but want whole bar at end
On 5/22/09 7:27 AM, Paul Hodges p...@cassland.org wrote: Hi all, I have looked around, but I can't find anything about this in the pdf documentation or snippets (v2.12.2): At the start of my piece, I have \partial for an upbeat. However, I wish to have a full bar (a semibreve in 2/2) at the end of the piece - following my source. However, Lilypond is insisting on having a final bar of three beats to match the upbeat at the start - which is blank, because I have no more notes. How can I get rid of this, pretty please? Just put \bar |. at the end of your last full measure. See Notation Reference 1.2.5. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Should sample code in NR build correctly?
On 5/22/09 4:25 PM, Nick Payne nick.pa...@internode.on.net wrote:
-Original Message-
From: Patrick McCarty [mailto:pnor...@gmail.com]
Sent: Saturday, 23 May 2009 8:15 AM
To: Nick Payne
Cc: lilypond-user@gnu.org
Subject: Re: Should sample code in NR build correctly?
On Sat, May 23, 2009 at 07:54:54AM +1000, Nick Payne wrote:
For example, on p.98 of the PDF version of the 2.12.2 NR the
following
example appears about half way down the page:
\repeat volta 2 { c4 d e f }
c2 d
\repeat volta 2 { d4 e f g }
If you try to build this using 2.12.2 on Windows you get
error: syntax error, unexpected NOTENAME_PITCH
c2 d
and the output is two separate staves rather than the single staff
shown
with the example. The whole thing has to be surrounded by \relative
c'' { }
to get the desired output.
The reason I ask is that I remember a post from someone a while ago
saying
that the code as shown in the manuals had been used to produce the
output.
If you click on the image of the musical example, and copy/paste the
appropriate code, it should compile.
That suggestion only works with the HTML documentation, not the PDF
documentation. I almost always use the PDF documentation, as I can build an
easily searchable index across all the different manuals.
Nearly all the examples are in relative mode, meaning they have a
\relative c' {}
(or some other octave)
around them. It was a conscious choice to do so. This convention is
explained in Learning Manual 2.1.4 How to read the manual.
How should it be more prominent?
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to achieve chord stop with ¬
On 5/21/09 1:08 AM, Stjepan Brbot stjepan.br...@zg.t-com.hr wrote:
M Watts wrote:
There are at least 2 versions in UTF-8; a normal one U+00AC, and a
full-width one U+FFE2.
To use these within lilypond, do \markup { \char ##x00AC } or \markup {
\char ##xFFE2 }.
Or, if your file is saved with UTF-8 encoding, you can paste the
character straight into it.
Thanks Marc, but it is not problem with character code. One can insert UTF-8
correct character ¬ like I did in this message using Character Map tool. The
issue is with position of this character inside chords line and how to
insert it easily. There is similar thread about N.C. on this forum. How to
easily insert N.C. (No Chord). The same story is here.
Stjepan,
First, you should know that this has been fixed in the git sources and will
be available in the next development release.
You can read the documentation about it here:
http://kainhofer.com/~lilypond/Documentation/user/lilypond/Displaying-chord
s.html#Displaying-chords
For clarity, you should be talking about a ChordNames context, rather than a
chords line. Chords can be displayed in many contexts, including at least
TabStaff, Staff, FretBoards, and ChordNames. I mention this not to complain,
but to try to help you learn a little bit more about LilyPond. I remember
when I started with LilyPond, all of the LilyPond specific terms like
context were very confusing to me. Now they make sense.
Anyway, if you can wait for the next development release (which should
probably be available in less than two weeks), you will have this
functionality.
Regards,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Complex chords
On 5/21/09 12:41 AM, Stjepan Brbot stjepan.br...@zg.t-com.hr wrote: Tim McNamara wrote: You need to define exceptions to the way that LilyPond writes chords. One way is to use one of the alternative chord rendering methods that you can find in the snippet repository. You can put this into a .ly file and use the \include command to call it when the music file is rendered into a PDF. Thanks Tim. It seems that this is exactly what I need but... it does not work for me!? I don't know why. Have you shared your whole file? This message looks like there was something before the code you've included that is causing this error. And the error occurs on line 18 of the input file, but it's line 3 of the included material. If you'll share the whole file, I'm sure we can help you. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Complex chords
On 5/21/09 2:54 PM, Stjepan Brbot stjepan.br...@zg.t-com.hr wrote: But this should be the whole snippet code form snippets guide, look at: Yes, but in your file there are apparently 16 lines that come before the lines you showed in your email. The line that caused the error is line 2 in your email, and line 18 in your file. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to achieve chord stop with ¬
On 5/21/09 2:07 PM, Stjepan Brbot stjepan.br...@zg.t-com.hr wrote: Carl D. Sorensen wrote: Stjepan, First, you should know that this has been fixed in the git sources and will be available in the next development release. You can read the documentation about it here: http://kainhofer.com/~lilypond/Documentation/user/lilypond/Displaying-chord s.html#Displaying-chords For clarity, you should be talking about a ChordNames context, rather than a chords line. Chords can be displayed in many contexts, including at least TabStaff, Staff, FretBoards, and ChordNames. I mention this not to complain, but to try to help you learn a little bit more about LilyPond. I remember when I started with LilyPond, all of the LilyPond specific terms like context were very confusing to me. Now they make sense. Anyway, if you can wait for the next development release (which should probably be available in less than two weeks), you will have this functionality. Thanks Carl, I really appreciate your help and hints. I'm not in a hurry. I'll wait for the next development release. I just want to emphasize that ¬ should always go with \set chordChanges = ##t There's no sense to have multiple ¬ chars in a row. Even when the new development release comes out, the character you use will not be part of it. The release will have N.C. as the default markup, and you'll need to change the markup to your character, which should be relatively straightforward. As far as the \set chordChanges = ##t, that will be up to the user. Understanding of contexts are still a little bit strange for me. Also I'm not totally sure how the proper lilypond score code structure should look like. I'm not sure what this comment says you're unsure about. If contexts don't make sense to you, please try rereading section 3.3 of the Learning Manual. I generally understand more when I reread it after fighting with scores on my own for a bit. Also I must admit that I'd never seen a triangle as a representation for maj7 chord until I started to tackle with lilypond and it's strange for me that this triangle sign is in default chords naming system. Apparently this is common in Germany. We don't use it in the US either. BTW, is it possible to have the following chord naming system :-) \croatianChordsE/DCmH/HH#/H#B/B I imagine it is, but it will take some work. Would you like to try to implement it? I'd be happy to give you advice, if you want to try. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: missing glissando features (bugs?)
On 5/20/09 9:20 AM, Graham Percival gra...@percival-music.ca wrote: On Tue, May 19, 2009 at 11:04:30AM +0200, Mats Bengtsson wrote: I've played several orchestral pieces where the violin parts include glissandi ranging over several strings. Mahler Symphony no. 4 comes to my mind, for example. I'm still uncertain on exactly how to play it, though, but perhaps the idea is that every player does it somewhat differently and the collective effect is what the composer is looking for. Oh, come on! There's no theoretical maximum frequency of a violin string[1]. Just start on the G string and slide up. ;) [1] Assuming a perfectly elastic string, being excited by an infitesimally narrow bow, with perfectly-controlled bow speed, pressure, and position... Don't forget that the fingerboard also needs to reach all the way to the bridge! Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: missing glissando features (bugs?)
On 5/20/09 10:41 AM, Graham Percival gra...@percival-music.ca wrote: On Wed, May 20, 2009 at 10:19:47AM -0600, Carl D. Sorensen wrote: Nonsense. You can push down a string without a fingerboard... ok, granted this *really* makes the ideal string calculations questionable, since you're changing the tension by quite a bit. But it can certainly be done; I've done it many times on the cello. Actually, one book on cello technique book (I think it was something like how to play the cello without pain; I read it soon after the first time I had tendonitus) actually recommends this style of playing for *all* notes. The claim was that pushing was less natural than pulling, and so you should pull the string to the left (towards your arm) instead of pushing down (exerting force perpendicular to the arm/hand plane). So I guess if you are using this technique, the only thing that makes a harmonic is when your finger is in a harmonic position? I've always thought that pushing against the fingerboard created a fixed end to the string, while just touching the string created a node. Perhaps the pulling the string towards the arm technique creates enough force that it functions as the end of the string, in contrast to the relatively light harmonic touch? Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: relative mode occasionally gets forgotten?
On 5/18/09 6:04 PM, Jonathan Kulp jonlancek...@gmail.com wrote:
Carl,
I'm working on your suggestions and have come across a problem.
\relative c' { \chordmode { c \relative c'' { c }}
This last example won't compile. (It was missing the last curly brace
but I added it.) Here's the terminal output:
chordmode.ly:1:40: error: syntax error, unexpected TONICNAME_PITCH
\relative c' { \chordmode { c \relative
c'' { c }}}
Apparently, you can't use \relative c'' inside of chordmode. \relative
needs a note (I think, but am not sure, it's called a NOTENAME_PITCH, not a
chord, and in chordmode c is read as a tonic for a chord, not as a note
(hence, a TONICNAME_PITCH).
Interestingly enough, you can get the following to compile:
\relative c' { \chordmode { c \relative {c}}}
but the result is not at all what I expected, although I can explain it.
I think the knownissue was wrong, and what should be said is
Items inside a \chordmode block are always in absolute mode, even if the
\chordmode block is in a \relative block.
with an example of
{
\relative c'' {\chordmode {c1}}
\chordmode {c1}
}
And the \chordmode section should say
\relative cannot be used inside a \chordmode block.
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Special markups
On 5/18/09 4:09 PM, Neil Puttock n.putt...@gmail.com wrote: 2009/5/18 Mark Polesky markpole...@yahoo.com: Helge Kruse wrote: I want to add markups... circled T and the half-moon... How do I add such special markups? See the 2 attached files. Nice curve. :) Here's a slightly simplified version: #(define-markup-command (fingernail layout props) () (ly:make-stencil (list 'bezier-sandwich '(list 1.6 1.5 0.4 1.5 0 0 2 0 This list is unnecessary, since the list is quoted, I think. 0.4 0.75 1.6 0.75 2 0 0 0) 0.15) '(0 . 2) '(0 . 1.75))) Perhaps for maximum clarity, we should write this as: #(define-markup-command (fingernail layout props) () (ly:make-stencil (list 'bezier-sandwich (list 1.6 1.5 0.4 1.5 0 0 2 0 0.4 0.75 1.6 0.75 2 0 0 0) 0.15) (cons 0 2) (cons 0 1.75))) I think we just had a discussion where we decided that the '(A . B) syntax was more confusing than (cons A B) because the period could be overlooked. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: relative mode occasionally gets forgotten?
On 5/15/09 5:05 AM, Jonathan Kulp jonlancek...@gmail.com wrote:
Chip wrote:
Patrick McCarty wrote:
On Thu, May 14, 2009 at 8:05 PM, Chip c...@wiegand.org wrote:
I think this is the issue mentioned in the Known Issues for Chapter
1.1.2 Transpose in the Notation Reference. However, the two
sentences included there are very confusing and should be rewritten to
make the issue more clear.
-Patrick
Yes, I see what you mean. Not sure I understand it myself.
--
Chip
If someone who understands the issue can send me new wording for this
passage that makes it clearer, I will make a patch for the docs.
How about:
Music inside a \transpose or \chordmode block is absolute, unless a
\relative is included inside the the \transpose or \chordmode block. When
\relative blocks are nested, the innermost relative block applies.
I think that this information should be put in several places in the NR.
First, I think that the information above should be put into 1.1.1 Writing
Pitches as examples under Relative octave entry. There should be three
separate items/examples:
When relative blocks are nested, the innermost relative block applies.
\relative c' { d e f \relative c'' { d e f}}
Music inside a \chordmode block is absolute unless a \relative is included
in the block.
\relative c' { \chordmode { c \relative c'' { c }}
Music inside a \transpose block is absolute unless a \relative is included.
\relative c' { d e \transpose f g { d e \relative c' { d e }}}
Second, I think a warning (inside a box, not just a known issue) under
t1.1.2 Changing multiple pitches Transpose should say
Music inside a \transpose block is absolute unless a \relative is included
in the block.
with a see-also to \relative.
Similarly, a warning in 2.7.1. Chord mode should say
Music inside a \chordmode block is absolute unless a \relative is included
in the block.
with a see-also to \relative.
Note: I haven't tested any of these examples.
HTH,
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: relative mode occasionally gets forgotten?
On 5/15/09 8:43 AM, Mats Bengtsson mats.bengts...@ee.kth.se wrote: Carl D. Sorensen wrote: Music inside a \transpose or \chordmode block is absolute, unless a \relative is included inside the the \transpose or \chordmode block. When \relative blocks are nested, the innermost relative block applies. I don't understand why \chordmode (and \chords) changes back to absolute mode, when \notemode doesn't. Is it just since it's less common that the roots of the chords span several octaves, or is there any other good reason why LilyPond is implemented in this way? I have no idea why LilyPond is implemented in this way. \chords behaves the same as \chordmode because \chords is just equivalent to \new ChordNames \chordmode, which I am sure you already knew. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: relative mode occasionally gets forgotten?
On 5/15/09 3:06 PM, Anthony W. Youngman lilyp...@thewolery.demon.co.uk
wrote:
In message 200905151909580...@1654122929, David Pounder
pound...@lineone.net writes
I don't know if it's worth mentioning, but you can also run into
problems using \repeat inside a \relative block if an \unfoldRepeats is
used outside the block. For example in
Tune = \relative c' { \partial 4 d4 |
\repeat volta 2 { c4 d e g | }
}
the first c will be relative to the last g on the second play through
using \unfoldRepeats. Rewriting as
Tune = { \partial 4 d'4 |
\repeat volta 2 \relative c' { c4 d e g | }
}
resolves the problem. I try to make sure I keep \relatives at the
innermost block for this reason. Is this a case of programming style,
and should the docs cover it?
Han-Wen gave me a resetOctave function that deals with this. I don't
know if it's made its way into the docs, though.
I just use the octave check construct and ignore the warning.
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Quoting everything from another voice
On 5/15/09 4:13 PM, Reinhold Kainhofer reinh...@kainhofer.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The notation reference states in section 1.6.3 that \quoteDuring is typically used for two instruments that play the same notes during a passage of music. Unfortunately, quoteDuring quotes only notes, rests and ties, but not dynamics, slurs, other markup etc. Thus in its plain vanilla form it is not suitable for passages where one instrument playes colla parte with another, since all markings will be missing in the instrumental score... One snippet in that section shows how one can prevent rests from being quoted (using the quotedEventTypes list), but it does not mention how can can exactly duplicate from another instrument. What is the correct value for quotedEventTypes to really quote everything, including dynamics, markups, tempo changes, key/clef/time changes, etc.? Is there any pre-defined list of all available event types that can be used? As an example I'm attaching a file, where \bb quotes everything from \aa, but in the output only the notes appear, but no key/clef/time, tempo change, markup, dynamic markings, articulartions, etc. Given your expertise in LilyPond, I hesitate to chime in here, but Why do you need to quote instead of just putting everything in a variable and including it in both voices? Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: printing rest in ChordNames context
On 5/14/09 8:07 AM, Tim McNamara tim...@bitstream.net wrote: into the \chords feels clunky and intrusive to me. I'd prefer to minimize putting formatting code in the music content as much as possible. Being able to write something like nc1 (or r1) and have it interpreted by LilyPond as N.C. would be much more elegant and intuitive: This solution to the N.C. problem (use r to indicate N.C.) is currently being implemented for 2.13.1. It should be available in git by the end of the day, for those who can build their own binary. For those who cannot build their own binary, Marc's solution should work until 2.13.1 is released. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: printing rest in ChordNames context
On 5/14/09 9:03 AM, Gilles Sadowski gil...@harfang.homelinux.org wrote: Hi. This solution to the N.C. problem (use r to indicate N.C.) ^^^ Will R also work? Not right now. I will investigate to see if it is easily done. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Need help with this trill
On 5/14/09 3:24 PM, Holger Hellebro hol...@gmail.com wrote:
Hi
I'm a new Lilypond user and I'm really enjoying the program so far. However I
am having difficulties typesetting a certain trill. You can see in the
attached picture what I want to achieve. I run into two difficulties:
1. How to get the two minor notes (sort of like appoggiaturas) placed
correctly after the main note, at the end of the bar. \appoggiatura seems to
always put the minor notes before the actual notes.
I think \graceAfter is what you're looking for.
2. How to put the natural symbol above the trill symbol. I've tried
^\markup{\tiny \natural} both before and after the \trill, but the trill sign
ends up above the natural sign in either case.
I can't help on this one.
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Newbie Question -- verse and chorus
On 5/12/09 4:44 AM, Tim Rowe digi...@gmail.com wrote:
Now on to my next exercise -- working out how to print capo chords in
parentheses after the regular chord, so I get:
(capo 3) C (A) G7 (E7)
The nearest I can find is at
http://www.mail-archive.com/lilypond-user@gnu.org/msg24850.html, but
that does them on different rows and without parentheses.
To do this on double rows is not too hard. I made it easier by developing a
parenthesizeAll function.
(I haven't put in the instrument name or the instrument_name_engraver that
was in the archives, but I think you can do that).
parenthesizeAll =
#(define-music-function (parser loc myMusic) (ly:music?)
(music-map
(lambda (ev)
(if (or (memq 'note-event (ly:music-property ev 'types))
(memq 'rest-event (ly:music-property ev 'types)))
(set! (ly:music-property ev 'parenthesize) #t))
ev)
myMusic)
myMusic)
mychords = \chordmode {
c1 g1 c1
}
\new ChordNames {
\mychords
}
\new ChordNames {
\parenthesizeAll
\transpose c a {\mychords}
}
Doing the two side-by-side will be a bit harder, because we'll need to
figure out a scheme for the timing. My initial thought was to just cut the
duration in half and add a \parenthesize{\transpose {}}. But this would be
really ugly if the chords were full duration. For example, if each chord
were a whole note, then the capo chords would be off half a measure from the
regular chords. Further, that scheme would mess up the chordChanges
behavior.
So I think the best way to go is to just mess with the chordNames function.
If I recall correctly, in the last year or so somebody posted on the list a
transposition function for chord names. You might be able to make that work
and to create a new chord name creation function that would create the chord
name, transpose it, and then combine the two with the second one in
parentheses. This would require Scheme knowledge.
Anyway, I hope this has been helpful.
Carl
P.S. It's generally a good idea to start a new thread when you change the
topic; it helps in archive searches later.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Bass in Chord Name
On 5/12/09 10:35 AM, Stjepan Brbot stjepan.br...@zg.t-com.hr wrote:
Kieren MacMillan wrote:
Hi Stjepan,
I'd like to get the following chord D7/F#. How to define this F#
as bass in
chord? I can use d:7/fis but I get fis, not wanted F# as bass.
If you're using english.ly, you need to use fs (not fis).
Kieren.
I do not use english.ly. I use template in OOoLilypond (lilypond macro for
OpenOffice.org). However I still don't know how to achieve F# as bass in
chord.
--
This works for me:
myChords = \relative c' {
\chordmode {
d1:7/fis
}
}
\new ChordNames {\myChords}
producing the attached output (FsharpBass.png).
HTH,
Carl
FsharpBass.png
Description: FsharpBass.png
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: writing chords
On 5/12/09 12:41 PM, James E. Bailey derhindem...@googlemail.com wrote:
I will be the first one to admit that I don't work with chords frequently. I'm
also trying to understand them. I understand that I can enter c:7 and lilypond
will recognise that I want to display c7, and display it accordingly. Since I
wanted to make some changes to some of the defaults, I decided to make a
little list of all the chords, and what is typed in order to get lilypond to
display them. I've run into some chords that I don't know how to name
properly, so I thought I would ask for help. I would like I know what I need
to type in order to get these chords. Here is what I want, and what I've
tried:
James,
Have you read the section in the notation reference on chord notation
(2.7.1)?
The reason I ask is that most of your chord notations do not comply with the
stated syntax rules.
Also, you should check out appendix B2 of the Notation Reference; it has
lots of these.
I'll write the way I'd code the chords up right after to your notes.
\version 2.12.2
\paper { indent = #0 }
\layout {\context {\Score \remove Bar_number_engraver} }
\score {
\new ChordNames {
c e g bes d' f' a'
c:13.11 (in appendix B2)
\break
c e g bes des' f' as'
c:13-.9-.11 (assuming, of course that as is what I would normally call aes)
\break
c e g bes des' f' a'
c:13.9-.11
\break
c e g b d' f' a'
c:maj13.11 (also in appendix B2)
\break
c e g b d' fis'
c:maj11.11+
\break
c f g
c:sus4 (in appendix B2)
\break
c f g bes
c:sus4.7-
\break
c f g bes d'
c:sus4.7-.9 or
c:9.4^3
\break
c e g d'
c:5.9
\break
c es g f'
c:m5.11
HTH,
Cqrl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: writing chords
On 5/12/09 1:51 PM, Tim Rowe digi...@gmail.com wrote: I can get them all except for the last; when I try to remove the 9th (c:m11^7^9) lilypond gets stuck :-( If you read the notation reference carefully, you'll see that only the *first* pitch to be removed is preceded by ^. (6 examples in under Extended and Altered Chords). What would have worked is c:m11^7.9 I'm also puzzled that lilypond gives the name of one of them as just C7, even though the 3rd is clearly augmented. The automatic chord namer for LilyPond is not good on altered and extended chords. Hopefully I'll get to it this summer. In the meantime, you can fix it by adding your own chord name exceptions. It's a bit cumbersome for a workaround, but it takes care of everything except bass notes, I think. BTW, Tim, thanks for jumping in to offer help. Unfortunately, relatively few who ask for help end up offering it. We appreciate having you around. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: bad spacing
On 5/5/09 9:03 PM, Victor Eijkhout vic...@eijkhout.net wrote:
This looks really bad:
harpchords = \relative c' { \time 15/8
s2^C s2^G/B s2^Am s4. | s2^Cmaj7/B s2^Em/G s2^F s4. |
s2^G s2^F/A s2^G/B s4. | s2^Dm/A s2^Dm/F s2 s4. |
\repeat volta 2 {
s2^C s2^G/B s2^Am s4.^Am/G# | s2^Cmaj7/G s2^Em s2^F
s4.^Bb/F |
s2^G s2^F/A s2^G/B s4.^Fdim/G# | s2^Am s2^F s2 s4. |
} s2^C
}
\score {
\new Staff { \set Staff.instrumentName = Harp \harpchords }
}
Should it look better, or am I using the wrong mechanism?
Why not use a ChordNames context? As you have written this, the chords are
just text, not really music elements.
If I were writing this, I think I'd write it as:
harpchords = \relative c' \chordmode {
\time 15/8
c2 g/b a:m s4. |
c2:maj7/b e:m/g f s4. |
...
}
\score {
\new ChordNames \harpchords
\new Staff {
\set Staff.instrumentName = Harp
\harpchords
}
}
Of course, this will set the notes as well as the chord names, which you may
not want to have.
Thanks,
Carl
Victor.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Chord Names Tweak
Jonathan, On 5/2/09 2:23 PM, Jonathan Townes edmundtow...@gmail.com wrote: Hello all, Does anyone have suggestions for tweaking the position of accidental in chord names. For example, the flat sign in in the chord name Ab? I find in the default Lilypond setting the flat symbol is too big and too low on the base line. Thanks, Jonathan Unfortunately, this is not an easy tweak, because there is no property in the chord-name-interface that allows control of this (the chord-name functionality of LilyPond is in need of a major rewrite; I hope to get to it this summer, but we'll see). If I were going to try it, I'd alter scm/chord-name.scm. In that file, you'll find (define-public (alteration-text-accidental-markup alteration) (make-smaller-markup (make-raise-markup (if (= alteration FLAT) 0.3 0.6) (make-musicglyph-markup (assoc-get alteration standard-alteration-glyph-name-alist ) To change the positioning of the flat, you change 0.3 to a different number. To change the positioning of the sharp, you change 0.6 to a different number. In order to change the size of the flat (and not the sharp, too) you will need to do some rewrite on this procedure. In terms of making the change, you have two choices. One is to make the change in scm/chord-name.scm. The other is to redefine the function in your .ly file #define-public (alteration-text-accidental-markup alteration) (make-smaller-markup (make-raise-markup (if (= alteration FLAT) 0.3 0.6) (make-musicglyph-markup (assoc-get alteration standard-alteration-glyph-name-alist ) This definition will override the one in scm/chord-name.scm. Hope this helps, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: adding to the LSR
On 5/2/09 5:50 AM, Daniel Hulme s...@istic.org wrote: On Wed, Apr 29, 2009 at 09:54:09PM +0800, Graham Percival wrote: Is it worth defining our own function replaceOnly(\\octave, ...) which does re.sub(\\octave[?a-z,A-Z], ...) or whatever the regex was? \\octave\b would work fine. \b matches a word Boundary. I think that LilyPond word boundaries are different from Python word boundaries. For example, LilyPond identifiers cannot contain numbers or special characters. That's why only alphabetic characters were chosen for exclusion, IMO. Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: auto-beam in pickup-bars with grace note
Christian,
This kind of question is better asked on lilypond-user.
Thanks,
Carel
On 4/30/09 12:57 PM, grisu_76 christian.hum...@univie.ac.at wrote:
As for I get some helpful hints for solving the spacing-problem in
pickup-bars starting with a grace note, now I struggle with the
auto-beaming:
global = {
\time 6/8
\key es \major
\tempo Presto
\partial 8*3 \grace {s8}
\autoBeamOn % this doesn't work to get the
auto-beaming back
\set beatGrouping = #'(3 3) %without the two following the result is
the
same as without...
\set beatLength = #(ly:make-moment 3 8)
}
ViolineEins = \new Voice {\relative c'{
\set Staff.midiInstrument = #violin
\partial 8*3 \grace c''8 \p b8 (a) b-.
g-. g-. g-. \grace{as8} g f g
\bar |.
}}
music = {
\tag #'score \tag #' vn1 \new Staff { \global \ViolineEins }
}
Some ideas? regards, Christian
--
View this message in context:
http://www.nabble.com/auto-beam-in-pickup-bars-with-grace-note-tp23322316p2332
2316.html
Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com.
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
On 4/30/09 1:36 AM, Marc Hohl m...@hohlart.de wrote: [snip] I have reworked my tablature.ly according to all suggestions and improvements by Neil and Carl. The modern tab clef seems to be scaling properly, I played a bit with some values for staff-space, and it looks now as it should be (at least in my opinion). I have managed (with excessive help) to get the staff-space and the line-count from the staff-symbol property, so there is no more need for explicitly using the tuning as an argument for the clef functions. (And again, I have gained some more insight in scheme and lilypond, thank you both!) As Neil proposed, it should be possible to code \clef tab for the current calligraphic clef, and to write \clef moderntab for the sans serif-style clef for compatibility's sake. This issue is beyond my abilities, so I call desperately for help ;-) If we add entries in parser-clef.scm to supported-clefs and c0-pitch-alist (either directly or by consing the new entries within the tablature file) for the modern tab, (moderntab . (markup.moderntab 0 0)) (markup.moderntab . 0) I tried to cons these values, and I succeded (or at least it seemed to me) for the supported-clefs list, but not with the c0-pitch-alist (see attached files and lilypond's error messages). Is this list only locally defined, or am I missing something? You are correct. c0-pitch-alist is not public. So it's currently not possible to cons a value in with the tablature.ly file. Your choices at this point are to a) change the scm/parser-clef.scm file to (define-public c0-pitch-alist and keep the additions to the clef list in tablature.ly b) hardcode the changes to supported-clefs and c0-pitch-alist in scm/parser-clef.scm c) add a scheme function (define-public (add-new-clef clef-name) ) to scm/parser-clef.scm. This function would cons the new clef values onto both lists. And because the function is defined in scm/parser-clef.scm, it will have access to c0-pitch-alist. Then you would revise tablature.ly to call add-new-clef to take care of things. My recommendation is that you pursue option c. The disadvantage of pursuing option c is that it won't be available to others until a new release of LilyPond is issued. However, the existing tablature.ly file that you posted to the list works for 2.12, so that will meet the needs of those users. And you will have made the changes to scm/parser-clef.scm on your system, so you'll have it available for your use. And you can post a patch that those who are interested can use to make changes to their own version of scm/parser-clef.scm. All in all, I'd say go ahead with the new function in scm/parser-clef.scm and modify tablature.ly to work with the new function. In my opinion, as tablature.ly is meant to be included by the user, not by default, the changings in these lists should be done within tablature.ly, if this is possible. You can also think about splitting tablature.ly into tablature-init.ly which will be always be run, and tablature.ly which will only be run if the user includes it. That's the way predefined-fretboards works. we can override the Clef 'stencil to check 'glyph before calling the default print-function. If the string markup.moderntab is found, then it's simple to return a stencil for the new tab markup. How can I achieve this? Define a new Scheme function to be used as the Clef 'stencil property (define (newClefPrint grob) ) It should check for the 'glyph property of the grob, and if it's markup.moderntab, it will call the new tab markup function. Otherwise, it will call (ly:clef::print grob). Hope this helps, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
On 4/29/09 3:12 AM, Marc Hohl m...@hohlart.de wrote:
Neil Puttock schrieb:
2009/4/27 Carl D. Sorensen c_soren...@byu.edu:
Neil,
Thanks for your input. I think it's all really good.
On 4/26/09 1:49 PM, Neil Puttock n.putt...@gmail.com wrote:
2009/4/25 Marc Hohl m...@hohlart.de:
Marc, there are probably at least two ways to do this. The easiest one
would be to take each of these magic numbers and divide them by the default
staff-space setting, and then change to something like
(base-skip (cond ((= 4 num-strings) (* staff-space 1.03))
and so forth. (1.03 = 1.55/1.5) And you'd need to find the value of
staff-space in order to be able to do this multiplication.
Ok, as Neil has posted somewhere else in this thread, the formula works
only with a
fixed staff-space. But I don't know how to find the value of staff-space.
I think it could be done similar to the proposals for the line-count
(see below), but this is far beyond my possibilities - any help is highly
appreciated!
See below for my comment.
There are two issues that I can't address:
1) I wasn't able to figure out how to get stringTunings in a music function
or a markup function. How do we do that?
You don't need to know stringTunings, since it's possible to access
'line-count from any grob which is placed on a StaffSymbol:
(let* ((staff-symbol (ly:grob-object grob 'staff-symbol))
(line-count (ly:grob-property staff-symbol 'line-count)))
This is way beyond my knowledge of the internals. I simply added these lines
accordingly in my definition of customTabClef:
#(define-markup-command (customTabClef layout props tuning) (pair?)
(define (square x) (* x x))
(let* ((staff-symbol (ly:grob-object 'grob 'staff-symbol))
(num-strings (ly:grob-property staff-symbol 'line-count))
(font-size (- (* num-strings 1.5) 7))
(base-skip (square (+ (* num-strings 0.195) 0.4
(interpret-markup layout props
(markup #:vcenter #:bold
#:override #'(cons 'font-family 'sans)
#:fontsize font-size
#:override #'(cons 'baseline-skip base-skip)
#:left-align
#:center-column (T A B)
but this doesn't work. Lilypond complains with
Unbound variable: grob
How can I assign the right value to this symbolic variable?
This was meant to be applied along with Neil's earlier comment about
changing from using ly:text-interface::print for the 'stencil to using
grob-interpret-markup. I've included his comments below:
% Wrappers for the different clefs
% the argument is the string-tuning, which is automatically set.
sansSerifTabClef = #(define-music-function (parser location tuning) (pair?)
#{
\override TabStaff.Clef #'stencil = #ly:text-interface::print
Use grob-interpret-markup instead of ly:text-interface::print:
\override TabStaff.Clef #'stencil = $(lambda (grob)
(grob-interpret-markup grob (make-customTabClef-markup tuning)))
The docs are slightly lagging behind here, but
ly:text-interface::print should only be used with objects which
support text-interface.
When you define 'stencil to be a function of some object (lambda(grob) is a
function with one parameter), LilyPond will call that function with the
parameter of the grob that is supposed to be printed -- in this case, the
clef. So then, grob will exist and will have the capability of learning
about both 'line-count and 'staff-space.
If this doesn't point you in the right direction, please let me know.
Thanks again for doing this!
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: adding to the LSR
On 4/28/09 4:42 PM, Jonathan Kulp jonlancek...@gmail.com wrote: Carl D. Sorensen wrote: Thanks for the offer, Chip. I've just finished a preliminary run through all of the snippets. I downloaded the tarball of the entire repo and ran them through the convert-ly script, then did a looping script that ran lilypond on each updated snippet using 2.12.2 and saved the terminal output for each in a text file. Cool -- I didn't know you were up enough on scripting to do that kind of work! I think such a script should be added to scripts/auxiliar so that we have it to use the next time we want to do an update. (And you just demonstrated that you have two of Larry Wall's attributes of a good programmer: laziness and hubris. Good for you!) This was a very simple script. I learned a good bit of scripting with the help of Patrick Horgan a while back when I was writing my lily2image script. Here's the script for any interested folks (first I did convert-ly -e *.ly on the whole directory): #!/bin/bash #*# # Run Lilypond on a lot of files and save # # the terminal output in text files # #*# for LILYFILE in *.ly do STEM=$(basename $LILYFILE .ly) echo running $LILYFILE... lilypond --format=png $LILYFILE $STEM.txt rm $STEM.ps done --- I chose png format b/c the ristretto image viewer on xubuntu allows for very quick paging through all of the images in a directory, much quicker than going through a bunch of pdfs. After running the script on the directory with all the snippets in it, I run this command to find snippets that didn't compile: grep failed *.txt It reads the terminal output from all the files and brings back the ones that failed. Cool! I still think that you ought to put it all (including the grep part) into a single script and store it in the source tree. And it ought to be added to the CG so that we have it tracked for the next time we release a stable version (I assume it will happen quickly, once Graham gets home from Singapore -- although maybe going to Scotland doesn't qualify as home). The results were pretty good, really. About 95% of the snippets compiled and look the same as they did in 2.10. Two snippets didn't compile at all, but I've already taken care of one of them (adding-octaves-automatically) because I've had to fix that one on some of my own files before. The convert-ly script took the \octaves command as if it were an octave check instead of a user-defined macro. I've changed the \octaves command in the original LSR code to \makeOctaves, which will survive the convert-ly update intact. This probably also indicates a need to change the convert-ly rule for \octave. If it doesn't work for \octaves, it also wouldn't work for \octaveAdjustFunction, or some other user-defined variable that starts with \octave. This should be either fixed or added to the issue tracker to get fixed. Yes, I was thinking the same thing but I don't know how to change the convert-ly rules. It was easier for me just to change \octaves to \makeOctaves. Any Frog willing to take on this convert-ly rule fix? You have a file that you can use to see if you have fixed the rule. There are also some snippets that work but should be changed to reflect changes in 2.12. I know of two snippets that have to do with lead sheets (Chords, Fret Diagrams, melody, and lyrics) that should be changed to use \predefinedFretboards and a FretBoards context, instead of using \markup \fret-diagram. I'm not sure if there are others. There may be one related to auto-beaming. I'm not sure what a good process on this is, but I think at a minimum, we should look at NEWS for 2.12 and see if there are any NEWS items related to each of the snippets. That's why I estimated 15 minutes per snippet (I wasn't thinking of automation, which I should have). We should check each of the snippets and see if the snippet is made obsolete or should be changed to reflect new features added, not just check to see if the syntax is right. Yes, to do it properly we'll need to examine each one more carefully. My idea with this is simply to find out which snippets are broken in 2.12 and get them at least to compile, so that the LSR could be switched to 2.12 and then the snippets can be checked out more carefully after that. Is that a good strategy? No, it's a *great* strategy. Get the easy work done quickly, so there's nothing us keeping from moving the LSR, then do the careful work at our leisure. Thanks for taking the lead on this. Chip, are you still willing to do some work reviewing the converted snippets? Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
On 4/27/09 3:38 AM, Marc Hohl m...@hohlart.de wrote:
Neil Puttock schrieb:
2009/4/25 Marc Hohl m...@hohlart.de:
(font-size (- (* num-strings 1.5) 7))
(base-skip (cond ((= 4 num-strings) 1.55)
((= 5 num-strings) 1.84)
((= 6 num-strings) 2.00)
((= 7 num-strings) 2.08)))
Can you rework these so they're not hard-coded?
That's a bigger problem: first, I used a definition as shown in the LSR
and played a bit with the
values for base-skip, font-size and raise. Here is my first attempt:
tabClefIV = \markup {
\raise #0.7 {
\override #'(font-family . sans)
\bold\fontsize #-1.0
\override #'(baseline-skip . 1.44)
\column { T A B }
}
}
I found out that the base-line for 4 ... 7 strings follows a quadratic
equation:
base-skip = ( 0.2 * num-strings + 0.4 )**2
but inserting this into the definition of customTabClef didn't work, and
neither
Carl nor I could nail down the problem, so finally, I hard-coded the values.
If you can help me with that, it would be great.
Marc, did you get the email from Robin Bannister? He found the problem we
were having with customTabClef. I had you put the baseline-skip override as
a cons to the property list, instead of using it as an :override function,
and the :fontsize reset the baseline-skip. That's why things weren't
working right. I think the code below works with your original quadratic:
#(define-markup-command (customTabClef layout props) ()
(define (square x) (* x x))
(let* ((num-strings (length (chain-assoc-get 'stringTunings props '(
(raise-value (- (* num-strings 0.4) 0.9))
(base-skip (square (+ (* num-strings 0.2) 0.4)))
(font-size (- (* num-strings 1.5) 7)))
(interpret-markup layout props
(markup #:raise raise-value #:bold
#:override #'(font-family . sans)
#:fontsize font-size
#:override #(cons 'baseline-skip base-skip)
#:column (T A B)
Imagine a user doesn't like the default staff-space setting for
TabStaff (1.5). If they change it, none of these empirical values
will work properly.
Here Neil points out the thing he's most concerned about. It's not a
concern about the magic numbers per se, it's that they don't change with
staff-spacing. In my earlier email (let me know if you didn't get it), I
asked for his help with that problem.
On a general note, I'd prefer to keep the string tunings separate from
setting the clef. To set the traditional tab clef, we have the
command \clef tab, so it would be nice to be able to set the modern
style using e.g. \clef moderntab without having to use a new function.
Yes, that would be better, but I didn't manage to get the information about
the number of strings internally, so I used the tuning as an argument.
Then, to avoid setting it twice, I wrote the wrappers.
On the other hand, I would have to set the tuning before setting \clef
moderntab,
but this could be easily mentioned in the docs.
As said above, any help for the base-skip problem and finding a way to
get the number of strings
without explicitly using the tuning as an argument are appreciated.
Thank you!
Marc
Thank you, too, Marc!
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
On 4/27/09 12:47 PM, Marc Hohl m...@hohlart.de wrote: Carl D. Sorensen schrieb: On 4/27/09 3:38 AM, Marc Hohl m...@hohlart.de wrote: No, I didn't get this mail. I played around with your suggestions and the improvements given by Neil and have now: #(define-markup-command (customTabClef layout props tuning) (pair?) (define (square x) (* x x)) (let* ((num-strings (min (max (length tuning) 4) 7)) (font-size (- (* num-strings 1.5) 7)) (base-skip (square (+ (* num-strings 0.2) 0.4 (interpret-markup layout props (markup #:vcenter #:bold ;;#:override #'(font-family . sans) #:fontsize font-size #:override #'(cons 'baseline-skip base-skip) I thought that there should be no ' before (cons 'baseline-skip base-skip). But apparently it works, so perhaps it's evaluated during the markup interpretation. The ' is a quote that prevents evaluation. In this case, we want to evaluate the expression, because we want to replace the symbol base-skip with its value, which was assigned above. But this apparently works with the macro expansion. #:center-column (T A B) The raise-value calculation has gone, because I use #:vcenter, but I had to comment out the font-family line, because I got an error saying unbound variable: font-family if it is in the source. What's going wrong here? Try #'(cons 'font-family 'sans), and see if that will work. It may be that the way things are substituted by the macro expansion is causing it to work differently than I would expect with straight Scheme. Imagine a user doesn't like the default staff-space setting for TabStaff (1.5). If they change it, none of these empirical values will work properly. Here Neil points out the thing he's most concerned about. It's not a concern about the magic numbers per se, it's that they don't change with staff-spacing. In my earlier email (let me know if you didn't get it), I asked for his help with that problem. With the definition above, I inserted #(set-global-staff-size num) and tried values from 10 to 100, and it worked as expected. So the quadratic equation seems to be the right way. OK, so the baseline skip is apparently sized in terms of staff spaces, which means your equations are right. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tablature.ly
Neil,
Thanks for your input. I think it's all really good.
On 4/26/09 1:49 PM, Neil Puttock n.putt...@gmail.com wrote:
2009/4/25 Marc Hohl m...@hohlart.de:
Hello tablature users*,
Like Carl, I'm not a tablature user, so I can only comment on matters of
coding.
Some suggestions and thoughts follow below:
SNIP
(font-size (- (* num-strings 1.5) 7))
(base-skip (cond ((= 4 num-strings) 1.55)
((= 5 num-strings) 1.84)
((= 6 num-strings) 2.00)
((= 7 num-strings) 2.08)))
Can you rework these so they're not hard-coded?
Imagine a user doesn't like the default staff-space setting for
TabStaff (1.5). If they change it, none of these empirical values
will work properly.
Marc, there are probably at least two ways to do this. The easiest one
would be to take each of these magic numbers and divide them by the default
staff-space setting, and then change to something like
(base-skip (cond ((= 4 num-strings) (* staff-space 1.03))
and so forth. (1.03 = 1.55/1.5) And you'd need to find the value of
staff-space in order to be able to do this multiplication.
The second way would be to try to define fundamental relationships for
base-skip, but I'm not sure exactly how you'd do that, so I'm not
recommending it right now.
SNIP
calligraphicTabClef = #(define-music-function (parser location tuning)
(pair?)
#{
\revert TabStaff.Clef #'stencil
\set TabStaff.stringTunings = $tuning
#})
On a general note, I'd prefer to keep the string tunings separate from
setting the clef. To set the traditional tab clef, we have the
command \clef tab, so it would be nice to be able to set the modern
style using e.g. \clef moderntab without having to use a new function.
I'd also like to do that. But I don't know how to help Marc do it. Neil,
if you can help him figure it out, I'd appreciate it.
There are two issues that I can't address:
1) I wasn't able to figure out how to get stringTunings in a music function
or a markup function. How do we do that?
2) I'm not sure how to use a markup, instead of a glyph, as a clef without
redefining the 'stencil property, and I don't know how to redefine the
'stencil property by means of a \clef cleftype command. If you can show us
how to do that, it would be really helpful.
Thanks for your help and insight,
Carl
Marc,
Can you revise your code according to Neil's recommendations and make me a
new patch?
Thanks,
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 9:37 AM, Neil Puttock n.putt...@gmail.com wrote: 2009/4/23 Jonathan Kulp jonlancek...@gmail.com: 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
Re: date in footer?
On 4/25/09 1:31 PM, Neil Puttock n.putt...@gmail.com 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: New fonts for chords
On 4/25/09 12:52 PM, Pekka Siponen pekka.sipo...@bastu.net 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 m...@hohlart.de wrote: Hello tablature users*, SNIP 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 2:36 PM, Pekka Siponen pekka.sipo...@bastu.net 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: TextSpanner at Score level?
On 4/25/09 3:38 PM, -Eluze elu...@gmail.com 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
On 4/25/09 5:38 PM, Nick Payne nick.pa...@internode.on.net 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
Re: Changing font of Table of Contents
On 4/25/09 5:38 PM, Nick Payne nick.pa...@internode.on.net 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: Removing empty (drum) staff in a score, instrument name placement
On 4/24/09 1:51 PM, Toine Schreurs a.m.m.schre...@chem.uu.nl wrote: 1. You would need (the nonexisting) RemoveEmptyDrumStaffContext. But inspection of engraver-init.ly points to the solution: SNIP Toine, Thanks for a great, clear answer. You're making a great contribution to LilyPond by doing this. You not only help users, but you free up time for developers! Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music expression explanation
On 4/24/09 4:22 PM, Peter Chubb lily.u...@chubb.wattle.id.au wrote: I'd really appreciate an appendix or something that gives Lily syntax as BNF, or as a syntax diagram. The syntax is very complex, and I've been caught out a number of times by things not being as I expected them to be from the NR --- not that the NR was wrong, but that the way elements are combined wasn't explicit. This has been asked for in the past. You'll find a thread on devel about it here: http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/7431 My best result is here: http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/7431/focus=7443 HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
On 4/23/09 9:31 AM, Graham Percival gra...@percival-music.ca wrote: On Thu, Apr 23, 2009 at 09:56:05AM -0500, Jonathan Kulp wrote: Graham Percival wrote: I will admit that outputting the version number appears in the Text list, rather than the titles. In fact, both snippets should appear in both Text and Titles, but currently they're only in one list. Somebody should fix this. Ok I found the snippets in the database, clicked modify, added the missing Text and Title tags in the respective snippets and clicked save for each one. I assume that since I was apparently allowed to modify these snippets that I am now an editor? I guess. I just checked, and it looks like it was all done correctly. That's...pretty easy :). No kidding. Now do you see why I wanted somebody who hasn't fought with git or learned the doc policy to do it? Of course, the job is much longer. Every snippet needs to be examined. The person doing this can exercise a fair amount of judgment over how many tags to have, how relevant something should be to warrent getting a tag, etc. Ideally, they'd also make sure the snippets all conform to the doc policies... easy-to-understand variable names (no \thrsddbx for three-sided box), etc. And we really (IMO) need to be doing it as part of moving to a 2.12 LSR. We should also be evaluating: A) Does it run in 2.12? B) Is it needed in 2.12 (i.e. has 2.12 introduced new features such that the snippet become irrelevant)? I'm estimating 20 hours to organize the current lot, plus 1 hour per month. With checking for vriable names, 2.12 validity, etc. I estimate about 15 minutes per snippet (although the time may go down as skill goes up). With 448 files in the LSR (at least according to Valentin's lsr tarball at http://lsr-update.lilynet.net) it's about 100 hours. Of course, if we drop to only the docs snippets, there will be less time than that. I think we need more than one person. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: date in footer?
On 4/23/09 12:04 PM, Jonathan Kulp jonlancek...@gmail.com wrote: Graham Percival wrote: On Thu, Apr 23, 2009 at 10:31:22AM -0600, Carl D. Sorensen wrote: And we really (IMO) need to be doing it as part of moving to a 2.12 LSR. We should also be evaluating: A) Does it run in 2.12? B) Is it needed in 2.12 (i.e. has 2.12 introduced new features such that the snippet become irrelevant)? There aren't so many new features in 2.12. And only the doc-related snippets need to be evaluated. I notice there's a TODO in the Contrib Guide about making multiple versions of LP coexist on the same system. This is something I would need to do to test these snippets, since I'm always runnning the latest development version. I'm not sure how to make 2.12 available at the same time. Can someone point me in the right direction? If I get it working then maybe I could also update that part of the CG. I think all you have to do is to install 2.12 from the download page, and have a different working directory for the 2.13 source. And then you can follow the instructions in the file HACKING that exists in the top LilyPond source directory. Of course, those instructions won't work on Windows, but IIRC you have Linux anyway. I could start checking snippets a few at a time at night after the kids are in bed once I get 2.12 running. But you can't update any snippets to 2.12 and put them on LSR until LSR is moved to 2.12. But if you just keep the updated, checked, and approved snippets in a directory, we can upload the changes later, I think. BTW, Graham, in the 2.12 docs, CG 1.1.2 Main source code it still says FIXME test this for the git commands. The 2.13 version of same doesn't say this. The commands work perfectly (I used them yesterday after a reinstall of my OS). I could go in and delete the FIXME stuff, but I'm not sure where to get at the 2.12 source files. I'm pretty sure my whole git repo is 2.13. How do I make a change to the 2.12 docs? For the time being, you don't make changes to the 2.12 docs. 2.12 is the last stable release; contributors should be working on 2.13 right now. Similarly, we are not backporting bug-fixes to 2.12. Besides, none of those changes would be available until we have a new release, and new releases appear to be problematic right now. If another release of 2.12 is planned (e.g. because we backport some bugfixes from 2.13), then we could update the docs. But right now, I don't see that happening. I think we have already seen the last 2.12 release. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Playing a file in midi
On 4/22/09 5:09 AM, Shayne Picard shay...@gmail.com wrote: How can I play a file in midi? See Notation Reference Section 3.5 in the LilyPond documentation. Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Vertical Spacing question
On 4/22/09 9:13 AM, Mischa Falkenburg because_producti...@myfairpoint.net wrote: Hello All, I'm using version 2.12.1, and my piece utilizes a GrandStaff with 6 Staffs. The .pdf file generated shows all the pages, except for the final page, with a big space between two GrandStaffs. I would like to modify the spacing so that three GS's would show on each page. Is this possible? Perhaps, if there's enough space on the page. Please review Section 4.6.2 of the Notation Reference. I think you want to set system-count. HTH, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Moving dynamics to a fixed vertical position (inside the staff)
On 4/20/09 3:11 PM, Reinhold Kainhofer reinh...@kainhofer.com wrote: Is there any way to position a dynamic sign at an explicit staff-relative (not note-relative) vertical position? Here's a hack that uses staff-padding together with a change in the Y-extent that makes it work. However, if you try to put it more than 2 staff lines down, then it will throw it well below the staff. I don't know if this will work for you or not, but at least it's a start. Carl dyn2.ly Description: dyn2.ly dyn2.pdf Description: dyn2.pdf ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Moving dynamics to a fixed vertical position (inside the staff)
On 4/20/09 4:32 PM, Neil Puttock n.putt...@gmail.com wrote:
2009/4/20 Reinhold Kainhofer reinh...@kainhofer.com:
Is there any way to position a dynamic sign at an explicit staff-relative
(not
note-relative) vertical position?
Since the dynamic's X-parent is the notehead, you can normalize its
position by retrieving the notehead's Y-offset:
dynamicsAllInside = #(define-music-function (parser location offsetX shiftY)
(number? number?)
#{
\once \override DynamicText #'X-offset = $offsetX
% \once \override DynamicLineSpanner #'Y-offset = #0
\once \override DynamicText #'Y-extent = #(cons 1 -1)
\once \override DynamicLineSpanner #'Y-extent = #(cons 1 -1)
\once \override DynamicText #'Y-offset =
$(lambda (grob)
(let* ((head (ly:grob-parent grob X))
(offset (ly:grob-property head 'Y-offset)))
(- (/ shiftY 2) offset 0.75)))
#})
Thanks, Neil. You just saved me the time of figuring out how to do this.
After I sent my hack, I realized that the trick was to get the parent offset
and then do a shift from that. But then I found that you had already
written it!
Carl
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
