Re: Doc: extend description of glissandi (2844) (issue 6567059)
Reviewers: benko.pal, Message: On 2012/09/28 07:52:32, benko.pal wrote: what about an example like \afterGrace f1\glissando f'16 ? Done - thanks! Description: Doc: extend description of glissandi (2844) Add examples of - connecting notes across staves - connecting notes in chords - adding timing marks and expressions to long glissandi - making glissandi breakable (Based on original work by Tiresia GIUNO tires...@googlemail.com, a patch by Werner LEMBERG w...@gnu.org and advice from Benkő Pál benko@gmail.com) Please review this at http://codereview.appspot.com/6567059/ Affected files: M Documentation/notation/expressive.itely A Documentation/snippets/adding-timing-marks-to-long-glissandi.ly A Documentation/snippets/making-glissandi-breakable.ly A Documentation/snippets/new/adding-timing-marks-to-long-glissandi.ly A Documentation/snippets/new/making-glissandi-breakable.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)
Am 28.09.2012 17:40, schrieb d...@gnu.org: On 2012/09/28 15:06:38, janek wrote: On Fri, Sep 28, 2012 at 9:30 AM, mailto:d...@gnu.org wrote: I must be in a controversial mood today since I feel like upholding the idea. I had been thinking about it while fetching breakfast and eating and was about to reenter discussion when I found that I had already convinced you, so this is a bit awkward. lol :) Actually, my cousin gave another reason to change \omit to something else: in his opinion omit implies \once in meaning. Like, \omit StringNumber sounds like only one StringNumber won't be printed. Maybe. The only drawback is that one might want \yes/\no as a pairing for some different purpose. \no is really a rather important word. Yes, this is my concern, too. Well, at some point of time we need to crack it open, anyway. What about \delete ? Afaik it's not taken yet. Guile begs to differ: scheme@(guile-user) delete $1 = #procedure delete (_ _) On Fri, Sep 28, 2012 at 9:53 AM, Marc Hohl mailto:m...@hohlart.de wrote: Am 28.09.2012 09:30, schrieb d...@gnu.org: And things like \once\no Clef also work reasonably well. The proposed \single is more awkward, but \single\omit Clef is not that much better, so maybe \single should change. I don't feel quite happy with \single either; just a spontaneous idea: does \here work? \here\EasyNoteHeadsOn c8 d e I'm not sure ... hmm... not quite perfect. No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly also work. Having to choose between \single and \next, I would take \next. Regards, Marc http://codereview.appspot.com/6575048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A points to B. For proper
cache invalidation, if B.y changes, then A.x becomes invalid. This
means that A has to store a back-reference to B. Hence all pointers
have to be stored both ways (including inverting 1-N relations into
N-1 relations), and the both-way links have to be rewritten correctly
during line breaking.
You can assign a generational count to properties. If the generational
count of any dependency is higher than that of the dependent property,
it needs to get regenerated. As long as the dependencies don't get lost
(and we use arbitrary size integers, resetting for each session), this
should be pretty straightforward and not require backwards links. It
just requires double-checking your dependencies for change.
But since the dependencies are also properties that could be
invalidated, you'd have to recurse , so each property access would
potentially expand into an almost infinite number of get_property
calls.
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would suggest looking at is removing
{before,after}_line_breaking which breaks this model somewhat.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)
Marc Hohl m...@hohlart.de writes: Am 28.09.2012 17:40, schrieb d...@gnu.org: hmm... not quite perfect. No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly also work. Having to choose between \single and \next, I would take \next. After thinking this over, I realized what worries me about \next: next is a loop control command in a number of different languages like awk, perl, Python. It is also frequently used for linked list pointers. All of those common uses in computing are quite grammatically different in their usage. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Error tracking through the log files [was: Re: Compilation errorwith page-breaking-page-count3.ly]
Am 28.09.2012 12:24, schrieb Phil Holmes: - Original Message - From: Marc Hohl m...@hohlart.de To: lilypond-devel@gnu.org Sent: Friday, September 28, 2012 11:00 AM Subject: Re: Error tracking through the log files [was: Re: Compilation errorwith page-breaking-page-count3.ly] [...] A brute force method is to find the most recent log file ... Thanks for the tip! Just simple, but I have never thought about that myself. input/regression/instrument-name-volta.ly is the file that throws the error. It looks as if that's the error Keith spotted with left-bar-glyph-name ... I'll investigate. Regards, Marc -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 29.09.2012 07:11, schrieb k-ohara5...@oco.net: Looks good so far. In one pdf previewer (evince) at low resolution, the span bars look a little thicker than the regular bar lines. Maybe a rounding fault of the viewer, but it would be better if you know how to avoid it. If you zoom it, this will disappear, of course (I looked at bar lines with Adobe Reader at very high zoom levels), but I use evince, too and do not see these artifacts. What I spot is a thin white line between staff and span bar that disappears when zooming in, due to the span bars being a different object. I don't know how this can be avoided, though. http://codereview.appspot.com/6498052/diff/24001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6498052/diff/24001/scm/bar-line.scm#newcode953 scm/bar-line.scm:953: (ly:grob-property right-bar-line 'glyph-name))) Sometimes I get a crash that I traced back to a null -- that is, '() -- left-bar-glyph-name here. The piece in question has a repeat alternative that starts a on new line. Thanks! I found out that this is exactly the error that lets 'make test' fail – in input/regression/instrument-name-volta.ly we have exactly this situation. http://codereview.appspot.com/6498052/diff/24001/scm/bar-line.scm#newcode1029 scm/bar-line.scm:1029: ;; normal bar -annotation end of line start of line span bar You are right, this should be documented in the comment; will do in the next patch release. Regards, Marc http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)
Am 29.09.2012 11:01, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 28.09.2012 17:40, schrieb d...@gnu.org: hmm... not quite perfect. No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly also work. Having to choose between \single and \next, I would take \next. After thinking this over, I realized what worries me about \next: next is a loop control command in a number of different languages like awk, perl, Python. ... or think about TeX ;-) It is also frequently used for linked list pointers. All of those common uses in computing are quite grammatically different in their usage. But on the other hand, we talk about usability, and I am not quite sure that *every* user thinks Perl/Python/TeX when he or she writes Lilypond. And \next seems to be more self-explanatory than \single (at least to me, it is). Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 29 sept. 2012, at 10:59, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A points to B. For proper
cache invalidation, if B.y changes, then A.x becomes invalid. This
means that A has to store a back-reference to B. Hence all pointers
have to be stored both ways (including inverting 1-N relations into
N-1 relations), and the both-way links have to be rewritten correctly
during line breaking.
You can assign a generational count to properties. If the generational
count of any dependency is higher than that of the dependent property,
it needs to get regenerated. As long as the dependencies don't get lost
(and we use arbitrary size integers, resetting for each session), this
should be pretty straightforward and not require backwards links. It
just requires double-checking your dependencies for change.
But since the dependencies are also properties that could be
invalidated, you'd have to recurse , so each property access would
potentially expand into an almost infinite number of get_property
calls.
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would suggest looking at is removing
{before,after}_line_breaking which breaks this model somewhat.
I agree 110%. The only corollary I'd add, which comes from my recent work, is
that pure properties be re-evaluatable all the time (meaning that one should be
allowed to arbitrarily flush the cache) to store better and better
approximations of things. For example, if one wants the pure heights of
cross-staff beamed stems, the approximation one can get before line breaking is
worse than that which one can get after. After line breaking, one could
theoretically run beam quanting using the pure heights and actual X positions,
whereas before, these X positions don't exist. So, pure properties in LilyPond
become progressively more accurate as they go downstream, and once someone is
positive that all the information is there to evaluate the actual property,
get_property (or get_extent or whatever) is called.
I agree about (before,after)_line_breaking.
The single biggest offenders of this model, in my mind, are to be found in the
engraver stage. More specifically, I think that if we can get rid of the
Tweak_engraver such that every property is initialized via the Grob::Grob (SCM
basicprops) constructor (like in engraver.cc, for example) and not via
set_property at the engraver stage, everything else will be easier.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On Sat, Sep 29, 2012 at 11:35 AM, m...@mikesolomon.org
m...@mikesolomon.org wrote:
On 29 sept. 2012, at 10:59, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Wed, Sep 26, 2012 at 10:40 PM, David Kastrup d...@gnu.org wrote:
Han-Wen Nienhuys hanw...@gmail.com writes:
In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A points to B. For proper
cache invalidation, if B.y changes, then A.x becomes invalid. This
means that A has to store a back-reference to B. Hence all pointers
have to be stored both ways (including inverting 1-N relations into
N-1 relations), and the both-way links have to be rewritten correctly
during line breaking.
You can assign a generational count to properties. If the generational
count of any dependency is higher than that of the dependent property,
it needs to get regenerated. As long as the dependencies don't get lost
(and we use arbitrary size integers, resetting for each session), this
should be pretty straightforward and not require backwards links. It
just requires double-checking your dependencies for change.
But since the dependencies are also properties that could be
invalidated, you'd have to recurse , so each property access would
potentially expand into an almost infinite number of get_property
calls.
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would suggest looking at is removing
{before,after}_line_breaking which breaks this model somewhat.
I agree 110%. The only corollary I'd add, which comes from my recent work,
is that pure properties be re-evaluatable all the time (meaning that one
should be allowed to arbitrarily flush the cache) to store better and better
approximations of things. For example, if one wants the pure heights of
cross-staff beamed stems, the approximation one can get before line breaking
is worse than that which one can get after. After line breaking, one could
theoretically run beam quanting using the pure heights and actual X
positions, whereas before, these X positions don't exist. So, pure
properties in LilyPond become progressively more accurate as they go
downstream, and once someone is positive that all the information is there to
evaluate the actual property, get_property (or get_extent or whatever) is
called.
pure-properties are misnamed. If they are always are recomputed, they
should be called methods or even pure functions and not properties.
Of course, if there is a cache, you have to think about a simple and
rigorous scheme to know when the cache can be thrown away; the real
problem is about caching data based on other grobs, since invalidation
implies a lot more of pointer juggling
I agree about (before,after)_line_breaking.
The single biggest offenders of this model, in my mind, are to be found in
the engraver stage. More specifically, I think that if we can get rid of the
Tweak_engraver such that every property is initialized via the Grob::Grob
(SCM basicprops) constructor (like in engraver.cc, for example) and not via
set_property at the engraver stage, everything else will be easier.
You could make a separate routine that prepends sym/value pairs onto
the immutable list; I'm not certain that this would intrinsically buy
you anything, though.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)
Reviewers: janek,
Message:
On 2012/09/28 06:22:40, janek wrote:
The description looks really nice, but unfortunately i think i don't
grasp the
consequences of this change. Could you give some before/after input
examples?
Embarrassingly, not really. The point of this change is to move forward
in removing the special-casing of various *_IDENTIFIER token types. The
target is to arrive at only a single SCM_IDENTIFIER type. Once that is
achieved, it is no longer necessary to evaluate identifiers in the
lexer, removing a source for awkward timing problems like
xxx = { c4 c4 c4 c4 }
\xxx
But as long as there remains more than one category of identifier, this
can't be done. In a similar vein, it would be nice to be able to use a
scheme function call anywhere you use a markup: if we arrive there,
markup and markup list commands become mostly uninteresting for defining
commands intended to be top-level markups, usually called with \markup
\my-command ... In that case, you can just use \my-command directly
without leading \markup and define it as a scheme function.
At the current point of time, this does not work at most places where
markups are allowed: you can use an identifier there (which basically is
an SCM_IDENTIFIER now) but you can't use a Scheme function as their
argument list parsing is a huge source of parser conflicts. Once
Scheme/music functions are called somewhat transparently, they can be
used pretty much everywhere, also in and as markup.
This patch is part of preparing for that change, but it does not provide
significant improvements in usability by itself. The main point is to
cut down on special cases provided by the lexer without _losing_
functionality. But the actual awards for that will only come after a
number of similar patches.
Does this have anything to do with what you proposed in [GLISS] turn
xxx.yyy
into (xxx yyy)?
Not really. It likely helps a bit. It also begs the question whether
the . syntax should work just for building string lists, or whether it
should be open to building arbitrary markup lists (of which string lists
are a special case). But that decision does not really require advance
consideration: it will more or less be hardwired into the parser actions
without requiring to be anchored in the grammar itself.
Description:
Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER
Those and their LYRIC variants are no longer generated by the lexer.
Instead, SCM_IDENTIFIER takes over their function. One advantage is
that standard Scheme strings and lists of strings (including the empty
list!) are no longer receiving special syntactic status when used as
identifier.
Another is that markups and markup lists can now also be produced and
interpreted by define-scheme-function. The ultimate goal, of course,
is to have try_special_identifiers return nothing except
SCM_IDENTIFIER. If that is the case, $... (immediate Scheme) does
no longer need to get evaluated in the lexer and can be retitled into
active Scheme. That would get rid of the Scheme timing problems and
make basically _everything_ doable by define-scheme-function.
This issue is a two-patch issue with the first patch being named:
parser.yy: remove embedded_scm as one production for assignment
This saved a few lines in the grammar for the price of clarity.
Please review this at http://codereview.appspot.com/6561053/
Affected files:
M lily/parser.yy
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)
On Sat, Sep 29, 2012 at 3:10 PM, d...@gnu.org wrote: Embarrassingly, not really. The point of this change is to move forward in removing the special-casing of various *_IDENTIFIER token types. The target is to arrive at only a single SCM_IDENTIFIER type. Once that is achieved, it is no longer necessary to evaluate identifiers in the lexer, removing a source for awkward timing problems like So the idea is to make the grammar simpler (use less different types) and have things happen on higher level? Sounds reasonable, i guess... In a similar vein, it would be nice to be able to use a scheme function call anywhere you use a markup: if we arrive there, markup and markup list commands become mostly uninteresting for defining commands intended to be top-level markups, usually called with \markup \my-command ... In that case, you can just use \my-command directly without leading \markup and define it as a scheme function. oh, that'd be nice. Thanks for explanation! LTGM. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)
On 2012/09/29 13:37:28, janek wrote: On Sat, Sep 29, 2012 at 3:10 PM, mailto:d...@gnu.org wrote: Embarrassingly, not really. The point of this change is to move forward in removing the special-casing of various *_IDENTIFIER token types. The target is to arrive at only a single SCM_IDENTIFIER type. Once that is achieved, it is no longer necessary to evaluate identifiers in the lexer, removing a source for awkward timing problems like So the idea is to make the grammar simpler (use less different types) and have things happen on higher level? Sounds reasonable, i guess... Actually, it is not really simplifying the grammar. At the current point of time, the lexer has to make decisions about the type of identifiers (and functions) at a point of time where those decisions are actually premature. As a result of those decisions, different tokens are generated for identifiers and functions. I am moving towards generating only one kind of token. The same kind of decisions as before still have to be made, and since the lexer no longer makes them, the decisions are instead taken in the actions of the parser. The results of those decisions are only apparent in the parser rules when those decisions lead to synthetic tokens (similar to the previous real ones) being generated in the parser actions. So the distinctions that were previously made are still there, they are just done at a later point of time, and result in different actions through different mechanisms. Of course, once the lexer only delivers identifiers in a single way, there are some simplifications possible, but the overall architecture is still a worse fit to the Bison/Flex pairing of parser/scanner generator than the state from two years ago, as that pairing is based on lookahead principles with rigid tokenization rules that are not really a perfect fit for LilyPond's sort of dynamic typing. So overall, the parser is not getting simpler. I can straighten out some stuff when passing certain milestones, boiling down complexity again, but since I am moving functionality from where it is intended to be from the view of the basic Bison/Flex architecture, the best it can be is a consistent subsystem not looking more complex than the task it is taking over. http://codereview.appspot.com/6561053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)
Marc Hohl m...@hohlart.de writes: Am 29.09.2012 11:01, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 28.09.2012 17:40, schrieb d...@gnu.org: hmm... not quite perfect. No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly also work. Having to choose between \single and \next, I would take \next. After thinking this over, I realized what worries me about \next: next is a loop control command in a number of different languages like awk, perl, Python. ... or think about TeX ;-) It is also frequently used for linked list pointers. All of those common uses in computing are quite grammatically different in their usage. But on the other hand, we talk about usability, and I am not quite sure that *every* user thinks Perl/Python/TeX when he or she writes Lilypond. And \next seems to be more self-explanatory than \single (at least to me, it is). I am not convinced. Unless I see either a new proposal that I feel I can get behind myself, or more prominent public support for one of the numerous existing proposals including \next, I am going to stick with \single. Since by far the easiest time to press a change is before a first version is installed, people should speak up now if they feel that c' \next \easyHeadsOn e' g' is significantly better than c' \single \easyHeadsOn e' g' for changing just the head on e', or if they think they have another good name. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2868 in lilypond: Patch: Various clean-ups in stems and beams.
Am 29.09.2012 17:01, schrieb lilyp...@googlecode.com: Comment #1 on issue 2868 by mts...@gmail.com: Patch: Various clean-ups in stems and beams. http://code.google.com/p/lilypond/issues/detail?id=2868#c1 Various clean-ups in stems and beams. *) Eliminates code dups for Kievan work. *) Transfers functions that are called a lot to C++ to speed things up. *) Eliminates unused variables. No regtest changes. http://codereview.appspot.com/6584045 Not tested, but according to modularity: LGTM. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Eliminate MARKUP_IDENTIFIER and MARKUPLIST_IDENTIFIER (issue 6561053)
On Sat, Sep 29, 2012 at 4:30 PM, d...@gnu.org wrote: Actually, it is not really simplifying the grammar. At the current point of time, the lexer has to make decisions about the type of identifiers (and functions) at a point of time where those decisions are actually premature. As a result of those decisions, different tokens are generated for identifiers and functions. I am moving towards generating only one kind of token. The same kind of decisions as before still have to be made, and since the lexer no longer makes them, the decisions are instead taken in the actions of the parser. The results of those decisions are only apparent in the parser rules when those decisions lead to synthetic tokens (similar to the previous real ones) being generated in the parser actions. ok. That's what i meant when i said have things happen on higher level (i expect that it's not a technically correct statement, of course :) ) thanks for explanations! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
Han-Wen Nienhuys hanwenn at gmail.com writes:
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would suggest looking at is removing
{before,after}_line_breaking which breaks this model somewhat.
Should that apply to properties that describe positioning of objects?
Often LilyPond needs tentative positions for objects.
For example, when setting note-spacing constraints, the separation of staves is
taken to be large enough that items do not interfere between staves. The
widths
of text items are ignored, based on their extra-spacing-* properties. Rests
avoiding beams have a tentative position. Some repeated accidentals on tied
notes exist, but may disappear.
The note-spacing code uses skylines, which depend on positions for the enclosed
objects, and wants tentative positions appropriate to this phase of layout.
One way to organize these phases of layout is by registering callbacks to be
performed (or maybe in future reset) between phases:
before/after-line-breaking.
The alternative organizational method in the code today is religious
observance:
for it is written, On the day of Note-Spacing, thou shalt avert thine eyes from
the stems, for stems keep the company of beams, and beams are impure, thus to
seek knowledge of the tip of a stem would be impure.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntactical question [was: Re: Call for help with bar lines]
David == David Kastrup d...@gnu.org writes: \bar inserts an empty stencil, so the padding around the (invisible) bar line is preserved. David Yes, I understood that. But what do we need that for? For the Renaissance music I transcribe, the composers weren't thinking in bar lines, so it's both unhelpful and unaesthetic to have, for instance, a run of quarter notes interrupted by the extra space where the non-existent barlines would be if they existed. The way I finally figured out how to do this with the old bar line interface was that instead of saying that the default bar type was either empty or , I leave the default bar type, and make it transparent, and then remove the padding. But I never figured out how to remove the padding from an empty or null bar line. I hope that the new interface both makes more sense than the old one, and still allows me to set barless music without ugly gaps where the bar lines aren't. -- Laura (mailto:lcon...@laymusic.org, twitter: @serpentplayer) (617) 661-8097 233 Broadway, Cambridge, MA 02139 http://www.laymusic.org/ http://www.serpentpublications.org Tristo e' quel discepolo che non avanza il suo Maestro. (It's a bad student who doesn't advance past his Master.) Leonardo da Vinci ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \no functions for transparent and void glyphs (issue 6575048)
Too bad that \delete is taken... Maybe using \no is the right choice, although i'd prefer to make this decision after GLISS decides that we don't need \no for something else. As for \single vs. \next, i don't have a strong opinion. Janek http://codereview.appspot.com/6575048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntactical question [was: Re: Call for help with bar lines]
Am 29.09.2012 18:39, schrieb Laura Conrad: David == David Kastrup d...@gnu.org writes: \bar inserts an empty stencil, so the padding around the (invisible) bar line is preserved. David Yes, I understood that. But what do we need that for? For the Renaissance music I transcribe, the composers weren't thinking in bar lines, so it's both unhelpful and unaesthetic to have, for instance, a run of quarter notes interrupted by the extra space where the non-existent barlines would be if they existed. The way I finally figured out how to do this with the old bar line interface was that instead of saying that the default bar type was either empty or , I leave the default bar type, and make it transparent, and then remove the padding. But I never figured out how to remove the padding from an empty or null bar line. I hope that the new interface both makes more sense than the old one, and still allows me to set barless music without ugly gaps where the bar lines aren't. Hmmm - with the new interface, nonexistent bar lines are not supported (yet), but I think that \bar #f or \defaultBarType = ##f *could* be made to work. On the other hand, why don't you just remove the Bar_engraver when you don't need it at all? I had not typeset music without bars so far, but this seems to me to be the easiest way to handle such situations. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)
On 12-09-29 09:47 AM, David Kastrup wrote: I am not convinced. Unless I see either a new proposal that I feel I can get behind myself, or more prominent public support for one of the numerous existing proposals including \next, I am going to stick with \single. Since by far the easiest time to press a change is before a first version is installed, people should speak up now if they feel that c' \next \easyHeadsOn e' g' is significantly better than c' \single \easyHeadsOn e' g' for changing just the head on e', or if they think they have another good name. From a relatively uninformed point of view, \single seems to be directly and tightly coupled to the object following it, and only to that one object, only for the life of that object. \next doesn't seem quite so definite and restricted, for some reason, perhaps because there could be an implication that it applies to the next instance of the object either before or after the \next token. It's early and the caffeine level is rather low in the brain stem, but \single is the more clear term for me. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs (issue 6575048)
Am 29.09.2012 18:54, schrieb Colin Campbell: On 12-09-29 09:47 AM, David Kastrup wrote: I am not convinced. Unless I see either a new proposal that I feel I can get behind myself, or more prominent public support for one of the numerous existing proposals including \next, I am going to stick with \single. Since by far the easiest time to press a change is before a first version is installed, people should speak up now if they feel that c' \next \easyHeadsOn e' g' is significantly better than c' \single \easyHeadsOn e' g' for changing just the head on e', or if they think they have another good name. From a relatively uninformed point of view, \single seems to be directly and tightly coupled to the object following it, and only to that one object, only for the life of that object. \next doesn't seem quite so definite and restricted, for some reason, perhaps because there could be an implication that it applies to the next instance of the object either before or after the \next token. You are a native speaker, so I would trust you more than my feelings. \single would be ok for me then. It's early and the caffeine level is rather low in the brain stem, but \single is the more clear term for me. Well, here it is 19:00 and the caffeine level is rather low already ;-) Regards, Marc Cheers, Colin ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] facilitate changes of the (default-) drumStyleTable
Am 27.09.2012 00:32, schrieb Thomas Morley: 2012/9/26 Marc Hohl m...@hohlart.de: I like the idea of giving the user the ability to change only parts of the list without having to rewrite the full list; I think that this concept could be of use in other parts of lilypond as well, Hi Marc, further testing showed a major-problem: Using `hashq-set!' here is too much force brute and will result in an unintended change of lily-internals. I.e. compiling all .ly files in a folder with lilypond *.ly will show the changes in _all_ files, even if \changeDrumStyleTable is _not_ used in a file. Oops. That's interesting (and not what we want, of course). \set DrumStaff.drumStyleTable = #(alist-hash-table my-drums) is not that invasive. Nevertheless, IMHO the question about an easy, less intricate method how to change a single value in the predefined drumStyleTable stands as a valid request. +1 I think you should raise an issue for that. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntactical question [was: Re: Call for help with bar lines]
Marc == Marc Hohl m...@hohlart.de writes: I hope that the new interface both makes more sense than the old one, and still allows me to set barless music without ugly gaps where the bar lines aren't. Marc Hmmm - with the new interface, nonexistent bar lines are not Marc supported (yet), but I think that \bar #f or \defaultBarType = ##f Marc *could* be made to work. Marc On the other hand, why don't you just remove the Bar_engraver Marc when you don't need it at all? Marc I had not typeset music without bars so far, but this seems to me Marc to be the easiest way to handle such situations. I would have thought so before I did it, too. I think if we were typesetting for 16th century musicians, it would be. However, I get complaints when a line break occurs within a bar. The facsimiles do this all the time (even in the 17th and eighteenth centuries, when they were printing bar lines almost as often as we do), but when I do it, the players complain. So if you have some way to say remove the Bar Engraver, but have the line breaker still keep some kind of count of where in the time signature it is, I'll try it. I don't know whether the relationship between the Bar Engraver and the line breaker would allow this at all. -- Laura (mailto:lcon...@laymusic.org, twitter: @serpentplayer) (617) 661-8097 233 Broadway, Cambridge, MA 02139 http://www.laymusic.org/ http://www.serpentpublications.org A traveling horn virtuoso, Barry Tuckwell, was once asked about the problem of how to practice while traveling and living in hotels. He replied that he just turned up the TV and practiced because no one minded the TV being loud! quoted by RC Walsh on recor...@yahoogroups.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
Hmm.
My answer to how would we place the glyph at the correct vertical
position, above the barline? is: i suppose that we're going to create
a \tickBreathe command; if so, i guess that defining it in this manner
tickBreathe = {
\override BreathingSign #'outside-staff-priority = something
\override BreathingSign #'staff-padding = something
\override BreathingSign #'stencil = #(...)
\breathe
}
should result in tick breathe appearing where we want it (i.e. i
hope that outside-staff-priority will result in placing this object
outside of the staff, and staff-padding will determine how far would
that be).
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 29 sept. 2012, at 18:34, Keith OHara k-ohara5...@oco.net wrote:
Han-Wen Nienhuys hanwenn at gmail.com writes:
I think it is a much clearer abstraction to decide that each property
can only be evaluated once, and that everything should be driven by
callbacks. In fact, one thing I would suggest looking at is removing
{before,after}_line_breaking which breaks this model somewhat.
Should that apply to properties that describe positioning of objects?
Often LilyPond needs tentative positions for objects.
For example, when setting note-spacing constraints, the separation of staves
is
taken to be large enough that items do not interfere between staves. The
widths
of text items are ignored, based on their extra-spacing-* properties. Rests
avoiding beams have a tentative position. Some repeated accidentals on tied
notes exist, but may disappear.
The note-spacing code uses skylines, which depend on positions for the
enclosed
objects, and wants tentative positions appropriate to this phase of layout.
The way you're using tentative is almost exactly how pure properties are used
in LilyPond. The only example that doesn't work that way is the accidental
one, which I believe is a bug in LilyPond - I want to say that the space is
reserved even after the accidental is killed off (I'd have to verify that).
One way to organize these phases of layout is by registering callbacks to be
performed (or maybe in future reset) between phases:
before/after-line-breaking.
The alternative organizational method in the code today is religious
observance:
for it is written, On the day of Note-Spacing, thou shalt avert thine eyes
from
the stems, for stems keep the company of beams, and beams are impure, thus to
seek knowledge of the tip of a stem would be impure.
I am a fan of the second over the first. I think all property look-ups should
be pure until one is absolutely certain that the property won't change, at
which point the unpure value should be cached and returned for both pure and
unpure queries (impure sounds too religious, thus unpure). The pure properties
need not always return the same value - they can get closer and closer to the
unpure as more and more information gets determined. Cached pure values for
Items can be flushed at any point if someone wants a potentially better
approximation, at which point the calculation would be redone and the cache
restocked.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
- Original Message -
From: Janek Warchoł janek.lilyp...@gmail.com
To: Phil Holmes m...@philholmes.net
Cc: James pkx1...@gmail.com; lilypond-devel@gnu.org; d...@gnu.org;
lemzw...@googlemail.com; re...@codereview-hr.appspotmail.com;
philehol...@googlemail.com
Sent: Saturday, September 29, 2012 6:25 PM
Subject: Re: Adds tick mark to scripts (issue 6568055)
Hmm.
My answer to how would we place the glyph at the correct vertical
position, above the barline? is: i suppose that we're going to create
a \tickBreathe command; if so, i guess that defining it in this manner
tickBreathe = {
\override BreathingSign #'outside-staff-priority = something
\override BreathingSign #'staff-padding = something
\override BreathingSign #'stencil = #(...)
\breathe
}
should result in tick breathe appearing where we want it (i.e. i
hope that outside-staff-priority will result in placing this object
outside of the staff, and staff-padding will determine how far would
that be).
cheers,
Janek
Well, in the current version of the NR, the guidance for changing the breath
sign is:
\override BreathingSign #'text = \markup {\musicglyph
#scripts.caesura.straight}
No padding or anything else there. This is what I thought it best to
replicate. I am OK with providing documentation that shows how to move the
tick sign away from the top of the stave. I'm just not OK with its default
being halfway across the staff line. That's plain ugly. I've designed the
glyph to be used as a tick for a breath mark. No-one has cried out for a
similar sign for any other purpose. Let's keep the baseline in the obvious
place - at the bottom of the glyph. If you want one elsewhere, please add
another glyph.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: The way you're using tentative is almost exactly how pure properties are used in LilyPond. Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking. If there are distinct properties to describe the position at different stages, then each property can be evaluated just once (as HanWen suggested, and as Mike agreed 100%). I think all property look-ups should be pure until one is absolutely certain that the property won't change, at which point the unpure value should be cached and returned for both pure and unpure queries (impure sounds too religious, thus unpure). The pure properties need not always return the same value - they can get closer and closer to the unpure as more and more information gets determined. This is the opposite approach, where some properties are not permanent at all. The word 'tentative' is a better label than 'pure', because pure functions would always return the same value given the same arguments. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 29 sept. 2012, at 19:53, Keith OHara k-ohara5...@oco.net wrote: On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: The way you're using tentative is almost exactly how pure properties are used in LilyPond. Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking. If there are distinct properties to describe the position at different stages, then each property can be evaluated just once (as HanWen suggested, and as Mike agreed 100%). I think all property look-ups should be pure until one is absolutely certain that the property won't change, at which point the unpure value should be cached and returned for both pure and unpure queries (impure sounds too religious, thus unpure). The pure properties need not always return the same value - they can get closer and closer to the unpure as more and more information gets determined. This is the opposite approach, where some properties are not permanent at all. The word 'tentative' is a better label than 'pure', because pure functions would always return the same value given the same arguments. True dat. Someone wanna do a perl one-line replace subbing in tenative for pure and post the patch? :-) Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntactical question [was: Re: Call for help with bar lines]
Am 29.09.2012 19:05, schrieb Laura Conrad: Marc == Marc Hohl m...@hohlart.de writes: I hope that the new interface both makes more sense than the old one, and still allows me to set barless music without ugly gaps where the bar lines aren't. Marc Hmmm - with the new interface, nonexistent bar lines are not Marc supported (yet), but I think that \bar #f or \defaultBarType = ##f Marc *could* be made to work. Marc On the other hand, why don't you just remove the Bar_engraver Marc when you don't need it at all? Marc I had not typeset music without bars so far, but this seems to me Marc to be the easiest way to handle such situations. I would have thought so before I did it, too. I think if we were typesetting for 16th century musicians, it would be. However, I get complaints when a line break occurs within a bar. The facsimiles do this all the time (even in the 17th and eighteenth centuries, when they were printing bar lines almost as often as we do), but when I do it, the players complain. So if you have some way to say remove the Bar Engraver, but have the line breaker still keep some kind of count of where in the time signature it is, I'll try it. I don't know whether the relationship between the Bar Engraver and the line breaker would allow this at all. Just an idea: have you tried \override Staff.BarLine #'stencil = ##f IIUC, then 'no stencil' leads to 'no padding'. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)
David Kastrup wrote Saturday, September 29, 2012 4:47 PM Marc Hohl m...@hohlart.de writes: Am 29.09.2012 11:01, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Am 28.09.2012 17:40, schrieb d...@gnu.org: hmm... not quite perfect. No other idea, though... \here misses the relation to the next item (not that \single is much better). \directly was nicer in that regard. \next would possibly also work. Having to choose between \single and \next, I would take \next. After thinking this over, I realized what worries me about \next: next is a loop control command in a number of different languages like awk, perl, Python. ... or think about TeX ;-) It is also frequently used for linked list pointers. All of those common uses in computing are quite grammatically different in their usage. But on the other hand, we talk about usability, and I am not quite sure that *every* user thinks Perl/Python/TeX when he or she writes Lilypond. And \next seems to be more self-explanatory than \single (at least to me, it is). I am not convinced. Unless I see either a new proposal that I feel I can get behind myself, or more prominent public support for one of the numerous existing proposals including \next, I am going to stick with \single. Since by far the easiest time to press a change is before a first version is installed, people should speak up now if they feel that c' \next \easyHeadsOn e' g' is significantly better than c' \single \easyHeadsOn e' g' for changing just the head on e', or if they think they have another good name. I prefer \single to \next. \justOne \onlyOne ? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)
Trevor Daniels t.dani...@treda.co.uk writes: David Kastrup wrote Saturday, September 29, 2012 4:47 PM Since by far the easiest time to press a change is before a first version is installed, people should speak up now if they feel that c' \next \easyHeadsOn e' g' is significantly better than c' \single \easyHeadsOn e' g' for changing just the head on e', or if they think they have another good name. I prefer \single to \next. \justOne \onlyOne ? It is, in a way, a complement to \once, so I would want to avoid multiple-word approaches leading to CamelCase. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
On 2012/09/29 09:14:08, marc wrote: Am 29.09.2012 07:11, schrieb k-ohara5...@oco.net: In one pdf previewer (evince) at low resolution, the span bars look a little thicker than the regular bar lines. Disregard. The slight mis-rendering on screen was there before your patch as well. http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Now looking at the log files, I do get undead errors for our regression test 'bar-line-define-bar-glyph.ly' but not from any other files that I tried. (I don't know why the scripts from `make check` did not flag it.) There are four messages, but the particular undead objects vary from run to run. http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)
I prefer \single to \next. \justOne \onlyOne ? It is, in a way, a complement to \once, so I would want to avoid multiple-word approaches leading to CamelCase. Had someone already suggested \here? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Regularize lyrics lexer mode (issue 6594047)
LGTM. http://codereview.appspot.com/6594047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB commands not running
On Mon, Sep 24, 2012 at 10:43:25AM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca Either lilypond.make has changed (only one change in the past two years: https://github.com/gperciva/gub/commit/dd2f4077f5f818a6f689b0f4a795bacb92dcb8ae which doesn't seem like it could cause this, but also check that Have another careful look at that change. We have: #FIXME: we cannot use python from tools, because of the gub/logging.py # name clash. Todo: rename gub/logging.py -- triggers full # rebuild. Not using tools means: we depend on /usr/bin/makeinfo #SET_TOOLS_PATH=PATH=$(CWD)/target/tools/root/usr/bin:$(PATH) and then the SET_TOOLS_PATH variable is used later in the make. But look - it's commented out in the change. My guess is that this is the problem. Do you agree? Hmm, that sounds distinctly plausible. I suggest uncommenting it out and see if that fixes it? I've had a look through the makefiles and logs and couldn't find where the missing commands were supposed to be run, but I remain suspicious about the above. Well, let's take the case of make -f lilypond.make test. I've extracted the relevant parts of lilypond.make below (but don't feel bad; these parts are somewhat disguised by the surrounding text) test: dist-check test-output test-export test-export: ... $(MAKE) cached-test-export cached-test-export: ... $(MAKE) $(subst cached,unlocked,$@) ... (in this case, it does unlocked-test-export) unlocked-test-export: ... $(SET_TOOLS_PATH) \ $(PYTHON) test-lily/rsync-test.py \ --version-file=$(NATIVE_LILY_BUILD)/out/VERSION \ --output-distance=$(NATIVE_LILY_SRC)/$(BUILDSCRIPTS)/output-distance.py \ --test-dir=uploads/webtest no, I don't claim to understand what all those steps are doing. But it certainly looks like it'll have problems if $(SET_TOOLS_PATH) is not set correctly. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
