Re: Beautify Grob_array and stop using std::vector::data() (issue 264950043 by nine.fierce.ball...@gmail.com)
On Sat, 05 Sep 2015 17:49:44 -0700,wrote: I have simply removed the comments warning about filtering ordered arrays. That seems to be correct. Those comments were incorrect. The filter_map* functions do not, in fact, change the order of the array under the meaning of 'ordered_'. Pál's comment makes sense. There is no sorting method in Grob_array so there is no reason to suspect that the member 'ordered_' has anything to do with order under a sorting criterion. Looking at the commits that touch 'ordered_' it is clear that its meaning was "this array should stay in its current order" and that removal of elements doesn't count as a change in order and substituting Grobs inherit the order the Grobs they replace. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Issue 4059: Document MIDI mapping and MIDI effects (issue 249980043 by tdanielsmu...@googlemail.com)
On Mon, 06 Jul 2015 15:19:20 -0700, tdanielsmu...@googlemail.com wrote: Setting midiChannelMapping to 'voice often prevents the context properties from having effect. Doesn't the paragraph under 'voice above explain explicitly what happens? That seems better than the rather vague often prevents the context properties There already is a reference back to that explanation. I didn't think the paragraph under 'voice sufficiently discouraged its use. It describes a first-approximation of the behavior, but the description isn't complete, and the behavior isn't transparent: \score{ \new Staff \new Voice = violin { c'4 % set the voice below to flute \set Staff.midiInstrument = flute r g' r } \new Voice = flute { % set the voice above to violin \set Staff.midiInstrument = violin r4 c' r g' } \layout{} \midi{\context {\Score midiChannelMapping=#'voice }} I don't think midiChannelMapping='voice has any use. Somebody added the code under sponsorship from Fruity Loops Sequencer, so if it has any use it is in conjunction with that software, so let the sponsor document it there. That programmer who added the code didn't know about Lilypond's engraver/performer method of routing events and property-changes to output, and didn't know much about midi, so the data flow doesn't make much sense in the context of Lilypond and MIDI. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid treating x as relative in \relative { \autochange {x} } (issue 250170043 by nine.fierce.ball...@gmail.com)
On Sat, 04 Jul 2015 05:45:04 -0700, nine.fierce.ball...@gmail.com wrote: Nobody knew \autochange was broken until Thomas found an unused variable, so these test are useful if \autochange is useful. Well, \autochange could have been useful, even to users of \relative if they used their \relative inside the \autochange. You don't have a very strong argument for yet another regression test. It is nice if the behavior matches the documentation, and if it stays that way. Your method of these two measures should look the same helps a lot. You could make the music look a little more normal, though: % \autochange needs to be given pitches in their final octaves, % so if \relative is used it must be applied inside \autochange. % The pitches in \autochange are unaffected by an outer \relative, % so that the printed output shows the pitches that \autochange used. \new PianoStaff { \autochange \absolute {g4 c g' c} \relative \autochange {g4 c g' c} % relative is ignored \autochange \relative {g4 c, g'' c,,} } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make music functions callable from Scheme (issue 244840043 by d...@gnu.org)
On Sat, 20 Jun 2015 22:28:13 -0700, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: Some people don't like side-effects in loop-control conditionals while (scm_is_pair (scm_cdr (signature)) // more slots ? scm_is_pair (scm_cadr (signature)) // next one optional ? (signature = scm_cdr (signature)));// deal with it now. Count me among some people here. Me too. A minute after I sent this I thought of a simpler way at https://codereview.appspot.com/247190043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make music functions callable from Scheme (issue 244840043 by d...@gnu.org)
On Mon, 08 Jun 2015 18:04:44 -0700, d...@gnu.org wrote: No dice. The main problem is dealing with all combinations of running out of signature and running out of available arguments. If you treat the optional argument skipping in an inner loop, you may still run out of signature, and in that case you still need to treat the case where you have simultaneously run out of arguments (namely because the non-matching argument triggering the skipping was \default aka *unspecified) separately _and_ break out of all loops. Since you have already fetched the next signature bit (since you would not know whether it was optional and skipping should continue), you can't return to the main loop which would fetch it again but need to clad the whole in one while (scm_is_false (scm_call_1 (pred, arg))) of its own. Treating all the terminating condition combinations in inner loop and outer loop separately causes the control structures to fray apart more than the skipping flag does, to the degree where the cleanest solution to handle one of the innermost loop termination conditions with a goto statement. Well, the inner loop can decide whether to continue by peeking-ahead at the next entry in the signature. Then the jobs of the inner/outer loops remain clean. Some people don't like side-effects in loop-control conditionals while (scm_is_pair (scm_cdr (signature)) // more slots ? scm_is_pair (scm_cadr (signature)) // next one optional ? (signature = scm_cdr (signature)));// deal with it now. so maybe I'll use test-in-the-middle loop, but that needs only break one loop. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: balloon-text: robust with empty stencils; issue 4447 (issue 243610043 by k-ohara5...@oco.net)
On Fri, 19 Jun 2015 23:50:50 -0700, d...@gnu.org wrote: https://codereview.appspot.com/243610043/diff/1/lily/balloon.cc#newcode94 lily/balloon.cc:94: b.widen (padding, padding); Basically we have two options here: not draw a box at all (it would be my guess that this is probably what happened previously when assertions were disabled) or draw a box around the not-with-stencil anchor point. The former behavior leaked NaNs and corrupted spacing on the whole line. This is for the situation where a user, through misunderstanding or oversight, requested an indicator box be drawn around an object that does not actually appear in print. A tiny empty box says clearly I heard you ask for a box, but I didn't recognize or find what you wanted me to draw it around. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: simple-spacer: inappropriate assert; issue 4448 (issue 249820043 by k-ohara5...@oco.net)
On Fri, 19 Jun 2015 23:59:11 -0700, d...@gnu.org wrote: https://codereview.appspot.com/249820043/diff/1/lily/simple-spacer.cc File lily/simple-spacer.cc (right): https://codereview.appspot.com/249820043/diff/1/lily/simple-spacer.cc#newcode199 lily/simple-spacer.cc:199: programming_error (misuse of expand_line); Any sensible fallback behavior for this misuse of expand_line? If we can reliably guess what the intent of the misuse is (after all, it would appear that the situation comes about from reasonably regular input rather than explicit user error), one could just do that and forget about the programming error. These two asserts cannot be triggered in current code, except maybe through roundoff error, because the only calls of the function are protected my matching conditionals in Simple_spacer::solve() The third assert is the one that trips (windows-only). Is there something reasonably continuous one can do so that small errors lead to small offsets? The following line obviously returns a quantity that changes continuously across the assert condition, so I am 90% sure you are defying national stereotypes and using irony. In that case, yes, I do think the behavior that was being protected against is so benign that there need be no traps at all for these conditions. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make music functions callable from Scheme (issue 244840043 by d...@gnu.org)
On Sun, 07 Jun 2015 23:09:31 -0700, d...@gnu.org wrote: So your problem appears to be that you understand the code but it does something you did not expect. Cross-check from the user end with the Extending LilyPond guide's explanation of optional arguments. It is Extending section 2.2.2. Yuck. A comment pointing to Extending-2.2.2 would help. The behavior in the parser is forced because LilyPond uses no delimiters for the arguments to a function. Scheme has delimiters so you know where the end of the argument list is, so we could use a simpler rule for optional arguments in Scheme interface. Or you could scan arguments using a recursive-descent method in C, so the parallel with the parser is maybe a bit more clear. Or maybe advance through 'signature' to the next non-optional argument immediately upon using a default value, rather than setting 'skipping'. The re-structuring I suggested was intended also to change the if-else branching so that you don't need the 'continue's. https://codereview.appspot.com/244840043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: add stencil-whiteout-outline function (issue 236480043 by paulwmor...@gmail.com)
On Mon, 01 Jun 2015 19:29:41 -0700, paulwmor...@gmail.com wrote: scripts/auxiliar/update-with-convert-ly.sh I get this: make: *** No rule to make target `python-modules'. Stop. xargs: ./out/bin/convert-ly: No such file or directory xargs: ./out/bin/convert-ly: No such file or directory I'm running LilyDev3 in a virtual machine. (Feeling like I'm in over my head with this one.) Looking at the first few lines of update-with-convert-ly, it looks like it expects you to have defined the build directory as BUILD_DIR where most other scripts expect LILYPOND_BUILD_DIR. Maybe export BUILD_DIR=$LILYPOND_BUILD_DIR ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: git-cl upload has stopped working (so has patchy)
Trevor Daniels t.daniels at treda.co.uk writes: The next step is to decide our preference: do we want to take on the commitment to maintain Allura ourselves or use the maintained version at SourceForge. Which would we prefer? (FWIW my preference would be to run Allura at Savannah as our primary DB, with a backup being maintained at SF, which I would be happy to do on a monthly basis.) I just read the threads since March on this topic. I'm not willing to help with administration, so appreciate everyone who is. If running Allura on savannah.gnu.org is possible that does seem best. There is another fallback in the native bug-tracking on Savane. It does handle a larger project https://savannah.gnu.org/bugs/?group=octave and accepts images, but you have to click the attachment links to see them http://savannah.gnu.org/bugs/?func=detailitemitem_id=28346 The user interface is nostalgic, but usable. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Master fails to compile
On Thu, 28 May 2015 01:36:54 -0700, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: I had an old RedHat installation with gcc updated as far as I could to 4.6. In the next few weeks I'll find some reasonably-modern linux. Well, using no longer supported systems with network access (and it's pretty hard to work on current LilyPond source without network access) is a security nightmare. Old GNU/Linux installations are actually pretty popular as mail hubs for malware distribution. Updating most software, was no problem, even synchronizing to the release of the whole distribution. But gcc and glibc tend to lag behind. The latest Centos that works on a 32-bit i386 is CentOS 6.6 (supported through 2020) with gcc 4.4.7. I'm looking into switching to Debian. The tricky bit about the function template in Smob_base template SCM (Super::*pmf)(void) static SCM smob_trampoline (SCM self) is the way it creates functions in Smob_base that call member functions of the derived classes like Listener. Following what happens requires a lot of flipping back and forth between header files. Smob_base may not be the best place. I remember wanting to put it in Dispatcher itself at first and I got some private/protected thing in the way. But it might make more sense to pierce the encapsulation with some sort of friend declaration (if unavoidable) rather than move the whole functionality there. If you can define the trampoline as a static member of the class whose member function is being called, that will be less surprising. It might be a bit ugly to have the boiler-plate code in each derived class that uses the mechanism, but the boilerplate is recognizable if we can see it all at once. LY_DECLARE_SMOB_APPLY_INIT(smob_apply_trampoline, 1, 0, 0) static SCM smob_apply_trampoline(SCM self, SCM arg) { return unsmob(self)-listen(arg); } SCM listen(SCM ev) { ...} ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Master fails to compile
On Mon, 25 May 2015 23:10:17 -0700, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: If I can't get the dependencies worked out I'll be tempted to skip the macro and use scm_call_1() through scm_call_3() in place of each of the three macro expansions. Why? Seriously. 10.04 is not even supported by Ubuntu itself any more. Phil has the Ubuntu. I had an old RedHat installation with gcc updated as far as I could to 4.6. In the next few weeks I'll find some reasonably-modern linux. The tricky bit about the function template in Smob_base template SCM (Super::*pmf)(void) static SCM smob_trampoline (SCM self) is the way it creates functions in Smob_base that call member functions of the derived classes like Listener. Following what happens requires a lot of flipping back and forth between header files. It took me quite a while to figure out why you register with scm_set_smob_apply() a static member function of Smob_baseListener rather rather than something in Listener directly. After a while I concluded that the goal was to put the trampoline code all in one place. This seemed odd as the general-case (four cases) trampoline outnumbered the use cases. You might want to expand the macro in-place, and follow each expansion with the definition of the trampoline function -- or let the routine implementing apply smob be a static member function, so it serves as its own trampoline. Hundreds of times, even. Once for every Smob-derived class, even. It's just the balance between code duplication and obfuscation. I have a patch cooking that will convert hundreds of Scheme callbacks to member functions with that technique. Part of the reason is to get argument type checks in for stuff like (ly:grob::stencil-height 0) which just segfaults right now. Having a member function instead of a static member makes the code simpler while the static template generated by this technique does the typechecking while creating a this-pointer from an SCM. And if you call the member function via C++ with an existing instance pointer, you bypass the typechecking. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Master fails to compile
Phil Holmes mail at philholmes.net writes: I've managed to work out how to upgrade Ubuntu 10.04 to gcc 4.8.1 with the help of StackOverflow, and can now compile again. I'm still working on sorting out dependencies. The troublesome macro asks is used in only three places, creating in each place a templated function call with the same name, asking the compiler to call the correct one of four variants of the function based on the argument count of a passed function pointer. If I can't get the dependencies worked out I'll be tempted to skip the macro and use scm_call_1() through scm_call_3() in place of each of the three macro expansions. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PDF is broken for at notation{} encoding
Phil Holmes mail at philholmes.net writes: whenever we use at notation{text}, then there is a paragraph break before the text. It took a while to figure out the guilty commit, but it is 9f3c7711bb73baf3aea8502227fb5fd2d2851753: update texinfo.tex from upstream. I think you found the correct cause, but I cannot see how it causes this exact problem. Every macro defined in our include-files *macros.texi is preceded by an extra line-break. The pdfs on the webpage show the problem. The change to texinfo was requested here http://lists.gnu.org/archive/html/bug-texinfo/2015-04/msg00037.html and made here http://lists.gnu.org/archive/html/texinfo-commits/2015-04/msg00030.html but that change makes 'active' in the TeX sense a range of characters that are non-printing in Latin1. If I could remember how to run texinfo on a 5-line example file, I might send a bug-report to texinfo ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pure/impure?!?!
On Sun, 24 May 2015 01:55:30 -0700, David Kastrup d...@gnu.org wrote: Anyway: how do impure functions reference (and trigger?) line breaks? Non-'pure' functions reference line-breaks very indirectly. Spanners are broken into two or more grobs at line-breaking, so their functions work on the split Grobs that have a line-break column as a bound. I would have to trace to find the path whereby functions trigger line-breaking. I think the path is when the Y-extent of a Grob depends on the Y-extent of a VerticalAxisGroup. The pure version of the VerticalAxisGroup.Y-extent uses functions like rest_of_line_pure_height(,start,end) while the non-pure version ends up calling generic_group_extent(), which I suspect eventually calls the line-breaker. The facility for any 'pure' estimate of a property to depend on the start/end columns seems to have started with the *_of_line_pure_height() of VerticalAxisGroups. I cannot think of any other object for which they are used. The 'start'/'end' parameters are passed down the call stack, so if a 'pure' property depends ultimately on the Y-extent of a VerticalAxisGroup, it would need a sensible start/end pair; I do not know of a case where the 'pure' call-chains for properties of Items (as opposed to Spanners) ask for VerticalAxisGroup dimensions. Conceptually, the height of the arc of a slur could be estimated for a potential line-breaking, but that has not been implemented. If in the future we implement that, it seems that the control logic that is evaluating potential line-breaks would need to provide start/end information, or better the horizontal positions of the slur bounds, to the height-estimator for the Slur; I cannot imagine a way for Slur to seek out the potential line-breaks. But I think we can remove the 'start'/'end' parameters from 'pure' functions for Items. Items have a 'pure' version of their functions as a way to promise that these functions *not* depend on line-breaking. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5a5a at oco.net)
Wols Lists antlists at youngman.org.uk writes: On 23/05/15 23:39, Keith OHara wrote: tdanielsmusic at googlemail.com writes: I'd prefer the syntax and options to parallel those of \relative. That is, an optional prefix pitch to indicate the starting octave, and taking the starting octave from the first contained note if the prefix is omitted. We could implement this, but ... Is this a good idea though? I think not, and everyone seems at least content to do without this behavior, at least for now. (I wasn't sure until now which behavior you were favoring, in the case of an omitted reference pitch.) If I want \fixed c {} but my first note just happens to be d' then it's going to be a pain. Well, the pain is limited to that involved in typing the explicit 'c', or the extra few letters in \absolute We will have the following choices, out of which maybe will emerge a second pattern as generally useful as many people find \relative{} : \absolute {\key g\major \clef alto \time 3/4 | d'8 d' b4 d' | b g a8 b8 | c'4 a d' | b g4. d'8 | d'4 b d' | b g a8 b8 | c'4 a d' | b g2 } \fixed c {\key g\major \clef alto \time 3/4 | d'8 d' b4 d' | b g a8 b8 | c'4 a d' | b g4. d'8 | d'4 b d' | b g a8 b8 | c'4 a d' | b g2 } \relative {\key g\major \clef alto \time 3/4 | d'8 d b4 d | b g a8 b8 | c4 a d | b g4. d'8 | d4 b d | b g a8 b8 | c4 a d | b g2 } \relative d' {\key g\major \clef alto \time 3/4 | d8 d b4 d | b g a8 b8 | c4 a d | b g4. d'8 | d4 b d | b g a8 b8 | c4 a d | b g2 } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5a5a at oco.net)
Wols Lists antlists at youngman.org.uk writes: On 21/05/15 07:36, k-ohara5a5a at oco.net wrote: I'm proposing to push a \fixed c' {} that always takes a reference pitch, as in the current patch. So the behaviour is different from \relative, which doesn't have to have a reference pitch. Before version 2.18, \relative{} defaulted to relative c'{} but that was deprecated with version 2.12. Since version 2.18 \relative{} defaults to \relative f{}, which acts the same as taking the starting octave from the first pitch \relative {c''4 c g' g} == \relative c'' {c4 c g' g} I have seen two different suggestions for what default behavior to use if the reference pitch after \fixed is omitted. Neither default seems obvious to me, so I'm proposing we use \fixed with an explicit pitch until it becomes clear that one usage is natural and useful enough to be default. 1) Something like the old \relative {} - relative c' {} If \fixed takes an optional (defaults to c') reference pitch then the underlying code will be the same. Earlier versions of the proposed patch did this, but defaulting to c not c' 2) Something like the new \relative {c'' ...} - relative c'' {c ...} tdanielsmusic at googlemail.com writes: I'd prefer the syntax and options to parallel those of \relative. That is, an optional prefix pitch to indicate the starting octave, and taking the starting octave from the first contained note if the prefix is omitted. We could implement this, but unlike \relative where each octave mark increments the octave of the previous pitch, there is no simple way to start the machinery of \fixed so that the octave shift is determined by the first pitch it acts upon. We need code to explicitly find the first pitch and extract its octave. -- absolute = #(define-music-function (parser location pitch music) ((ly:pitch?) ly:music?) (_i Shift the octave of each pitch in @code{music} according to the ocatve marks @code{pitch}. If @code{pitch} is ommitted, use the octave marks from the first pitch found in @code{music} to shift the octave of all the pitches in @code{music} except the first. The result is absolute music, wrapped as @samp{RelativeOctaveMusic} to hide it from surrounding @code{\\relative} and @code{\\absolute} commands.) (define (extract-octave-from-first-pitch m) (if (eq? (ly:music-property m 'name) 'RelativeOctaveMusic) #f (or (let ((p (ly:music-property m 'pitch))) (and (ly:pitch? p) (let ((octave-marks (1+ (ly:pitch-octave p ;;Reverse-shift the first pitch, ;; so later we can shift back with all the others (ly:music-transpose m (ly:make-pitch (- octave-marks) 0 0)) octave-marks))) (let ((e (ly:music-property m 'element))) (and (ly:music? e) (extract-octave-from-first-pitch e))) (let loop ((elts (ly:music-property m 'elements))) (and (pair? elts) (or (extract-octave-from-first-pitch (car elts)) (loop (cdr elts (let ((octave-marks (or (and pitch (1+ (ly:pitch-octave pitch))) (extract-octave-from-first-pitch music) 0))) (display octave-marks) (newline) (cond ((not (= 0 octave-marks)) (ly:music-transpose music (ly:make-pitch octave-marks 0 0)) ;;In order to leave unchanged the notes in any enclosed ;; \absolute or \fixed or \relative, make a cancelling shift (map (lambda (m) (ly:music-transpose m (ly:make-pitch (- octave-marks) 0 0))) (extract-named-music music 'RelativeOctaveMusic) (make-music 'RelativeOctaveMusic 'element music)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pure/impure?!?!
David Kastrup dak at gnu.org writes: Ignored or not: those are values indicating breakpoints of the current system. They should not even be available for functions evaluated before any line-breaking. Or maybe they are called for one of a set of tentative not-final line breaks, but in that case it would make little sense to call the post-linebreak (impure?) functions without the actual linebreak information. Yes. The parameters 'start' and 'end' let the page-breaking code estimate how tall each system will be by calling the pure-height function on each VerticalAxisGroup, which might call pure-height on its contained spanners like Slurs, whose height could depend on where the line-breaks are. The results are cached in a hash table indexed by the start/end pair. The idea was to consider line-breaks and page breaks simultaneously, to find the best overall page layout. In practice, this does not work very well because 1) there is no time to do a trial horizontal spacing for each line-break set, so the page fit is evaluated with conservatively estimated heights of systems only, not skyline 2) in frenched scores, where well-chosen line-breaks let us remove more empty staves, the page-fit score often favors generating mostly-empty staves to fill pages more uniformly. We can't simply remove the simultaneous consideration of line- and page-breaks, because page-turn-breaking needs to put the final line- break on each odd page at a feasible point. We might be able to shift to two strategies: 1) line-breaking then best-fit onto pages using the skylines of the lines, 2) page-turn-breaking at feasible places, then line breaking within each page. The usual (not 'pure') functions to determine Y-offsets are free to look up properties of other objects, that can call functions to look up the line-breaking results or induce line-breaking if it hasn't been done yet. The 'pure' functions are supposed to avoid calling functions with the side effect of inducing line-breaking, and that has caused a proliferation of 'pure' versions of functions where we would not expect a distinction between pre-/post line-breaking ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add French-specific note names (issue 239930043 byv.villenave at gmail.com)
Trevor Daniels t.daniels at treda.co.uk writes: BTW dear lilylist: where do you have the 'ñ' on your keyboards? We don't have it anywhere on the English keyboard. You might have more than you think, or can easily get more. The US-International layout has the accented characters of English, in the same places, plus more; the right-bottom row with right-Alt gives ñ µ ç . ¿ The layout is the same under Windows and Linux, at least. Modern text editors will save the result as unicode. We do have the problem in the US that Alt-Gr is often set as a second Alt. At work I have sent some partial emails because I had not enabled the Alt-Gr key, and the keys that should give me ß gave instead Alt-s = Send. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On Sun, 17 May 2015 04:58:22 -0700, tdanielsmu...@googlemail.com wrote: The proper name for this would \absoluteWithFixedOctaveOffset, but that's too long and the acronym is similarly uninspiring. All three of the proposed options appear in this name, so the question is, Which alludes most memorably to the actual function?. At the risk of going round in circles, on reconsidering in this light, I rather favour retaining \absolute. The other terms are modifiers to the primary function; the offset is both apparent and optional, absolute is used in the text and is an established concept. The word absolute is established in the docs and in the user community to mean the method of entering pitches where octave marks ' and , count octaves from the small octave of Helmholtz notation, so the octaves are indicated against an absolute reference. As Carl pointed out, a function that applies an octave offset changes that reference, so is different from absolute. The two functions \fixed and \relative each convert user input into absolute pitches. \relative applies octave marks relative to the previous pitch; \fixed adds octave marks to those of a fixed pitch. The primary function of the music-function \absolute is to write a stretch of absolute pitches within \relative, but the primary function of \fixed will be to choose the fixed octave from which entered octave marks count. I switched the name in the patch from \absolute to \fixed when I made the function skip over any enclosed \relative section. The docs say the starting pitch in \relative is an absolute pitch, and I didn't want to start making the distinction of absolute octaves versus the octave established by the enclosing absolute so I made the change \absolute c'' {c e g \relative c, {c e g} } = c''4 e'' g'' c' e' g' \fixed c'' {c e g \relative c, {c e g} } = c''4 e'' g'' c, e, g, For some reason I find the word 'fixed' easier to type than 'absolute' I started looking ahead at further documentation, and found \fixed more natural https://codereview.appspot.com/235010043/diff/120001/Documentation/learning/tutorial.itely but I backed away from adding anything to the Tutorial because \relative is enough to learn there. BTW, I started replacing @lilypond[relative=2] with complete examples https://codereview.appspot.com/237340043/ I replaced with explicit \relative, but the patch set is a quick way to skim the examples in the Learing Manual where we chose to hide the '\relative' and imaging how \fixed or \absolute might work. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \shiftOff an assertive \override, not a \revert (issue 190500043 by k-ohara5...@oco.net)
On Sun, 10 May 2015 11:02:21 -0700, d...@gnu.org wrote: It's not clear why you are now mixing in variants of conversion rules for issue 4372. I noticed that my rule made the same \b mistake as yours, and they are right next to each other, and I thought it was an easy fix, so I tried fixing both at once. But at any rate I think you need to explain why you think that you want a convert-ly rule to retain behavior that you consider a) to not correspond to the documentation or expected behavior b) to not deserve a command of its own c) you do not consider worth documenting separately d) which requires explicit protection of the documentation from conversion It was hard to decide whether to have the convert-ly rule or not for \shiftOff. For existing music that used the old shiftOff = \revert NoteColumn.horizontal-shift, the replacement \undo\shiftOn has the same expansion. I searched for uses of \shiftOff and found that Urs Metzger has a few pieces on mutopiaproject that use \shiftOn \shiftOff pairs as if they were a set/revert pair. The convert-ly rule doesn't help for those examples, though, because they have hand-adjusted shifts in the other voices. The \revert version generated too many clashing notecolumns warnings, which is now need a \shiftXxx, and I thought it a bit safer to keep a warning. The manuals did not use \shiftOff in LilyPond code where it had any effect, but only talked about its desired effect in the text. Thus the manuals should not get any convert-ly rule. If you revert the convert-ly rule, it would be more tidy if you also reverse its changes in 'Documentation/learning/fundamental.itely' and 'Documentation/fr/learning/fundamental.itely' Only three lines each file. :%s/\\undo\\shiftOn/\\shiftOff/g ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On Sun, 10 May 2015 00:25:18 -0700, d...@gnu.org wrote: On 2015/05/09 23:58:22, Keith wrote: It is a bit of an inconvenience that \relative skips over \transpose, and I suspect \relative has this feature so that we do not get rising octaves in \relative c \transpose c c' {c c c c} We could change that if desired. Good point, but the change is probably too disruptive of old scores. \fixed c'' { c e g c \transpose c d {c4 e g c}} = c'' e'' g'' c'' { d'' fis'' a'' d'' } The question is rather what happens when writing \transpose c c' in the middle. In that case I'd expect, like discussed for \relative, to have the transposition temporarily reversed before applying the \fixed, and then transpose back again. For \absolute c' or \fixed c' there is no need for special effort. These operations commute with transpose. \fixed c' { c4 e g c \transpose c d' {c4 e g c}} = c'4 e'4 g'4 c'4 { d''4 fis''4 a''4 d''4 } https://codereview.appspot.com/235010043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Make \shiftOff an assertive \override, not a \revert (issue 190500043 by k-ohara5...@oco.net)
On Sun, 10 May 2015 05:06:24 -0700, d...@gnu.org wrote: In addition, the following commit commit a1d73a332fc4d1cb99bace19a5ec2c35262429e7 Author: Keith OHara k-ohara5...@oco.net Date: Tue Dec 30 23:30:27 2014 -0800 Update by hand instead of convert-ly The documentation already described the new behavior of \shiftOff did not bother updating the version numbers in the translations. In consequence, running scripts/auxiliar/update-with-convert-ly.sh now will overwrite the German, Spanish, Catalan, French, Hungarian, Italian, Japanese and other translations with inappropriate changes. Oops. Yep, I had intended to bump version numbers across translations. I'll clean that up in an follow-up to issue 44242 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: absolute pitch entry: accept an offset octave (issue 235010043 by k-ohara5...@oco.net)
On Mon, 04 May 2015 23:58:12 -0700, Valentin Villenave valen...@villenave.net wrote: Speaking as someone who regularly gives LilyPond initiation seminars for adults and children, the hardest part is explaining to them why \relative mode is not on by default. What if they didn't have to type all those 's in absolute mode ? You might not need to explain relative mode at all. It was hard for me to remember when in \relative I needed g' to get a G5 but later in a very similar circumstance the same pitch is spelled g \relative {r2 c'4 c | g' g a a | g2 f4 f | e4 e d d | c2 g'4 g | f4 f e e | e4 d g g | f4 f e e | e4 d c c | g' g a a | g2 f4 f | e4 e d d | c2 r } \absolute c' {r2 c4 c | g g a a | g2 f4 f | e4 e d d | c2 g4 g | f4 f e e | e4 d g g | f4 f e e | e4 d c c | g g a a | g2 f4 f | e4 e d d | c2 r } If the melody crosses above and below C \relative {c''4 c e8 c g4 | g8 g16 g g8 g e'4 c | c4 c e8 c g4 | g8 g16 g g8 g c2 | c8 c c e g e c4 | g8 g' g, g' e4 c | c8 c c e g e c4 | g8 g' g, g' c,2 } then absolute mode needs a lot of octave marks, but all the pitches that sound low get consistently a low octave mark \absolute c'' {c4 c e8 c g,4 | g,8 g,16 g, g,8 g, e4 c | c4 c e8 c g,4 | g,8 g,16 g, g,8 g, c2 | c8 c c e g e c4 | g,8 g g, g e4 c | c8 c c e g e c4 | g,8 g g, g c2 } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
On Sun, 26 Apr 2015 14:35:33 -0700, Dan Eble d...@faithful.be wrote: If there existed a command to redirect the sequential iterator’s output to another Voice context without requiring a wrapper context, it could not function in a parallel sequence; the commands would have to be injected into the part sequence itself. Well, the current \partcombine works that way, using events like solo-one-event or unisono-event that signal to part-combine iterator to redirect one of the the two sequential iterators that part-combine-iterator.cc tracks. Breaking up the music into subsequences still looks better overall to me. I tried writing the output of a hypothetical \partcombine that no longer depends on part-combine-iterator.cc \partcombine {R1*3 g''2 d''2 } {R1 r2 b2 R1 b2 d'2 } % Breaking into subsequences \new Staff \context Voice = one \with { \voiceOne } \context Voice = two \with { \voiceTwo } \context Voice = solo \context Voice = shared { \context Voice = shared {R1 r2} \context Devnull { r2 } \context Voice = shared {R1 } \context Voice = one { g''2 } \context Voice = shared { d'' } } { \context Devnull {R1 r2} \context Voice = solo { \marksolo II b2 } \context Devnull { R1 } \context Voice = two { b2 } \context Voice = shared { d'2 } } % Using a parallel sequence of \change events \layout { \context { \name Thread \type Engraver_group } \context { \Voice \accepts Thread } } \new Staff \context NullVoice = null \context Voice = one \with { \voiceOne } \context Voice = two \with { \voiceTwo } \context Voice = solo \context Voice = shared \new Thread { \change Voice = shared s1 s2 \change Voice = null s2 \change Voice = shared s1 \change Voice = one s2 \change Voice = shared s2 } { R1 r2 r2 R1 g''2 d''2 } \new Thread { \change Voice = null s1 s2 \change Voice = solo \marksolo II s2 \change Voice = null s1 \change Voice = two s2 \change Voice = shared s2 } { R1 r2 b2 R1 b2 d'2 } In any case, if you want to retire the part-combine-iterator, you need new code to properly break rests. I think there are still bugs with \partcombine when rests overlap changes of state, so the rewrite might solve some bugs. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
On Sun, 26 Apr 2015 05:37:14 -0700, Dan Eble d...@faithful.be wrote: I think \context...{} segments make a better implementation of \partcombine than re-routing outlets in the part-combine-iterator.cc I believe that would work, but it looks less tidy than keeping the original part intact and wrapping it in a context which moves between Voice contexts. ... c4 } \context Voice = one { d4 ... is only slightly less tidy than ... c4 \change Voice = one d4 ... If you were thinking of a separate sequence of {... s1 \change Voice = one s2...} in parallel with the part, then the \change method could be more tidy. The wrapping context, though, means that we have to explicitly specify Voice in any overrides that should carry through to the combined part \partcombine { c'4 d'4 } {\slurDashed g'4( b') } \partcombine { c'4 d'4 } {\override Voice.Slur.dash-definition = #'((0 1 0.4 0.75)) g'4( b') } If your wrapping context is not aliased to Bottom, maybe you could convert-ly to specify the Bottom context \override Bottom.Slur.dash-definition = #'((0 1 0.4 0.75)) My guess is that the wrapping context will cause mysterious behavior that outweighs its tidiness. It would definitely be a challenge to reconstruct the part for \displayLilyMusic; I’d probably stash the original parts in a property just for that purpose, which seems like a dumb idea. Don't reconstruct the input if you can show the output. If \partcombine produces a music expression with context changes, rather than structures like 'split-list, then we would want \displayLilyMusic to show the result of \partcombine, not try to guess the input. The documented purpose of \displayLilyMusic is to show the result of music function, displayed in LilyPond input syntax. \displayLilyMusic \relative c' {c4 e g c e g c e g c e g } \displayLilyMusic \transpose c bes {c4 e g c } \displayLilyMusic \appendToTag#'t d' { c'4 e' \tag#'t g' c' } \displayLilyMusic \removeWithTag#'t { c'4 e' g' c''} {c'4 \tag#'t e' g' c''} Only in cases where the music output from a function cannot be directly expressed in Lilypond input syntax, does \displayLilyMusic try to guess the function that produced the music. This reverse-engineering always seems a bit silly, but producing valid LilyPond input for these cases means we can use \displayLilyMusic more easily for its primary purpose. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
On Fri, 24 Apr 2015 22:04:28 -0700, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: The thing you want to change is the outlet of the sequential iterator. That's just \context Voice = xxx. However, it does not take engravers and properties along, as opposed to \change ... Yes. The current part-combine-iterator does not carry properties along either, which is to first approximation what we want, when a line of music moves from 'a2' with \oneVoice to 'two' with \voiceTwo style. A big difference is that \change... changes routing so that all following music is affected, while \context... applies to only the following music expression. We would need to form sequential music groups in order to use the \context... method. \new Staff \context Voice = up \with { \voiceOneStyle } s1*2 \context Voice = down \with { \voiceTwoStyle } s1*2 { \context Voice = up { f'2 f' } \context Voice = down { e' e' } } Current \partcombine does not collect segments into sequential music groups, but it could do so. The analysis pass of \partcombine looks at the music globally to find the transition points that it puts in 'split-list, so a next pass can form sequential music groups between the transition points. \partcombine {R1*3 g''2 d''2 } {r1 r2 b2 R1 b2 d'2 } could be transformed into \new Staff \context Voice = one \with { \voiceOne } \context Voice = two \with { \voiceTwo } \context Voice = solo \context Voice = shared { \context Voice = shared {R1 r2} \context Devnull { R2 } \context Voice = shared {R1 } \context Voice = one { g''2 } \context Voice = shared { d'' } } { \context Devnull {r1 r2} \context Voice = solo { \marksolo II b2 } \context Devnull { R1 } \context Voice = two { b2 } \context Voice = shared { d'2 } } I imagined the splitting of multi-measure rests being done in the grouping pass, rather than in the iterator as it is done now. If we define the names one, etc., in just one place, then we can choose to replace solo with shared so that they use the same Voice. I think \context...{} segments make a better implementation of \partcombine than re-routing outlets in the part-combine-iterator.cc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: \change Voice
Dan Eble dan at faithful.be writes: Would it be hard to make \change Voice work as below without relying on the extra “NoteSequence” context? \layout { \context { \name Thread \type Engraver_group } \context { \Voice \accepts Thread \defaultchild Thread } } I think it would be hard. The code uses the concept that \change... takes a context from one enclosing context into another. Usually there is no context like NoteSequence that lives inside a Voice. (The code in change-iterator.cc is written in a general way, so that \change GrandStaff=b finds the highest context below the enclosing GrandStaff and moves that context to GrandStaff b, but I don't think anything other than \change Staff works in a useful way.) We probably don't want Thread to be created by default, because then all \overrides for the Voice need an explicit 'Voice'. Once I read old old mailing list message about contexts called threads that would live inside Voice, which might be a similar idea. I think people decided the idea caused too much complication. The thing you want to change is the outlet of the sequential iterator. So rather than a \change event that is acted upon by change-iterator.cc you might want a partCombineStatus event that is acted upon by sequential- iterator.cc. That, though, would look similar to the current part-combine iterator. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid floating-point compares on Stem:head_positions; issue 4310 (issue 217720043 by k-ohara5...@oco.net)
On Wed, 11 Mar 2015 02:10:29 -0700, d...@gnu.org wrote: _How_ do we arrive at different versions of 3.0 here, or at GCC considering 3.0 3.0 ? Probably we get different numbers that are close to 3.00... or 2.99... The head positions are individually multiplied by staff-space in Grob::get_offset() and then divided by staff-space Staff_symbol_referencer::internal_get_position() and at magstep=2 staff-space is 2^(1/3) I think a standard-conforming implementation should give bit-identical floating-point results for these parallel computations, but suspect some compiler option is set to allow non-conformance (retaining the most-recent value in register with its guard bits intact for the comparison, maybe). In general, I think it wisest for us to code in a way that allows floating point to be inexact. The broader change that I considered was to count only only [+inf -inf] as the 'empty' interval in is_empty() as we considered doing before. https://codereview.appspot.com/217720043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
Phil Holmes mail at philholmes.net writes: I completed a full GUB build of lilypond yesterday That's very good news. I was beginning to worry. Thanks for taking the time to work through the problems. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4275: Allow user-defined rest styles. (issue 200860043 by nine.fierce.ball...@gmail.com)
On Sat, 31 Jan 2015 14:49:29 -0800, nine.fierce.ball...@gmail.com wrote: https://codereview.appspot.com/200860043/diff/20001/lily/rest.cc#newcode166 lily/rest.cc:166: + offset); On 2015/01/31 06:02:50, Keith wrote: I guess that get_position() could possibly trigger a full layout, but I can't tell for sure without booting Linux to experiment. I don't know what trigger a full layout means. I meant that get_position() might call functions that call other functions that choose line-breaks, set beam slopes, etc. I was trying to imaging how there might be a cyclical dependency. \new Staff \transpose c c' {r2 g'2} \\ {r2 d2 } \\ {e8 f g a b2} #(ly:set-option 'debug-skylines) \layout {\context { \Score \override PaperColumn.stencil = #ly:separation-item::print } } The ledgers on the upper half-rest potentially depends on beam slope, which depends on horizontal spacing. https://codereview.appspot.com/200860043/diff/20001/lily/rest.cc#newcode203 lily/rest.cc:203: On 2015/01/31 06:02:50, Keith wrote: The comments depend on the meaning of the word 'pure' as used by a subset of LilyPond programmers. You could just say: // Get a stencil, but if 'pure'=true do so without testing if the rest needs a ledger If pure=true, do not cache the result in the stencil-pure property. Oh. Then I was wrong about this patch making it less likely to repeatedly look up the rest glyph, and I am no longer see the point of a separate 'stencil-pure property. This patch only solves issue 4245 for users who know how to put their custom rest stencil in a pure-unpure-container. The pre-patch approach seemed reasonable, in that it evaluated the X/Y-extent by calling he stencil-building function, while leaving a link to that function in the 'stencil property for re-evaluation when time comes to print a possibly-moved rest. The problem with the pre-patch code is that it assumes the Rest.stencil points to the built-in default. After an earlier patch https://codereview.appspot.com/7300082#msg6 the usual way to handle stencils that change shape depending on other layout is to put the smarts in the X/Y-extent, rather than the 'stencil. It would be more similar to other Grobs if you can make the Rest.stencil actually 'pure' in the sense of returning a stencil without asking for the beam slopes that (probably) cause the cycle. Probably Rest.staff-position rather than get_position() can determine whether to use the ledgered version, without triggering beam slope calculations. Then the 'X/Y-extent callbacks can use get_pure_property(stencil) to determine the extents, and later the print routine will re-evaluate the stencil function. For that to work properly, all code that moves rests up and down would need to update the Rest.staff-position, but that seems like a good idea anyway. (This is because the CG says looking up a pure property should never result in a call to set_property.) Usually, when a property holds a function, LilyPond's evaluation routines evaluate the function once and then overwrite the property with the result. Progress is thus made in determining the layout. The idea of 'pure' evaluation of properties that hold functions was to delay progress in determining the layout. Joe Neeman's approach to choosing line- and page-breaks evaluates tentative layouts, requiring that we evaluate the functions in properties like 'Y-extent, but leave the function in place for future evaluation. The 'pure' methods leave any function in place, and also promise not to cause any irreversible progress in determining the layout. The rule that a 'pure' evaluation may not set_property() might help to keep promise not to irreversibly advance layout, but the rule does lead to a lot of re-computation. There is no problem setting properties that are known to be final before line-breaks are determined. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4274: Fix a cyclic dependency in Rest_collision (issue 193590043 by nine.fierce.ball...@gmail.com)
On Wed, 28 Jan 2015 17:40:33 -0800, nine.fierce.ball...@gmail.com wrote: Yes, the ledgered rest stuff is a big tangle. See https://codereview.appspot.com/200860043/ for the best I've been able to do without changing Rest_collision. Shucks. The similar issue with Accidentals (issue 3646) was not so bad. There we could look up the stencil one, put it in the 'stencil property like usual for purposes of line spacing, and then just after line-breaking remove the accidentals on notes tied to a previous note on the same line. I had hoped that for Rests we could look up a tentative glyph and put it in the 'stencil for use in spacing, then after the last step of vertical position is done, substitute the ledgered glyph when appropriate. I'll try to look at the new patch over the weekend, but if you didn't see a way to untangle the tangle I'm not likely to either. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4274: Fix a cyclic dependency in Rest_collision (issue 193590043 by nine.fierce.ball...@gmail.com)
On Tue, 27 Jan 2015 05:09:58 -0800, nine.fierce.ball...@gmail.com wrote: On 2015/01/27 05:21:47, Keith wrote: I discovered this when I tried to use get_property(stencil) from Rest::height while trying to fix issue 4245. It looks like some rests (whole and half rests) have two glyphs, with and without the ledger line, so the *final* stencil should not be generated until after rest_collision is finished, and maybe after beams are set and rests moved to avoid them, when we finally know if the rest needs a ledger. So when you ask for the stencil in order to figure note-spacing, the routine to generate the stencil asks for most all layout to be completed, so it knows in the general case whether it should fetch the glyph with a ledger. There is some code trying to handle that problem in Rest::generic_extent_callback (Grob *me, Axis a) (but it seems strange that if we want the a=Y_AXIS extent, it includes a possible ledger -- we would seem to need to know the height of a rest in order to know how far we need to move it to clear a note.) I do not like that it re-fetches the glyph from font forge every time generic_extent_callback() is called; hopefully the extent is cached somewhere. It seems that we want to look up a tentative rest glyph (either with or without ledger) to get the extent, figure out note spacing and line-breaking, and rest-collisions, and beaming, all with that extent, and then finalize the stencil at some point after we are finished moving rests vertically, but before printing. If you can follow the sequence of calls between Scheme and C, maybe you can find a simple way to get this tentative extent for issue 4245. Use of the pure-height in rest-collision.cc would assume, for purposes of placing a given rest, that every other rest is on staff-center. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce size of PDF files when inc. in *TeX docs (issue 194090043 by pkx1...@gmail.com)
On Tue, 20 Jan 2015 13:19:26 -0800, pkx1...@gmail.com wrote: https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode8 ps/encodingdefs.ps:8: /LilyNoteHeadEncoding [ On 2015/01/18 06:33:02, Keith wrote: This is a little different from FetaNoteheadsEncoding in 'mf/out/feta-noteheads11.enc' generated by 'scripts/build/mf-to-table.py' I need some advice on what to do here from Knut. https://codereview.appspot.com/194090043/diff/20001/ps/encodingdefs.ps#newcode108 ps/encodingdefs.ps:108: /noteheads.d0doFunk {01 show} def On 2015/01/18 06:33:02, Keith wrote: I suppose you use PS definitions here because the Scheme code does not know the encoding table, so the Scheme does not know what number to write in '\?? show' Again I cannot comment - Knut? https://codereview.appspot.com/194090043/diff/20001/scm/output-ps.scm File scm/output-ps.scm (right): https://codereview.appspot.com/194090043/diff/20001/scm/output-ps.scm#newcode64 scm/output-ps.scm:64: (ly:inexact-string i 8))) On 2015/01/18 06:33:02, Keith wrote: This is the old code that output PS 'show' rather than 'glyphshow' I don't know what to do here (if anything). Nothing need be done about these threee. They were only suggestions for simplification -- and note even suggestions, just hints that simplification might be possible. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mentorship
Kevin Barry barrykp at gmail.com writes: Thank you for responding. I would like to be able to contribute code to the project but I'm not really a programmer (I'm a music academic). I worked through some chapters of SICP in the past, so I have a rudimentary understanding of ... the first few chapters of SICP. I would like to learn more, if that's something that would help. Otherwise I will help any way that might be needed. I don't have any specific goals other than contributing somehow and maybe learning more about programming along the way. https://code.google.com/p/lilypond/issues/detail?id=703 is an interesting case. Eight people 'starred' it to indicate interest. The tricky bit is figuring out how we might make LilyPond easier to use for a variety of instruments. The relevant code is in Scheme, which I is the language used in Structure and Interpretation of Computer Programs ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB fail with smob templates
Phil Holmes mail at philholmes.net writes: Phil Holmes mail at philholmes.net writes: /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org-- lilypond.git- release-unstable/lily/include/smobs.tcc:131: error: invalid operands of types 'scm_unused_struct* (Grob::*)()' and 'scm_unused_struct* (Smob_baseGrob::*)()' to binary 'operator!=' This involves the address of a function in a templated class, the behavior of which didn't get resolved until C++ defect 115 and gcc 4.5.0 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11407 We could probably use some other test to see if the base mark_smob() function has been redefined in the derived class ... or put the responsibility to register mark_smob() into each derived class. OK: here's the result of a grep for gnu/gcc on the GUB machine: [...] It looks like a bit of a mish-mash. But if we were going to upgrade from what is mostly gcc 4.1.1/2, which version should we go to? Phil, How does the upgrade to gcc 4.8.2 look now ? The changes from Masamichi to librestrict look safe, and the later floating-point-endless-loop-eating-all-memory should be gone now that I've re-worked the skyline merge code. If gcc 4.8.2 still looks difficult, I'll look into problem with the templates. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: crosslinks update
Jean-Charles Malahieude lilyfan at orange.fr writes: I've locally merged master into translation, and before merging translation back to staging will correct bad cross-links. Sorry, I should have changed the rlearning links. Don't forget that translators use the English node names with at translationof. I do not know, however, who should update the translationof links. In Learning, translationof Accidentals and key signatures will be translationof Pitches and key signatures and translationof Accidentals will be translationof Pitch Alterations (the second is present in only some languages) In Notation the node Accidentals and translationof Accidentals remain unchanged. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce size of *TeX generated pdfs with lilypond snippets
Knut Petersen Knut_Petersen at t-online.de writes: The attached patch (against 2.18.2) changes the way lilypond uses fonts to draw glyphs. It avoids to used glyphshow for all emmentaler glyphs and adds encoding vectors to the emmentaler fonts before they are used. It also changes the ghostscript parameters used to generate pdfs from postscript code. I put the patch in the usual LilyPond form at https://codereview.appspot.com/191360043/ along with links to LilyPond history and the Ghostscript discussion. This helps with TeX documents having several LilyPond inclusions, but only after post-processing with pdfsizeopt.py. My first impression that we do not want this patch, but might be wise to go back LilyPond's former use of encoding vectors, if we can avoid whatever problems induced HanWen to move to using glyph names in the .ps. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce size of *TeX generated pdfs with lilypond snippets
On Sun, 28 Dec 2014 21:10:59 -0800, Werner LEMBERG w...@gnu.org wrote: https://codereview.appspot.com/191360043/ Unfortunately, this doesn't correctly include the new file `encodingdefs.ps' – it is tagged as a `binary'... Oops, forgot to change the settings. There is no existing file to compare to, so the 'download' link gives you as much as the comparison would. My first impression that we do not want this patch, Can you explain why? As Knut writes, he wants it encapsulated with a command line option so that it has be to explicitly activated. It should be thus straightforward to remove the related code as soon as a better solution becomes available. It was only a first impression. I thought that the effort to implement and at least minimally document the command-line option would be greater than the value to the users of TeX + LilyPond + pdfsizeopt (excluding Knut, who can already already use his patch). If you find it straightforward to encapsulate the code, then we can probably incorporate it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB and mpfr/mpc
Dan Eble dan at faithful.be writes: On Dec 8, 2014, at 08:21 , David Kastrup dak at gnu.org wrote: Masamichi HOSODA trueroad at sea.plala.or.jp writes: I agree that changing the algorithms is preferred; I didn’t mean to suggest otherwise. But if that’s not going to happen overnight, and there is a way to mitigate the problem in the meantime without touching the code, the people affected would value it. I tried -mfpmath=sse -msse2. It worked fine. bad_alloc didn't occur. Correct PDF was generated. It can be a workaround until changing the algorithms. It's not architecture independent. And may blow up for other reasons. But it’s good to know that the problem was floating point and not memory corruption, so thanks for testing it. This sounds like the runaway-loop problem we noticed when allowing zero-width items into skylines. I opened issue 4229 and will post a patch. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: mentorship
Kevin Barry barrykp at gmail.com writes: It depends on which part of LilyPond you want to help with as to the availability of people to help you. Is there a particular skill-set, set of issues or area of LilyPond you are particularly interested in? Thank you for responding. I would like to be able to contribute code to the project but I'm not really a programmer (I'm a music academic). I worked through some chapters of SICP in the past, so I have a rudimentary understanding of ... the first few chapters of SICP. I would like to learn more, if that's something that would help. Otherwise I will help any way that might be needed. I don't have any specific goals other than contributing somehow and maybe learning more about programming along the way. Kevin Given that you know a lot about how various kinds of printed music are supposed to look, and have an interest in how the program works, I suggest you watch for interesting bug-reports, follow the resolutions, and compile lilypond and test the patches if you can set up a computer to do that. Often we have enhancement requests http://code.google.com/p/lilypond/issues/detail?id=1503 that turn out not to be completely wise http://code.google.com/p/lilypond/issues/detail?id=4222 Sometimes the main question is one of how to design a feature to be useful http://code.google.com/p/lilypond/issues/detail?id=1321 http://code.google.com/p/lilypond/issues/detail?id=3279 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
Urs Liska ul at openlilylib.org writes: Keith wrote: I suggest looking over the existing partcombine bugs, and orchestral scores, to see what problems generally need solving. If there's anything I can do to help (without understanding more than basic Scheme and without any option to help on the C++ part) please let me know. Maybe it helps that I'm currently working on a big orchestral score? I remember that you were once trying to define \new Voices in the music you gave to \partcombine (but it seems you decided you did not need to) : http://lists.gnu.org/archive/html/lilypond-user/2014-10/msg00509.html This doesn't work because \partcombine rearranges the music into Voices that it defines, with names one two shared solo. With the color coding below, you can see that LilyPond's layout receives notes in four distinct voices from \partcombine. soprano = { d''2 f'' g'' a'' g''4 e''~e''2 R1 e''1} alto = { b'2. c''4 c''2( e'') R1 f''4 d''~d''2 c''1} \new Staff \context Voice = one { \override NoteHead #'color = #red } \context Voice = two { \override NoteHead #'color = #green } \context Voice = shared {\override NoteHead #'color = #blue } \context Voice = solo {\override NoteHead #'color = #grey } \partcombine \soprano \alto Dan has for a long time wanted to be able to control which voices get which notes, while still having \partcombine do the tedious work of finding where the parts can be joined into chords, figuring rests, etc. For example, it seems that one shared and solo could be reduced to one Voice, allowing us to continue dynamics from a solo part into a2, for example, when we force the transition with \partcombineChords. Dan's recent question was whether two notation elements from the same 'part' (e.g. FluteII) at the same moment, might ever need to go into to different LilyPond Voices for purposes of layout. The current mechanism describes, at any moment in time, the state of the combined music: unison, chords, solo, etc. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Sun, 30 Nov 2014 13:46:35 -0800, Dan Eble d...@faithful.be wrote: I have a question. If the Scheme code produces something like (‘apart “one” “two”) with “one” and “two” being the chosen output voices for the input parts at the moment, would it make sense to write those decisions back to the input parts themselves and have the iterator find them there? Would that allow finer control over the routing than there is now (say different routing of simultaneous events in the same part) or have any other advantages? I thought about it. I'm not sure. There is some reason that the existing \partcombine makes a separate split-list, rather than embedding the results of the analysis in the two parts. It might be simply because part_combine_iterator normally looks only at properties of the PartCombineMusic itself, not the sequential music contained within. The question seems to be whether the results of the analysis of \partcombine mostly describes the state of the combined parts, or mostly information about individual parts. I suggest looking over the existing partcombine bugs, and orchestral scores, to see what problems generally need solving. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
Dan Eble dan at faithful.be writes: I would like to break the rigid link between the split states (apart, unisilence, etc.) and the names of the voices into which the Part_combine_iterator routes events. The patch back at http://lists.gnu.org/archive/html/lilypond-devel/2008-09/msg00079.html makes sense, and seems flexible enough. The awkward part was naming the Voice contexts for the four states of music. Given that you need that information in the output of \partcombine pc = \displayMusic \partcombine {b2 b ...} {b2 b ...} for the iterator to see, it seems that music properties are the only places to put it. Maybe one property that takes the full list of context names... I would like the Scheme portion of the part combiner to dictate the names of the voices to use at every moment. Simply letting us specify the Voices _once_ for the whole output of \partcombine would help a lot. Include an example in your patch, where we want to rearrange the routing of soloI, unison, etc., to Voices mid-piece. The example in the 2008 thread, setting unison directions, is better done with \context Voice=shared {\voiceOne} than by changing Voices. The first use I can imagine is that I would usually want the shared Voice to be identical with the first-part Voice, but sometimes would want the shared events to go to the second-part Voice. In that case, I am thinking of the Voice output arrangement all at once, so specifying a list of four is natural. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Sat, 29 Nov 2014 14:44:48 -0800, Dan Eble d...@faithful.be wrote: On Nov 29, 2014, at 16:46 , Keith OHara k-ohara5...@oco.net wrote: Dan Eble dan at faithful.be writes: I would like the Scheme portion of the part combiner to dictate the names of the voices to use at every moment. Simply letting us specify the Voices _once_ for the whole output of \partcombine would help a lot. It would, and I’m glad you’re encouraging me to dig up my ancient patch to do that, but I wasn’t thinking of making any user-visible changes in the scope of the work suggested in this thread. (That could come later.) Well, if I can't use it, I am less motivated to review it. I am eager for either nameable outputs from \partcombine, or VoiceGroup, in LilyPond so we can have a stable and functional \partcombineUp/Down. Include an example in your patch, where we want to rearrange the routing of soloI, unison, etc., to Voices mid-piece. This suggestion was motivated by recent work on cases in which both parts are resting. If the desired action is to route only one of the voices to the shared voice, the Scheme half currently can only say “unisilence” and the Part_combine_iterator picks a voice. The problem is that sometimes it doesn’t pick well. It seems that the Scheme half has the information to make a better decision. Oh, so you meant let the Scheme portion dictate to partcombine_iterator which _input_ voice, as it iterates the music expression produced by \partcombine, to use. That makes more sense. However, the current problem with the iterator picking which input part to route to output Voice shared, seems best solved by your current patch, that marks these situations as 'apart-silence' whenever there is a difference between the input parts. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Part combiner: separate split state and voice names
On Sat, 29 Nov 2014 18:09:34 -0800, Dan Eble d...@faithful.be wrote: On Nov 29, 2014, at 18:48 , Keith OHara k-ohara5...@oco.net wrote: Oh, so you meant let the Scheme portion dictate to partcombine_iterator which _input_ voice, as it iterates the music expression produced by \partcombine, to use. My reasoning probably needs more clarification. The iterator takes sequences of events and routes them into voices. So, I thought that where now the Scheme portion produces simply ‘unisilence, it might produce something like (’silence “shared” #f) to tell the iterator that both parts are silent, the first part should be placed into the voice named “shared”, and the second part should be dropped. That’s what I meant by telling the iterator which output voice to use. Telling the iterator which input to use would be something like defining new states ‘unisilence1 and ‘unisilence2. Adding the new split-state tags 'unisilence1' and 'unisilence2' would preserve the relative roles of the \partcombine function and the part_combine_iterator The function \partcombine analyzes the music to describe which part or parts must be printed and when they should be combined in chords. That analysis is what you want to improve so that \partcombine {R1 R1} {R1 r4 b2.} reports that the first beat of the second measure is not really 'unisilence', but 'silence2'. The part_combine_iterator takes the results of \partcombine and decides what events to send to what Voices. Maybe you can make \partcombine completely take over the routing decisions. Then maybe the iterator would be reduced to following orders, and keeping track of which voices need to start or stop multimeasure rests. If \partcombine can only assume part of the responsibility for routing decisions, though, I seems cleaner to enhance the set of split-state tags to completely describe the results of \partcombine's analysis, rather than tell part_combine_iterator (partially) how to do its job. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)
On Fri, 07 Nov 2014 04:37:41 -0800, nine.fierce.ball...@gmail.com wrote: On 2014/11/06 05:44:50, Keith wrote: Changing the current global variable 'partcombine-chord-range' will not become the user interface. All I meant for that variable was to avoid repeating the same magic numbers three times. Is there a more idiomatic way to do that in Scheme? Should I have commented it? No, that seems fine as it is. I was trying to go through the possible user-interfaces systematically, and exposing that global variable was one possible interface. I had trouble articulating exactly /why/ simply changing that global variable wouldn't become the user-interface. I forgot the originally-suggested possible interface for the user to change the chord-range, by setting some context property of the temporary Voice contexts, the ones used by \partcombine to iterate through its inputs. Then we could change chord-range in the middle of the music, but I'm not sure the \partcombine logic can handle mid-music changes. The analysis is global, so if you double-stem the e' below, probably the slurs should separate and all slurred become double-stemmed (like \partcombine already does if there is a voice-crossing). \partcombine {e'( e' b' f')} {c'( e' g' c')} Changing chord-range just before the e' might (or might not) fool \partcombine. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads at gmail.com)
On Mon, 03 Nov 2014 05:11:02 -0800, Dan Eble d...@faithful.be wrote: On Nov 3, 2014, at 02:25 , Keith OHara k-ohara5...@oco.net wrote: That kind logic is already at the end of Time_signature::special_time_signature() now, but I don't see any way to use it for anything except 2/2 and 4/4. The logic used for neomensural, mensural, and any other style that is not explicitly named Oh. Now I see how it works. I should have read the doc-string at the bottom of time-signature.cc. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: how to make space between time signature and following material squeezable
This is https://code.google.com/p/lilypond/issues/detail?id=1785 For four years this space was too compressible, and would not stretch. The behavior did not match the names of the settings and code comments, so I raised issue 1785 to make the space rigid. Another option, semi-fixed-space in place of fixed-space, looked like a better choice for the space after prefatory matter. However we do not want the space to stretch, and there is no setting for compressible-only space. I'll mark issue 1785 as open. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: staff-symbol-referencer: ledger logic; issue 4184 (issue 167040043 by k-ohara5...@oco.net)
'notehead' noted. On Sat, 01 Nov 2014 23:43:34 -0700, lemzw...@googlemail.com wrote: /* If we are closer to the staff than the notehead, quantize for ledger lines. */ But I wonder whether this is the best description – it's rather about note heads and attached grobs having the same direction, right? Well, if by 'direction' of the notehead you mean its position relative to the staff, then yes, but he code does not use the word 'direction' for that. The comment says loosely what case we are trying to catch, and fits either old or new code. Matching the code would be if the Script is above(below) the Head but below(above) the staff, avoid ledger lines ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads at gmail.com)
Dan Eble dan at faithful.be writes: On Nov 1, 2014, at 18:48 , Noeck noeck.marburg at gmx.de wrote: * leave the default style alone * add to the C style: 4/2 - CC, 2/1 - cut-CC This would end the equivalence of default and C styles. Does that seem like a bad idea to any seasoned Lilypond developers? This is a bad idea. The time required for a user to find and understand the single-C style is greater than the time to find an example of a custom time signature made using markup on the LSR. Then the user can further customize the markup, or use the concept elsewhere. Any added complexity has some risk of surprising side-effects (e.g. https://code.google.com/p/lilypond/issues/detail?id=1926 ) Computers are helpful when they help us follow a pattern, as the single-digit style does, or a solid convention like the default style. Computers are frustrating when we need to figure out what they are doing. style defaultc¢ 2/4 2/1 4/2 8/4 3/4 6/8 C c¢ 2/4 ¢¢ cc 8/4 3/4 6/8 --- single-C c¢ [¢] ¢c 8/4 3/4 6/8 --- numbered 4/4 2/2 2/4 2/1 4/2 8/4 3/4 6/8 single-digit 42224836 If I needed to set the Schubert Op90n3, which looks like 4/2 to me, I might notice a single-C style in the manual, figure out how to use it, wonder why the c's are not barred where Schubert has them barred, look into the code, be confused, decide to use markup like I should have in the first place. The single-C style is borderline useful as a style, double-c is not. The current code has some logic to choose a glyph timesig.C34 if we set style=C in 3/4 time, but it seems that code is disabled by complex logic. Cleaning that up, as part of moving toward scheme markup, would be nice. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3286: add single-C time signature style (issue 164830043 by nine.fierce.ballads at gmail.com)
On Sun, 02 Nov 2014 18:11:58 -0800, Dan Eble d...@faithful.be wrote: On Nov 2, 2014, at 14:52 , Keith OHara k-ohara5...@oco.net wrote: The current code has some logic to choose a glyph timesig.C34 if... I followed everything you said except this, maybe because of the sudden mention of 3/4. Are you implying that changing the “complex logic to 1. if there is a glyph of the right name, use it 2. otherwise, fall back on numbered style would be a good idea? I was considering that. That kind logic is already at the end of Time_signature::special_time_signature() now, but I don't see any way to use it for anything except 2/2 and 4/4. I was arguing that as the use-cases get more specific, where you would want to pick a particular glyph, figuring out what options to set is harder than the direct approach: {\override Staff.TimeSignature.stencil = #ly:text-interface::print \override Staff.TimeSignature.text = \markup {\musicglyph #timesig.C22 \musicglyph #timesig.C22 } \time 4/2 b1 b1 } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ballads at gmail.com)
dak at gnu.org writes: On 2014/10/31 22:50:35, Dan Eble wrote: One thing just occurred to me. If this option is going into the UI, do you think the numbers should be 1-based for easier comprehension by musicians? As a UI, numbers instead of intervals (possibly represented only by a pitch in relation to c' like \transposition does) do not make much sense. I may be having trouble with the negative sentence construction, but if you mean that \partcombine d' c'' {} {} would be the intuitive way to indicate seconds through octave may be be combined into chords, then I disagree. Or, maybe you were joking. Numbers are very good for representing intervals; we use numerical names to represent them. Numbers are also good for representing differences in staff-position as well. Either 1-based or 0-based should be fine, if the docs consistently speak in terms of intervals of the chords, or in terms of the graphical separation between noteheads, respectively. Regarding such user interface extensions, I think we should rather go in the direction of URL:https://code.google.com/p/lilypond/issues/detail?id=1321#c30. Using context modifications makes it reasonably straightforward to add arbitrary named settings in arbitrary order on demand. Well, the currently-proposed patch at your link uses optional arguments to \partcombine, which would also be appropriate here for the chord-range, and later for 'no-solo. If that is the direction you mean, we all agree: optional input argument #'(2 . 8) If you mean to use context properties, they cannot be context properties of the output Voices because those are not created when the chord-range needs to have its effect. they cannot be properties of the temporary Voices for the same reasons that idea failed for the interface to force part-combine decisions. Generally issue 1321 concerns how the voices output from partcombine are set on the staff, so it should not change the input interface to partcombine at all. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)
On Thu, 30 Oct 2014 20:19:01 -0700, nine.fierce.ball...@gmail.com wrote: This is the beginning of the function I've actually been using: (define-public (dfe-determine-split-list evl1 evl2 chord-range enable-solo) @var{evl1} and @var{evl2} should be ascending. @var{chord-range} is a pair (min . max) defining the distance (in steps) between notes that may share a stem. If @var{enable-solo} is false, skip solo analysis and display the rests of both voices. If I understand, this is the style where if one part plays solo, you show the rests of the resting part on the score. J.F.Lucarelli used that style for Dvorák Symph #7 at http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1901 which is a good test-case for partcombine and its override functions. skip solo analysis doesn't make sense unless you read the code. I guess the idea is instead of using SoloI/II, display the rests of the resting part. Based on the feedback I've received so far, it seems that reimplementing this solo control like the forced partcombine states would be the best approach for that, leaving me free to add the chord-range as an optional parameter to \partcombine without fear that the options will get out of hand. What do you say? A reasonable choice, given that a no-solo override is related to the other PartCombineForceEvents (and given the fact that there is no context shared by the inputs to \partcombine, in which to set context properties like we would normally prefer). https://codereview.appspot.com/144170043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add chord range to make-part-combine-music (issue 144170043 by nine.fierce.ball...@gmail.com)
On Fri, 31 Oct 2014 15:50:35 -0700, nine.fierce.ball...@gmail.com wrote: One thing just occurred to me. If this option is going into the UI, do you think the numbers should be 1-based for easier comprehension by musicians? For example, use '(1 . 9) to allow chording unisons to ninths, rather than '(0 . 8)? Good to think of this now, because it is awkward to change later. I think either convention will be fine, if the doc strings are clear. I understood the zero-based system without hesitation, because your docstring said the numbers were the distance (in steps) between notes.There are probably cases where negative values are appropriate, so as to set two parts as chords even if they cross, on the conductor's score. Negative values make more sense on the zero-based scheme. https://codereview.appspot.com/144170043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: Issue 3324: Add explanation of clashing note columns warning (issue 154640043 by tdanielsmu...@googlemail.com)
On Thu, 23 Oct 2014 02:43:56 -0700, tdanielsmu...@googlemail.com wrote: On 2014/10/22 05:58:54, Keith wrote: I have been thinking that when the user gives explicit \voiceOne or \shiftOn to the voices, Lily should set those voices at the shifts requested, even if two voices have the same shift I had forgotten that I already pushed that patch. Not sure I understand this. Doesn't \voiceThree already set the shifts? Yes it does. I was emphasizing the case where a user sets the same shift on two voices, because I didn't realize that you had seen the patch that I was thinking of. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4169: Line and page breaking syntactic sugar (issue 156400043 by tdanielsmu...@googlemail.com)
On Tue, 21 Oct 2014 09:33:56 -0700, tdanielsmu...@googlemail.com wrote: I've decided to keep the reverts for the On predefs, since \once does not do what [the name implies] with these overrides. Yuck. The problem seems to be that the override takes effect at the first beat in a bar, after the paper-column for the previous barline has been generated, and the \once makes the override expire before the next bar. Unfortunately this also means that \override Score.NonMusicalPaperColumn.line-break-permission = #'allow R1 only has effect /after/ the R1. We have a workaround for that timing problem in \overrideProperty, and then \once works fine with autoLineBreaksOn = { \overrideProperty Score.NonMusicalPaperColumn.line-break-permission #'allow \override Score.NonMusicalPaperColumn.line-break-permission = #'allow } autoLineBreaksOff = { %?? \overrideProperty Score.NonMusicalPaperColumn.line-break-permission ##f \override Score.NonMusicalPaperColumn.line-break-permission = ##f } I put the %?? because I'm not sure whether it is more intuitive if \autoBreaksOff R1 should forbid a break before the R1, or mean here is your last chance to break, Lily. https://codereview.appspot.com/156400043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
On Mon, 08 Sep 2014 16:28:24 -0700, Dan Eble d...@faithful.be wrote: How about placing the voices inside a VoiceGroup context, moving the Accidental_engraver there, and leaving the NullVoice outside, like in my recent partcombine experiments? Usually, accidentals are reported up the context hierarchy. We can do things like this %% Cautionary accidentals to cancel accidentals anywhere on the score \set Score.localAlterations = #'() \set Score.autoCautionaries % 0 - current measure only = #`(Score ,(make-accidental-rule 'any-octave 0)) If reports of accidentals do not penetrate your VoiceGroup, it would be an exception to the general rule. I think it might be because localAlterations is not initialized in VoiceGroup. Another quick way to hide pitches from the Accidental_engraver note-heads is to set NoteHead.style=#'harmonic and Staff.harmonicAccidentals=##f I am leaning toward generalizing that mechanism so that any voice could say I should not have any accidentals printed. Then the Accidental_engraver handles things consistently: it knows that it generated no accidentals reports no accidentals for cancellation. On the other hand, maybe it is better to put NullVoice at the Score level, and let people, like you, who want the unprinted pitches to be logically associated with the Staff, move NullVoice on their own. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
On Sun, 07 Sep 2014 01:21:58 -0700, d...@gnu.org wrote: But messing up the basic grob definition by fetching internals and meddling through them locally: no. Well, you say messing up the basic grob definition I say reading the basic definition, and making a local modified copy We can do in LilyPond code with ly:grob-interfaces, making a copy with one interface removed, and storing the shorter list in the NullVoice context definition with an \override, so the changes to apply to grobs made in this context. LilyPond tries to be robust to grobs different interfaces, by checking has-interface() before using the properties associated with that interface. It turns out that there is a hierarchy in define-event-classes that says all note-events are musical-events and all musical-events are rhythmic-events. Maybe we have assumed that the correspondingly-named interfaces have a corresponding hierarchy. I'll try some other way of telling Accidental_engraver to ignore NullVoice. I'm trying to let people move NullVoice to Staff without reintroducing the known issue of the cancellation accidentals in \new Staff \new NullVoice {cis dis es fis} \new Voice {r4 c d e } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4083: Implement \tagGroup command (issue 137920043 by d...@gnu.org)
Patch set 5 will probably be fine. My concern was that someone would be confused that adding to the list of tags to keep \keepWithTag editorial { ... \tag#'editorial \tag#'score \bar'||' } \keepWithTag part.editorial { ... \tag#'editorial \tag#'score \bar'||' } can reduce the things that are kept. But that will not likely come up, and you do explain it in the docstring for \keepWithTag Don't put too much value on symmetry between how the tags in \keepWithTag, and the tags on each given piece of music enter, into the keep-or-remove decision. One set defines a single filter, the other describes each item that is going through the filter. The keep-or-remove decision is part of an asymmetric operation. On Sat, 06 Sep 2014 12:45:40 -0700, d...@gnu.org wrote: On 2014/09/06 18:55:42, Keith wrote: The old patch : \keepWithTag will keep music if any tag matches, removing music with unmatching tags, but ignoring tags in a different tagGroupfrom any of the tags to keep. But if any tag matches becomes very tricky to explain when one needs to implement a behavior where \tag A { \tag B ... is supposed to be equivalent to \tag A \tag B ... while \keepWithTag A \keepWithTag B is different from \keepWithTag A.B even when A and B are in different tag groups. The explanation above does cover the points you think might be tricky. \tag A { \tag B ... has not to date been equivalent to \tag A \tag B ... The explanation above says when B would be ignored by keepWithTag. If A is ignored, or if B is ignored, the expressions just above are equivalent. \keepWithTag A.B might keep more music than \keepWithTag A \keepWithTag B. The explanation above seems to make that clear, because it is easier to match any tag in A and B than to match each of A and B. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Die, instrumentSwitch. (issue 133390043 by k-ohara5...@oco.net)
On Sun, 31 Aug 2014 01:06:46 -0700, tdanielsmu...@googlemail.com wrote: A few minor comments below, but I don't see how we can just remove the instructions for setting up InstrumentSwitch without some replacement. InstrumentSwitch is used by \cueDuring and friends. \cueDuring itself does not use InstrumentSwitch; we were manually creating a temporary cueVoice just before the \cueduring. That takes the font-size from CueVoice to use for the printed text, which is nice, but any overrides require a non-obvious path through InstrumentSwitch \new CueVoice \with { \override InstrumentSwitch.direction = #DOWN \override InstrumentSwitch.font-shape = #'italic instrumentCueName = Tuba } \cueDuring tuba #DOWN { R1 g'2 bes' } So the replacement for this use of InstrumentSwitch _\markup\italic\teenyTuba is covered by the markup docmentation The history is long. I argued that the use of instrumentSwitch, to label the instrument playing cues, was useless http://lists.gnu.org/archive/html/lilypond-user/2010-10/msg00148.html and we removed it for some time, http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=4c1aa3b16f7b94ca32b0c022f60ed66826d031b0 http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=539934ff10d5ab0d4e06dedcb8ff5a54ed43d427 But we used a construction that used zero-length durations, which we later removed http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=4ab6e4df934e57c51dbbdbf2c209273c6cb5b888 Instead of ^\markup, I went back to the instrumentCueName; the reason I gave in the reitveld was complaints about the markup being tricky http://lists.gnu.org/archive/html/lilypond-user/2011-10/msg00118.html That was dumb. I had long-since stopped using instrumentCueName, so had forgotten that it is much more tricky to use. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4078: Doc: Use variables rather than instrument definitions (issue 138950043 by tdanielsmu...@googlemail.com)
On Sun, 31 Aug 2014 00:14:11 -0700, d...@gnu.org wrote: On 2014/08/31 06:58:47, Keith wrote: https://codereview.appspot.com/138950043/diff/1/Documentation/notation/vocal.itely#newcode2646 \set instrumentCueName = Flute This is the *other* use of instrumentSwitch, which I'll probably put back to a ^\markup I think one of the points of the instrument switches was that you could do as many as you liked in a row (namely, attaching the instrument switch to the start of any music variable to be used for a particular instrument) without triggering extraneous switch messages. ^\markup would seem to defeat that part of the original design. While we don't need the instrumentSwitch command as such, the respective engravers weeding out duplication still serve a purpose. This particular engraver seems to try, but fails, to suppress repeated identical settings. (Maybe incorrect use of Scheme's eq? to compare the strings?) { \set instrumentCueName = hautbois c'4 \set instrumentCueName = hautbois \set instrumentCueName = cor.Ang. c'4 \set instrumentCueName = cor.Ang. c'4 \set instrumentCueName = cor.Ang. c'4 } However, the (mis)use of instrumentCueName for labeling the instrument that is playing a cue (the topic of the documentation linked above) would not seem to benefit from suppression of repeated settings. The use-case is something like oboeNotes = \relative c'' { R1*32 \new CueVoice { \set instrumentCueName = flute } \cueDuring #flute #UP { R1 } g2 c, R1*32 \new CueVoice { \set instrumentCueName = flute } \cueDuring #flute #UP { R1 } g2 c, } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: indclude notnames bn, etc., in English (issue 133840043 by k-ohara5...@oco.net)
On Mon, 25 Aug 2014 00:28:14 -0700, pkx1...@gmail.com wrote: Excuse my ignorance, is this going to need any extra documentation or perhaps a changes.tely entry? https://codereview.appspot.com/133840043/ I read through the documentation and saw no changes except mentioning the alternative names for bn, etc., just after the alternative spelling 'ases' for 'asas'. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
On Sat, 23 Aug 2014 13:16:22 -0700, Dan Eble d...@faithful.be wrote: On Aug 23, 2014, at 08:03 , Dan Eble d...@faithful.be wrote: I think I’m really close (again!) to getting modern-voice-cautionary accidentals with combined-part stems by defining a new accidental style that disregards the part combiner’s voices. It looks to me like make-limited-accidental-rule limits the creation of accidentals to a particular context, but it seems the accidental engraver would still consider the history of pitches recently seen throughout the staff. Each context Staff, Voice, your previous SpecialVoiceGroup, keeps track of accidentals in a data structure called localAlterations. You might need to initialize it with \set SpecialVoiceGroup.localAlterations = #'() Your previous approach with the SpecialVoiceGroup seemed more promising, if that group includes only the separate voices for each part, and if you move the accidental_engraver to that group. It appears that in some cases both a cautionary and a normal accidental are typeset. If just the normal accidentals were typeset, the output of the following example would be exactly what I want. Is this a bug? In your latest code, the interaction between contexts and the setter routines is complicated, but as I understand it, the partcombine voices are still producing accidentals following the portion of the rule that was not restricted to NullVoice. That portion includes a rule to produce Cautionaries, but no rule for normal Accidentals. Those voices, made by partcombine, produce the cautionary (in black) because those voices didn't produce any normal accidentals. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
On Sat, 16 Aug 2014 11:29:29 -0700, Dan Eble d...@faithful.be wrote: On Aug 11, 2014, at 02:43 , Keith OHara k-ohara5...@oco.net wrote: I'll still put NullVoice in \score by default, so it doesn't interact with the accidental engraver, or anything else that we haven't noticed yet, and let you \new Staff \with { \accepts NullVoice } when you really want NullVoice included in the Staff. Isn’t this backwards? Not if there are uses of NullVoice as a completely invisible voice. If NullVoice does not show its own accidentals, alterations on NullVoice notes should not count for figuring which further notes need visible accidentals. The bugs with part-combined accidentals seem to arise from the part combiner’s destroying information (and creating misleading information) by reassigning notes to other voices. Instead of removing the NullVoice which has the valuable original information useful to the Accidental engraver, shouldn’t there be a way to make the Accidental_engraver ignore the voices created by the part combiner? Here is an example that shows combined issues with accidentals, lyrics, and dynamics. \accidentalStyle modern-voice-cautionary \partcombine \soprano \alto One person wrote the accidental-setter to accept per-voice accounting; a different person wrote \partcombine. I don't think either programmer considered using \partcombine with per-voice accidentals. A lot of what \partcombine does, printing solo and suppressing rests during solos, and single-stemming unisons, does not seem to be traditional for engraving four-part harmony. That makes me hope that someone has found a simpler way to combine two voices per staff without the complications of \partcombine. Your method of using NullVoices to handle the Accidentals instead of the Voices seems like a sensible way to adapt LilyPond. The combination of moving NullVoice to Staff, and changing the other Voices accordingly, could then be a packaged set of context definitions using the Voice building-blocks in a different way. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
On Sun, 10 Aug 2014 17:15:47 -0700, Dan Eble d...@faithful.be wrote: On Aug 10, 2014, at 15:40 , Dan Eble d...@faithful.be wrote: On Aug 10, 2014, at 14:55 , Keith OHara k-ohara5...@oco.net wrote: You could then enter \accepts NullVoice into just those Staffs where you use this technique. (Usually, \partcombine refuses to change the voicing during dynamics, resulting more often in doubled dynamics; I didn't know it would lose dynamics.) Doh! I just remembered that I’m not using the default functions for generating the part combiner split list. I’m using 2.16(?) with my own modifications that make it look better for vocal music. I’ll test the default and provide an example. Maybe I need to merge the scheme code from the newer release into my own. Please try this. The first score is missing a dynamic mark. The second score has both, with each on the correct side of the staff. So \partcombine has another limitation in that it sets \partcombine b4\f b\p as unison despite the different dynamics. Using \partcombineApart is the simple solution. If you meant \new Staff .. in your example then I see now NullVoice helps. \new Dynamics \soprano above the Staff would do similar, but then all the dynamics would be set on the same line. I'll still put NullVoice in \score by default, so it doesn't interact with the accidental engraver, or anything else that we haven't noticed yet, and let you \new Staff \with { \accepts NullVoice } when you really want NullVoice included in the Staff. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
On Sun, 10 Aug 2014 10:05:04 -0700, Dan Eble d...@faithful.be wrote: Patch set 3 seems more useful to me than patch set 4. Yep. I'll combine the best of both: 1) NullVoice in Score by default, so that the invisible notes do not affect the setting of accidentals 2) settings enabled so that you can move NullVoice to Staff without the bugs we know how to solve With NullVoice accepted by Staff, I am able to use NullVoice \with { dynamics engravers } to overcome another shortcoming of part-combined music, which is that simultaneous dynamics in the two source voices are lost if the notes to which they are attached are moved [by \partcombine?] into the shared voice. My workaround fails when the NullVoice is accepted by Score instead of Staff. You could then enter \accepts NullVoice into just those Staffs where you use this technique. (Usually, \partcombine refuses to change the voicing during dynamics, resulting more often in doubled dynamics; I didn't know it would lose dynamics.) Also, the documentation should probably include \killCues on the notes within NullVoice. Without it, there are warnings and extra notes in a score that has cues. (Unless there’s something that could be done to NullVoice to make \killCues unnecessary.) Here, I think it would be much better advice to enter the music so that the notes intended for NullVoice are not fed into \addQuote. That would seem more natural if NullVoice is entered outside of the \new Staff ... I don't use lyrics so have trouble imagining a practical example. The NullVoice context does not have any natural way to know that notes sent to it, are also being sent to \addQuote, nor to apply \killCues in some other context that uses \cueDuring on that qoute. I’m also trying to figure out if there is a simple way to add MIDI performance to NullVoice. Should there be a simpler pre-packaged way to do this? Currently, NullVoice provides the correct timing for MIDI output of any Lyrics attached to it, without sending any note-events to MIDI. That seems to be what we should expect from an otherwise-invisible voice. The most clear way of sending the notes, unprinted in the score to MIDI is with a separate \score for MIDI output, in which we put those notes (presumably stored in a variable) in a regular Voice. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 4024: Clarify break-align symbols and space-alist args in IR. (issue 114160044 by markpole...@gmail.com)
On Tue, 29 Jul 2014 13:12:47 -0700, markpole...@gmail.com wrote: Ah, I see. Here's the confusion: when paired with right-edge, *all* 5 of the spacing-styles actually do something (to be clear, they all do the same thing: they behave like extra-space, with space that doesn't stretch). Anyway, am I correct in concluding that right-edge is only intended to work with extra-space? I've edited the patch according to that understanding; please review and comment again if you would. That looks like what the code in 'break-alignment-interface.cc' would do. When I worked on the spacing code, the behavior of these space-alist settings was maddening, and I had always planned to simplify them. I like the idea of documenting them now, because that summarizes what we would have to think about in a convert-ly rule if we do simpify them. For some reason Rietveld doesn't show the deltas from the previous patch set (maybe because I rebased?), so you'll just have to read it again. We can still see that delta if we ask for it in the pull-down menus : https://codereview.appspot.com/114160044/diff2/1:60001/scm/define-grob-properties.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify the NullVoice context (issue 117050043 by k-ohara5...@oco.net)
On Sun, 27 Jul 2014 23:07:58 -0700, d...@gnu.org wrote: The ugliness is with messing up the whole grob definition of a NoteHead (which is fixed to the degree of being documented in the Internals Reference) inside of a particular context. I thought that was pretty, as well. We override the defaults of grobs all the time to suit particular contexts (\omit NoteHead for example). And this seemed a clear way of saying all the default interfaces of a NoteHead except rhythmic-head. I see that we usually don't change interfaces, though. It is easy to make the rest of the code accept an object with rhythmic-head-interface that is unattached to any Rhythmic_Column (just removing a test and warning in rest-collision.cc as I recall). The thing I didn't like about that was changing completely unrelated code to accommodate the weirdness of NullVoice. I don't see anything wrong with letting code work in more combinations than originally envisioned. Where is the point in having separate building blocks if you can only assemble them in a single way? Well, the code worked, but gave a warning. We might want to warn that someone is assembling blocks in a dangerous way. Looking at the history, this warning does not seem helpful. I can remove that warning, and restore the \omit Accidental* so that someone can have Staff accept NullVoice The point would be to stop the Tie_engraver from bothering about melismaBusy at all. Splitting the melismaBusy function from Tie_engraver, etc., and putting it in a new engraver does seem sensible. But isn't NullVoice for faking lyrics to a synthetic voice that is _not_ actually being printed? That would imply that we want to rather align to the existing NoteHeads/NoteColumns rather than the NullVoice one. And even if there are no actual notes (like in a chant situation), we'd rather align on a well-spaced pattern rather than one based on imaginary noteheads, optical stem adjustments and what not. (We don't get stem-corrections without stems.) My first inclination was to produce no NoteHead grobs. LyricExtenders and I think LyricHyphens needed work to help them find the NoteColums within their parent PaperColumns (like Janek made happen for LyricText). With all that, NullVoice can be just Devnull plus a melisma_signal_engraver. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Set X-parent of TextScript to NoteColumn instead of PaperColumn (issue 106640043 by janek.lilyp...@gmail.com)
On Sun, 27 Jul 2014 09:44:22 -0700, janek.lilyp...@gmail.com wrote: On 2014/07/26 21:36:12, Keith wrote: On 2014/07/26 06:49:41, janek wrote: Setting TextScript.cross-staff property to #f is required to ensure that there are no collisions between TextScripts and cross-staff notes: The concept of a cross-staff note seems strange. It appeared with the change for issue 2527 https://codereview.appspot.com/6827072#msg13 Hmm. Do i see correctly that the patch in https://codereview.appspot.com/6827072 was then partially reverted with commit 7891600a5dd421c1f25776ea3b405c64f4f14752 ? Right. NoteColumns are no longer cross-staff. If we mark TextScript.cross-staff=#t it collides with /any/ note. Cross-staff things are skipped during outside-staff placement axis-group-interface.cc:939 (though it seems they could, with more code, be placed relative to their parent staff, without being included in the parent staff's skyline). Most things that go cross-staff use the side-position-interface to avoid collisions, but the engraver for TextScripts does not put anything into its 'support' list so that method has no effect. I think the example of issue 1300 succeeds only because TextScript is put in a ScriptColumn with the accent. It collides in the stable release if there is no accent, or a trill in place of the accent. define-grob-properties says 'cross-staff' means that the object can change shape or move relative to its parent, depending on how staves are spaced on the page. TextScripts do not yet respond to staff-spacing, except when they are in a ScriptColumn that knows how to avoid a cross-staff beam, and that case seems inconsistent. Shall i revert commit 2371d6ba3b62d4d6dc349ab50fa0d76eadfba044 for now? I don't know. The case of issue 1300 was not a realistic input, and similar cases fail in the stable build. On the other hand, from the tracker issue, it looks like your commit doesn't provide us with any improvements. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
Dan Eble dan at faithful.be writes: On Feb 9, 2014, at 21:19 , Dan Eble dan at faithful.be wrote: Here is a work-around for https://code.google.com/p/lilypond/issues/detail?id=3834 NullVoice looks like a long list of workarounds. Now that Janek has independent Lyrics aligned as of version 2.19.9, entering with durations { La2. di4 da1 } works pretty well, and NullVoice need only watch for slurs, etc., and signal melismata. Try \layout { \context { \name NullVoice \type Engraver_group \description For aligning lyrics without printing notes \alias Staff \alias Voice \consists Tie_engraver \consists Beam_engraver \consists Slur_engraver % maybe a single scheme engraver to signal melismata }} ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: AccidentalCautionary in NullVoice
Dan Eble dan at faithful.be writes: It sounds like you are saying the issue with spurious accidental cancellations is fixed in 2.19.9 No, NullVoice still has those problems, because it still creates invisible note-heads, and applies various workarounds so that the note-heads don't have any effect except for positioning Lyrics. 2.19.9 positions Lyrics better if you enter Lyrics with durations, no longer needing the note-heads for positioning. This opens the door to avoid the problems in NullVoice. Entering lyrics with durations is inconvenient. So we want to get durations from music in a NullVoice. What I posted earlier was a suggested re-definition of NullVoice that does only what is needed. I see now that my suggestion does not align lyrics to moments between printed note columns (which is done if you enter lyrics with durations) so we would have to include a Rhythmic_column_engraver and convince it to produce note-columns even when there are zero note heads. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fix Issue 2462. (issue 108280044 by janek.lilyp...@gmail.com)
On Fri, 04 Jul 2014 14:38:19 -0700, Janek Warchoł janek.lilyp...@gmail.com wrote: 2014-07-04 23:26 GMT+02:00 Janek Warchoł janek.lilyp...@gmail.com: That's actually not what i want to do; I apologize for being unclear. I *want* the columns to behave the same way in case of both accidentals and lyrics (and everything else). The desired behaviour is that changing min_distance shouldn't affect ideal distance. Sensible, for the data object Springs. The special behavior when min_distance is larger or within 0.3 of ideal is confusing. The fact that the special behavior appears only after using merge_springs() makes things more confusing. Notice that frax/springs keeps that special behavior, in Spring::length(). The natural, force=0, length of a spring is *always* at least min_distance+0.3 Achieving this [desired, not-special] behaviour when columns arewide due to lyrics is simple: but there are side effects (too tight spacing in some cases, for example in beam-rest-extreme.ly) which i'm unable to fix. Trace back and see what code uses that +0.3 to good effect, though probably by accident. Only spacing-spanner.cc uses Spring::merge_springs(), and when setting 'beam-rest-extreme.ly' it is used to 'merge' only one spring! So one good effect is that accidentals are prevented from getting too close to the previous note. That would be better handled with padding associated with the accidental http://code.google.com/p/lilypond/issues/detail?id=3869 You could limit the changes in one patch, if you like, by moving the ideal = max(idea, min_distance +0.3) to the point where spacing-spanner.cc finds min_distance to avoid collisions. A magic number is better than a magic number in a mysterious place, and making the 0.3 a parameter is safer to do after we narrow down its beneficial effect. If merge_springs() behaves more simply, it might do a little better for http://code.google.com/p/lilypond/issues/detail?id=3887 (I notice that the option 'average-spacing-wishes' is no longer checked; the code seems to always average spacing between voices.) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: fix Issue 2462. (issue 108280044 by janek.lilyp...@gmail.com)
On Wed, 02 Jul 2014 23:56:20 -0700, janek.lilyp...@gmail.com wrote: you should try to make the change consistently everywhere ? Yes, that's what i'm aiming for. However, as you remember, some of these changes produce unwanted side-effects I remember you said there were side effects, but you did not until now say what they were. You say you want ideal spacing to be at least as large as the required 'rod' that prevents collisions, if the collisions involve accidentals, 0.3 is needed to slow down approaching min_distance_, for example in beam-rest-extreme.ly - because of the accidentals and suspended notes, the min_distance_ is bigger than distance_, which means that even for natural (ragged-right) spacing the springs would be set to the min distance (making the accidentals touch previous notes). We want to add some space [to the ideal distance_ -KOH], so that the accidentals willtouch previous notes only when there is a significant compressing force. but not if the note-columns are wide due to lyrics. Description: When objects like lyrics are added to the PaperColumns, LilyPond inserts rods between these columns to ensure that the objects won't overlap. However, the ideal distance should remain unchanged. It is surprising that you distinguish those cases by lengthening the ideal spacing in merge_springs() but not lengthening the ideal spacing in set_blocking_force(). I would have expected both functions to be used in each of your examples, the one with accidentals and that with lyrics. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR Pitches.itely - added 2 new snippets (issue 110240044 by pkx1...@gmail.com)
On Mon, 30 Jun 2014 14:40:17 -0700, pkx1...@gmail.com wrote: Is it worth making the Notation Reference longer? What do you suggest? Depending on your opinion about the NR length, maybe leaving these examples in lsr only. https://codereview.appspot.com/110240044/diff/40001/Documentation/notation/pitches.itely#newcode1325 Documentation/notation/pitches.itely:1325: \override Staff.KeySignature.flat-positions = #'((-5 . 5)) On 2014/06/29 03:17:00, Keith wrote: This already shows how to print key signatures over a different or wider range of the staff. You might consider this good enough. I don't understand what you mean. Good enough compared to what? Good enough alone, without the creating-custom-key-signatures.ly snippet. The double-clef would fit in tweaking-clef-properties.ly Or, the double-clef might be a better example for \translate in appendix A.10.2 \markup { \combine \musicglyph #clefs.C \translate #'(2.5 . 2) \musicglyph #clefs.G } If you don't mind the NR length, this all looks good as it is. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 3254: align unassociated lyrics using NoteColumn extent. (issue 108110044 by janek.lilyp...@gmail.com)
On Thu, 26 Jun 2014 01:01:11 -0700, janek.lilyp...@gmail.com wrote: pushed as c73b41b3e7be6d7280c6336cf03610cd7aed3000 - thanks for review! I'll post a follow-up patch later today. https://codereview.appspot.com/108110044/ It seems that after this patch, the old well-tested Devnull context should do everything that the new NullVoice does, without the complications and remaining problems. Do you also expect this to be true? If you understand the full purpose of NullVoice and can check that Devnull fills the need, you might create a patch to make NullVoice a simple alias for Devnull (and reverse any patches related to NullVoice that we wouldn't otherwise want in the code). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line-breaking bug in 2.19
On Sun, 16 Feb 2014 23:50:06 -0800, Keith OHara k-ohara5...@oco.net wrote: On Sun, 16 Feb 2014 17:33:16 -0800, Keith OHara k-ohara5...@oco.net wrote: On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł janek.lilyp...@gmail.com wrote: 2014-01-17 17:55 GMT+01:00 Keith OHara k-ohara5...@oco.net: Starting with version 2.19.0, the bassoon part from http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 gets a short line. I can revert the commit https://github.com/Keith-OHara/lilypond/commit/a389298c5c2fc5cfce75be1600c2da85b4be5acb (resolving conflicts by hand) to remove the problem. \version 2.19.1 \new Staff \relative c' { \override Score.SpacingSpanner.shortest-duration-space = #1.75 e16*2/3 f g e d c d e f e d c d e f e g g f e d e c c \break e1 e e e } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line-breaking bug in 2.19
On Mon, 17 Feb 2014 00:24:22 -0800, Keith OHara k-ohara5...@oco.net wrote: On Sun, 16 Feb 2014 23:50:06 -0800, Keith OHara k-ohara5...@oco.net wrote: On Sun, 16 Feb 2014 17:33:16 -0800, Keith OHara k-ohara5...@oco.net wrote: On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł janek.lilyp...@gmail.com wrote: 2014-01-17 17:55 GMT+01:00 Keith OHara k-ohara5...@oco.net: Starting with version 2.19.0, the bassoon part from http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 gets a short line. I can revert the commit https://github.com/Keith-OHara/lilypond/commit/a389298c5c2fc5cfce75be1600c2da85b4be5acb (resolving conflicts by hand) to remove the problem. Tuplets are not required, so here is a closer-to-minimal example: \version 2.19.1 \new Staff \relative c' { \override Score.SpacingSpanner.shortest-duration-space = #1.6 e16 f g e d c d e f e d c d e f e g g f e d e c c f e e d e c c f \break e1 e e e } ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line-breaking bug in 2.19
On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł janek.lilyp...@gmail.com wrote: 2014-01-17 17:55 GMT+01:00 Keith OHara k-ohara5...@oco.net: Starting with version 2.19.0, the bassoon part from http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 gets a short line. I have tried to minimize the example, but unfortunately convert-ly is not enough to make the score compile with 2.19, I used one tiny bit of Scheme, which convert-ly cannot update automatically. I put a version of the sources that works with version 2.19 at http://k-ohara.oco.net/Lilypond/ With that version the short line is in the Trumpet part (not the Bassoon part). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: line-breaking bug in 2.19
On Sun, 16 Feb 2014 17:33:16 -0800, Keith OHara k-ohara5...@oco.net wrote: On Sun, 16 Feb 2014 13:58:01 -0800, Janek Warchoł janek.lilyp...@gmail.com wrote: 2014-01-17 17:55 GMT+01:00 Keith OHara k-ohara5...@oco.net: Starting with version 2.19.0, the bassoon part from http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 gets a short line. I put a version of the sources that works with version 2.19 at http://k-ohara.oco.net/Lilypond/ With that version the short line is in the Trumpet part (not the Bassoon part). There is a line in the Trumpet part that consists of one measure of cue notes, and lilypond 2.19 puts this one measure alone on a line. I can copy the cue notes directly into the Trumpet part, in the usual Voice not the CueVoice, and still see the problem. This single measure is a full measure of triplet 16th notes. I can rewrite them as 16*2/3 notes and still see the problem. If I rewrite as 16 32 32 the problem goes away and I see reasonable line-breaking. I can revert the commit https://github.com/Keith-OHara/lilypond/commit/a389298c5c2fc5cfce75be1600c2da85b4be5acb (resolving conflicts by hand) to remove the problem. I still have not been able to extract an example of reasonable size that shows the problem. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: NR: Removed example for alternate repeats (issue 61170044)
On Mon, 10 Feb 2014 04:31:25 -0800, pkx1...@gmail.com wrote: These three examples are more useful as regression tests than as documentation. Are they robust enough? Do they exercise each property properly? They seem good enough, but it is not essential to add them to /input/regressoin/ They won't get lost, being findable in the mailing list archives, and there is tracker issue 3841 to remind us to get the newly-working behavior into regression tests eventually. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regtest for new glyphs necessary?
Marc Hohl marc at hohlart.de writes: I am about to upload a patch for these four glyphs within the next days, but I wanted to ask whether a new (or enhanced existing) regtest is necessary for this type of enhancement? They could conceivably be broken accidentally, by a mistaken change to our .mf files or a metafont bug, so a regression test is useful. LilyPond probably has too many tests, but you could add to 'clefs.ly' ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: note-spacing: stretch somewhat uniformly; issue 3304 (issue 36830045)
On Thu, 26 Dec 2013 22:47:41 -0800, Trevor Bača trevorb...@gmail.com wrote: I suppose it's important to note that all of my scores use proportional notation everywhere. So I imagine that most of the horizontal spacing improvements don't actually impact my scores. (The recent spacing changes optimize Lily's *default* spacing, correct?) This patch does concern the default method of horizontal spacing. The bug that this is meant to fix (http://code.google.com/p/lilypond/issues/detail?id=3304) can be seen even with proportionalNotationDuration, if there are interleaved rhythms on a line that is stretched or compressed. Probably, though, you also set 'uniform-stretching', which removes the problem. This patch makes the default spacing case stretch/compress more like it does with uniform-stretching, while keeping the detailed spacing adjustments in response to things like neighboring stem directions that 'uniform-stretching' would normally skip. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)
On Sun, 22 Dec 2013 11:45:49 -0800, Devon Schudy dsch...@gmail.com wrote: Unfolding during iteration doesn't extend well to voltas, because it changes their length. Even if the length is updated, the old length has already been used by the parent iterator to compute moments for subsequent events. So unless this can be changed, Okay. That eager evaluation of lengths by the iterators also frustrated my attempt at a \RestUntil function (to fill the tuba part, for example, with rests until the next tempo change) so we might change that someday. Keith wrote: I think we need the tremolo-type property to hold the 32 from input c2:32 On TremoloEvent, yes. But do we need it on TremoloRepeatedMusic? I suppose it might be handy for tweaking. I see. It is not very likely that anyone refers to tremolo-type of the Music, so possible tweaking does not seem enough reason to keep it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatically unfold percent and tremolo repeats in MIDI output. (issue 769) (issue 40720060)
On Sat, 21 Dec 2013 00:23:05 -0800, d...@gnu.org wrote: Keith comments: The other limitation of \unfoldRepeats is that it fails to see repeats in parallel expressions {\repeat volta 2 s1 } {c2 d2} while this approach using the iterators will see them and be able to expand them when requested. I think he is wrong about that. I don't see anything inherent in this code that would work differently here. I meant the future of this approach, after there is the option to unfold volta repeats. I was thinking that by doing the unfolding in the iterators (as opposed to working on music expressions as \unfoldRepeats does) it would be at least possible to expand volta repeats. It would not be easy, because there are nonsense cases like {s1 \repeat volta 2 s1 } {c1~ c2 d2} and probably some very similar things that actually make sense. It would take significant work to communicate between various iterators, similar to the efforts Mike made to break slurs at repeats. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Sat, 14 Dec 2013 23:57:20 -0800, Mike Solomon m...@mikesolomon.org wrote: On Dec 15, 2013, at 12:58 AM, Keith OHara k-ohara5...@oco.net wrote: The most transparent reorganization might be to have all properties that can hold data use the usual callback mechanism: where the callback function is used just once, and the data it returns takes the place of the callback. This is indeed transparent, but given that a single object can return many pure heights based on the begin/end values being used or based on how far downstream we are, it’s not clear what this property would look like. There would be no more 'pure properties' as you use that term. The property 'height' would give the final height. If the object changes height based on layout, 'height' would be a callback. Code that works while layout is tentative would not call callbacks, but could lookup a property 'height-estimator' that links to the pure_height() function. This seems to get the same result we have now while adding a lot of extra properties. Extra properties on those Grobs that use them, in place of the unpure-pure-containers. Reorganization for transparency makes complexity visible. I like the idea of there being a single property that is honed in on with successive estimates until we get the perfect value. But so far, we do not use the previous estimate of a property to inform the next estimate. In fact, with only one slot to hold either the property value or the function to compute it, Grobs keep secret any progress they have made toward a better estimate, and even forget it themselves. Simple properties like 'height' could hold either data or simple callbacks that are executed once, with these callbacks allowed to *pull* information from other grobs and cause their callbacks to execute as well. Separate function-properties like 'height-estimator' could provide estimates when we must avoid forcing other decisions. They could use /data/ in other Grobs' properties, but not callbacks. These function-properties belong to the Grob, so can write the result to its 'height when that estimate is good enough to share. You have wanted to use a preliminary shape for cross-staff slurs to inform layout, for example. The code re-shaping things like Slurs after page-spacing could *push* an improved shape onto the 'stencil' and 'height' properties. Something about using the container (the property) as a holder of the estimates and the final item itself feels sound design-wise. At the moment, the property does not hold any estimates; it holds either the final data or various functions to fetch the data, and some of these functions operate under subtly different rules, both in your unpure-pure-container system and Joe's former system. This subtleties confuse people: issues 3512 and 3482, and the difficulty I had in this thread understanding that the same function was called multiple times to repeatedly build 'vertical-skylines around each letter. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Sat, 14 Dec 2013 00:49:43 -0800, Mike Solomon m...@mikesolomon.org wrote: On Dec 14, 2013, at 9:35 AM, David Kastrup d...@gnu.org wrote: Most of the contortions seem focused about when or when not and how to pass begin/end columns. It would seem to make sense to turn them into dynamic parameters *begin* *end* that you can then query with (*begin*) and (*end*). If (*begin*) returns ##f, we can assume being in a pure calculation. That would seem to get rid of most of the current interface complications. I can see the utility of having one function instead of two for these things. The current pure and non-pure functions are often wrappers around a single internal function that has a bool parameter called “pure”, so this would eliminate the need for the wrapper functions. Well, the presence of 'begin' and 'end' parameters is a far less important distinction, between the pure-estimate and unpure-final versions of a function, than the vastly different roles of these functions in layout. When the same code is shared too much between these roles, LilyPond does some immensely silly things. DynamicLineSpanner uses the same code for 'vertical-skylines' in both 'pure' and 'unpure' roles. This causes a spanner pf to generate a detailed skyline for each distinct 'start' and 'end' column that contains the spanner among the line-breaking possibilities that LilyPond considers and also for start=0 end=10 and for start=0 end=2^31 [2]. But the horizontal positions have not been set when the pure-estimates are requested, so these skylines all describe a 'p' overprinted upon a crushed hairpin and an 'f'. Several considered line-breaks might have the same 'start' and 'end' around the hairpin, but the upper-level axis-group structure caches results for each start/end pair so just one skyline is generated for each distinct pair request. The path that generates these calls, however, bypasses the cache, and causes repeated generation of the skyline. (My suggested patch stores the individual skylines for each Dynamic, so the 'p' and 'f' glyphs are fetched and outlined just once, and only the skyline-merging to outline the pf is repeated.) The operations in side-position-interface, when called as 'pure', compute locations that are not quite so silly, but not very useful. The word 'pure' might have too much a connotation as 'good'. Maybe we should rename 'pure' - 'shitty_hack_estimate_because_I_am_unable_to_order_layout_decisions_better_please_forgive_me' -- The most transparent reorganization might be to have all properties that can hold data use the usual callback mechanism: where the callback function is used just once, and the data it returns takes the place of the callback. The layout engine could use get_property_data() freely, but before it has set line-breaks the layout engine would refrain from calling any callback functions directly. Instead of a callback for 'height', layout functions would look up the grob property 'tentative-height-estimator' where tentative-*-estimators are always functions that take the start-end columns as parameters. The tentative-height-estimator for something like a Slur or VerticalAxisGroup would return its best guess for the height, while the estimator for a Clef would simply get_property(height) causing its stencil to be formed and leaving the resulting data in the 'stencil' and 'height' properties for further use. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Sat, 14 Dec 2013 14:58:52 -0800, Keith OHara k-ohara5...@oco.net wrote: Several considered line-breaks might have the same 'start' and 'end' around the hairpin, but the upper-level axis-group structure caches results for each start/end pair so just one skyline is generated for each distinct pair request. The path that generates these calls, however, bypasses the cache, and causes repeated generation of the skyline. Sorry, I was pointing a few lines up when I typed these calls but of course you can't see that. That second sentence should be : The path that generates the calls with start=0 end=10 and with start=0 end=2^31, however, bypasses the cache, and causes repeated generation of the skyline. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Thu, 12 Dec 2013 23:07:19 -0800, Keith OHara k-ohara5...@oco.net wrote: I am happy to say that I was wrong here. Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo I had failed to notice how the 'pure' calls to vertical-skylines are implemented. Most properties, if directed to a callback function, have result of the callback function replace the pointer to that function. This way the function does its job just once. Sizes of spanners, that do depend on layout but are needed to evaluate potential layouts, are cached in Spanner::get_cached_pure_property() for each combination of 'start' 'end' columns that define the line of music on which they might appear. If the property-lookup is 'pure' (tentative) then usually callback functions are not called. Previously, functions providing stencils of objects whose shape does not depend on page-layout were on a pure-print-callback list, so their shapes could be used during layout decisions. At the moment, there is an unpure-pure-container wrapper around the (expensive) function that builds skylines for text. For some reason this allows repeated function calls to re-compute the property, even when the 'pure' and 'unpure' versions are the same. Somewhere there should be a way to mark the skylines as independent of layout and the method should be used for vertical-skylines of text. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Fri, 13 Dec 2013 01:38:23 -0800, Werner LEMBERG w...@gnu.org wrote: I will check whether I can improve that in FreeType. Is there a reason this would have such a significantly different impact in Windows? No. It's exactly the same code on both platforms. However, for lilypond, even a single-element cache would help, see attached quick'n'dirty patch (for FreeType). The repeated look-ups of the same character, however, are not likely to be successive calls to FT_Get_Name_Index(), so will not find the answer in such a cache. I do see how sfnt_get_name_index() does a linear search through the font to find a matching name. Much better if LilyPond could look up text characters by their Unicode encoding. The issue with Lilypond 2.17.95 is a more complicated than the original case where we noticed that these look-ups took longer on Windows: http://code.google.com/p/lilypond/issues/detail?id=1926 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Dec 13, 2013, at 9:07 AM, Keith OHara k-ohara5...@oco.net wrote: Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo The layers of functions that result in repeated calls to the skylining code have changed since the original skylines patch. The latest change was author David Kastrup d...@gnu.org Thu, 21 Feb 2013 19:02:48 + (20:02 +0100) Issue 3200: Make ly:make-unpure-pure-container accept a single callback Like with fixed values, this gets duplicated for the pure value as well, but converted into a callback taking two more arguments (which are ignored). This type of unpure-pure-container is not a container of two functions but rather a single callback function, that promises to refrain from forcing line-break decisions (to be 'pure') and that ignores the two arguments giving the start- and end- of the line it would be on in the tentative line-breaks under consideration. In this case repeated calls will recompute the same value, so I see no reason to keep the function-call pointer in place after the first use. So I suggest we treat this case as if it were a simple lookup of a property, rather than a 'pure' lookup. http://codereview.appspot.com/42190043 This case includes the function to find skylines for Lyrics and TextScripts. On Thu, 12 Dec 2013 23:45:45 -0800, Mike Solomon m...@mikesolomon.org wrote: My LilyPond is not working for some reason (see previous e-mail about debugging). Once I get it up and running, I’ll have a go at this. Could you look at issue 3512 first ? If we get clear on what unpure-pure is all about we might be able to simplify things. For example, it seems to me that the unpure-pure-container with a single callback is not logically connected to any other unpure-pure-containers, so should have its own tag and different behavior. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Fri, 13 Dec 2013 23:05:49 -0800, David Kastrup d...@gnu.org wrote: That does not make sense. If you want call-once behavior, you can just use a callback. At the moment, the decision on whether to preserve the callback pointer in the grob property, or fill the property with the returned value, depends on the method used to request the property, get_pure_property() versus get_property(). A callback would be called multiple times (and it would have to support the unpure-pure calling convention). The information of whether the callback is providing a value that /should/ be kept as final is better stored in the Grob itself, so I am thinking of ways to reorganize. The way stencil callbacks are evaluated now is interesting. The stencil callback itself is a simple callback, but when the layout engine wants to know the size of a stencil it does get_pure_property(Y-extent). Y-extent property is set to either execute the stencil callback, or estimate a height without building the final stencil, as appropriate for each Grob. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 22:44:18 -0800, Keith OHara k-ohara5...@oco.net wrote: After a brief look at the code, it looked like for each glyph being laid out there is one extra call of Open_type_font:: or Pango_font::name_to_index(), which is the function called by find_by_name() that caused the extra time with issue 1926. I am happy to say that I was wrong here. Open_type_font:: and Pango_font::name_to_index() each call FT_Get_Name_Index(). Inserting print statements to trace those calls I find that FT_Get_Name_Index is called: 7 times for each character in a Tempo 5 times for each character in a Text Script ... 1 time for each notehead 5 times for each rest If I use boxes instead of glyph outlines for vertical-skylines: 0 times for each character in a Tempo (probably just uses the Unicode index) 0 times for each character in a Text Script ( ) 1 time for each notehead 5 times for each rest So the outlines for each letter are re-built several times (through some path in the code that I have not yet found). Whether the expensive part is the FreeType function call, or joining about 60 boxes per character into the skyline for the word, there is a good chance that we can save both by building skylines once for each word. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Mon, 25 Nov 2013 00:10:08 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: I timed one big score, Movement 1 of http://www.mutopiaproject.org/cgibin/piece-info.cgi?id=1793 2.16.2 2.17.95 WinXP 2m 30s 5m 10s Fedora 1m 50s 1m 50s Have you used the GUB-compiled binary package, or Fedora's built-in or a self-compiled package? I think that you probably can only make platform-specific comparisons if you use GUB for all. GUB-compiled packages in all cases give the same results as above. Most of the increase in time to set this score happened between 2.17.0 and .1 2.16.2 2m 30s 2.17.0 2m 28s 2.17.1 4m 06s so it is probably the issue 2148 patch, use of outlines instead of boxes for layout. I did speed-test that patch, but under Linux. Maybe the system calls to the font server, to get outlines for the glyphs, take longer under Windows. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote: When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: normal music had almost no effect. As a result, I concluded with skylining was the correct default. I agreed about the default being good, but normal music was 30% slower http://lists.gnu.org/archive/html/lilypond-devel/2013-09/msg00234.html (We see there the effect of Mike's commit that cached the (millions) of page-fillings from Joe's line-breaking scheme; that caching made 2.14 3x faster than 2.12.) I had seen the same, moderate, effect on Linux, but the same music suffers more with skylines on my WinXP system. I'll try your Mikado on my WinXP system, to narrow down the key components that show the 2x slowdown. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 09:57:20 -0800, Keith OHara k-ohara5...@oco.net wrote: On Tue, 10 Dec 2013 01:59:09 -0800, Phil Holmes m...@philholmes.net wrote: When I benchmarked with and without skylines, I found there was only a noticeable difference with a lot of markup or similar: normal music had almost no effect. As a result, I concluded with skylining was the correct default. I'll try your Mikado on my WinXP system, Chorus Number 5 takes 17.2s with 2.16.2, and takes 31.1s with 2.17.95 This ratio of times is worse than Phil saw when he timed the full Act1 using Win64Vista. So maybe the larger slowdown is localized to WinXP. Disabling all the vertical-skylines-from-stencil-integral settings brings the time down to 16.2s with version 2.17.95. The last time we had a doubling of time required on Windows relative to Linux, issue 1926, it was repeated calls to find_by_name() that go through Pango to the font server. Here the outlines seem to be properly cached; it looks like each text glyph is looked up just one extra time. The call the to FreeType glyph-outline code might cause the extra time, or maybe Guile is less efficient on WinXP, as every nook and cranny in every letter is represented in the skylines objects in Scheme. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anyone notice speed of 2.17.95 on Windows ?
On Tue, 10 Dec 2013 17:22:19 -0800, David Kastrup d...@gnu.org wrote: Keith OHara k-ohara5...@oco.net writes: The last time we had a doubling of time required on Windows relative to Linux, issue 1926, it was repeated calls to find_by_name() that go through Pango to the font server. Here the outlines seem to be properly cached; it looks like each text glyph is looked up just one extra time. Once every time it is written, or once per document? And what does just one extra time mean? One extra per which occasion? After a brief look at the code, it looked like for each glyph being laid out there is one extra call of Open_type_font:: or Pango_font::name_to_index(), which is the function called by find_by_name() that caused the extra time with issue 1926. That is, for every 'mf' in the piece, we look up two glyphs by name 'm' and 'f' from the font to get a skyline for the 'mf', each skyline is built just once. The look-ups are extra over those used to implement the stencil. One extra lookup per glyph might be enough to explain the difference. We need to look up the glyph to get a skyline, but maybe could cache its index into the font in the stencil. What did you mean to suggest here? : In this case, the answer is to cache frequently accessed information instead of requesting it again and again. The call the to FreeType glyph-outline code might cause the extra time, or maybe Guile is less efficient on WinXP, as every nook and cranny in every letter is represented in the skylines objects in Scheme. If there are differences in speed, I can't imagine them to be in anything but possibly garbage collection/allocation, and it seems unlikely that they would not then have been apparent with other uses. Probably true. I mentioned these possibilities after noticing that there are quite a few boxes required to represent the outline of each letter.. What did you mean to suggest here? : Maybe caching in unsuitable form? Cached data should be in a form directly usable for processing (with some possible tradeoffs between memory impact and unpacking speed), not in the form that function/library/system calls will return it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
On Sat, 30 Nov 2013 23:56:09 -0800, janek.lilyp...@gmail.com wrote: I have one request: this patch makes the situation better, and even if the baseline-skip approach is wrong, it was already used that way so it's not making things worse. I suggest to push this patch, and then work on making this smarter (in the spirit of best is the enemy of the good). Definitely. The patch as it is already fixes both cases here \markup { \concat { 8 \super va } \fontsize #3 \concat { 8 \super va } } because \fontsize changes baseline-skip in harmony. Scaling on font-size would properly change the #:properties line of some of these functions, which affects `make doc`, and last time I did that in this file it was a disaster (http://codereview.appspot.com/9295044/). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduce offsets of \super and \sub (issue 35320043)
On Sat, 30 Nov 2013 21:21:49 -0800, lemzw...@googlemail.com wrote: Would it be possible to directly compute the height of the current font's `x' glyph as a basis value for raising and lowering? https://codereview.appspot.com/35320043/ I tried to do that for centering dynamics on their hairpins, but could not see anyway except to build a sample stencil https://codereview.appspot.com/7005056/diff/29001/scm/output-lib.scm#newcode861 and decided against it because it costs some time and I cannot guess be sure it would do any good (in someone's real situation where he uses some other font for dynamics). Do you know if the fonts, in the form LilyPond uses, will report their x-height, and if so how to get the information out of pango ? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: script-column: earlier scripts support later scripts; issue 3683 (issue 35010043)
On Fri, 29 Nov 2013 00:20:11 -0800, d...@gnu.org wrote: https://codereview.appspot.com/35010043/diff/1/lily/script-column.cc#newcode156 lily/script-column.cc:156: use all the scripts so far as support for the current grob A question of understanding: supports are not transitive automatically (if a supports b, and b supports c, a supports c)? The support relationship is not intrinsically transitive. It was effectively transitive when side-placement was one-dimensional, but no longer with placement using skylines. See the tracker example, where 1 supports 4, 4 supports 5. https://codereview.appspot.com/35010043/diff/1/lily/script-column.cc#newcode159 lily/script-column.cc:159: for (SCM t = ss; scm_is_pair (t) !scm_is_eq (t, s); t = scm_cdr (t)) Drop the scm_is_pair (t) condition. It can never be false, and makes the loop more confusing to read (the condition looks like the loop skips over a-a pairings but with cover both a-b and b-a when it doesn't). Done. That was my first inclination and I have tested it already. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel