Re: Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)
On 2013/08/15 05:51:36, mike7 wrote:
On 15 août 2013, at 08:35, mailto:k-ohara5...@oco.net wrote:
Could you mark the relevant object as 'cross-staff' when the
cross-staff
item is added to it 'support', rather than search through its
support
later?
see above: this would mean that ottava brackets are marked as
cross-staff, which
we don't want.
Well, the thing we did not want was to have ottava brackets ignored for
staff-spacing.
The bracket overlaps the next staff the same way, whether you call it
'cross-staff' or
function_to_deal_with_one_special_case()
chUp = \change Staff = upper
chDn = \change Staff = lower
\new PianoStaff \new Staff = lower { s1 }
\new Staff = upper
{ \relative c' { \ottava #1 c'8 \chDn c \chUp c \chDn c \chUp f''2 } }
https://codereview.appspot.com/12951044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)
If the spanners have never successfully responded to the position of cross-staff support, we should just skip cross-staff items from the support. This is a great idea, but I'm not sure the best way to implement it. It's not possible at the engraver stage when the grobs are originally put in the list. And it's kinda kludgy to check for it every time we extract the grob set. https://codereview.appspot.com/12951044/diff/5001/lily/side-position-interface.cc File lily/side-position-interface.cc (right): https://codereview.appspot.com/12951044/diff/5001/lily/side-position-interface.cc#newcode305 lily/side-position-interface.cc:305: aligns_to_cross_staff |= cross_staff; You already check all the 'support' for cross-staffitude every time you unpack the list. I am beginning to doubt that the special case for aligns_to_cross_staff has any effect. If the code has not succeeded in considering cross-staff support, skip them up above if (!me-cross_staff || e- cross-staff ) continue; https://codereview.appspot.com/12951044/diff/5001/lily/side-position-interface.cc#newcode373 lily/side-position-interface.cc:373: dim.set_minimum_height (dim.max_height ()); Really? If a spanner lies over one cross-staff grob, draw a box around *all* the grobs in the support, whether cross-staff or not ? https://codereview.appspot.com/12951044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)
On 15 août 2013, at 09:03, k-ohara5...@oco.net wrote:
On 2013/08/15 05:51:36, mike7 wrote:
On 15 août 2013, at 08:35, mailto:k-ohara5...@oco.net wrote:
Could you mark the relevant object as 'cross-staff' when the
cross-staff
item is added to it 'support', rather than search through its
support
later?
see above: this would mean that ottava brackets are marked as
cross-staff, which
we don't want.
Well, the thing we did not want was to have ottava brackets ignored for
staff-spacing.
The bracket overlaps the next staff the same way, whether you call it
'cross-staff' or
function_to_deal_with_one_special_case()
chUp = \change Staff = upper
chDn = \change Staff = lower
\new PianoStaff \new Staff = lower { s1 }
\new Staff = upper
{ \relative c' { \ottava #1 c'8 \chDn c \chUp c \chDn c \chUp f''2 } }
Ok, so, the bracket is ignoring the cross-staff stems that support it.
Do you know where in side-position-interface.cc this ignoring happens?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)
On 2013/08/15 06:12:15, mike7 wrote: On 15 août 2013, at 09:03, mailto:k-ohara5...@oco.net wrote: Well, the thing we did not want was to have ottava brackets ignored for staff-spacing. The bracket overlaps the next staff the same way, Ok, so, the bracket is ignoring the cross-staff stems that support it. Do you know where in side-position-interface.cc this ignoring happens? If you mean the stems in the upper staff, the ottava-bracket engraver ignores them. I think we want the ottava bracket to ignore them. https://codereview.appspot.com/12951044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove 'thickness from LedgerLineSpanner interface. (issue 12945044)
Reviewers: Trevor Daniels,
Message:
On 2013/08/14 21:35:16, Trevor Daniels wrote:
Should this not be @ref{...}?
No. @rinternals{...}. See
http://lilypond.org/doc/v2.17/Documentation/contributor/syntax-survey#cross-references
- Mark
Description:
Remove 'thickness from LedgerLineSpanner interface.
Please review this at https://codereview.appspot.com/12945044/
Affected files:
M lily/ledger-line-spanner.cc
Index: lily/ledger-line-spanner.cc
diff --git a/lily/ledger-line-spanner.cc b/lily/ledger-line-spanner.cc
index
d36f908b2c81d78aae69d3b1b8136500350b961d..ed234712d35ad6735987bf00cc54719d98bdd02c
100644
--- a/lily/ledger-line-spanner.cc
+++ b/lily/ledger-line-spanner.cc
@@ -326,14 +326,15 @@ Ledger_line_spanner::print (SCM smob)
ADD_INTERFACE (Ledger_line_spanner,
This spanner draws the ledger lines of a staff. This is a
separate grob because it has to process all potential
-collisions between all note heads.,
+collisions between all note heads. The thickness of
ledger
+lines is controlled by the @code{ledger-line-thickness}
+property of the @rinternals{StaffSymbol} grob.,
/* properties */
gap
length-fraction
minimum-length-fraction
note-heads
- thickness
);
struct Ledgered_interface
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove 'thickness from LedgerLineSpanner interface. (issue 12945044)
On 2013/08/15 06:59:58, Mark Polesky wrote:
On 2013/08/14 21:35:16, Trevor Daniels wrote:
Should this not be @ref{...}?
No. @rinternals{...}. See
http://lilypond.org/doc/v2.17/Documentation/contributor/syntax-survey#cross-references
- Mark
That documentation states as first entry:
@ref{…} — link within current manual.
https://codereview.appspot.com/12945044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tests for either cross-staff or supported by cross-staff stems to skip elements in pure side-positi… (issue 12921043)
https://codereview.appspot.com/12921043/diff/3001/lily/side-position-interface.cc File lily/side-position-interface.cc (right): https://codereview.appspot.com/12921043/diff/3001/lily/side-position-interface.cc#newcode278 lily/side-position-interface.cc:278: // do not use cross_staff elements as supports of spanners Well, I meant to suggest do not use cross-staff elements as supports of objects that are not cross-staff whether said elements are spanners or not. The reason is simply order of decisions in layout: before staff-spacing we want to lay out everything possible (everything that is not cross-staff) and then place the cross-staff objects. It would be nice in the future to have pedal brackets, for example, move away from cross-staff beams and slurs, but doing so would make their position depend on staff-layout, so probably they would need to inherit a cross-staff flag in those cases. http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1776 https://codereview.appspot.com/12921043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)
On 2013/08/15 06:12:28, Keith wrote: If the code has not succeeded in considering cross-staff support, skip them up above if (!me-cross_staff || e- cross-staff ) continue; I meant this to be an .AND. if (!me-cross_staff e-cross-staff ) continue; https://codereview.appspot.com/12951044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tests for either cross-staff or supported by cross-staff stems to skip elements in pure side-positi… (issue 12921043)
On 15 août 2013, at 10:29, k-ohara5...@oco.net wrote: https://codereview.appspot.com/12921043/diff/3001/lily/side-position-interface.cc File lily/side-position-interface.cc (right): https://codereview.appspot.com/12921043/diff/3001/lily/side-position-interface.cc#newcode278 lily/side-position-interface.cc:278: // do not use cross_staff elements as supports of spanners Well, I meant to suggest do not use cross-staff elements as supports of objects that are not cross-staff whether said elements are spanners or not. Good call - patch up w/ this. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
Hi David and Janek,
On 14/08/13 14:30, d...@gnu.org wrote:
On 2013/08/14 12:18:12, janek wrote:
2013/8/14 d...@gnu.org:
would there be a technical problem to have /both/ -! and -' as
shorthands for staccato?
Technical? Not really except that we'd have to make a choice of
convert-ly rule. But I don't think we help anybody by providing
two shorthands for one particular articulation.
1+
Anybody else with an opinion regarding -! or -' (and of course the
corresponding _! ^! _' ^' too) as the shorthand for staccatissimo,
replacing the previous -| (which would not work due to technical
reasons).
1+ for -'
(' is visually mnemonic for notation staccatissimo,
also
' is ergonomic on my keyboard -
no Shift key involved, both keys on right-hand side of
main keyboard)
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
On 2013/08/15 09:22:12, Ian Hulin wrote:
Hi David and Janek,
On 14/08/13 14:30, mailto:d...@gnu.org wrote:
On 2013/08/14 12:18:12, janek wrote:
2013/8/14 d...@gnu.org:
would there be a technical problem to have /both/ -! and -' as
shorthands for staccato?
Technical? Not really except that we'd have to make a choice of
convert-ly rule. But I don't think we help anybody by providing
two shorthands for one particular articulation.
1+
Anybody else with an opinion regarding -! or -' (and of course the
corresponding _! ^! _' ^' too) as the shorthand for staccatissimo,
replacing the previous -| (which would not work due to technical
reasons).
1+ for -'
(' is visually mnemonic for notation staccatissimo,
also
' is ergonomic on my keyboard -
no Shift key involved, both keys on right-hand side of
main keyboard)
Cheers,
Ian
Sigh. What do people think countdowns are for? This was a merge commit
with three different topics and a single application of convert-ly.
https://codereview.appspot.com/12432043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Remove 'thickness from LedgerLineSpanner interface. (issue 12945044)
On 2013/08/15 07:24:48, dak wrote:
That documentation states as first entry:
@ref{…} — link within current manual.
Well, shoot. That's why we have a countdown. Sorry for the
mistake. Just, um, asserting my humanity, I guess...
Anyway, I made the change.
- Mark
https://codereview.appspot.com/12945044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
Franciszek Boehlke writes: The result looks nice but if you want any chance of putting this in, it should be rewritten as a make post-processor (IMHO of course), think I like the idea of making is make post-processor, but I don't think it's possible to do - and if not, it is much, much harder way. There is possibly another option; if you make it fully pluggable, i.e., not require any changes to the current make rules but only need an include in your .local.make # local.make include make/colorful.make that would help. When something is broken, it's very easy to remove it again. The thing is, someone needs to support this. If the world changes this needs updates. We'll get bug reports. If you promise to support and maintain it, that also helps. Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
LGTM, but add suggested clarification to EM text.
Ian
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode650
Documentation/extending/programming-interface.itely:650: To prevent the
markup from printing on the page, use
By default @code{\displayMarkup} will print to the console and the
output document. To avoid affecting the output file, use
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
Maybe I just missed some solution (possibly I don't know about some make capabilities in that area), but I don't think it's possible to be done without changing current rules. It is because output is in many cases specific for these rules (e.g. contains name of used program). I mean, now it prints something like g++ compiling whatever or bison compiling something else, or g++ linking lilypond, and deducting what should be printed from outside the rule would be rather tricky, and error-prone. I can change way of suppressing output to using special .SILENT rule, so that it wouldn't be necessary to add all that @s. But this way is less flexible, and demands maintaining list of rules, which have to be hidden. I will try to find out, if there is a way to add a bit more generic output (like Building target $@) without changing the rules. I would be painful trade-off for me, but would possible allow to make changes less invasive. I think I can promise to support and maintain it. By the way, current colors are quite random (I just took 7 subsequent colors for 7 types of output), it would be good to standarize them somehow. And maybe some rules deserve a bit more verbose output than just Creating $@ - for some I wasn't sure, what they really does. 2013/8/15 Jan Nieuwenhuizen jann...@gnu.org Franciszek Boehlke writes: The result looks nice but if you want any chance of putting this in, it should be rewritten as a make post-processor (IMHO of course), think I like the idea of making is make post-processor, but I don't think it's possible to do - and if not, it is much, much harder way. There is possibly another option; if you make it fully pluggable, i.e., not require any changes to the current make rules but only need an include in your .local.make # local.make include make/colorful.make that would help. When something is broken, it's very easy to remove it again. The thing is, someone needs to support this. If the world changes this needs updates. We'll get bug reports. If you promise to support and maintain it, that also helps. Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode650
Documentation/extending/programming-interface.itely:650: To prevent the
markup from printing on the page, use
On 2013/08/15 10:14:03, Ian Hulin (gmail) wrote:
By default @code{\displayMarkup} will print to the console and the
output
document. To avoid affecting the output file, use
I find that even worse. It's more like
By default, @code{\displayMarkup} does not only display the markup but
also returns it for use in the document. This allows you to insert
@code{\displayMarkup} before a markup expression in the document without
changing the resulting document.
If you only want the markup to be displayed but not used in the
document, use @code{\void \displayMarkup} instead.
Personally, I find this does not really meet the to see how this works
criterion since the markup expression does _not_ contain a call to the
markup macro at all. Instead, it is a nested list.
Also, the only thing that makes this \displayMarkup rather than
\displayScheme is the restriction of the argument type to markup?.
Perhaps it would make sense to call the whole function \displayScheme
instead and allow arguments of type scheme? here?
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
Franciszek Boehlke franio.kropk...@gmail.com writes: I think I can promise to support and maintain it. If we have a subsystem depend on continued support by a single person, it must be easy to remove the subsystem as a whole. Consider it LilyPond's life insurance. We don't really want such dependencies. They mean that if one person quits, it will take at least five times the original effort to maintain stuff. Don't look here, somebody else will maintain it corners are really expensive in the long run. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode277
Documentation/extending/programming-interface.itely:277: If you want to
evaluate an expression only for its side-effect and
Here \void is declared.
Why repeat it later?
I think a reference should be sufficient.
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode651
Documentation/extending/programming-interface.itely:651: @w{@samp{\void
\displayMarkup @var{markup}}}. Also, as with the
See above.
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
If we have a subsystem depend on continued support by a single person, it must be easy to remove the subsystem as a whole. Yes, that's true. However, when I replace @s with some variable (which i'm going to do), all changes are going to be removable by just a few regex replacements, I believe (which replacements would remove this variable occurences, and lines with printing). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
On 2013/08/15 10:36:06, dak wrote: Also, the only thing that makes this \displayMarkup rather than \displayScheme is the restriction of the argument type to markup?. Perhaps it would make sense to call the whole function \displayScheme instead and allow arguments of type scheme? here? +1 Though, that would mean very little difference between \displayMusic and \displayScheme. Any chance to join them completely? https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
On 2013/08/15 11:24:15, thomasmorley651 wrote: On 2013/08/15 10:36:06, dak wrote: Also, the only thing that makes this \displayMarkup rather than \displayScheme is the restriction of the argument type to markup?. Perhaps it would make sense to call the whole function \displayScheme instead and allow arguments of type scheme? here? +1 Though, that would mean very little difference between \displayMusic and \displayScheme. Any chance to join them completely? Not yet. It's a long-term goal. And of course, there are a few things that are not easily reconciled: compare \void\displayScheme -5 with \void\displayMusic -5 https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
Use David's wording for EM with some tweaks.
Re \displayMarkup \displayScheme:
Markup needs some special-casing as we have our own home-brew
customisable/extensible interpreter in there for interpreting \markup
arguments. The markup interpreter sometimes does some surprising things
under the bonnet - like implicitly wrapping markup commands in #:line.
Would \displayScheme make debugging markups easier or more difficult?
Should we have a \display class expression or \dump class
expression API to part-interpret a LilyPond expression to
scheme-primitives, display these to the console and/or file and *never*
affect the output document? We now have \displayMusic,
\displayLilyMusic, \displayMarkup (and potentially \displayScheme), so
perhaps we need a one-stop shop function to interpret
Music/Markup/Scheme? E.g. \dump 'Music {c'4 e f g},
\dump 'Markup {\italic { Hello \bold {Pond!}}},
\dump 'Scheme #(reverse (list Pond! the from Hello )
These are good ideas but maybe stuff for another issue, given that
Mark's original fix was to clarify obtuse wording in the EM.
Ian
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):
https://codereview.appspot.com/12732043/diff/7001/Documentation/extending/programming-interface.itely#newcode650
Documentation/extending/programming-interface.itely:650: To prevent the
markup from printing on the page, use
By default, @code{\displayMarkup} displays the markup and also returns
it for use in the document. This allows you to insert
@code{\displayMarkup} before a markup expression in the document without
changing the resulting document.
If you only want the markup to be displayed but not used in the
document, use @code{\void \displayMarkup} instead.
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows tutorial
- Original Message - From: Phil Holmes em...@philholmes.net To: Devel lilypond-devel@gnu.org Sent: Sunday, August 11, 2013 12:52 PM Subject: Windows tutorial There have been occasional comments on -user to the effect that the current windows tutorial does not describe what actually occurs with the Windows install. I've downloaded the latest LilyPond version and redrafted the tutorial based on what now we see. I've also updated all the images. Don't think it's worth making this into a patch at this point, since checking it would require the ability to make doc. I've put it on a web page: http://www.philholmes.net/lilypond/windtut/ Comments? Over 30 people have looked at this page and I've had no comments, so I'm going to prepare a patch for review on the assumption that people are broadly OK with the proposed changes. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
ianhuli...@gmail.com writes:
Use David's wording for EM with some tweaks.
Re \displayMarkup \displayScheme:
Markup needs some special-casing as we have our own home-brew
customisable/extensible interpreter in there for interpreting \markup
arguments. The markup interpreter sometimes does some surprising
things
under the bonnet - like implicitly wrapping markup commands in #:line.
Would \displayScheme make debugging markups easier or more difficult?
Uh, nobody suggested changing its internals (except for letting it
accept more arguments). It uses display-scheme-music either way.
Should we have a \display class expression or \dump class
expression API to part-interpret a LilyPond expression to
scheme-primitives, display these to the console and/or file and
*never*
affect the output document? We now have \displayMusic,
\displayLilyMusic, \displayMarkup (and potentially \displayScheme), so
perhaps we need a one-stop shop function to interpret
Music/Markup/Scheme? E.g. \dump 'Music {c'4 e f g},
\dump 'Markup {\italic { Hello \bold {Pond!}}},
\dump 'Scheme #(reverse (list Pond! the from Hello )
These are good ideas but maybe stuff for another issue, given that
Mark's original fix was to clarify obtuse wording in the EM.
I think you are confused. We need separate \display*Music commands
because of having type coercion for its argument and being a music
expression, not because it would format things differently.
This requirement is not there for markups. LilyPond's display-*-music
commands accept any Scheme expression; they just format those internal
to LilyPond in a friendlier manner.
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows tutorial
Phil, you wrote Thursday, August 15, 2013 1:21 PM Over 30 people have looked at this page and I've had no comments, so I'm going to prepare a patch for review on the assumption that people are broadly OK with the proposed changes. I think you should. I looked at the page and it seemed fine to me, but I didn't study it carefully enough to give it unqualified support. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows tutorial
Phil Holmes writes: http://www.philholmes.net/lilypond/windtut/ Comments? Over 30 people have looked at this page and I've had no comments, so I'm going to prepare a patch for review on the assumption that people are broadly OK with the proposed changes. Looks fine. I can only think of describing the workaround https://code.google.com/p/lilypond/issues/detail?id=3343q=windowscolspec=ID%20Type%20Status%20Stars%20Owner%20Patch%20Needs%20Summary until it's identified/fixed, but that seems out of scope for this tutorial. Greetings, Jan -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.nl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Screenshots/PNG files in manuals
As I said earlier, I'm working on the tutorial in the LM. It uses screenshots to show what users will see on the screen. The versions on the web are (as expected from a pixel-based system) fine. However, the versions in the PDF docs are badly scaled and look ugly. It seems that this is generally tackled for images by making them large and then constraining the width in the tex version of the source (this is how it's done in the essay). I'm wondering if there's a better way - is there a recommended pixel-per-inch setting for image files that will end up in the PDFs? I've looked on the web and couldn't find anything, but am hoping someone will know. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
On Thu, 15 Aug 2013 02:33:55 -0700, d...@gnu.org wrote:
On 2013/08/15 09:22:12, Ian Hulin wrote:
1+ for -'
(' is visually mnemonic for notation staccatissimo,
also
' is ergonomic on my keyboard -
no Shift key involved, both keys on right-hand side of
main keyboard)
Sigh. What do people think countdowns are for?
You can't please everyone. Don't worry about it.
'!' also looks like a staccatissimo,
is a stop character so conceptually related to the '.' for staccato,
conflicts less with the use of ''' in pitches:
e'4-! cs-! bf-! g-! e'-! cs-! \tuplet3/2{bf- g- e-}
e'4-' cs-' bf-' g-' e'-' cs-' \tuplet3/2{bf- g- e-}
indicates an exclamation which Hey! is conceptually similar to a
staccatissimo,
is easier to type on key layouts that use ''' for accents (like mine, US
deadkeys on Windows).
''' would look ridiculous when using octave checks: e'='-'
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: maintaining advanced power-user Scheme functions
Hi Pierre, 2013/8/15 Pierre Perol-Schneider pierre.schneider.pa...@gmail.com: Hi Janek, Hi Harm, 2013/8/14 Thomas Morley thomasmorle...@gmail.com So I was annoyed by the lack of help/interest of others and I'm still pissed off. Sorry for that, I think I totaly missed this discussion. I referred to the last LSR-upgrade starting early 2012 http://lilypond.1069038.n5.nabble.com/polychords-a-working-solution-td20169.html (Skip the first posts, it's a long thread) Volunteers? Be sure that I'd grant support. Sure ! Maybe give me some links where I can find how to do it. Cheers, Pierre That's great!! Though, honestly, perhaps you should wait until 2.18. is out. I still hope it's coming soon. Meanwhile you may read the relevant chapter of our CG: http://lilypond.org/doc/v2.17/Documentation/contributor/updating-the-lsr-to-a-new-version Step 1 might be problematic. Recently I had difficulties to contact Seba successfully (about other LSR-problems). At the time I initiated the last round of LSR-upgrade Phil Holmes did this for me. Though you may want to try steps 2-4, simply to get an impression about the amount of work. Best, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Let Skyline's copy constructor use whole-sale copy construction of members (issue 12747043)
LGTM, but then why not let the compiler generate the copy constructor? https://codereview.appspot.com/12747043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let Skyline's copy constructor use whole-sale copy construction of members (issue 12747043)
Reviewers: benko.pal,
Message:
On 2013/08/15 19:00:39, benko.pal wrote:
LGTM, but then why not let the compiler generate the copy constructor?
Good point.
Description:
Let Skyline's copy constructor use whole-sale copy construction of
members
Originally connected with issue 3490, now separate.
Please review this at https://codereview.appspot.com/12747043/
Affected files:
M lily/skyline.cc
Index: lily/skyline.cc
diff --git a/lily/skyline.cc b/lily/skyline.cc
index
5073e69e14b3eaccb805a712e8979be7d9b8856f..77c2443fe836971018c2c131584b3c87da270f6b
100644
--- a/lily/skyline.cc
+++ b/lily/skyline.cc
@@ -457,16 +457,8 @@ Skyline::Skyline ()
empty_skyline (buildings_);
}
-Skyline::Skyline (Skyline const src)
+Skyline::Skyline (Skyline const src) : sky_(src.sky_),
buildings_(src.buildings_)
{
- sky_ = src.sky_;
-
- /* doesn't a list's copy constructor do this? -- jneem */
- for (listBuilding::const_iterator i = src.buildings_.begin ();
- i != src.buildings_.end (); i++)
-{
- buildings_.push_back (Building ((*i)));
-}
}
Skyline::Skyline (Direction sky)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: maintaining advanced power-user Scheme functions
Thomas Morley thomasmorle...@gmail.com writes: That's great!! Though, honestly, perhaps you should wait until 2.18. is out. I still hope it's coming soon. You've seen the flurry of discussions and purported fixes (tending to fall through even the regression tests) about cyclic backend dependencies regressions? Even if this did not look like fresh brainstorming rather than tightly focused bug fixes, we'd be talking about weeks of stabilization. As it is, pre- and post-branching stabilization will be at least 6 weeks all in all. When everything goes really swimmingly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
Keith OHara k-ohara5...@oco.net writes:
'!' also looks like a staccatissimo,
is a stop character so conceptually related to the '.' for staccato,
conflicts less with the use of ''' in pitches:
e'4-! cs-! bf-! g-! e'-! cs-! \tuplet3/2{bf- g- e-}
e'4-' cs-' bf-' g-' e'-' cs-' \tuplet3/2{bf- g- e-}
indicates an exclamation which Hey! is conceptually similar to a
staccatissimo,
is easier to type on key layouts that use ''' for accents (like mine,
US deadkeys on Windows).
''' would look ridiculous when using octave checks: e'='-'
Well, we can have eis'!='-! or even eis!=-! as well, but then
octave-less octave checks always look like an oddity. But forced
accidentals are usually less frequent than octave marks.
And I agree that in the non-contrived interlinear comparison above, the
variant using ! is less of an overall distraction.
https://codereview.appspot.com/12432043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make several special characters with or without backslash non-special (issue 12432043)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Keith
On 15/08/13 18:18, Keith OHara wrote:
On Thu, 15 Aug 2013 02:33:55 -0700, d...@gnu.org wrote:
On 2013/08/15 09:22:12, Ian Hulin wrote:
1+ for -' (' is visually mnemonic for notation staccatissimo,
also ' is ergonomic on my keyboard - no Shift key involved,
both keys on right-hand side of main keyboard)
Sigh. What do people think countdowns are for?
You can't please everyone. Don't worry about it.
'!' also looks like a staccatissimo, is a stop character so
conceptually related to the '.' for staccato, conflicts less with
the use of ''' in pitches: e'4-! cs-! bf-! g-! e'-! cs-!
\tuplet3/2{bf- g- e-} e'4-' cs-' bf-' g-' e'-' cs-'
\tuplet3/2{bf- g- e-} indicates an exclamation which Hey! is
conceptually similar to a staccatissimo, is easier to type on key
layouts that use ''' for accents (like mine, US deadkeys on
Windows).
''' would look ridiculous when using octave checks: e'='-'
OK. I'm convinced, 1+ for the -! staccatissimo.
Cheers,
Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSDWgnAAoJEBqidDirZqASlAAH/0PCUnyVMqH/Bq90cegVHFT+
L+bd+eU4/YDDG0hKFSm7niBHvXomkJ1tOVnWYx3BaH4fy2AbHHcyV93XUxnh2i1N
5x77q1GiQaljfptWl4REkVIp4eXioM+3B3/T0pvVShvHUeF6qhwt+SjDN1KYDLRl
IidvdR8aZpcSt7uSm7cX1yEaUb8V38fSRmU47AWizbk6GAmi0n/MuYhv22dcsybz
jETXb76u8NBIS2KXx79KI+9Nl/LfAttZ/foaqoTLfOzQOQp6lHrsLwuWTiWL1lFy
iTbXCsKLXminSM6gAfqWFDzJcfferi/tKaf93k5z5S4yI++yNbMoTNWEkUcybVI=
=aBdM
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
David Kastrup wrote: Any chance to join them completely? Not yet. It's a long-term goal. And of course, there are a few things that are not easily reconciled: compare \void\displayScheme -5 with \void\displayMusic -5 Well, I played around with this, and David's example is pretty convincing. I vote to go ahead with adding \displayMarkup. I can change the doc wording to suit everyone, but I'll wait for consensus on the function itself. One thing I don't understand though: what value is there in writing a \displayScheme command that takes a scheme argument and prints a scheme expression to the console? Seems pretty redundant to me. - Mark https://codereview.appspot.com/12732043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make website fails on platforms where python3 is the default. (issue 12769043)
When building with WEBSITE_ONLY_BUILD, $(PYTHON) will default to python (as defined at the top of the file). We do that because we don't run ./configure on the web server. I _think_ this will be safe enough, but it might be nice to change the upper definition to $(PYTHON) = python2 https://codereview.appspot.com/12769043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3468: lilypond-book and spaces in application name (issue 12708047)
LGTM https://codereview.appspot.com/12708047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds bar line section to LM (Issue 3408) (issue 12724043)
https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely File Documentation/learning/common-notation.itely (right): https://codereview.appspot.com/12724043/diff/1/Documentation/learning/common-notation.itely#newcode64 Documentation/learning/common-notation.itely:64: @node Bar lines and bar checks Do we really need to explain how to do special bar lines before explaining accidentals? The only reason we have bar checks here is that it helps the reader to see the | symbols in the input. I don't think it's useful to explain special bar lines here. Can't people find special bar lines in Notation? https://codereview.appspot.com/12724043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3491: Add \displayMarkup command. (issue 12732043)
On 2013/08/16 02:38:49, Mark Polesky wrote:
David Kastrup wrote:
Any chance to join them completely?
Not yet. It's a long-term goal. And of course, there are a
few things that are not easily reconciled: compare
\void\displayScheme -5
with
\void\displayMusic -5
Well, I played around with this, and David's example is
pretty convincing. I vote to go ahead with adding
\displayMarkup.
Huh? Can you name a _single_ advantage that is gained by having
\displayMarkup (which is only different from \displayScheme by refusing
to accept a number of arguments) instead of \displayScheme?
One thing I don't understand though: what value is there in
writing a \displayScheme command that takes a scheme
argument and prints a scheme expression to the console?
Seems pretty redundant to me.
You are aware that a scheme? argument does not mean that the argument
needs to be entered with #?
\markup { Hi } is a perfectly valid Scheme argument for a music
function.
https://codereview.appspot.com/12732043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
