Re: why is Dutch the default language for note-entry?
Mark Polesky wrote: Why is Dutch the default language for note-entry? Because the originators of LilyPond are Dutch. -David English uses the fewest keystrokes. For comparison, here's a measure from Chopin's Fantasie-impromptu: English: r16 gs( a gs fss gs cs e ds cs ds cs bs cs e gs) Dutch: r16 gis( a gis fisis gis cis e dis cis dis cis bis cis e gis) 49 keystrokes in English compared with 62 in Dutch. English allows for 20% less typing in this example. I think the LM / NR should at least mention that. - Mark p.s. Incidentally, in keys with fewer accidentals, the languages with the most keystrokes are Arabic/ Catalan/Spanish/Italian/Portuguese/Flemish. In keys with many accidentals, Swedish is the worst. More Chopin... Arabic/Catalan/Italian: r16 sold( la sold fadd sold dod mi red dod red dod sid dod mi sold) Catalan/Spanish/Portuguese: r16 sols( la sols fass sols dos mi res dos res dos sis dos mi sols) Flemish: r16 solk( la solk fakk solk dok mi rek dok rek dok sik dok mi solk) Swedish: r16 giss( a giss fississ giss ciss e diss ciss diss ciss biss ciss e giss) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
why is Dutch the default language for note-entry?
Why is Dutch the default language for note-entry? English uses the fewest keystrokes. For comparison, here's a measure from Chopin's Fantasie-impromptu: English: r16 gs( a gs fss gs cs e ds cs ds cs bs cs e gs) Dutch: r16 gis( a gis fisis gis cis e dis cis dis cis bis cis e gis) 49 keystrokes in English compared with 62 in Dutch. English allows for 20% less typing in this example. I think the LM / NR should at least mention that. - Mark p.s. Incidentally, in keys with fewer accidentals, the languages with the most keystrokes are Arabic/ Catalan/Spanish/Italian/Portuguese/Flemish. In keys with many accidentals, Swedish is the worst. More Chopin... Arabic/Catalan/Italian: r16 sold( la sold fadd sold dod mi red dod red dod sid dod mi sold) Catalan/Spanish/Portuguese: r16 sols( la sols fass sols dos mi res dos res dos sis dos mi sols) Flemish: r16 solk( la solk fakk solk dok mi rek dok rek dok sik dok mi solk) Swedish: r16 giss( a giss fississ giss ciss e diss ciss diss ciss biss ciss e giss) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 1:26 PM, "Francisco Vila" wrote: > 2008/12/15 Carl D. Sorensen : >> >> >> >> On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote: >> >> >>> Try not to form mental models. Use the source instead. >> >> Unfortunately, not very many of us understand the source completely, and so >> we need mental models to work in LilyPond. Of course, our mental models >> will be incorrect in some detail, and we'll need to revise them from time to >> time. > > I have a question for the few developers that in some degree do > understand the source code and are able to hack it, fix bugs, > implement new features, etc. > > Is the code properly commented, so that (thinking on the future) new > people can learn from it without having to figure out all the time > what does each function, file etc. do? Sure, I can look at it and say, > but I want the opinion of skilled programmers. > > If not, is there any chance of this to improve? In my opinion, the code is written sufficiently well that if you're willing to spend the time you can eventually get up to speed. There are very few comments, but there are good function names, good variable names, and good consistency. For me, the biggest thing missing is an overall sense of the architecture. It's alluded to in Erik Sandberg's thesis, and you can kind of get it figured out with the source code and the ongoing discussions. But it's still a bit challenging to get into starting from scratch. As far as the prospects for improving the situation, I'd say they're not great. It seems to me that remedying the situation would require a major time investment, and provide no new functionality, just improved accessibility for an unnamed future round of developers. If we had somebody who was interested in getting into the internals and also interested in documenting things, then I think the situation might change. But I have no idea who that person might be. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature req: slur versions of \repeatTie and \laissezVibrer
here's a ly file and png (attached) to help visualize. - Mark This will generate 2 warnings: warning: unterminated slur warning: cannot end slur \version "2.11.65-1" \relative { \time 2/4 \repeat volta 2 { f4( e~ } \alternative { { e f) } { e\repeatTie d) } } \bar "|." } \relative { \time 2/4 f( e~ \repeat volta 2 { e f) } \alternative { { f( e\laissezVibrer } { f2 } } \bar "|." } <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
feature req: slur versions of \repeatTie and \laissezVibrer
feature req: slur versions of \repeatTie and \laissezVibrer When a (non-initial) volta alternative starts with a note tied from the end of the volta, we can use \repeatTie to correctly display the half-tie, but it seems there's no way of displaying a half-slur when the alternative contains a note slurred from the volta (ie. there's no \repeatSlur). One issue would be that the half-slur would need to look backwards for the beginning of the alternative because the slurred-to note wouldn't necessarily be the first note of the alternative. Similarly, when a (non-final) volta alternative ends with a note tied back to the beginning of the volta, we can use \laissezVibrer to fake a half-tie. There seems to be no trick for faking a half-slur when the alternative contains a note slurred back to the beginning of the volta. In this instance the issue would be that the half-slur would need to look forward to find the end of the alternative since the repeat sign doesn't necessarily follow the slurred note immediately -- the slur would need to go past other notes until the repeat sign is reached. However, if an implementation were even plausible (I have no idea), I wouldn't propose \laissezVibrerSlur since that's nonsensical. Perhaps \repeatSlurRight? WARNING: the following may be preposterous. Since the \laissezVibrer half-tie trick is semantically wrong, we could introduce \repeatTieRight. While we're in that ballpark, we could introduce \laissezVibrerLeft -- I have seen French editions (Messiaen?) where chords held across measures have left- and right-sided l.v. ties. And then there are the phrasing slurs... Assuming these additions, we're left with: \repeatTie \repeatTieRight \repeatSlur \repeatSlurRight \repeatPhrasingSlur \repeatPhrasingSlurRight \laissezVibrer \laissezVibrerLeft Amid this new constellation of commands, perhaps \repeatTie, \repeatSlur, and \repeatPhrasingSlur would be less vague if they were called \repeatTieLeft, \repeatSlurLeft, and \repeatPhrasingSlurLeft? Yikes. As always, curious to know your thoughts. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 6:09 PM, Patrick McCarty wrote: > Hi Trevor, > > On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača wrote: > > > > * OK, so based on this understanding, can somebody please correct my > > understanding of the parsing (not the iteration, just the parsing) of the > > following expression (which is the same as my original example #2): > > > > { > > \new Voice { > > c'8 c'8 c'8 c'8 > > } > > d'8 d'8 d'8 d'8 > > } > > > > If I'm understanding how the parser works, then what should result here > is a > > music expression that looks like this: > > > > Global > > V > >\new Score > > V > >\new Staff > > V > >\new Voice > > V > > Sequential > > V > > \new Voice, d'8, d'8, d'8, d'8 > >V > > Sequential > >V > > c'8, c'8, c'8, c'8 > > > > > > If I'm counting correctly, that's 15 total nodes in the expression tree. > > Eight atomic nodes and seven internal nodes. The Global, \new Score, \new > > Staff and the first \new Voice are all created implicitly. > > > > I know that the next part in the process is iteration. But I want to stop > > and check my understanding here: am I understanding the output of the > parser > > correctly at this point? > > I'm pretty sure this would be the result *after* iteration. > > The parser output can be visualized with \displayMusic. So your > example would look like this, using your convention above: > > Sequential > VV > \new Voice d'8, d'8, d'8, d'8 > V > Sequential > V > c'8, c'8, c'8, c'8 > > After this, the iteration process starts, proceeding moment by moment > and making sure everything is placed in the correct context. Then you > would end up with a tree that looks like the one you posted. I > believe the implicit creation of contexts happens during iteration. > > (I could be completely wrong, but it makes sense to me). OK, and Han-Wen confirms what you're saying, too. Much appreciated. Going back to look at more code now ... -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 6:21 PM, Han-Wen Nienhuys wrote: > On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys > wrote: > > >> I know that the next part in the process is iteration. But I want to > stop > >> and check my understanding here: am I understanding the output of the > parser > >> correctly at this point? > > > > No. the \new Staff and \new Score are created at iteration time. Look > > for path_to_acceptable_context(). > > and to be extra clear, it's the "Staff" and "Score" contexts that get > created. The expression is not modified during iteration. > OK, got it. Will check path_to_acceptable_context( ). -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys wrote: >> I know that the next part in the process is iteration. But I want to stop >> and check my understanding here: am I understanding the output of the parser >> correctly at this point? > > No. the \new Staff and \new Score are created at iteration time. Look > for path_to_acceptable_context(). and to be extra clear, it's the "Staff" and "Score" contexts that get created. The expression is not modified during iteration. -- 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: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 8:12 PM, Trevor Bača wrote: > * OK, so based on this understanding, can somebody please correct my > understanding of the parsing (not the iteration, just the parsing) of the > following expression (which is the same as my original example #2): > > { > \new Voice { > c'8 c'8 c'8 c'8 > } > d'8 d'8 d'8 d'8 > } > > If I'm understanding how the parser works, then what should result here is a > music expression that looks like this: > > Global > V >\new Score > V >\new Staff > V >\new Voice > V > Sequential > V > \new Voice, d'8, d'8, d'8, d'8 >V > Sequential >V > c'8, c'8, c'8, c'8 > > > If I'm counting correctly, that's 15 total nodes in the expression tree. > Eight atomic nodes and seven internal nodes. The Global, \new Score, \new > Staff and the first \new Voice are all created implicitly. > > I know that the next part in the process is iteration. But I want to stop > and check my understanding here: am I understanding the output of the parser > correctly at this point? No. the \new Staff and \new Score are created at iteration time. Look for path_to_acceptable_context(). Also, you can use the \displayMusic music function to get to the parse tree. -- 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: Scheme function to print out active Voice context during interpretation?
Hi Trevor, On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača wrote: > > * OK, so based on this understanding, can somebody please correct my > understanding of the parsing (not the iteration, just the parsing) of the > following expression (which is the same as my original example #2): > > { > \new Voice { > c'8 c'8 c'8 c'8 > } > d'8 d'8 d'8 d'8 > } > > If I'm understanding how the parser works, then what should result here is a > music expression that looks like this: > > Global > V >\new Score > V >\new Staff > V >\new Voice > V > Sequential > V > \new Voice, d'8, d'8, d'8, d'8 >V > Sequential >V > c'8, c'8, c'8, c'8 > > > If I'm counting correctly, that's 15 total nodes in the expression tree. > Eight atomic nodes and seven internal nodes. The Global, \new Score, \new > Staff and the first \new Voice are all created implicitly. > > I know that the next part in the process is iteration. But I want to stop > and check my understanding here: am I understanding the output of the parser > correctly at this point? I'm pretty sure this would be the result *after* iteration. The parser output can be visualized with \displayMusic. So your example would look like this, using your convention above: Sequential VV \new Voice d'8, d'8, d'8, d'8 V Sequential V c'8, c'8, c'8, c'8 After this, the iteration process starts, proceeding moment by moment and making sure everything is placed in the correct context. Then you would end up with a tree that looks like the one you posted. I believe the implicit creation of contexts happens during iteration. (I could be completely wrong, but it makes sense to me). -Patrick ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LP's staff lines are thinner than Henle...
On Mon, Dec 15, 2008 at 02:07:35PM -0800, Mark Polesky wrote: > I'm intentionally making a big deal out of this because this > is the text on page 2 of the manual, and disingenuous claims > are off-putting to new users. We're trying to "sell" a > product, but our pitch is unconvincing and maybe a little > suspicious. Thanks for looking into this. My initial thought is that we should print out our flat (at 4800dpi or whatever), then scan that printout. This would avoid any pdf->png confusion, as well as presenting a more unified comparison. (well, it would if we could print it on the same paper as the Henle and Barenreiter flats used) However -- and I really hate asking people to delay things when they're enthusiastic -- could you wait a few weeks until GOP starts? With Christmas and preparing for 2.12, this isn't the best of times to fiddle with such details. In addition, the entire Engraving essay will be removed from the LM, put somewhere else, and quite possibly be rewritten from scratch as part of GOP. (that said, we will probably retain the comparison of flats, so perhaps there's no point waiting before producing the scans) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 3:12 PM, "Trevor Bača" wrote: > On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys wrote: >> On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen wrote: On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote: >> Try not to form mental models. Use the source instead. Unfortunately, not very many of us understand the source completely, and so we need mental models to work in LilyPond. Of course, our mental models will be incorrect in some detail, and we'll need to revise them from time >> to time. >> >> sure, but if you spend a lot of time and effort on theorizing (like >> Trevor did), you might as well invest that time & effort into looking >> at the source code itself. > > I think both are good: wanton speculation taken together with digging through > source. > > :-) > > I've been digging through source this morning ... and I'm understanding much > better ... but still unable to resolve at least one example, which I've > included at the end of this message. > > What I've found so far: > > * There are 22 -iterator.cc files with Music_iterator being the base class > from which the others all directly (or, more usually, indirectly) inherit. > (Simple_music_iterator, Music_wrapper_iterator and Sequential_iterator are all > popular choices to derive from, too, but all three inherit from Music_iterator > at base.) Concrete iterators exist to iterate over regular stuff like > EventChord and and 'simple music' (which parser.yy makes me think means > basically notes and rests). Iterators also exist to iterate over more complex > music expressions like grace music, time-scaled music, voltas, and music > expressions passed to the \unfold command. My understanding of this flock of > iterators available in the C++ source is as a type of realization of the > visitor pattern that separates traversal from other activities like > calculation and modification. > > * Additionally, both the comments at the head of music-iterator.hh and Erik's > thesis make it clear that the object over which the different iterators > iterate is a (conceptual) queue of music events *that all happen at the same > moment*. That is, when it comes time to iterate, the first thing that happens > is that the entire context tree (starting from the Global context and > proceeding all the way to bottom-level voice contexts) are *prepared* for > Moment 0; then iterators iterate over all events that happen at Moment 0 *no > matter at which level of the context tree those different events occur*. This > helps because I was assuming (wrongly) earlier that iteration would be a > depth-first search starting from the root of the expression tree; if that were > the case then each context would be visited before any of its children. But, > in fact, section 9.4 of Erik's thesis says "One of the consequences of a > OneTimeStep stream event, is that all contexts are visited in a post-order > tree walk; i.e., each context is visited after all its children have been > visited." I haven't been able to verify this in the code, however. > > * I've also found that a pronouncement like "\new Voice { c'4 }" is actually > THREE expressions. The "\new Voice" is actually a music expression all by > itself (of type ContextSpeccedMusic). There is a > Context_specced_music_iterator defined in an eponymous .cc file and inheriting > from Music_wrapper_iterator. The purpose of the Context_specced_music_iterator > is to descend to the one (and only one) child that each ContextSpeccedMusic > like "\new Voice" music have: something like Sequential is the usual option. > So the parser (which I only understand vaguely) decomposes "\new Voice { c'4 > }" into three expressions with "\new Voice" parsed as ContextSpeccedMusic, > with "{ }" parsed as Sequential, with "c'4" parsed as EventChord (I think). > Further, the parser builds the resulting music expression such that > ContextSpeccedMusic is the parent of Sequential which is, in turn, the parent > of EventChord. > > * Also, all parsing is done before any iteration is done. > > * OK, so based on this understanding, can somebody please correct my > understanding of the parsing (not the iteration, just the parsing) of the > following expression (which is the same as my original example #2): > > { > \new Voice { > c'8 c'8 c'8 c'8 > } > d'8 d'8 d'8 d'8 > } > > If I'm understanding how the parser works, then what should result here is a > music expression that looks like this: > > Global > V >\new Score > V >\new Staff > V >\new Voice > V > Sequential > V > \new Voice, d'8, d'8, d'8, d'8 >V > Sequential >V > c'8, c'8, c'8, c'8 > > > If I'm counting correctly, that's 15 total nodes in the expression tree. Eight > atomic nodes
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys wrote: > On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen > wrote: > > > > > > > > On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote: > > > > > >> Try not to form mental models. Use the source instead. > > > > Unfortunately, not very many of us understand the source completely, and > so > > we need mental models to work in LilyPond. Of course, our mental models > > will be incorrect in some detail, and we'll need to revise them from time > to > > time. > > sure, but if you spend a lot of time and effort on theorizing (like > Trevor did), you might as well invest that time & effort into looking > at the source code itself. > I think both are good: wanton speculation taken together with digging through source. :-) I've been digging through source this morning ... and I'm understanding much better ... but still unable to resolve at least one example, which I've included at the end of this message. What I've found so far: * There are 22 -iterator.cc files with Music_iterator being the base class from which the others all directly (or, more usually, indirectly) inherit. (Simple_music_iterator, Music_wrapper_iterator and Sequential_iterator are all popular choices to derive from, too, but all three inherit from Music_iterator at base.) Concrete iterators exist to iterate over regular stuff like EventChord and and 'simple music' (which parser.yy makes me think means basically notes and rests). Iterators also exist to iterate over more complex music expressions like grace music, time-scaled music, voltas, and music expressions passed to the \unfold command. My understanding of this flock of iterators available in the C++ source is as a type of realization of the visitor pattern that separates traversal from other activities like calculation and modification. * Additionally, both the comments at the head of music-iterator.hh and Erik's thesis make it clear that the object over which the different iterators iterate is a (conceptual) queue of music events *that all happen at the same moment*. That is, when it comes time to iterate, the first thing that happens is that the entire context tree (starting from the Global context and proceeding all the way to bottom-level voice contexts) are *prepared* for Moment 0; then iterators iterate over all events that happen at Moment 0 *no matter at which level of the context tree those different events occur*. This helps because I was assuming (wrongly) earlier that iteration would be a depth-first search starting from the root of the expression tree; if that were the case then each context would be visited before any of its children. But, in fact, section 9.4 of Erik's thesis says "One of the consequences of a OneTimeStep stream event, is that all contexts are visited in a post-order tree walk; i.e., each context is visited after all its children have been visited." I haven't been able to verify this in the code, however. * I've also found that a pronouncement like "\new Voice { c'4 }" is actually THREE expressions. The "\new Voice" is actually a music expression all by itself (of type ContextSpeccedMusic). There is a Context_specced_music_iterator defined in an eponymous .cc file and inheriting from Music_wrapper_iterator. The purpose of the Context_specced_music_iterator is to descend to the one (and only one) child that each ContextSpeccedMusic like "\new Voice" music have: something like Sequential is the usual option. So the parser (which I only understand vaguely) decomposes "\new Voice { c'4 }" into three expressions with "\new Voice" parsed as ContextSpeccedMusic, with "{ }" parsed as Sequential, with "c'4" parsed as EventChord (I think). Further, the parser builds the resulting music expression such that ContextSpeccedMusic is the parent of Sequential which is, in turn, the parent of EventChord. * Also, all parsing is done before any iteration is done. * OK, so based on this understanding, can somebody please correct my understanding of the parsing (not the iteration, just the parsing) of the following expression (which is the same as my original example #2): { \new Voice { c'8 c'8 c'8 c'8 } d'8 d'8 d'8 d'8 } If I'm understanding how the parser works, then what should result here is a music expression that looks like this: Global V \new Score V \new Staff V \new Voice V Sequential V \new Voice, d'8, d'8, d'8, d'8 V Sequential V c'8, c'8, c'8, c'8 If I'm counting correctly, that's 15 total nodes in the expression tree. Eight atomic nodes and seven internal nodes. The Global, \new Score, \new Staff and the first \new Voice are all created implicitly. I know that the next part in the process is iteration. But I want to stop and check my understanding here: am I understanding the output o
code comments (was Re: Scheme function to print out active Voice context during interpretation?)
On Mon, Dec 15, 2008, Francisco Vila said: > I have a question for the few developers that in some degree do > understand the source code and are able to hack it, fix bugs, > implement new features, etc. > > Is the code properly commented, so that (thinking on the future) new > people can learn from it without having to figure out all the time > what does each function, file etc. do? Newbie to the project, but one who has been programming since 1968, this is something I have discussed at length with other experience programmers. I speak in general, have yet to delve into Lp code at all, so please forgive if this is already covered by a project policy or perhaps a gnu policy. Good code commenting is a challenging skill, at its best the comments on archived code should Be accurate, uptodate, not telling lies. Explain why someone would want to invoke the code Describe context for use - arguments in, side effects, value(s) returned. Cite sources for non-trivial algorythms used, if original, publish a white paper to the project which can be cited. In many cases comments will exceed the code itself. Line-by-line comments are sometimes useful but should give information beyond the obvious. In a language like postscript the expected state of the stack is ofen a useful comment. Some projects embed text for documentation and help files with the code itself to encourage parallel maintenance. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 2:26 PM, "Han-Wen Nienhuys" wrote: > 2008/12/15 Carl D. Sorensen : >> > >> I'd say it differently: >> >> EXPRESSIONS: >> Establish the timing of music-events relative to one another > >> CONTEXTS: >> Provide the evaluation environment (my words, not Han-Wen's) in which all >> music events will be evaluated when it's time to put them in the output >> stream (midi file or printed page). > > very well said. > >> The confusion comes in because, if there is no appropriate context >> available, when LilyPond sees a music expression it will automatically > > In this case, the order of instantation depends on the order in the > music expression, which helps people confuse context and music > expressions too. But it's the order in the music stream, not the input stream, isn't it? Otherwise, why does { \new Voice="foo" { c } d } result in only a single voice being instantiated, but { d \new Voice="foo" { c } } result in two voices being instantiated? Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Fix custom key signatures which use octave-specific accidentals
Hello, Please review: http://codereview.appspot.com/11052 Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
2008/12/15 Carl D. Sorensen : > > I'd say it differently: > > EXPRESSIONS: > Establish the timing of music-events relative to one another > CONTEXTS: > Provide the evaluation environment (my words, not Han-Wen's) in which all > music events will be evaluated when it's time to put them in the output > stream (midi file or printed page). very well said. > The confusion comes in because, if there is no appropriate context > available, when LilyPond sees a music expression it will automatically In this case, the order of instantation depends on the order in the music expression, which helps people confuse context and music expressions too. -- 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: Scheme function to print out active Voice context during interpretation?
On 12/15/08 6:25 AM, "Trevor Bača" wrote: > On Sun, Dec 14, 2008 at 9:10 PM, Han-Wen Nienhuys wrote: >> On Mon, Dec 15, 2008 at 12:18 AM, Trevor Bača wrote: > > ... even though contexts do not literally nest! (Even though their iterators > inherit from one another.) > > So, to resume, this leads to the following situation: > > EXPRESSIONS: > * exhibit syntactic nesting > * do not exhibit 'visual nesting' (or, maybe, 'properties nesting') > > CONTEXTS: > * do not exhibit syntactic nesting > * do exhibit 'visual nesting' / 'properties nesting' > > > Or maybe a better way of saying it: > > EXPRESSIONS: > * exhibit syntactic nesting > * do not store grob properties > > CONTEXTS: > * do not exhibit syntactic nesting > * do store grob properties > > > > Hm. I think I get it now. Much thanks to everyone. If anyone sees more details > missing from my working-out process, please correct. > > > > Trevor. I'd say it differently: EXPRESSIONS: Establish the timing of music-events relative to one another So there is no difference between { {c4 d} {e f} {g a}} and {c4 d e f g a } Similarly, there is no difference between { {\override myObject #'prop = #value c4 d} {\override myObject #'prop = #new-value e f} {g a} } and { \override myObject #'prop = #value c4 d \override myObject #'prop = #new-value e f g a } Both expressions cause the first override to apply to the current context starting and the moment of the note c4 and the second override to apply starting at the moment of the note e. Note that those overrides will apply to ALL OBJECTS OF TYPE myObject IN THE CURRENT CONTEXT, starting at those times. So << { c4 d \override myObject #'prop = #value e f} { g4 a b c} >> will have the overrides applied to the e, f, b, and c, but not g4 and a. This is because it's the music moment, not the source file relative location, that defines the applicability of the overrides. CONTEXTS: Provide the evaluation environment (my words, not Han-Wen's) in which all music events will be evaluated when it's time to put them in the output stream (midi file or printed page). All properties that matter but are not tied to a particular grob reside in a context that contains the grob. They may be tied to the immediate context containing the grob (e.g. Voice, for NoteHead) or may come from a context above the current context in the heierarchy (e.g. the Staff that contains the Voice that contains the notehead). The confusion comes in because, if there is no appropriate context available, when LilyPond sees a music expression it will automatically create a context. And there is nothing in the input syntax that tells you when the context will be created. So I continue to get surprised from time to time if I don't explicitly instantiate all contexts. I think your discussion about "naked" music expressions is illuminating, but also potentially confusing. It's not naked expressions that cause the challenge, but expressions that occur at a point in the music stream (not the input stream) where no appropriate context exists, therefore requiring LilyPond to create one. So if we look at your example 2: %%% VOICE-RESOLUTION EXAMPLE 2 %%% \version "2.11.57" { \new Voice = "foo" { \override Voice.NoteHead #'color = #red g'8 a'8 b'8 c''8 } d''8 e''8 f''8 g''8 } %%% END EX 2 %%% Looking in music stream (not input stream) order: 1a instantiate Voice foo (this takes no musical time). Oops, we don't have a Staff context to hold foo, so we'll need to create one. 1b Make an override to the notehead color (this also takes no musical time) 1c engrave g'8 (this is the first thing that takes musical time) 2 engrave a'8 3 engrave b'8 4 engrave c''8 Now we're done with the music expression explicitly created in voice "foo" 5 engrave d''8 -- and since we have a voice "foo", just keep on with it. 6 engrave e''8 7 engrave f''8 8 engrave g''8 In contrast, we have Example 2+1 Note: %%% EX 2 + 1 NOTE %%% { c'8 \new Voice = "foo" { \override Voice.NoteHead #'color = #red g'8 a'8 b'8 c''8 } d''8 e''8 f''8 g''8 } %%% END EX 2 MOD %%% Looking at this in music stream order we have 1. engrave c'8. Oops, we don't have a Voice context to engrave c'8. Therefore we need to create a Voice context for c'8. And since we don't have a Staff to hold the Voice, we'll need to create a Staff context as well. 2a. create a new Voice context called foo, and assign the next expression to voice foo. (no musical time) 2b. engrave g'8 in foo context 3. engrave a'8 in foo context 4. engrave b'8 in foo context 5. engrave c''8 in foo context Now I'm done with the music expression that was assigned to Voice foo. 6. engrave d''8. It goes in the Voice context that we were using before we created "f
Re: Changing snippets in the documentation
Hi Carl, > The make web choked on trying to run a lilypond snippet. I looked at the > snippet, and the reason that lilypond choked was because the snippet was the > *old* version of the snippet, not the new version of the snippet. So the > last lines of the make web output aren't likely to be helpful. If there are > helpful lines in the output, they would be likely to show up somewhere > above, where snippets are extracted from the .itely files. The old snippets were in the translations; running update-snippets.py copied the syntax changes over from user. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 09:26:15PM +0100, Francisco Vila wrote: > Is the code properly commented, so that (thinking on the future) new > people can learn from it without having to figure out all the time > what does each function, file etc. do? Sure, I can look at it and say, > but I want the opinion of skilled programmers. > > If not, is there any chance of this to improve? In my (somewhat limited) experience, no matter how good the documentation for source code, getting involved in a large project is always easier if you have a mentor. There's always little details or tricks that a person can pass along that never make it into the source docs... and besides, a mentor can tailor his answers directly to your questions, rather than the general info that you'd find in documentation. That's why I was hoping that somebody would offer to be the Frogmeister (you can have a non-silly name if you want!). People willing to spend time fixing bugs would gain a mentor to guide them towards a better understanding of the source code, and the mentor would gain more people fixing bugs in lilypond (which in turn leads to a better program which presumably the mentor is using :). Sure, we could ask a skilled developer to spend 50 hours writing better source docs... but I don't think that's a good trade-off. Their time is so limited, and the number of potential developers is so small, that I think that personal mentorship is the best way to go. Now, if one of those new developers wants to spend 5 hours a week carefully documenting what he's learned about the internals while fixing bugs, I certainly wouldn't object. But of course, that developer needs to consider the trade-offs involved: more bug fixes? Writing translations? Documenting the source code? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR-snippet for tick barline
2008/12/14 Reinhold Kainhofer : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I just saw the git commit to update input/lsr/tick-bar-lines.ly > > I suppose it would be easier / better to use > \set Score.defaultBarType = "'" > globally instead of explicit \bar "'" for each barline... Ah yes, I couldn't for the life of me remember the correct property for this; I wasted time playing around with whichBar and 'glyph for some reason. I guess my brain wasn't in gear yesterday, what with this *and* reviewing patches that had already been sorted. :) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
2008/12/15 Carl D. Sorensen : > > > > On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote: > > >> Try not to form mental models. Use the source instead. > > Unfortunately, not very many of us understand the source completely, and so > we need mental models to work in LilyPond. Of course, our mental models > will be incorrect in some detail, and we'll need to revise them from time to > time. I have a question for the few developers that in some degree do understand the source code and are able to hack it, fix bugs, implement new features, etc. Is the code properly commented, so that (thinking on the future) new people can learn from it without having to figure out all the time what does each function, file etc. do? Sure, I can look at it and say, but I want the opinion of skilled programmers. If not, is there any chance of this to improve? -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen wrote: > > > > On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote: > > >> Try not to form mental models. Use the source instead. > > Unfortunately, not very many of us understand the source completely, and so > we need mental models to work in LilyPond. Of course, our mental models > will be incorrect in some detail, and we'll need to revise them from time to > time. sure, but if you spend a lot of time and effort on theorizing (like Trevor did), you might as well invest that time & effort into looking at the source code itself. -- 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: Scheme function to print out active Voice context during interpretation?
On 12/15/08 7:18 AM, "Han-Wen Nienhuys" wrote: > Try not to form mental models. Use the source instead. Unfortunately, not very many of us understand the source completely, and so we need mental models to work in LilyPond. Of course, our mental models will be incorrect in some detail, and we'll need to revise them from time to time. But even if we use the source, we'll have to make mental models of the source, and those may be incorrect as well. Maybe I'm the only person who doesn't understand the full source code, but I doubt it. Certainly developers should understand the source code when they modify it, and understanding the source code is preferable to an incorrect mental model, but the idea of documentation is to allow users to form correct mental models about program operation WITHOUT reading the source code. So I believe that we SHOULD form mental models, based on the docs and our experiences, and whenever there's a weakness in the mental model, it points to a place to improve the docs. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
thin bar lines are thinner than Henle...
While browsing the introductory docs I noticed that in those showing 'us' vs 'them' vs 'Henle' thin bars were same line thickness as staff lines in 'us' and 'them', but slightly thicker in 'Henle'. Perhaps some discussion would strengthen our claims. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: spaces must be inserted around property commands?
On Mon, Dec 15, 2008 at 10:15 AM, Trevor Daniels wrote: > This is the general syntax, but the rider above needs to be > applied when entering overrides directly in \lyricmode. This is already documented, but making it clearer is on my TODO-list for when I get a life (ETA 2 weeks or so). Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LP's staff lines are thinner than Henle...
Years ago I made a 4800dpi film in a printshop. It was surprisingly different than a 600dpi laser-print. So to make a fair comparison one should print pages with the same professional technology and see. Bert Carl D. Sorensen wrote: On 12/14/08 11:45 PM, "Mark Polesky" wrote: LM 1.1 Background - "Engraving" states: "our staff lines... are also much thicker than lines in the computer edition." In both the HTML and PDF versions, LilyPond's staff lines are in fact the thinnest when compared. I've included a png to make this easier to see. In the HTML version, the distance from top to bottom staff line of the LP example was smaller than the other 2, but even when scaling the LP example to match the other 2 (as I've done here) the LP lines are still the thinnest. The PDF example is magnified about 300 times. Can someone explain this? - Mark The staff lines on your other examples have been broadened by anti-aliasing. The staff line on the LilyPond example have not been, because it's a vector drawing. So your comparision is not apt. I have not viewed the originals to make any judgement of them. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LP's staff lines are thinner than Henle...
On 12/14/08 11:45 PM, "Mark Polesky" wrote: > LM 1.1 Background - "Engraving" states: > > "our staff lines... are also > much thicker than lines in the > computer edition." > > In both the HTML and PDF versions, LilyPond's staff lines are > in fact the thinnest when compared. I've included a png to > make this easier to see. In the HTML version, the distance > from top to bottom staff line of the LP example was smaller > than the other 2, but even when scaling the LP example to > match the other 2 (as I've done here) the LP lines are still > the thinnest. The PDF example is magnified about 300 times. > > Can someone explain this? > > - Mark > > > > The staff lines on your other examples have been broadened by anti-aliasing. The staff line on the LilyPond example have not been, because it's a vector drawing. So your comparision is not apt. I have not viewed the originals to make any judgement of them. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 11:25 AM, Trevor Bača wrote: > 6. Lily reads the terminal close } brace. Even here, I'm willing to bet, > Lily sees no reason to kill off the explicit named "foo" context. I bet Lily > reads the terminal close } brace and instead simply closes off the original > music *expression*. My guess would be that not until EOF does Lily finally > kill off the original named "foo" context. EOF does not play any role in this. The parsing into trees of music expressions is done beforehand, and the iteration is not connected directly with the input file. Each iterator contains a pointer to the context it delivers events to. This pointer is actually reference counted, and a context is ended when its reference count drops to zero. > ==> naked { } expressions DO NOT cause contexts to be instantiated at the > open { brace and destroyed at the close } brace. Look for descend_to_bottom(). Generally, event chords (rests, notes, lyrics) cause a bottom context (lyrics, voice, chordnames) to be instantiated as child of the current context. The iterator for { } (sequential) will change its context to the one of its child if that child has a deeper level than the current one. so, \new Staff { c d } the iterator for 'c' will create a Voice, the enclosing iterator will change from Staff to Voice, since Voice is deeper nested in the context tree. > This is a super long-winded way of me coming around to Carl's mental model: Try not to form mental models. Use the source instead. -- 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: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Reinhold Kainhofer: > However, I'm now running into the next problem: Lilypond's configure > claims it is missing guile! - From the log file: configure:8270: checking for scm_boot_guile configure:8326: i686-linux-gcc -I/home/lilypond/gub/target/linux- x86/build/lilypond-git.sv.gnu.org--lilypond.git-master -o conftest -O2 - finline-functions -g -pipe -I/home/lily pond/gub/target/linux-x86/root/usr/include -Wl,--as-needed conftest.c - L/home/lilypond/gub/target/linux-x86/root/usr/lib -lguile -lgmp -ldl >&5 conftest.c:8:1: warning: "PACKAGE_NAME" redefined conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libltdl.so.3: undefined reference to `__stack_chk_f...@glibc_2.4' collect2: ld returned 1 exit status configure:8332: $? = 1 [...] configure:10752: checking for pango_ft2_font_map_create_context configure:10808: i686-linux-gcc -I/home/lilypond/gub/target/linux- x86/build/lilypond-git.sv.gnu.org--lilypond.git-master -o conftest -O2 - finline-functions -g -pipe -I/home/lil ypond/gub/target/linux-x86/root/usr/include/python2.4 - I/home/lilypond/gub/target/linux-x86/root/usr/include/pango-1.0 - I/home/lilypond/gub/target/linux-x86/root/usr/include/free type2 -I/home/lilypond/gub/target/linux-x86/root/usr/include - I/home/lilypond/gub/target/linux-x86/root/usr/include/glib-2.0 - I/home/lilypond/gub/target/linux-x86/root/usr/lib/gli b-2.0/include-Wl,--as-needed -Wl,-rpath -Wl,\$$ORIGIN/../lib conftest.c - L/home/lilypond/gub/target/linux-x86/root/usr/lib -lpangoft2-1.0 -lpango-1.0 - lfreetype -lz -lfontcon fig -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -ldl >&5 conftest.c:8:1: warning: "PACKAGE_NAME" redefined conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libexpat.so.0: undefined reference to `__stack_chk_f...@glibc_2.4' collect2: ld returned 1 exit status Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlyXTqjEwhXvPN0RAuqvAJ9q4WcwBo5rdIOefwE/QGE8Q37q+wCfXi5q Iav13eE6fRLaCRV+QGuUkbk= =xmTM -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen: > Op zaterdag 13-12-2008 om 01:59 uur [tijdzone +0100], schreef Reinhold > > Kainhofer: > > Unfortunately, gmp does not build there, since the configure check seems > > to think it is on a 64-bit platform: > > Is this with GUB3? It's the checkout of git://github.com/janneke/gub.git > > checking size of mp_limb_t... 4 > > You can look in configure.ac for the test with this text > > > configure: error: Oops, mp_limb_t is 32 bits, but the assembler code > > in this configuration expects 64 bits. > > and fix or disable it. Searching the web and the mailing lists a bit more revealed that there is an undocumented environment variable, which one can use to force a given ABI: ABI=32 make lilypond It's not ideal that gmp doesn't detect this automatically, but at least now it builds correctly. However, I'm now running into the next problem: Lilypond's configure claims it is missing guile! Here's the output: [...] checking for guile-config... i686-linux-guile-config checking i686-linux-guile-config version... 1.8.5 checking guile compile flags... -I/home/lilypond/gub/target/linux- x86/root/usr/include checking guile link flags... -L/home/lilypond/gub/target/linux-x86/root/usr/lib - -lguile -lgmp checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... no checking for scm_boot_guile... no checking GUILE rational bugfix... ok [...] checking for guile... guile checking for guile... /home/lilypond/gub/target/tools/root/usr/bin/guile [...] config.status: creating config.make config.status: creating config.hh config.status: config.hh is unchanged ERROR: Please install required programs: libguile (libguile-dev, guile-devel or guile-dev package). Strange enough, on that same machine the nightly binary and docs builds work fine and detect guile just fine... The configure output of the current git master (using the system-wide installed guile) is: [...] checking for guile-config... guile-config checking guile-config version... 1.8.5 checking guile compile flags... -pthread checking guile link flags... -pthread -lguile -lltdl -Wl,-Bsymbolic-functions - -lgmp -lcrypt -lm -lltdl checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... yes checking for scm_boot_guile... yes checking GUILE rational bugfix... ok [...] checking for guile... guile checking for guile... /usr/bin/guile So, apparently the guile built by gub is missing scm_boot_guile or some link flag Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlhsTqjEwhXvPN0RApAyAJ9MuLyiQu3M0xmn2pQ2+2PQxQIYOACeNlAG iiE7n2bGfUUQA8uUWOeqjnU= =/7rL -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen: > Op vrijdag 12-12-2008 om 06:18 uur [tijdzone -0800], schreef Graham > > Percival: > > Problem building the netpbm package. gcc doesn't seem to > > recognize the "-flax-vector-conversions" option, > > What happens if you remove that option? It would be nice if this > option is only needed for gccs that are so new that they are > too strict with vector conversions? We could then add some > code like in > >gub/specs/librestrict.py I've now upgraded the server to kubuntu intrepid, so I can't test this any more... With intrepid (gcc 4.3.x instead of 4.2.4 in hardy) the netpbm builds without problems. Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlOSTqjEwhXvPN0RAtGaAJsH+QgOFs2Qq4JydFDB6R4Mjp9gjACfcJTc bhcWsgbxhrYjApMWiLfSJ54= =vgL9 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: function lookup
So there is a distinction between parser keywords and music functions? On Sun, Dec 14, 2008 at 12:43 PM, Neil Puttock wrote: > Hi John, > > 2008/12/14 John Mangual : > > how would i go about looking up the scheme source code for a specific > > function like "transpose" or "tuple" or "key" > > It depends on whether the function is a parser keyword or music > function; if it's the latter (you can check this by looking at > appendix B.14, Identifiers) then you're most likely to find it in > ly/music-functions-init.ly. > > In the case of keywords, you'll have to follow the trail from the > parser. For example, here's the parser entry for \transpose: > >| TRANSPOSE pitch_also_in_chords pitch_also_in_chords music { >Pitch from = *unsmob_pitch ($2); >Pitch to = *unsmob_pitch ($3); >SCM pitch = pitch_interval (from, to).smobbed_copy (); >$$ = MAKE_SYNTAX ("transpose-music", @$, pitch, $4); >} > > The MAKE_SYNTAX macro calls the Scheme function transpose-music, which > you'll find in scm/ly-syntax-constructors.scm: > > (define-ly-syntax-simple (transpose-music pitch music) > (make-music 'TransposedMusic > 'element (ly:music-transpose music pitch))) > > Regards, > Neil > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build failure
Op vrijdag 12-12-2008 om 06:18 uur [tijdzone -0800], schreef Graham Percival: > Problem building the netpbm package. gcc doesn't seem to > recognize the "-flax-vector-conversions" option, What happens if you remove that option? It would be nice if this option is only needed for gccs that are so new that they are too strict with vector conversions? We could then add some code like in gub/specs/librestrict.py > but doens't gub > download gcc itself to avoid specific-version compiler problems? Yes, but not for target/tools/*. Using a gub-compiled gcc there could be more robust, but would be a lot of work still, esp. bootstrapping this could be tricky. We still use all kinds of dependencies (glibc, zlib, whatnot from /usr to build tools/). Jan. -- Jan Nieuwenhuizen | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with GDP doc build on kainhofer.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 06:20:21 schrieb Carl D. Sorensen: > I've noticed that there's a problem with the doc build on kainhofer.com. Yes, the build has been failing for some days already. I'm doing a clean build now... Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRjD8TqjEwhXvPN0RAhvoAKDIDr7rYiK+0xLpGPUFQ7wmPdB88wCgpGRJ vHuaA4+7fuLiV7iEK4IkIQE= =eygV -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: spaces must be inserted around property commands?
Mark Polesky wrote Monday, December 15, 2008 8:02 AM NR 2.1.2 "Entering lyrics: Lyrics explained" states... Similarly, a period which follows an alphabetic sequence is included in the resulting string. As a consequence, spaces must be inserted around property commands: do not write \override Score.LyricText #'font-shape = #'italic but instead use \override Score . LyricText #'font-shape = #'italic Is this true? If so, I've been doing it the wrong way all along! This is not mentioned in 4.1.4 "Tweaking methods: \override command" which states... Yes, this is true, but only for overrides which are entered *directly* in \lyricmode. It is not necessary for other overrides or for overrides entered as part of a variable which is then applied in \lyricmode. The general syntax of this command is: \override Context.LayoutObject #'layout-property = #value This is the general syntax, but the rider above needs to be applied when entering overrides directly in \lyricmode. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: spaces must be inserted around property commands?
Well, it's only specific to Lyrics. Earlier in the section, it states: A word or syllable of lyrics begins with an alphabetic character, and ends with any space or digit… Any character that is not a digit or white space will be regarded as part of the syllable; one important consequence of this is that a word can end with }… Am 15.12.2008 um 09:02 schrieb Mark Polesky: NR 2.1.2 "Entering lyrics: Lyrics explained" states... Similarly, a period which follows an alphabetic sequence is included in the resulting string. As a consequence, spaces must be inserted around property commands: do not write \override Score.LyricText #'font-shape = #'italic but instead use \override Score . LyricText #'font-shape = #'italic Is this true? If so, I've been doing it the wrong way all along! This is not mentioned in 4.1.4 "Tweaking methods: \override command" which states... The general syntax of this command is: \override Context.LayoutObject #'layout-property = #value Somebody clear me up! Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
spaces must be inserted around property commands?
NR 2.1.2 "Entering lyrics: Lyrics explained" states... Similarly, a period which follows an alphabetic sequence is included in the resulting string. As a consequence, spaces must be inserted around property commands: do not write \override Score.LyricText #'font-shape = #'italic but instead use \override Score . LyricText #'font-shape = #'italic Is this true? If so, I've been doing it the wrong way all along! This is not mentioned in 4.1.4 "Tweaking methods: \override command" which states... The general syntax of this command is: \override Context.LayoutObject #'layout-property = #value Somebody clear me up! Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel