Re: working on the web front page
On Thu, Jul 30, 2009 at 10:09:17PM -0700, Patrick McCarty wrote: On Thu, Jul 30, 2009 at 04:38:25PM -0700, Graham Percival wrote: Remember that we can set background images in CSS. I recommend keeping all such images in css/, and modifying the css file rather than the raw texinfo. Typically websites inline the branded images so that users with stylesheets turned off or users with a non-graphical browser will know that the image is there. You have a point there. Also, whenever we produce info and pdf, we'd want the logo in there. That part of the patch has been reverted. I guess my basic complaint is that the logo doesn't do anything for me -- a lily pad has nothing to do with notation. I'd be happier if it had something musical in it. I've just pushed a change to move the What is lilypond box to the right. It also has an ugly black background to remind everybody that we can do things like that, although it might not terrible if it were light gray rather than black. I don't see a black background. I see a cropped treble clef though. Err, that's what I meant. An ugly cropped black background treble clef. Also, I must have missed the reason why you moved the box. I think it was much more noticeable in its previous location. Really? I thought it merged with the news too easily. I just tried shading the background (like the @warning) and now I think it's better. Are are any volunteers to continue work on the CSS? I truly hope so, since neither of us are web developers. Furthering my challenge to produce alternate CSS: we now have a default.css and an alt1.css. The alt1.css is what I produced (moving more stuff to the right). Check out the two styles, send in your own, etc. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Han-Wen Nienhuys wrote:
Braces are overloaded in LilyPond. In some cases they define scopes
(like \paper and \header), and in other cases, they just group
syntactic constructs (\book, \score, sequential musics).
The solution you propose sounds hairy to me. I think you probably
are looking for a real scoping construct inside music expressions. I
don't think this is a very neat idea, because these scoping constructs
will necessarily not nest correctly wrt { } and .
Well, not *inside* music expressions... Werner's idea was to have the
\score block define a scope, in which I presume every slur left-
parenthesis and every simultaneous-expression double left-angle-bracket
would have a matching close. So, a score block would be a good candidate
for allowing the final } to reset all parser-variables (that were
defined within that score block) to the value stored outside the block.
I don't imagine that this is easy (or even practical), but it's an
interesting proposition, so I might as well ask around to see if it's
feasible.
The confusion
arises from your use of #(set! .. ), ie. direct interaction with the
scheme interpreter. It is assumed that people who do this know what
they are doing. Note that in 'native' lilypond syntax, this problem
is nonexistent, since assignments may only occur at toplevel.
I don't think that's true. The use of set! seems irrelevant. The
problem of unintended value-inheritance still occurs when using
define instead of set!. The code below is almost verbatim from the
docs. This is the gotcha that I'm trying to fix. The consequences of
this can be aggravating in complex, multi-score projects:
*
\version 2.13.3
\score {
\relative {
{ c1 \afterGrace d1 { c16[ d] } c1 }
#(define afterGraceFraction (cons 15 16))
{ c1 \afterGrace d1 { c16[ d] } c1 }
}
}
\score {
\relative {
%% value of afterGraceFraction inherited from previous score.
{ c1 \afterGrace d1 { c16[ d] } c1 }
#(define afterGraceFraction (cons 15 16))
{ c1 \afterGrace d1 { c16[ d] } c1 }
}
}
*
Now maybe the only viable solution is to place the burden on the user
to reset all parser variables manually after they're done with them
in a particular block. But I very much dislike that solution because
it multiplies the user's chances of making a mistake. And a lot of
times, features with unintended consequences are hard to track down.
Many, many things affect spacing, for example - so when I see spacing
that looks wrong in the middle of a huge project, how can I possibly
know where to look? And the realization that the cause of the problem
could be in another score entirely... I really think this needs to be
fixed.
Does this make more sense?
- Mark
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LilyPond concept glossary?
Patrick McCarty wrote: I like this idea. Having a list in an NR appendix would be just fine with me. However, it would be difficult to auto-generate a lot of this documentation, because not all of it is defined in LilyPond's internals: grob - LilyPond prob - LilyPond smob - Guile output-def - LilyPond callback - Programming concept simple-closure - Programming concept I don't imagine this will be auto-generated any more than the music glossary is. For smob, a link to the guile manual would suffice for the time being. callback needs to be explained in LilyPond terms; there's a good start in NR 1.6.6 Scheme procedures as properties. I imagine this will be a team effort over time. Probably best to start with stubs and gradually flesh them out. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 5.2 redistribute
Graham Percival wrote Friday, July 31, 2009 3:05 AM Could you redistribute the material in LM 5.2 Scores and parts elsewhere in the LM? Maybe beef up LM 2.4.1, maybe insert a new LM 2.4.2 that continues the scores and parts theme, maybe something in LM 3... whatever. Done. I made a new subsection at the end of LM 3.4. It can't go earlier as it assumes knowledge of \new etc. It also uses \include, which isn't introduced anywhere, but that's just one of the things that needs attention. I leave it up to your judgement; I just want to start abolishing LM 5 and making the new Usage document, so I'd like that subsection gone so it's easier to keep track of what I need to deal with. :) Perhaps we should move 5.1 Suggestions for writing ... to LM 3 too. LM 3 then becomes rather more general, but that's no bad thing. Shall I do that now? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keyboard navigation in html docs
At 17:37 on 30 Jul 2009, Mark Polesky wrote: Jonathan Kulp wrote: I think it's possibly to detect keypresses in javascript. 1) Would it be cool or annoying to press n in the docs to proceed to the next page? Admittedly this would be much more useful in the LM than the NR. I appreciate anything like this that keeps me off the mouse. Have you tried the Opera browser? Last time I looked, they were the leaders in the area of keyboard shortcuts. That was a couple years ago, but I remember being impressed. For the ultimate in keyboard browsing, try Vimperator. Like all the best software (e.g. LilyPond, Vim, etc.) there's a steep learning curve... http://vimperator.org/ -- Mark Knoop ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keyboard navigation in html docs
A learning curve is always steep: http://www.psywww.com/intropsych/ch07_cognition/learning_curve.html Bert Mark Knoop wrote: At 17:37 on 30 Jul 2009, Mark Polesky wrote: Jonathan Kulp wrote: I think it's possibly to detect keypresses in javascript. 1) Would it be cool or annoying to press n in the docs to proceed to the next page? Admittedly this would be much more useful in the LM than the NR. I appreciate anything like this that keeps me off the mouse. Have you tried the Opera browser? Last time I looked, they were the leaders in the area of keyboard shortcuts. That was a couple years ago, but I remember being impressed. For the ultimate in keyboard browsing, try Vimperator. Like all the best software (e.g. LilyPond, Vim, etc.) there's a steep learning curve... http://vimperator.org/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] make essay a directory-based book
Le jeudi 30 juillet 2009 à 19:42 -0700, Graham Percival a écrit : The patch works for me; please push if you think it's ok. LGTM, will push as soon as 'make doc' works again (I'm on it). John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [patch] move INSTALL from AU to CG, rename file.
Le jeudi 30 juillet 2009 à 20:59 -0700, Graham Percival a écrit : Attached patch works for me. LGTM, will push with the other patch. John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 5.2 redistribute
On Fri, Jul 31, 2009 at 09:18:45AM +0100, Trevor Daniels wrote: Graham Percival wrote Friday, July 31, 2009 3:05 AM Could you redistribute the material in LM 5.2 Scores and parts elsewhere in the LM? Maybe beef up LM 2.4.1, maybe insert a new Done. I made a new subsection at the end of LM 3.4. It can't go earlier as it assumes knowledge of \new etc. Thanks! It also uses \include, which isn't introduced anywhere, but Woah, seriously? LM 3.1 is perfect for that. Anyway, I'll leave this for you. I leave it up to your judgement; I just want to start abolishing LM 5 and making the new Usage document, so I'd like that subsection gone so it's easier to keep track of what I need to deal with. :) Perhaps we should move 5.1 Suggestions for writing ... to LM 3 too. LM 3 then becomes rather more general, but that's no bad thing. Shall I do that now? No; I think the rest of LM 5 is going into the AU. Makefiles: AU without a doubt. Suggestions and Errors: we could make a case in both ways. For me, it comes down to two things: - people might want to look at Errors during their daily use, whereas theoretically the LM is for an initial-read only. (assuming people remember the overall info) - AU is looking really lean once we kill AU 1 and 2, so this would give that manual more of a reason to exist. Besides, suggestions for writing files totally _sounds_ like usage information to me. :) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 5.2 redistribute
Graham Percival wrote Friday, July 31, 2009 10:50 AM On Fri, Jul 31, 2009 at 09:18:45AM +0100, Trevor Daniels wrote: It also uses \include, which isn't introduced anywhere, but Woah, seriously? LM 3.1 is perfect for that. Anyway, I'll leave this for you. OK Perhaps we should move 5.1 Suggestions for writing ... to LM 3 too. LM 3 then becomes rather more general, but that's no bad thing. Shall I do that now? No; I think the rest of LM 5 is going into the AU. Makefiles: AU without a doubt. Fine Suggestions and Errors: we could make a case in both ways. For me, it comes down to two things: - people might want to look at Errors during their daily use, whereas theoretically the LM is for an initial-read only. (assuming people remember the overall info) OK - AU is looking really lean once we kill AU 1 and 2, so this would give that manual more of a reason to exist. Not a *good* reason, though Besides, suggestions for writing files totally _sounds_ like usage information to me. :) Not sure about totally. Maybe 5.1.1, 5.1.2 and 5.1.3 are usage, but 5.1.4 and 5.1.5 look much more like teaching material to me. I'd find these last two useful in LM 3. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 5.2 redistribute
On Fri, Jul 31, 2009 at 12:00:53PM +0100, Trevor Daniels wrote: Graham Percival wrote Friday, July 31, 2009 10:50 AM - AU is looking really lean once we kill AU 1 and 2, so this would give that manual more of a reason to exist. Not a *good* reason, though :) Besides, suggestions for writing files totally _sounds_ like usage information to me. :) Not sure about totally. Maybe 5.1.1, 5.1.2 and 5.1.3 are usage, but 5.1.4 and 5.1.5 look much more like teaching material to me. I'd find these last two useful in LM 3. Ah, I'd forgotten about those. Yes, 5.1.4 and 5.1.5 would be better off in LM 3. Or maybe LM 4, since they both discuss tweaks. To avoid making the same mistake, 5.2.3 is covered in the website. 5.2.1 could go easily with the other convert-ly docs. This leaves 5.2.2, which IMO lies somewhere between reference material and sequential reading material. As such, I think it's better suited in the AU than LM. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 5.2 redistribute
Graham Percival wrote Friday, July 31, 2009 12:47 PM On Fri, Jul 31, 2009 at 12:00:53PM +0100, Trevor Daniels wrote: Graham Percival wrote Friday, July 31, 2009 10:50 AM Besides, suggestions for writing files totally _sounds_ like usage information to me. :) Not sure about totally. Maybe 5.1.1, 5.1.2 and 5.1.3 are usage, but 5.1.4 and 5.1.5 look much more like teaching material to me. I'd find these last two useful in LM 3. Ah, I'd forgotten about those. Yes, 5.1.4 and 5.1.5 would be better off in LM 3. Or maybe LM 4, since they both discuss tweaks. OK. I'll move 5.1.4 and 5.1.5 out sometime in the next 24 hrs or so. To avoid making the same mistake, 5.2.3 is covered in the website. 5.2.1 could go easily with the other convert-ly docs. This leaves 5.2.2, which IMO lies somewhere between reference material and sequential reading material. As such, I think it's better suited in the AU than LM. Agreed. I'll leave you to move 5.2 out then. And I guess you'll also deal with the rest of 5.1 and 5.4? That seems to settle all LM 5 :) Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Vertical spacing docs
Hi guys, Could someone checks paragraphs and the snippet I @ignored today in Notation, chapter Spacing, in order to compile docs? Maybe they should be deleted. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
On Fri, Jul 31, 2009 at 3:39 AM, Mark Poleskymarkpole...@yahoo.com wrote:
\score {
\relative {
%% value of afterGraceFraction inherited from previous score.
{ c1 \afterGrace d1 { c16[ d] } c1 }
#(define afterGraceFraction (cons 15 16))
{ c1 \afterGrace d1 { c16[ d] } c1 }
}
}
*
Now maybe the only viable solution is to place the burden on the user
to reset all parser variables manually after they're done with them
in a particular block. But I very much dislike that solution because
it multiplies the user's chances of making a mistake. And a lot of
times, features with unintended consequences are hard to track down.
Many, many things affect spacing, for example - so when I see spacing
that looks wrong in the middle of a huge project, how can I possibly
know where to look? And the realization that the cause of the problem
could be in another score entirely... I really think this needs to be
fixed.
Does this make more sense?
No. In the specific case, I'd recommend making another music function
that takes an argument, so you can pass the 15/16 explicitly, without
mucking with variables.
- Mark
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updating THANKS
On Thu, Jul 30, 2009 at 11:22 PM, Mark Poleskymarkpole...@yahoo.com wrote: here are some proposed updates for THANKS. I don't know who usually takes care of this and/or who decides which names go where, but here are You can make an EMERITUS section and put my name there, I think. I can't recall any major change that I contributed to 2.13. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: keyboard navigation in html docs
Bertalan Fodor wrote: A learning curve is always steep: http://www.psywww.com/intropsych/ch07_cognition/learning_curve.html In the opposite sense, that is! See the last paragraph. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LM 5.2 redistribute
Trevor Daniels wrote Friday, July 31, 2009 3:32 PM Graham Percival wrote Friday, July 31, 2009 12:47 PM Ah, I'd forgotten about those. Yes, 5.1.4 and 5.1.5 would be better off in LM 3. Or maybe LM 4, since they both discuss tweaks. OK. I'll move 5.1.4 and 5.1.5 out sometime in the next 24 hrs or so. Moved. 5.1.4 to LM 3 and 5.1.5 to LM 4. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the separate, but integrated website proposal
Le lundi 27 juillet 2009 à 18:13 -0700, Graham Percival a écrit : My apologies for being unclear in the past. (and my advanced apologies for being unclear in the future, although hopefully I won't be unclear about this specific issue) Thanks, I've been preparing a detailed reply but have been unable to complete it so far, because of the consequences of moving to Italy soon (I'll go to Pisa a few days just to have a look in August, then move there in October if possible); I'm afraid the reply to this message will wait for tomorrow. OTOH the PhD degree starts hard only in January, which gives me plenty of time for LilyPond... when I'm not learning Italian. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Main page of new website [was: some css tweaks]
Hi Jan, Le jeudi 30 juillet 2009 à 15:45 +0200, Jan Nieuwenhuizen a écrit : Or just two very big (scalex4) glyphs, clef+eight, flat/sharp + sixteenth? This sounds better than a full bar of music: we don't want to make a music piece so prominently, which could in particular distract the reader, but we want to show the site is about music ntoation software that focuses on typographic quality. However, the glyphs you added are *a bit* too large... Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Vertical spacing docs
On Fri, 2009-07-31 at 16:49 +0200, John Mandereau wrote: Hi guys, Could someone checks paragraphs and the snippet I @ignored today in Notation, chapter Spacing, in order to compile docs? Maybe they should be deleted. They should be deleted, yes. I'll get working on some new docs. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the web front page
2009/7/31 Graham Percival gra...@percival-music.ca: I guess my basic complaint is that the logo doesn't do anything for me -- a lily pad has nothing to do with notation. I'd be happier if it had something musical in it. Here I propose a possible solution. Merge John's snippet (made transparent) with the lily logo and you have a lily logo with music. Attached is a small sample. This is the link to an actual-sized version. It has the same name as the current image for easy testing. http://paconet.org/double-lily-modified2.png -- Francisco Vila. Badajoz (Spain) www.paconet.org www.csmbadajoz.com attachment: web-snippet-lily-small.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Han-Wen Nienhuys wrote: No. In the specific case, I'd recommend making another music function that takes an argument, so you can pass the 15/16 explicitly, without mucking with variables. So it sounds like you believe that one way or another, the burden should be on the user. Then do you think we should add a warning in the docs, something like this? When the value of such a variable is changed in a .ly file, the change is global, and unless explicitly reverted, the new value will persist to the end of the file, affecting subsequent \score blocks as well as external files added with the \include command. This can lead to unintended consequences (if a variable is not explicitly reverted). Especially in complex typesetting projects, these types of errors can be difficult to track down. Would this be something to add to LM 5.2.2 Common errors? I suppose we could also explain (in the docs) how to devise (in general) a custom music-function with the extra argument as you described, but this is a little trickier than simply pointing users to NR 6.1.3 Paired substitution functions. Rewriting the music-function involves not only finding the location of its definition in the distribution files, but also manipulating the scheme code -- far more advanced than explicitly reverting the value, but much safer. What do you think? ** By the way, the number of parser variables susceptible to this situation may be quite small. I grepped (ly:parser-lookup and found these 12 variables: afterGraceFraction musicQuotes mode output-count output-suffix parseStringResult partCombineListener pitchnames toplevel-bookparts toplevel-scores showLastLength showFirstLength Of these 12, 5 were involved in examples (in the docs) showing how to modify the value from a .ly file: #(define afterGraceFraction (cons 15 16)) #(set! output-count 1) #(define output-suffix violin) showFirstLength = R1*1 showLastLength = R1*5 - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: working on the web front page
On Fri, Jul 31, 2009 at 11:03 AM, Francisco Vilapaconet@gmail.com wrote: 2009/7/31 Graham Percival gra...@percival-music.ca: I guess my basic complaint is that the logo doesn't do anything for me -- a lily pad has nothing to do with notation. I'd be happier if it had something musical in it. Here I propose a possible solution. Merge John's snippet (made transparent) with the lily logo and you have a lily logo with music. Attached is a small sample. This is the link to an actual-sized version. It has the same name as the current image for easy testing. http://paconet.org/double-lily-modified2.png Thanks! I added this to the web-gop branch. I also made a couple small changes to liven things up a bit. Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Mark Polesky wrote Friday, July 31, 2009 7:10 PM Han-Wen Nienhuys wrote: No. In the specific case, I'd recommend making another music function that takes an argument, so you can pass the 15/16 explicitly, without mucking with variables. So it sounds like you believe that one way or another, the burden should be on the user. Then do you think we should add a warning in the docs, something like this? When the value of such a variable is changed in a .ly file, the change is global, and unless explicitly reverted, the new value will persist to the end of the file, affecting subsequent \score blocks as well as external files added with the \include command. This can lead to unintended consequences (if a variable is not explicitly reverted). Especially in complex typesetting projects, these types of errors can be difficult to track down. Would this be something to add to LM 5.2.2 Common errors? No, I don't think this is a *common* error. I've never seen it mentioned on -user. And it's too obscure for the LM anyway. What we could do is add a full explanation of parser (or global) variables in NR 6.8 Difficult tweaks, together with your warning, and reference that from each of the examples in the docs that uses them. This accords with the established style of the NR. Your handy lists, below, could also be included. If you're happy with this, and there are no adverse comments over the next couple of days, I'll initiate it. I will need some help from you to hone the text though. By the way, the number of parser variables susceptible to this situation may be quite small. I grepped (ly:parser-lookup and found these 12 variables: afterGraceFraction musicQuotes mode output-count output-suffix parseStringResult partCombineListener pitchnames toplevel-bookparts toplevel-scores showLastLength showFirstLength Of these 12, 5 were involved in examples (in the docs) showing how to modify the value from a .ly file: #(define afterGraceFraction (cons 15 16)) #(set! output-count 1) #(define output-suffix violin) showFirstLength = R1*1 showLastLength = R1*5 - Mark Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
First Lilypond Score
I made my first lilypond score for more than one instrument, and I
thought I'd give some comments on some of the things that were really
difficult from a beginner's perspective. I think it would be helpful to
have a section in the LM on migrating from Finale/Sibelius, or a
separate document, if there isn't one already.
I'm sure some of the following issues will become easier for me once I
go through the docs again and do some more projects, but I imagine other
first time users might run into some of these, so here are my
first project experiences.
slurs - I had a lot of cannot end slur problems early on, evidently
because I was trying to end a slur in a different voice (which isn't a
problem in Finale). Also, longer slurs ( more than a measure ) were often
a little flat: the middle of the slur would get way too close to a notehead,
tie, or something else. Since there are so many settings for
slurs, I didn't have time to figure out how to do a global override to
make them more curvy.
cross-staff tremolos - when doing a \repeat tremolo 4 { c16 d }, you
can't put a \change inside the brackets, so I had to use an
\autochange to get cross-staff tremolos.
vertical spacing - toward the end of the process, I needed to move a staff
in the second system down slightly, and the only way I could find to do
this was in the NR using explicit vertical spacing. Since you have to
use a list of numbers to specify the offsets for each staff, it's
complicated to do this. What I wanted was a way to say
\override Vertical-Distance-From-This-Staff-To-The-One-Below #'padding =
#'[number of staff spaces]
or maybe \nudgeNextStaff #2. Is there anything like this?
internals reference- I found myself going into the internals reference
way too often. Of course this is a good thing in order to gain more
control over one's score, but a lot of it was wasting time, for example:
spending 10 minutes to build and test a macro to flip a tuplet position
when \tupletUp \tupletDown already exist.
I'll keep this in mind the next time through the docs, and see if there's
something I overlooked, or that is missing, about the built in commands.
Pedagogically, btw, I think these macros are great. If someone who uses
Finale sees \slurUp d( e), it's pretty easy to comprehend that Hey,
that's basically the same as selecting a slur with the mouse and using
ctrl-f to flip it up. And no mousing! Whereas seeing:
\once \override Slur #'direction = #UP d( e)
means dear lord, I have to learn a programming language just to move
a slur? No thank you.
spacing - basically, if there is a macro just to nudge a note column to
the left or right, and to turn on some kind of piano staff dynamic spacing so
dynamics are placed in the middle, I think that would make it so that
overrides are only necessary for more advanced stuff.
\mark - This is really handy. Would be cool if spanners could be used
with \mark so accel., rit., a tempo, etc., could be used.
resizing staff/score - since layout-set-staff-size does not
resize the distance between staff lines, what's the best way to, say,
make the pianostaff larger than the other instruments?
Finally, if anyone has tips on 'final touches', I'd appreciate it.
Basically I'm used to making a final pass through a score, and nudging
a few notes/staves, to improve spacing and readability. What's the
easiest way to touch up the final score in Lilypond?
Lilypondtool is great, btw. Looking forward to trying out the new
version.
Thanks,
Jonathan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: First Lilypond Score
Aw man, I meant to send this to the user list! Sorry about that.
-Jonathan
--- On Fri, 7/31/09, Jonathan Wilkes jancs...@yahoo.com wrote:
From: Jonathan Wilkes jancs...@yahoo.com
Subject: First Lilypond Score
To: lilypond-devel@gnu.org
Date: Friday, July 31, 2009, 9:18 PM
I made my first lilypond score for
more than one instrument, and I
thought I'd give some comments on some of the things that
were really
difficult from a beginner's perspective. I think it
would be helpful to
have a section in the LM on migrating from
Finale/Sibelius, or a
separate document, if there isn't one already.
I'm sure some of the following issues will become easier
for me once I
go through the docs again and do some more projects, but I
imagine other
first time users might run into some of these, so here are
my
first project experiences.
slurs - I had a lot of cannot end slur problems early on,
evidently
because I was trying to end a slur in a different voice
(which isn't a
problem in Finale). Also, longer slurs ( more than a
measure ) were often
a little flat: the middle of the slur would get way too
close to a notehead, tie, or something else. Since
there are so many settings for
slurs, I didn't have time to figure out how to do a global
override to
make them more curvy.
cross-staff tremolos - when doing a \repeat tremolo 4 {
c16 d }, you
can't put a \change inside the brackets, so I had to use
an
\autochange to get cross-staff tremolos.
vertical spacing - toward the end of the process, I needed
to move a staff
in the second system down slightly, and the only way I
could find to do
this was in the NR using explicit vertical spacing.
Since you have to
use a list of numbers to specify the offsets for each
staff, it's
complicated to do this. What I wanted was a way to
say
\override
Vertical-Distance-From-This-Staff-To-The-One-Below #'padding
= #'[number of staff spaces]
or maybe \nudgeNextStaff #2. Is there anything like
this?
internals reference- I found myself going into the
internals reference
way too often. Of course this is a good thing in
order to gain more
control over one's score, but a lot of it was wasting time,
for example:
spending 10 minutes to build and test a macro to flip a
tuplet position
when \tupletUp \tupletDown already exist.
I'll keep this in mind the next time through the docs, and
see if there's
something I overlooked, or that is missing, about the built
in commands.
Pedagogically, btw, I think these macros are great.
If someone who uses
Finale sees \slurUp d( e), it's pretty easy to comprehend
that Hey,
that's basically the same as selecting a slur with the
mouse and using
ctrl-f to flip it up. And no mousing! Whereas
seeing:
\once \override Slur #'direction = #UP d( e)
means dear lord, I have to learn a programming language
just to move
a slur? No thank you.
spacing - basically, if there is a macro just to nudge a
note column to
the left or right, and to turn on some kind of piano staff
dynamic spacing so dynamics are placed in the middle, I
think that would make it so that
overrides are only necessary for more advanced stuff.
\mark - This is really handy. Would be cool if
spanners could be used
with \mark so accel., rit., a tempo, etc., could be used.
resizing staff/score - since layout-set-staff-size does not
resize the distance between staff lines, what's the best
way to, say,
make the pianostaff larger than the other instruments?
Finally, if anyone has tips on 'final touches', I'd
appreciate it.
Basically I'm used to making a final pass through a score,
and nudging
a few notes/staves, to improve spacing and
readability. What's the
easiest way to touch up the final score in Lilypond?
Lilypondtool is great, btw. Looking forward to trying
out the new
version.
Thanks,
Jonathan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Trevor Daniels wrote: No, I don't think this is a *common* error. I've never seen it mentioned on -user. And it's too obscure for the LM anyway. What we could do is add a full explanation of parser (or global) variables in NR 6.8 Difficult tweaks, together with your warning, and reference that from each of the examples in the docs that uses them. This accords with the established style of the NR. Your handy lists, below, could also be included. If you're happy with this, and there are no adverse comments over the next couple of days, I'll initiate it. I will need some help from you to hone the text though. I'm okay with it. But I'd like to see what the others think. Am I correct in thinking that if an object returns #t for this test from within a .ly file, it qualifies as a parser variable? #(defined? 'object-name) - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
sorting texinfo indices?
In scm/documentation-generate.scm, I find this: 146 @appendixsec Function index 147 148 @printindex fn ...from which texinfo magically generates IR A. Indices: http://kainhofer.com/~lilypond/Documentation/internals/Indices.html I'd like the list (and others like it) to be sorted according to the algorithm in scm/lily-sort.scm. Judging from recent threads, I figure some python tweaking would be necessary? I'm not about to learn python, but does anyone know how this could be done? Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Adjusting Piano centered dynamics template and Les Néréides
Hello, Since Joe added a new Dynamics context to LilyPond, the two examples mentioned in the subject are currently broken. How should they be modified? Attached is the current produced from latest git. Thanks, Patrick attachment: piano-centered-dynamics.pngattachment: les-nereides.png___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
Mark Polesky wrote Friday, July 31, 2009 8:51 PM I'm okay with it. But I'd like to see what the others think. Am I correct in thinking that if an object returns #t for this test from within a .ly file, it qualifies as a parser variable? #(defined? 'object-name) Sorry, I don't know. Anyone else? - Mark Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adjusting Piano centered dynamics template and Les Néréides
On Fri, 2009-07-31 at 14:00 -0700, Patrick McCarty wrote: Hello, Since Joe added a new Dynamics context to LilyPond, the two examples mentioned in the subject are currently broken. Thanks for pointing this out. How should they be modified? It should be sufficient to simply remove the definition of the Dynamics context from these files (and the \accepts Dynamics part from PianoStaff). The default Dynamics context is very similar (and drew heavily from) the piano dynamics template, so it should be a drop-in replacement. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adjusting Piano centered dynamics template and Les Néréides
2009/7/31 Joe Neeman joenee...@gmail.com: It should be sufficient to simply remove the definition of the Dynamics context from these files (and the \accepts Dynamics part from PianoStaff). The default Dynamics context is very similar (and drew heavily from) the piano dynamics template, so it should be a drop-in replacement. This works fine for the dynamics themselves, but there are two issues concerning pedals and text: In the centred template, the pedals are too close to the bass stave. Perhaps the snippet should define a separate Pedals context to ensure they're positioned correctly (or just add the pedal directions to the bass part). In Les Néréides, there's a problem with text alignment: both rall. and a tempo should be centred with the dynamics, but they appear too high or too low (depending on the text direction). Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
On Fri, Jul 31, 2009 at 2:44 PM, Trevor Danielst.dani...@treda.co.uk wrote:
Mark Polesky wrote Friday, July 31, 2009 8:51 PM
I'm okay with it. But I'd like to see what the others think. Am
I correct in thinking that if an object returns #t for this test
from within a .ly file, it qualifies as a parser variable?
#(defined? 'object-name)
Sorry, I don't know. Anyone else?
I *think* that's true.
For example, in a \paper block, you could do:
\paper {
annotate-spacing = ##t
#(display (defined? 'annotate-spacing))
}
or
\paper {
#(define annotate-spacing #t)
#(display (defined? 'annotate-spacing))
}
Both display true. But this will display false:
\paper {
#(display (defined? 'annotate-spacing))
}
The same should be true for variable assignments outside of \paper,
\layout, and \header too. I recently read about this in the Guile
manual:
http://www.gnu.org/software/guile/manual/html_node/Binding-Constructs.html#Binding-Constructs
HTH,
Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: parser variables persist beyond { } scope
2009/7/31 Patrick McCarty pnor...@gmail.com: I *think* that's true. Hmm, what about primitive procedures? I wouldn't class these as identifiers, but they'll also return #t: #(display (defined? 'car)) = #t Since ly:parser-lookup returns EOL if it can't find the variable, the following is probably a safer bet: (define (parser-defined? x) (not (null? (ly:parser-lookup parser x Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: documentation of \wordwrap-field is broken
2009/7/30 Werner LEMBERG w...@gnu.org: In notation-big-page.html, the output of the snippet which documents \wordwrap-field is broken: It only shows the `title' field; the `description' field is completely missing. Oops, my fault. Nicolas very kindly gave me some examples for this and a few other markup commands when I was documenting them, and I made a mistake here when I changed `descr' to `description' in the \header block without also doing the same for the command itself. Will fix shortly. Thanks, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: sorting texinfo indices?
On Fri, Jul 31, 2009 at 01:11:02PM -0700, Mark Polesky wrote: ...from which texinfo magically generates IR A. Indices: http://kainhofer.com/~lilypond/Documentation/internals/Indices.html I'd like the list (and others like it) to be sorted according to the algorithm in scm/lily-sort.scm. Judging from recent threads, I figure some python tweaking would be necessary? I'm not about to learn python, but does anyone know how this could be done? - download the texinfo source code. It's in C. - download the texi2html source code. It's in perl. - implement your favorite sorting routine as an optional feature in both those projects. Alternately, add hooks to those projects so that users can specify their own sorting routines in some language. - wait 1 year for new releases to come out in those projects - get the sorting you want in those indexes. As I said in http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00710.html it's pretty much beyond our control, and IMO totally not worth the effort involved. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: updating THANKS
On Fri, Jul 31, 2009 at 12:55:47PM -0300, Han-Wen Nienhuys wrote: On Thu, Jul 30, 2009 at 11:22 PM, Mark Poleskymarkpole...@yahoo.com wrote: here are some proposed updates for THANKS. I don't know who usually takes care of this and/or who decides which names go where, but here are You can make an EMERITUS section and put my name there, I think. I can't recall any major change that I contributed to 2.13. You reviewed patches and explained some of the internal details. IMHO, that's plenty. At least, plenty to be a development team. If you'd rather be listed as Reviewer and emeritus professor or something like that, I won't object. :) But I still think you should be in the main team. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \eyeglasses bbox problem
On Thu, Jul 30, 2009 at 6:54 AM, Werner LEMBERGw...@gnu.org wrote: [git 17492869] The \eyeglasses example image in notation-big-page.html is apparently cut off at the right. This probably indicates that the bounding box of this glyph has incorrect values. Thanks for the report. In current git, the bbox should be more accurate. -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote:
Interesting idea. As a first attempt, I tried making the functionality
of the \arpeggioArrowUp command dependent on the 'connectArpeggios
context property, but obviously I'm doing something wrong. Does anyone
know why this doesn't work? Can anyone see how to make this work? If
not, are there other oppositions to my earlier solution of defining new
commands?
I think I might have figured out how to make \arpeggioArrowUp and
its kin select the appropriate context depending on whether
'connectArpeggios is set. Can someone look at this and check to
make sure it's legit?
Thanks!
- Mark
*
\version 2.13.3
#(define (arpeggio-generic context pushpops)
(let* ((PianoStaff (ly:context-find context 'PianoStaff))
(target (if (and PianoStaff
(eq? #t
(ly:context-property PianoStaff
'connectArpeggios)))
PianoStaff
context)))
(for-each
(lambda (pushpop)
(if (pair? pushpop)
(ly:context-pushpop-property target
'Arpeggio
(car pushpop)
(cdr pushpop))
(ly:context-pushpop-property target
'Arpeggio
pushpop)))
pushpops)))
arpeggioArrowUp =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,UP
arpeggioArrowDown =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,DOWN
arpeggioNormal =
\applyContext
#(lambda (context)
(let ((PianoStaff (ly:context-find context 'PianoStaff))
(Staff (ly:context-find context 'Staff)))
;; not sure if the conditional tests are necessary
(if PianoStaff
(arpeggio-generic PianoStaff
`(stencil X-extent arpeggio-direction dash-definition)))
(if Staff
(arpeggio-generic Staff
`(stencil X-extent arpeggio-direction dash-definition)))
(arpeggio-generic context
`(stencil X-extent arpeggio-direction dash-definition
arpeggioBracket =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(X-extent (stencil . ,ly:arpeggio::brew-chord-bracket
\new PianoStaff \relative
\new Staff {
\arpeggioArrowUp
c e g4\arpeggio
\arpeggioNormal
c e g\arpeggio
\set PianoStaff.connectArpeggios = ##t
\arpeggioArrowUp
c e g\arpeggio
\arpeggioBracket
c e g\arpeggio
\set PianoStaff.connectArpeggios = ##f
\arpeggioNormal
c e g\arpeggio
}
\new Staff {
\clef bass
\arpeggioArrowDown
c, e g4\arpeggio
c e g\arpeggio
c e g\arpeggio
c e g\arpeggio
c e g\arpeggio
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote: ;; not sure if the conditional tests are necessary (if PianoStaff (arpeggio-generic PianoStaff `(stencil X-extent arpeggio-direction dash-definition))) (if Staff (arpeggio-generic Staff `(stencil X-extent arpeggio-direction dash-definition))) One small thing - just figured out that the above conditional tests *are* necessary. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
On Fri, 2009-07-31 at 18:58 -0700, Mark Polesky wrote: Mark Polesky wrote: Interesting idea. As a first attempt, I tried making the functionality of the \arpeggioArrowUp command dependent on the 'connectArpeggios context property, but obviously I'm doing something wrong. Does anyone know why this doesn't work? Can anyone see how to make this work? If not, are there other oppositions to my earlier solution of defining new commands? I think I might have figured out how to make \arpeggioArrowUp and its kin select the appropriate context depending on whether 'connectArpeggios is set. Can someone look at this and check to make sure it's legit? Have you tried using ly:context-property-where-defined instead of searching for PianoStaff explicitly? There are non-PianoStaff contexts containing Span_arpeggio_engraver, after all. Other than that, this is a very cool trick! Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Joe Neeman wrote:
Have you tried using ly:context-property-where-defined instead of
searching for PianoStaff explicitly? There are non-PianoStaff contexts
containing Span_arpeggio_engraver, after all. Other than that, this is a
very cool trick!
Joe,
Thanks for the tip. I rewrote arpeggio-generic with ly:context-
property-where-defined and also made some changes to arpeggioNormal.
Also, line 281 of property-init.ly says this:
% For drawing vertical chord brackets with \arpeggio
% This is a shorthand for the value of the print-function property
% of either Staff.Arpeggio or PianoStaff.Arpeggio, depending whether
% cross-staff brackets are desired.
This is completely false, right? Otherwise these commands would work
without the \applyContext gymnastics I've been coding in this thread.
If my code (below) gets approved, I think I'll either remove the
comment it or change it to:
% These commands look for 'connectArpeggios (cross-staff arpeggios)
% to determine the proper context in which to operate.
Any objections? How close is this to being acceptable? I'll wait for
approval.
Thanks.
- Mark
*
\version 2.13.3
%% begin property-init.ly revision %%
#(define (arpeggio-generic context pushpops)
(let* ((parent (ly:context-property-where-defined context
'connectArpeggios))
(target (if (null? parent) context parent)))
(for-each
(lambda (pushpop)
(if (pair? pushpop)
(ly:context-pushpop-property target
'Arpeggio
(car pushpop)
(cdr pushpop))
(ly:context-pushpop-property target
'Arpeggio
pushpop)))
pushpops)))
arpeggioArrowUp =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,UP
arpeggioArrowDown =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(stencil X-extent (arpeggio-direction . ,DOWN
arpeggioNormal =
\applyContext
#(lambda (context)
(let ((Staff (ly:context-find context 'Staff)))
(if (and Staff (not (eq? context Staff)))
(arpeggio-generic Staff
`(stencil X-extent arpeggio-direction dash-definition)))
(arpeggio-generic context
`(stencil X-extent arpeggio-direction dash-definition
arpeggioBracket =
\applyContext
#(lambda (context)
(arpeggio-generic context
`(X-extent (stencil . ,ly:arpeggio::brew-chord-bracket
%% end property-init.ly revision %%
%% demonstration %%
\new PianoStaff \relative
\new Staff {
\arpeggioArrowUp
c e g4\arpeggio
\arpeggioNormal
c e g\arpeggio
\set PianoStaff.connectArpeggios = ##t
\arpeggioArrowUp
c e g\arpeggio
\arpeggioBracket
c e g\arpeggio
\set PianoStaff.connectArpeggios = ##f
\arpeggioNormal
c e g\arpeggio
}
\new Staff {
\clef bass
\arpeggioArrowDown
c, e g4\arpeggio
c e g\arpeggio
c e g\arpeggio
c e g\arpeggio
c e g\arpeggio
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: cross-staff versions of \arpeggioArrowUp etc.
Mark Polesky wrote:
Any objections? How close is this to being acceptable? I'll wait for
approval.
Okay, this is not ready yet. I found a confusing problem. When setting
connectArpeggios to #f after it has been #t, there's some issue with
the unreverted PianoStaff stencil somehow overriding the new Voice
stencil. Or something. I'm not really sure -- it's confusing.
You can see it in action below (note that you need the definitions
from the previous post for this to make sense).
Maybe it's because I'm so tired, but this is so confusing to me that I
feel that anyone who is able to explain this ought to get a special
prize. Unfortunately, I don't have any special prizes to give.
Sometimes computer programming reminds me of this:
http://www.puzzlemethis.com/cgi-bin/puzzle/scan/st=db/ml=33/co=yes/sf=category/se=Disentangle%20%26%20Blacksmith/op=eq.html
Does anyone else feel like this from time to time?
I think I'd feel better if I knew that you guys did!
- Mark
\new PianoStaff \relative
\new Staff {
c e g4\arpeggio
\set PianoStaff.connectArpeggios = ##t
%% bizarre...
%% \arpeggioBracket persists in lower staff after setting
%% connectArpeggios to #f; \arpeggioArrowUp doesn't do this.
\arpeggioBracket
%\arpeggioArrowUp
c e g\arpeggio
\set PianoStaff.connectArpeggios = ##f
c e g\arpeggio
}
\new Staff {
\clef bass
\arpeggioArrowDown
c, e g4\arpeggio
c e g\arpeggio
c e g\arpeggio
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
scm/kpathsea.scm
Hello, Is scm/kpathsea.scm used anymore? If not, can it be removed from LilyPond's source? Thanks, Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
