Re: API for getting various kinds of grobs
What i would like: specify the reference grob in a property, for example
\override LyricText #'align-to = #'Stem
and then have one callback function that would be smart enough to find
appropriate grob to use and feed it to the method calculating
alignment.
Hi Janek,
I think this would be a nice generalization of the existing interface.
Unfortunately, I'm pretty busy right now, but here are a few quick thoughts.
The callback would probably look like this:
MAKE_SCHEME_CALLBACK (Self_alignment_interface, x_aligned, 1)
SCM
Self_alignment_interface::x_aligned (SCM smob)
{
Grob *me = unsmob_grob (smob);
what_to_align_to = me-internal_get_property (ly_symbol2scm (align-to))
return general_alignment (me, me-get_grob (what_to_align_to), X_AXIS);
}
The magic lies in writing get_grob. I know that there is a function
called get_object, but i'll probably have to modify it.
The easiest way to define get_grob is to make 'align-to a list of symbols,
which you interpret as a path from the current grob to the grob you want to
align it to. For example, if me is NoteHead and 'align-to is '(X-parent,
stem) then you go from me to
me-get_object(X-parent)-get_object(stem).
The disadvantage of this approach is that you ask users to know about which
grobs have references to which other grobs; IIRC, this is not in the user
documentation right now. Another possible approach is to do something
similar to how BreakAlignment works. The disadvantages with that are (1)
it's more work and (2) you have to decide in advance on all valid values
for 'align-to.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: API for getting various kinds of grobs
On Wed, Mar 13, 2013 at 4:33 PM, Janek Warchoł janek.lilyp...@gmail.comwrote: On Wed, Mar 13, 2013 at 12:27 AM, Joe Neeman joenee...@gmail.com wrote: The easiest way to define get_grob is to make 'align-to a list of symbols, which you interpret as a path from the current grob to the grob you want to align it to. For example, if me is NoteHead and 'align-to is '(X-parent, stem) then you go from me to me-get_object(X-parent)-get_object(stem). The disadvantage of this approach is that you ask users to know about which grobs have references to which other grobs; IIRC, this is not in the user documentation right now. Is there any place with such information? I don't recall seeing anything like that. It would be useful. Grep for ly:grob? and ly:grob-array? in scm/define-grob-properties.scm. Although they're documented in the same place as properties, the properties with type ly:grob? and ly:grob-array? should actually be part of the object alist, not the property alist (ie. they are accessible with get_object, not get_property). But I'm not sure if the list in scm/define-grob-properties.scm is complete, since the sanity checks in the regression tests only check that things in the /property/ alists are documented. So you may also need to grep the source for set_object and extract_grob_set. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 1:26 PM, David Kastrup d...@gnu.org wrote:
Joe Neeman joenee...@gmail.com writes:
On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote:
You are viewing this from the stack angle. But that is a complex
view already. The actual user view is
A.
\override sets a context-specific property value
\revert removes a context-specific property value
This works reliably. If I ever need more complex stuff than that,
I can
look it up.
And to make the this works reliably part work, we won't expose
any
isolated \temporary \override without matching \revert in
LilyPond.
How do you plan to achieve this? If there are any commands using a
\temporary...\revert that spans for more than one timestep, I can
always nest them and I can always sneak in \overrides between the
\temporary and the \revert, just by putting music in parallel.
Sneaking is expected to cause problems, and sneaking in _overrides_ is
not problematic as they just change the _top_ of the stack, and that
gets reverted anyway. Only sneaking in _reverts_ destroys the stack
balance, and that means that some states get reverted _more_ than
appropriate. However, if the expectation of the user is that they get
reverted _totally_ when he writes reverts, things end up better than
expected.
[talk] If you want this to be the user's expectation, then perhaps it would
be more appropriate to have \revert clear the stack entirely. Consider
something like this:
\redNotes { ...
\greenNotes { ...
\override NoteHead.color = #purple
...
\revert NoteHead.color
}
...
}
where the functions redNotes and greenNotes use a push. With the current
behaviour, the note colors will go red, green, purple, red, black, so the
\revert neither undoes a single change nor does it return to the default.
If \revert clears the stack, then you'll get red, green, purple, black,
which is not ideal in my opinion, but at least better than the earlier
option. (My preferred behaviour would be red, green, purple, green, red.)
People have complained about \push/\pop being intolerably
programmer-centric _terminology_, but terminology is cheap. The
underlying fear was people won't understand what push/pop does,
and
that can't be cured by using prettier names but only by not doing
anything hard to understand unless asked for it.
I think stacks are easy to understand, even for non-technical users.
The reason for avoiding push/pop is just to stop people from thinking
oh, that's programming, it must be hard.
Having to keep a stack properly nested _is_ a nuisance. The fundamental
complaint about Scheme as the core programming language of LilyPond is
that you need to keep so many parentheses nested.
An override stack is more forgiving than nested parentheses for two
reasons: first, it isn't an error if you have a non-empty stack at the end
of the piece, and second, there would be a command to clear the stack and
reset the default. It is admittedly hard to know for sure without trying
it, but I find it hard to imagine that keeping track of the stack will
cause difficulties.
LilyPond is _complex_, and sometimes one needs that complexity.
But we
should try to keep simple things simple, and leave the need to
understand complex behavior for when complex things are required.
While that's true, I think that a coherent and consistent whole is
more important than a slightly simpler beginner interface.
I don't find the user interface, as it is, inconsistent. One rarely
needs to bother with the full power of a stack (heck, we got along
7 years without a hook into push), and the non-pushing default of
\override reflects that.
But now that we are giving a hook into push, I think that the non-pushing
default of override will cause problems.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Tue, Oct 16, 2012 at 10:21 AM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: But now that we are giving a hook into push, I think that the non-pushing default of override will cause problems. I consider it utterly ludicrous that the mere availability of \temporary will magically cause problems with the existing usage of \override, Is the example I posted (and which you snipped) utterly ludicrous? but there is no point in continuing this farce as I have already given up. Do you really consider this discussion a farce? I thought I was making reasonable points, but if they are indeed farcical then perhaps I should give up too. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote: Trevor Daniels t.dani...@treda.co.uk writes: A. \override does a pop/push \revert does a pop \temporary\override does a push. so \temporary\override and \revert are a matching pair. More importantly: on an empty stack, any number of \override followed by \revert are a matching pair. B \override does a push \revert does a pop \clear restores the stack to the default state. so \override and \revert are a matching pair. Both of these are essentially equivalent, except A does not have a stack clear operation, but which of these is the clearer, and which the more intuitive? You are viewing this from the stack angle. But that is a complex view already. I disagree with this point. I suspect that many of our users are familiar with word processors (probably more so than me) and are perfectly comfortable with the undo stack. I don't see why an override stack is more complicated. The actual user view is A. \override sets a context-specific property value \revert removes a context-specific property value This works reliably. If I ever need more complex stuff than that, I can look it up. I don't find this much more complex: \override sets a context-specific property value \revert undoes the last \override \reset (or whatever) restores lilypond's default. And to make the this works reliably part work, we won't expose any isolated \temporary \override without matching \revert in LilyPond. As I said elsewhere in this thread, I don't see how this is possible to achieve given that we support simultaneous music. People have complained about \push/\pop being intolerably programmer-centric _terminology_, but terminology is cheap. The underlying fear was people won't understand what push/pop does That wasn't my underlying fear. My fear is that users will hear push and pop, think that they mean something complicated, and turn off their brains. Anyway, I don't want you to interpret this argument as being against your patch per se; obviously, it fixes a bunch of real bugs and that's great. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote: You are viewing this from the stack angle. But that is a complex view already. The actual user view is A. \override sets a context-specific property value \revert removes a context-specific property value This works reliably. If I ever need more complex stuff than that, I can look it up. And to make the this works reliably part work, we won't expose any isolated \temporary \override without matching \revert in LilyPond. How do you plan to achieve this? If there are any commands using a \temporary...\revert that spans for more than one timestep, I can always nest them and I can always sneak in \overrides between the \temporary and the \revert, just by putting music in parallel. People have complained about \push/\pop being intolerably programmer-centric _terminology_, but terminology is cheap. The underlying fear was people won't understand what push/pop does, and that can't be cured by using prettier names but only by not doing anything hard to understand unless asked for it. I think stacks are easy to understand, even for non-technical users. The reason for avoiding push/pop is just to stop people from thinking oh, that's programming, it must be hard. LilyPond is _complex_, and sometimes one needs that complexity. But we should try to keep simple things simple, and leave the need to understand complex behavior for when complex things are required. While that's true, I think that a coherent and consistent whole is more important than a slightly simpler beginner interface. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: stepping down as project manager
On Sat, Oct 13, 2012 at 1:22 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Hello Graham, Many thanks for the amazing amount of energy and work you've put in over the years. You certainly brought a very new style of leadership to the project after I have left. I hope we can count on you to stick around to give comments in the role of experienced emeritus. +1 Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org wrote: No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names push and pop as being opaque to non-programmers, while Werner was complaining that the plethora of new context-manipulation functions have become confusing. I interpret his comments as a request for orthogonalization rather than a complaint about the options that the new commands introduce. Now, it's true that the comments may not have been entirely constructive as they didn't propose alternatives, but I also don't think anyone claimed that your proposal is worse than the status quo. For what it's worth, I think push, pop and clear (perhaps with more intuitive-to-non-programmer names) makes a nicer stack interface than push, pop-push and pop. I also think that undo should be rethought in light of this recent discussion. In particular, this discussion has made me realize that undo doesn't just reverse the effect of an override, since after \override Something #'color = #green \override Something #'color = #red \undo\override Something #'color = #red, then the color is not back to green as one might think. What if we gave the users a push, pop and clear interface and we made overrides use push and \oneVoice use clear? This solves the \voiceOne\voiceTwo\oneVoice problem and it lets \temporary be a shortcut for \override ... \undo \override. Since override is non-destructive, we could even get fancy and let \override Something #'color = #green \override Something #'color = #red \undo\override Something #'color = #green go back to the pre-green color. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org wrote: No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. If you are referring to Werner's and Reinhold's comments, I think you may not be reading them as the authors intended. In particular, I believe that Reinhold was merely objecting to the names push and pop as being opaque to non-programmers, To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Lately, I have seen many suggestions that would turn lilypond more ^ into a programming language and away from being a description of ^^^ music. Now, while lilypond really is a programming language, in the past we have tried to hide the concepts (e.g. queue theory) from the user, with more or less success. David's attempts to get rid of the #' in propery names is a great step in this direction, but using push/pop would be a huge step in the wrong direction, IMO. while Werner was complaining that the plethora of new context-manipulation functions have become confusing. That makes it sound like it would be a chaotic bunch. And what do we have? \override overwrites the last definition \revert throws it away/reestablishes the previous if not overwritten. In other words, we have a pop-push and a pop. In the context of Reinhold's email, you were suggesting (although perhaps not seriously) adding a push. Now, I'm happy to have push and pop, but I think pop-push is a bad interface for a stack. The reason that we have gotten away with it for so long is because our interface ensures that the stack is almost always empty anyway (since the only way to push is with \once, and that always pops immediately). Once we start talking about composability, the deficiencies of pop-push become clear. So my proposed set of orthogonal commands would be push and pop (again, with more intuitive names). I also suggest adding clear for convenience. Everything else would be syntactic sugar on push and pop. Then we have modifiers for possibly multiple combined overrides, as those are for example available in large numbers in property-init.ly and we want to be able to use them for as many things as possible without having to retype them with modifications. \once \override non-destructively masks the definition for one time step, then restores \temporary \override non-destructively masks the last definition \undo \override drops like corresponding \reverts would A \tweak goes through a music object rather than through context properties, so we get \single \override (again an \override prefix) converts into one or more tweaks All those are separate tools, apply in the same manner to one or multiple overrides, to get a clear effect derived from the original \override-based command, and complementing each other in functionality. People shout I want fewer, but they are a set. It's like saying you want a smaller set of spanners, so you leave out every second one. But that means that you won't be able to do a random subset of required tasks because the spanners are a full set. You can't just randomly leave out some and expect to be able to still do every job. I interpret his comments as a request for orthogonalization rather than a complaint about the options that the new commands introduce. What's not orthogonal here? _Every_ modifier works on \overrides (granted, \undo will also work on \set but just because it does not make sense not to include this as well). \once allows a one-step temporary replacement, \temporary and \undo allow the start and stop of a temporary replacement to be separately specified. What isn't orthogonal is that you can't express, say, \temporary in terms of \override and \revert. If we switch to using push and pop instead of pop-push and pop, then push and pop become the orthogonal underpinnings of everything and \once, \temporary, and \undo become syntactic sugar. The sugar is then easy to explain to users because it can be expressed in terms of commands that they already know. \single converts into a different grob modifier mechanism. No, the complaint was clear, from several parties: I get the feeling that we have to completely reconsider how \set, \revert, and friends are named and used. Your clean-ups and reorganization of the syntax reveal more and more inconsistencies, and my head starts aching if I think of \once, \undo, and so on. [...] In other words, we have \override, \tweak, \set, \revert, \unset, \undo, \single (and maybe more). It's getting
Re: Project - Eliminating grob parents and outside-staff-priority
On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org m...@mikesolomon.orgwrote: Hey all, As was the case in a few of my previous projects, before I start something new I make architecture changes that facilitate my work. Working on 2801, I've realized that any multi-pass algorithm for the spacing of grobs is difficult because results of callback calculations are always cached. So triggering callbacks a second time is, in the current architecture, impractical and requires a fair bit of kludgery. Are you proposing not to cache callbacks at all? That sounds like a real performance killer to me; we would probably end up re-typesetting each beam hundreds of times. By the way, the problem is not only in the caching of callbacks; there are also many other places with side effects (calls to set_property, translate_axis, suicide, etc). To start this process, I'd like to expand the role of the side-position-interface significantly. All grobs would use this interface for their X and Y offsets and they would have two different grob arrays for X and Y side-position-elements. This would allow me to eliminate two things: 1) parents. Grobs are X/Y aligned to parents, but these parents could be elements in the side-position-elements array. Functions like get_parent, which could be kept around for legacy reasons, could return the first element of these arrays for a given axis and raise a warning if there are multiple elements. If you get rid of unique parents, what would X-offset mean? Would it be relative to the System? The first element of side-position-elements array? 2) outside-staff-priority. Saying a grob has outside staff priority is the same thing as saying that a grob has as its Y side support elements all inside-staff grobs plus all grobs with lower outside staff priority. A callback creating the side-position-elements arrays could do the sorting that takes place in Axis_group_interface::skyline_spacing. I think you'll have trouble making this fully callbacky/functional. For example, we lay out the outside-staff grobs in a very particular order (the left-to-right layout thing), which we don't know ahead of time. That is, until we get _all_ of the outside-staff grobs together, we don't know which grobs have to depend on which other grobs. That means it isn't really possible for each grob to determine its own position; there needs to be one grob that lays them out simultaneously. The same issue will come up, I think in laying out Accidentals and VerticalAxisGroups. At some point, I had grand plans to formalize this problem by having two distinct kinds of properties: one that is user-overridable using callbacks, and one that is internal and gets set by other grobs as a side-effect. Everything would have explicit dependencies so that caches could be invalidated. I even started to write a proof-of-concept in scala, but I never finished it... The benefits of this are twofold: 1) All work on a multi-pass algorithm could be done with respect to side-positioning, making it simpler to find bugs and modify code. Not all positioning is side-positioning. 2) A call to translate_axis in avoid_outside_staff_collisions would be eliminated, and translate_axis is bad: it goes against the callback model at the core of LilyPond layout. Agreed, but this is just one instance of translate_axis, which is just one example of a side-effect in lilypond. Is your eventual goal to remove them all? The disadvantage is that this results in the construction of many more skylines (one for each call to Side_position_interface::skyline_side_position). How this will impact performance is uncertain, but it'd probably require more optimization in skyline.cc and/or caching of skylines. I would suggest that you completely ignore performance in favor of a clean design. Performance can come later. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On Wed, Sep 26, 2012 at 12:17 PM, m...@mikesolomon.org m...@mikesolomon.org wrote: On 26 sept. 2012, at 17:38, Joe Neeman joenee...@gmail.com wrote: On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org m...@mikesolomon.org wrote: To start this process, I'd like to expand the role of the side-position-interface significantly. All grobs would use this interface for their X and Y offsets and they would have two different grob arrays for X and Y side-position-elements. This would allow me to eliminate two things: 1) parents. Grobs are X/Y aligned to parents, but these parents could be elements in the side-position-elements array. Functions like get_parent, which could be kept around for legacy reasons, could return the first element of these arrays for a given axis and raise a warning if there are multiple elements. If you get rid of unique parents, what would X-offset mean? Would it be relative to the System? The first element of side-position-elements array? Relative to the skyline of the elements of the side-position-elements array. If you want to construct one skyline for all the elements in that array, you need some way of finding their offsets relative to each other. How do you propose to do that without some notion of a common refpoint? 2) outside-staff-priority. Saying a grob has outside staff priority is the same thing as saying that a grob has as its Y side support elements all inside-staff grobs plus all grobs with lower outside staff priority. A callback creating the side-position-elements arrays could do the sorting that takes place in Axis_group_interface::skyline_spacing. I think you'll have trouble making this fully callbacky/functional. For example, we lay out the outside-staff grobs in a very particular order (the left-to-right layout thing), which we don't know ahead of time. That is, until we get _all_ of the outside-staff grobs together, we don't know which grobs have to depend on which other grobs. That means it isn't really possible for each grob to determine its own position; there needs to be one grob that lays them out simultaneously. The same issue will come up, I think in laying out Accidentals and VerticalAxisGroups. You're right that, in general, any time that a collecting grob does some type of organizing, this type of problem will come up. However, there are ways around it. For example, a grob can get the elements array from its vertical alignment or system, sort it from left to right, and trigger callbacks for all grobs to the left. This avoids an overarching positioning grob while still achieving the same effect. For outside-staff positioning, I think you could achieve the same effect. For something more complicated, like TieColumn or AccidentalPlacement, I think it would be much more difficult (and more obfuscated) to do it with callbacks. The benefits of this are twofold: 1) All work on a multi-pass algorithm could be done with respect to side-positioning, making it simpler to find bugs and modify code. Not all positioning is side-positioning. True - my goal is to see if all positioning can be articulated this way. For example, ScriptColumn could have used translate_axis, but whoever wrote it made the good decision to use side-position-interface. I think this grob could be eliminated entirely if all scripts in a script column had a function that calculated the side-position-elements grob-array using the sorting algorithm at the heart of script-column.cc. Another way to think of this is that, in general, we'd try to eliminate grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do traffic-coppery. Or, inversely, we'd say that positioning only happens via traffic-cop grobs and no grob has the right to position itself. But it seems like we need to pick one. I gave this some thought a while ago, and concluded that it isn't possible to get rid of the traffic cops (however, I'd be happy to be proven wrong). My eventual decision was to have them everywhere. A grob could suggest its own position using a callback, and if no other grob wanted to override that, then the System grob would take the traffic cop role and set the grob's position to whatever its suggestion was. That way you could write a lot of the positioning code as callbacks, and the cops would only kick in where necessary. There were also explicit dependencies so you could figure out which grob was in charge of positioning for which other grob. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Apparently the amd64 build of LilyPond 2.16.0 failed on Ubuntu
[oops, +lily-devel] On Fri, Sep 21, 2012 at 11:00 AM, Joe Neeman joenee...@gmail.com wrote: On Fri, Sep 21, 2012 at 10:34 AM, David Kastrup d...@gnu.org wrote: Cf. URL:https://launchpad.net/~dns/+archive/test/+build/3803769 Anybody have an idea from looking at the build log? A crash while building the regtests, possibly. But I wouldn't know which one without the log files in out/lybook-db. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gerrit - does it allow writing commits using a web interface?
On Fri, Sep 7, 2012 at 6:01 AM, Janek Warchoł janek.lilyp...@gmail.comwrote: On Fri, Sep 7, 2012 at 11:07 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: Can someone please explain me very slowly why we don't simply use Git as intended? Have you noticed that git patches are already in e-mail form? Additional two disadvantages of this approach that come to my mind: - how would you review a patch so monstrous as Mike's skylines? Rietveld also sucks for this. That's why I kept asking Mike to update his git branch. - it's hard/impossible to compare different versions of the patch. Again, a git branch is better than a website. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
On Tue, Sep 4, 2012 at 1:00 AM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: On Mon, Sep 3, 2012 at 2:46 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: To me, a Grand Input Syntax fixing of LilyPond, would amount to creating a syntax that strictly separates parsing and interpretation. This implies not only rethinking a lot of syntax, but also it means letting go of some of the flexibility and conciseness of the current format. This sound like a Right Thing to do, but i'm not knowledgeable enough to know what the results would actually be. Examples appreciated (hopefully some examples will show in other discussions). Well, one simple consequence would be that one can't define music functions in a document (their definition is interpretation, their use is parsing). With the current syntax, this is certainly true. But if a music function's arguments were delimited syntactically somehow then we could parse without interpreting any music functions, right? The argument list as such would require delimiting to make this work independently from advance knowledge about the number of elements. Which gets us to Scheme syntax. The enthusiasm of people about this kind of fully delimited syntax is about on par with the enthusiasm about writing XML files manually. Also the type of an argument is not necessarily known without consulting the function signature. As a silly example, try var = \relative c'-3 \void\displayLilyMusic \var Try guessing its output before running it. Find an explanation. Replace \displayLilyMusic with \displayMusic and corroborate your explanation. Isn't this an argument for delimiting the argument list? If you don't expect anyone to guess where it begins and ends correctly (and I didn't), doesn't that mean we should have a more explicit syntax? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: preliminary GLISS discussions
On Mon, Sep 3, 2012 at 2:46 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: On Mon, Sep 3, 2012 at 7:20 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: To me, a Grand Input Syntax fixing of LilyPond, would amount to creating a syntax that strictly separates parsing and interpretation. This implies not only rethinking a lot of syntax, but also it means letting go of some of the flexibility and conciseness of the current format. This sound like a Right Thing to do, but i'm not knowledgeable enough to know what the results would actually be. Examples appreciated (hopefully some examples will show in other discussions). Well, one simple consequence would be that one can't define music functions in a document (their definition is interpretation, their use is parsing). With the current syntax, this is certainly true. But if a music function's arguments were delimited syntactically somehow then we could parse without interpreting any music functions, right? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: automated computing tasks for lilypond
On Tue, Aug 28, 2012 at 3:42 AM, James pkx1...@gmail.com wrote: Yes you are correct, I did quick look up and see that the British Telecom's Home Hub I have will work with DynDNS (BT itself does not offer fixed IP to its residential customers). I could get a basic DynDNS account - it's not that expensive for a year - if anyone thinks it would be worth it as I have no personal desire to manage my server from work. no-ip.com offers a free service (DynDNS used to also, but it seems that they don't anymore). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
building gub on arch linux
Hi Waltroppers, I've just successfully make bootstrapped gub (the waltrop branch on Graham's github account), with only one change required: I replaced the entire contents of gub/2/db.py with import anydbm as db Apparently bsddb doesn't work anymore in upstream python and arch linux decided to stop patching it: https://bugs.archlinux.org/task/25045 Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Waltrop meeting outline
On Fri, Aug 24, 2012 at 2:31 PM, Valentin Villenave valen...@villenave.netwrote: On Thu, Aug 23, 2012 at 8:12 AM, Martin Tarenskeen m.tarensk...@zonnet.nl wrote: I wish you a lot of fun and inspiration at the Waltrop LilyPond meeting! Likewise. Greetings from Paris (only 41.5°C today, yay!); sorry not to be with you guys, but I wish you a lot of fun and have no doubt that things will be both entertaining and interesting. Please just remember to take a few pictures and notes for the upcoming LilyPond Report! (And remember to disable BW mode on your cameras, unlike me last month with Joe ;-) Don't forget that we also took a photo (color, presumably) with Ngoc's camera. Unfortunately, it seems that I have some trouble in arranging to have a computer, camera, and USB cable all in the same place... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Sat, Aug 18, 2012 at 5:34 AM, Keith OHara k-ohara5...@oco.net wrote: On Fri, 17 Aug 2012 10:16:25 -0700, mts...@gmail.com wrote: http://codereview.appspot.com/**5626052/diff/106004/lily/axis-** group-interface.cc#newcode780http://codereview.appspot.com/5626052/diff/106004/lily/axis-group-interface.cc#newcode780 lily/axis-group-interface.cc:**780: while (dirty); On 2012/08/17 08:12:56, Keith wrote: I am beginning to understand the new code. Would you consider again using distance() instead of the repeated calls to intersects() in the while(dirty) loop ? It might look simpler now that you've been away from the code for awhile. floors[j] = padding - forest[j][UP]~distance~pair[**DOWN] ceilings[j] = forest[j][DOWN]~distance~pair[**UP] You know the solution will be to move an amount equal to one of the floors[j], and you want to find the smallest that fits, so make trials = sort (floors) and find the smallest among trials that satisfies trials[n] 0 for all j (trials[n] floors[j] || trials[n] ceilings[j] ) I am not adverse to using distance if possible - my trouble case is the following. A B Image that object A above is placed first and LilyPond is now considering whether it should leave B where it is or place it above A. The distance function would dictate that it needs to be shifted above A because its DOWN skyline is below A's UP. We need not let the distance function between A[UP] and B[DOWN] dictate, because having positive distance between A[DOWN] and B[UP] is another solution. If you check out the dev/jneem-skylines (which is a simplified but not (yet) feature-compatible version of Mike's branch), you'll see that I'm using this method under the name 'bool Skyline_pair::intersects.' Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Sat, Jul 14, 2012 at 8:33 PM, mts...@gmail.com wrote: http://codereview.appspot.com/**5626052/diff/85004/lily/** skyline.cc#newcode302http://codereview.appspot.com/5626052/diff/85004/lily/skyline.cc#newcode302 lily/skyline.cc:302: while (dirty); On 2012/07/14 14:01:08, joeneeman wrote: I don't understand this do while (dirty) part. It seems to me that unless you have two empty segments in a row, you only need one pass. On the other hand, if you have two empty segments in a row then this function will fail anyway because you will end up setting center-slope_ and center-y_intercept_ both to -infinity, which is bound to start creating NaN sooner or later. I'll rewrite this so that it combines all interior skylines with an infinite y intercept and then only does one pass. This sounds like a good idea. If you put the skyline combination part in a separate function, we could just use it after merges, etc, so that the property of not having adjacent empty buildings is always maintained. http://codereview.appspot.com/**5626052/diff/90001/lily/** include/skyline.hhhttp://codereview.appspot.com/5626052/diff/90001/lily/include/skyline.hh File lily/include/skyline.hh (right): http://codereview.appspot.com/**5626052/diff/90001/lily/** include/skyline.hh#newcode58http://codereview.appspot.com/5626052/diff/90001/lily/include/skyline.hh#newcode58 lily/include/skyline.hh:58: NOT_ENOUGH_INFO On 2012/07/14 14:01:08, joeneeman wrote: I wish I could convince you to think of a skyline as a region instead of just the boundary of that region. Once you think of it that way, it becomes clear that this information can be easily obtained from the Skyline_pair, using the existing distance function. Suppose s and t are Skyline_pairs. max(s[UP].distance(t[DOWN]), s[DOWN].distance(t[UP])) = -infinity means the objects don't overlap horizontally at all, so it's meaningless to talk about which one is higher (I think this is what you're calling NOT_ENOUGH_INFO). min(s[UP].distance(t[DOWN]), s[DOWN].distance(t[UP])) 0 means that the objects intersect. s[UP].distance(t[DOWN]) = 0 and s[DOWN].distance(t[UP]) 0 means that s is below t t[UP].distance(s[DOWN]) = 0 and t[DOWN].distance(s[UP]) 0 means that t is below s This logic uses two calls to distance, which is expensive, whereas using the e-num gets this info from one call to distance. I can use the method you propose, but don't you think that'd cause a performance hit? Won't you need two skyline comparisons anyway? If T's up skyline is always above S's down skyline, then S and T may intersect but you won't know until you've compared T's down skyline with S's up skyline. Anyway, I'm always in favor of writing simple code first and then optimizing once things have been measured. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is gcc able to handle anonymous functions?
On Fri, Jul 6, 2012 at 9:51 AM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: I think it's exercises like that that help strengthen the Scheme bindings and thus lead to more customizability/extensibility. In this case, I disagree. The function in question is used in 2 places in the C++ code, neither of which is a good candidate for customization. The only argument for porting this function in the first place is that it happened to live in the same file as some other stuff (which _did_ make sense to port). That doesn't sound like a very good argument to me. To me it sounds like a Scheme interface to Pointer_group_interface::find_grob is needed here. That may be useful at some point, but it's orthogonal to what's going on here. I think being able to move the _entire_ chunk of functionality to Scheme makes _excellent_ sense since it means we arrive at a piece of functionality that can serve as a template for _user_ written functionality without requiring recompilation. The entire chunk of functionality has already been ported. That is not the issue. A chunk of Scheme code with just one or two semi-trivial C++ functions required to complete it is useless for that purpose. The semi-trivial C++ function is _not_ useful for the scheme code. It is used in two parts of the C++ code. However, because it belonged to the same file as various other functions that were being ported, Marc was planning to port this semi-trivial function to scheme also, and then call the new scheme function from C++ code. In the amount of time we've spent discussing this, we could have rewritten the function in scheme, haskell, perl, and brainf*ck by now. I really think that the best thing is just to leave the function where it is and stop worrying. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is gcc able to handle anonymous functions?
On Fri, Jul 6, 2012 at 7:13 PM, Marc Hohl m...@hohlart.de wrote: Am 06.07.2012 18:06, schrieb Joe Neeman: [...] The semi-trivial C++ function is _not_ useful for the scheme code. It is used in two parts of the C++ code. However, because it belonged to the same file as various other functions that were being ported, Marc was planning to port this semi-trivial function to scheme also, and then call the new scheme function from C++ code. In the amount of time we've spent discussing this, we could have rewritten the function in scheme, haskell, perl, and brainf*ck by now. I really think that the best thing is just to leave the function where it is and stop worrying. Thinking a bit more about the problem, what about rewriting the whole Pointer_group_interface::find_**grob in scheme? Why? It's never called from scheme code. Anyway, I've made my opinion known, so I'm going to bow out of this conversation now. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is gcc able to handle anonymous functions?
On Thu, Jul 5, 2012 at 12:37 AM, m...@apollinemike.com m...@apollinemike.com wrote: On 4 juil. 2012, at 20:10, Marc Hohl wrote: Am 04.07.2012 13:29, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Hello list, the topic is somewhat over my head, but perhaps someone with more insight can answer this question? I think that gcc likely can, don't know about g++, and we don't want to rely on it anyhow. Ok. Well then, is there an alternative? I want to get rid of bar-line.cc (issue 1320), and I have managed to get all definitions but Bar_line::non_empty_barline into scheme. In lily/note-spacing.cc, I have Grob *bar = Pointer_group_interface::find_grob (right_col, ly_symbol2scm (elements), Bar_line::non_empty_barline); The simple approach bool non_empty_barline = ly_scm2bool (scm_call_1 (ly_lily_module_constant (bar-line::non-empty-barline), right_col-self_scm ())); with (define-public (bar-line::non-empty-barline grob) (and (grob::has-interface grob 'bar-line) (pair? (ly:grob-extent grob grob X doesn't work. I just realized that there's an easier way to do this w/ existing code conventions. You can overload Pointer_group_interface::find_grob so that it accepts a simple closure as the third argument. Then, wrap the Scheme function in a simple closure. Why not just leave the function in C++? I have nothing against porting things to scheme, but in this case it just seems like an exercise in making things more complicated, for no gain. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Is gcc able to handle anonymous functions?
On Thu, Jul 5, 2012 at 8:44 AM, m...@apollinemike.com m...@apollinemike.com wrote: On 5 juil. 2012, at 08:14, Joe Neeman wrote: On Thu, Jul 5, 2012 at 12:37 AM, m...@apollinemike.com m...@apollinemike.com wrote: On 4 juil. 2012, at 20:10, Marc Hohl wrote: Am 04.07.2012 13:29, schrieb David Kastrup: Marc Hohl m...@hohlart.de writes: Hello list, the topic is somewhat over my head, but perhaps someone with more insight can answer this question? I think that gcc likely can, don't know about g++, and we don't want to rely on it anyhow. Ok. Well then, is there an alternative? I want to get rid of bar-line.cc (issue 1320), and I have managed to get all definitions but Bar_line::non_empty_barline into scheme. In lily/note-spacing.cc, I have Grob *bar = Pointer_group_interface::find_grob (right_col, ly_symbol2scm (elements), Bar_line::non_empty_barline); The simple approach bool non_empty_barline = ly_scm2bool (scm_call_1 (ly_lily_module_constant (bar-line::non-empty-barline), right_col-self_scm ())); with (define-public (bar-line::non-empty-barline grob) (and (grob::has-interface grob 'bar-line) (pair? (ly:grob-extent grob grob X doesn't work. I just realized that there's an easier way to do this w/ existing code conventions. You can overload Pointer_group_interface::find_grob so that it accepts a simple closure as the third argument. Then, wrap the Scheme function in a simple closure. Why not just leave the function in C++? I have nothing against porting things to scheme, but in this case it just seems like an exercise in making things more complicated, for no gain. It's doable - the goal was to port the entire thing to Scheme. You're right that it is much easier to write in C++. I think it's exercises like that that help strengthen the Scheme bindings and thus lead to more customizability/extensibility. In this case, I disagree. The function in question is used in 2 places in the C++ code, neither of which is a good candidate for customization. The only argument for porting this function in the first place is that it happened to live in the same file as some other stuff (which _did_ make sense to port). That doesn't sound like a very good argument to me. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: whitespace issue with ly:one-line-breaking
On Sat, Jun 30, 2012 at 7:42 AM, Werner LEMBERG w...@gnu.org wrote:
Consider this example file `foo.ly':
\version 2.15.41
\paper {
page-breaking = #ly:one-line-breaking
}
\header {
copyright = ##f
footer = ##f
tagline = ##f
}
\relative c' {
\repeat unfold 200 { d16 d d d e e e e f f f f g g g g }
}
If called with
lilypond --png foo.ly
I get a PNG file with the dimensions 58201x1181. This is far too
high. If you load this in GIMP and do an autocrop operation, you get
a size of 58123x52. Adding a 40px top and bottom margin (similar to
the left and right one), the correct height would be approx. 130px.
Where do the additional vertical 1000px come from? Looks like a
bug...
It comes from the height of the page: ly:one-line-breaking doesn't
(currently) adjust the height, but only the width.
And what about documentation of ly:one-line-breaking? In particular,
I miss the constraints (besides ignoring the paper format), for
example, whether \header is ignored, or whether the `indent' parameter
in the \paper block gets honoured.
Point taken, I'll write some documentation...
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: European lilypond meetings
On Thu, May 31, 2012 at 11:30 AM, Graham Percival gra...@percival-music.cawrote: I'm floating two possibilities for face-to-face lilypond meetings in the next few months. UK: I'll be in the Birmingham area on 26 June. Depending on interest and availability, there could be a short meeting that day, or a longer meeting including a stay at a BB or something like that. If there was serious interest in a longer meeting of lilypond people in the UK, we could meet somewhere else easily accessible by train (I assume that Birmingham has good links)... Northampton, Manchester...? There's a distinct possibility that I'll be in Manchester around then, in which case I'd be happy to meet up. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
2012/3/6 Janek Warchoł janek.lilyp...@gmail.com On Tue, Mar 6, 2012 at 11:48 PM, Joe Neeman joenee...@gmail.com wrote: 2012/3/6 janek.lilyp...@gmail.com Mike all, i did a quick compile with patchset 36 and unfortunately didn't notice significant speedups from previous version. Could you try the dev/jneem branch in git? It has some optimizations. If that doesn't help, could you please send me some of the worst files? They look better indeed time-wise. As for the output, i've only did a quick look and noticed this: why you deleted horizontal padding? This results in mf at the bottom right of 1st page of Tota pulchra to jump into above lyrics. The way skyline padding was being done made the code very messy. Also, padding was being added in multiple places, so some things were getting extra padding. However, the capability for doing padding is still there (for example, with the outside-staff-horizon-padding property). I agree, though, that the defaults will need to be revisited. Actually, small/zero horizontal padding might give better results in some places, but that needs thorough investigation. Something that, FWIW, never happened with the previous defaults. A bunch of the lines I deleted had comments like // TODO: figure out what horizon_padding should be Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
2012/3/7 Janek Warchoł janek.lilyp...@gmail.com On Wed, Mar 7, 2012 at 11:43 AM, Joe Neeman joenee...@gmail.com wrote: 2012/3/6 Janek Warchoł janek.lilyp...@gmail.com Actually, small/zero horizontal padding might give better results in some places, but that needs thorough investigation. Something that, FWIW, never happened with the previous defaults. do you mean that there was no padding previously? No, I mean that the previous default values were never investigated. When the code was written, values were hard-coded with comments like TODO: what's the proper value? Years later, those comments were still there... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
2012/3/6 janek.lilyp...@gmail.com Mike all, i did a quick compile with patchset 36 and unfortunately didn't notice significant speedups from previous version. Could you try the dev/jneem branch in git? It has some optimizations. If that doesn't help, could you please send me some of the worst files? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Fri, Mar 2, 2012 at 8:26 PM, Pavel Roskin pro...@gnu.org wrote: Hello! On Tue, 28 Feb 2012 15:14:29 -0800 Joe Neeman joenee...@gmail.com wrote: Don't use ly:axis-group-interface::add-element, because stems don't implement the axis-group-interface. (Removing this will also remove the axes warning.) Instead, use ly:grob-set-parent!. You'll probably want to set both the X parent and the Y parent. Then the X and Y offsets of new-stem will be measured relative to stem (instead of relative to the whole system, which is the default). OK, this is what I have now. I think it's a pretty good solution. Looks good! The code is capable of creating multiple cross-staff stems per moment. It's possible to connect more than two stems as long as they lie on the same line. There is a workaround for a problem with Lilypond 2.14 that has a flag as part of the stem. I spent way too much time on the issue, but it helped me learn Scheme and Lilypond. That's ok; now that you're an expert, your next feature will be much easier... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Tue, Feb 28, 2012 at 2:56 PM, Pavel Roskin pro...@gnu.org wrote: Hello, Joe! In case it wasn't clear from what I said before, engravers in lilypond don't do the actual layout. Instead, they build the grobs and set up the connections between them. Most of the layout is done in callback functions. Yes, I realize it now. Your suggestion to create a new stem worked fine. I can get the relative coordinates of themes on different staves. The attached file shows where I am now. There are many minor issues, and I hope I can solve most of them, but I'll certainly appreciate help. I'm getting a message Weird stem, and I don't see how to avoid it. Perhaps I should create a totally new grob with a unique name, such as StemSpan. Is that possible? What would be needed? It would be nice to do this eventually, because having a different grob name would make it easier for the users to tweak it. I think it would involve editing scm/define-grobs.scm, but there may be a way to do it from an .ly file also How do I make the new stem start at the same point as the original one. I tried this: (set! (ly:grob-property stem 'axes) (list X)) I don't understand how it works. Not setting axes leads to: programming error: axes should be nonempty Don't use ly:axis-group-interface::add-element, because stems don't implement the axis-group-interface. (Removing this will also remove the axes warning.) Instead, use ly:grob-set-parent!. You'll probably want to set both the X parent and the Y parent. Then the X and Y offsets of new-stem will be measured relative to stem (instead of relative to the whole system, which is the default). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Tue, Feb 28, 2012 at 1:32 PM, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, I've put up a new version that doesn't issue warnings. Any change of getting an updated git branch, too? ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
ghostscript in gub
This patch allows me to build ghostscript in gub on Ubuntu 11.10. The problem is that ghostscript only looks for sys/types.h in /usr/include, whereas Ubuntu 11.10 has it in /usr/include/x86_64-linux-gnu. This patch just assumes that sys/types.h is always present... is there any modern system where it isn't? Cheers, Joe From fea85af4b47bae0031e9efc858cda60dc5ce6e06 Mon Sep 17 00:00:00 2001 From: Joe Neeman joenee...@gmail.com Date: Sun, 26 Feb 2012 18:45:55 +1100 Subject: [PATCH] Work around ghostscript's broken sys/types check. --- gub/specs/ghostscript.py |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/gub/specs/ghostscript.py b/gub/specs/ghostscript.py index 09f5029..a3b834a 100644 --- a/gub/specs/ghostscript.py +++ b/gub/specs/ghostscript.py @@ -52,7 +52,8 @@ models.''' + ' mandir=%(prefix_dir)s/share/man/ ' + ' docdir=%(prefix_dir)s/share/doc/ghostscript/doc ' + ' exdir=%(prefix_dir)s/share/doc/ghostscript/examples ') -make_flags = target.AutoBuild.make_flags + ' TARGET=%(target_os)s' +# Ghostscript's check for sys/time.h is buggy: it only looks in /usr/include. +make_flags = target.AutoBuild.make_flags + ' TARGET=%(target_os)s CFLAGS+=-DHAVE_SYS_TIME_H=1' obj = 'obj' @staticmethod def static_version (): -- 1.7.5.4 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Sat, Feb 25, 2012 at 9:14 PM, Pavel Roskin pro...@gnu.org wrote: Using an engraver to catch the stems sounds like a good approach. I could even do some filtering in the engraver. And it should be possible to replace stems with one rather than connect them together. It would simplify SVG output, and I suspect the connect point could be seen in some renderings of the postscript output. Thank you for your help! I'm getting really close! Glad to hear it :) In case it wasn't clear from what I said before, engravers in lilypond don't do the actual layout. Instead, they build the grobs and set up the connections between them. Most of the layout is done in callback functions. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Sun, Feb 26, 2012 at 11:25 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 26, 2012, at 7:37 PM, Werner LEMBERG wrote: AFAIK, Pango returns a list of glyph indices and coordinates to position glyphs. It's straightforward to feed those indices directly into FreeType's `FT_Load_Glyph' function which is able to return an `FT_Outline' structure holding the glyph's outline. This is great Werner - thank you! I just checked out FT_Outline. It's really straightforward, which is great. Joe - this likely means that the build system work you were thinking about doing w/ glyph outlines is no longer necessary and that I can scrap all of the .scm stuff I wrote and replace it with calls to this. I'll have time Wednesday morning to check this out. Sounds good! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Fri, Feb 24, 2012 at 3:04 PM, Pavel Roskin pro...@gnu.org wrote: Hello! I'm moving the thread to lilypond-devel and changing the subject. I hope it's OK. On Thu, 23 Feb 2012 15:37:02 + Neil Puttock n.putt...@gmail.com wrote: On 23 February 2012 15:18, Pavel Roskin pro...@gnu.org wrote: I actually wanted to make a stopgap solution in Scheme. I wrote some code that looks for other stems and sets the stem length so it would touch the stem above (attached). But the code is unreliable. Some stems are not calculated yet. I'd love to be proven wrong, but I don't think you'll have much success with this approach. At the very least, you'll need a Scheme engraver at the correct context level to collect the stems at the right time. If a simple length override were possible with the current infrastructure, we wouldn't need a Span_arpeggio_engraver to typeset cross-staff arpeggios. I tried writing an engraver that could be added to the StaffGroup context. Collecting stems is not a problem. The problem is that even the finalize handler is called to early. I'm getting a warning: programming error: vertical alignment called before line breaking continuing, cross fingers It's a little hard to guess what's going wrong without knowing exactly what you've tried. Are you trying to do layout logic in the engraver (ie. by collecting stems, reading their properties, doing calculations and then setting more properties)? If you are, the first step is to move the layout logic into grob callbacks. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cross-staff stem engraver (was: New frog in an empty pond?)
On Sat, Feb 25, 2012 at 5:49 AM, Pavel Roskin pro...@gnu.org wrote: Quoting Joe Neeman joenee...@gmail.com: On Fri, Feb 24, 2012 at 3:04 PM, Pavel Roskin pro...@gnu.org wrote: I tried writing an engraver that could be added to the StaffGroup context. Collecting stems is not a problem. The problem is that even the finalize handler is called to early. I'm getting a warning: programming error: vertical alignment called before line breaking continuing, cross fingers It's a little hard to guess what's going wrong without knowing exactly what you've tried. Are you trying to do layout logic in the engraver (ie. by collecting stems, reading their properties, doing calculations and then setting more properties)? Yes, except that I'm not setting anything yet. The current file is attached. The problem is where you ask for the stem Y-extent relative to yref (the VerticalAlignment): in order to calculate the vertical distance between the various staves and the VerticalAlignment, line breaking needs to be done first. (And line breaking doesn't happen until after all the engravers are done.) If you are, the first step is to move the layout logic into grob callbacks. I guess I'll need to redefine the stencil for stems. Or maybe you mean some other callback? You could redefine stencil, but I think redefining length would be easier. I did a similar thing before. I put all the logic into a function that was used to redefine the length property of the stem. It worked for a simple case of two stems, but failed when three stems needed to be connected. The Y-extent for at least one of the stems wasn't calculated yet. Can you be more specific about the Y-extent not being calculated yet? When you ask for the Y-extent, the calculation should be triggered if it hasn't already happened. As a general approach, setting length sounds like a reasonable way forward. In addition, I'd suggest creating a new stem in process-acknowledged, then doing (set! (ly:grob-object new-stem 'spanned-stems) old-stems) (set! (ly:grob-property new-stem 'length) your-length-callback) In your length callback, you read back the spanned-stems object and do your calculations. Is this similar to what you tried? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplify font building. (issue 5695061)
On Sat, Feb 25, 2012 at 8:23 AM, Graham Percival gra...@percival-music.cawrote: On Sat, Feb 25, 2012 at 03:57:55PM +, julien.ri...@gmail.com wrote: This is good, I now get the error message right away when running configure. No problem with the patch after installing the required package. Do lilydev and gub already include the fontforge python package? No, and adding this to GUB will be particularly challenging. I'm afraid that this will probably postpone the patch indefinitely. :( Why would it be particularly challenging? In fact, since GUB builds fontforge, the python bindings may already be included (I'm attempting to check this now). It's just that debian-like distros feel the need to separate each package into 5 pieces... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Unicode range for lilypond fonts
I found this comment in the font generation scripts: # crashes fontforge, use PUA for now -- jcn # SetUnicodeValue(i + 0xF, 0); SetUnicodeValue(i + 0xE000, 0); It seems that this comment is obsolete: fontforge (at least, my version) no longer crashes if I use 0xF. Is one range preferable to the other? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Feb 23, 2012 at 1:35 AM, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, The newest patch set implements several of Joe's suggestions but takes a time hit because I am using the fancy skylines for Scripts. This makes script-accidental-collision.ly look better (as well as a few other regtests) but it slows things down even more. I think that the coding is sound, though, and it is as fast as possible given what I know how to do. I could maybe eliminate one or two loops here or there (i.e. transforming buildings to points and back to buildings for the skyline constructor that accepts skyline pairs) but this seems like chump change. Each successive slow down comes from the skylining of a new grob, which is linear (there's tons of scripts, so tons of subtleties in the skylines). Of course, any speed-up suggestions are welcome. I don't see any obvious things to speed up... can you update your git branch? Then I'll profile it and take a closer look. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Feb 23, 2012 at 3:13 AM, mts...@gmail.com wrote: http://codereview.appspot.com/**5626052/diff/30003/lily/**skyline.cchttp://codereview.appspot.com/5626052/diff/30003/lily/skyline.cc File lily/skyline.cc (right): http://codereview.appspot.com/**5626052/diff/30003/lily/** skyline.cc#newcode393http://codereview.appspot.com/5626052/diff/30003/lily/skyline.cc#newcode393 lily/skyline.cc:393: Skyline::Skyline (Building b, Real start, Axis horizon_axis, Direction sky) On 2012/02/22 09:34:43, joeneeman wrote: This isn't quite what I had in mind (for one thing, it means that the caller has to be aware of buildings, calculating their slope, etc.) what about Skyline::Skyline (vectorpairPoint, Point const segments, Axis, Direction)? it works similarly to Skyline::Skyline(vectorBox..**.) except that the resulting skyline shows the outline of the given set of line segments. Done. http://codereview.appspot.com/**5626052/diff/30003/lily/** skyline.cc#newcode647http://codereview.appspot.com/5626052/diff/30003/lily/skyline.cc#newcode647 lily/skyline.cc:647: out.merge (to_merge); On 2012/02/22 09:34:43, joeneeman wrote: merge is linear, so this loop is quadratic. It should now be n*log(n). http://codereview.appspot.com/**5626052/diff/34001/lily/**skyline.cchttp://codereview.appspot.com/5626052/diff/34001/lily/skyline.cc File lily/skyline.cc (right): http://codereview.appspot.com/**5626052/diff/34001/lily/** skyline.cc#newcode362http://codereview.appspot.com/5626052/diff/34001/lily/skyline.cc#newcode362 lily/skyline.cc:362: result.push_front (Building (last_end, -infinity_f, -infinity_f, iv[LEFT] - 2 * horizon_padding)); On 2012/02/23 11:11:47, joeneeman wrote: push_back is constant time for STL lists. No need to push_front and then reverse. I'm not not in favor of this, but why is there a reverse in the other non_overlapping_skyline function? Good question... ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Wed, Feb 22, 2012 at 12:57 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 22, 2012, at 9:48 AM, David Kastrup wrote: m...@apollinemike.com m...@apollinemike.com writes: Hey all, I've uploaded a first-pass attempt at implementing the suggestion that Joe talked about (using buildings directly in the skylines). This saves a lot of time in the calculation of skyline distance (time spent in Axis_group_interface::skyline_spacing can go from 2 to 0.2 seconds for scores with lots of beams and hairpins). However, the global time takes a huge hike with this patchset because skylines are constantly being rebuilt with padding added on. It would appear to me that one would want to implement padding operations working on whole readily-built skylines. That should be more efficient than padding the individual elements. The question boils down to this: Grob X (say a NoteColumn) has skyline A. Grob X's skyline is subsumed in grob B's (say a PaperColumn) skyline Y. Grob X has skyline-horizontal padding of 0.15 and Grob Y has skyline-horizontal-padding of 0.1. Does this mean that grob X, when subsumed into grob Y's skyline, has a resultant skyline-horizontal-padding of 0.25? My inclination used to be no, but over the past 24 hours my brain has come around to yes as I see the assumptions that the code is written on. I think that padding needs to be built into skylines at creation time, always. Bear in mind that the reason we currently handle padding the way we do is so that it affects the distance between staves but it doesn't force outside-staff-grobs too far away. Really, though, you should just pick something that's easy to implement and offers the user some flexibility. Padding is currently done the way it is because that's what came to my mind at the time; no need to keep it that way. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Sun, Feb 19, 2012 at 1:22 PM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 19, 2012, at 10:31 PM, Joe Neeman wrote: On Sun, Feb 19, 2012 at 11:59 AM, David Kastrup d...@gnu.org wrote: m...@apollinemike.com m...@apollinemike.com writes: I've now optimized the crap out of this sucker and cached as much as I can cache. I'm not sure the caching is of much help. What kind of information would save recalculation? For example, I get the sense that the new key signature skyline function is not much faster than the old, which means that either the lookups of cached accidental skylines or the merging of these skylines to create the signature takes a lot of time. Merging sounds like O(n^2) unless one takes precautions. No, it's O(n + m). (m is the length of the other skyline). Building a skyline from scratch is O(n log n). However, there may be room for more heuristics that speed things up (see non_overlapping_skyline, which resulted in a measurable speedup). If you get a chance to look over the entirety of the patch w/ your speed-up glasses on, I'd appreciate it. I know it looks like a lot, but the gist of it is that there are two main vertical-skylines functions (ly:grob::vertical-skylines-from-stencil and ly:grob::vertical-skylines-from-element-stencils) and the other skyline functions are (supposed to be) speed ups (ly:key-signature::vertical-skylines is probably the heftiest one). Lemme know if in any of these things you see places where I may be creating bottlenecks, where Scheme code may be slowing things down, where I'm passing around too-large data structures, needless recalculation (if it winds up being a lot of recalculation - I know I do some in beam.cc w/ ly:beam::vertical-skylines, for example, but I'm not sure how much this slows things down). Another possible speedup could come from the initial building of the skylines using add_boxes: when the children of an axis-group mostly don't have skylines, then we gather up all of their extent boxes, before turning them into one skyline and merging it (this is O(n log n) in the number of children). If the children do have skylines, we merge them one at a time (this is O(n^2), but it didn't use to matter because there were very few children that had their own skylines). To fix this, you could make a constructor for skylines that takes a vector of skylines and merges them recursively, in the same way that internal_build_skyline merges boxes recursively. Again, you should only do this if you have evidence that the skyline merges caused by add_boxes are taking lots of time. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mon, Feb 20, 2012 at 12:07 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 20, 2012, at 1:58 AM, Joe Neeman wrote: I think you're going about things in the wrong order. I think that the first goal should be to make the code clear and correct. (In fact, if your code were done but slow, you could push it to master but with skylining disabled for most grobs by default. That way, people could test it and give feedback. They could even enable skylining on more grobs if they didn't mind the performance hit.) This idea was kicked around the list in various vicissitudes, but it seemed that the majority of people favored LilyPond making the best result possible out of the box. That's fine, but it doesn't mean that it has to be that way when you first push it to master. It's up to you, of course, but I prefer not to keep my own branches unsynced from master for a long time... Then you should profile and benchmark it to figure out which parts need to be faster (use ./configure --enable-profiling). For example, do you know that making special cases for beams and key signatures actually helps? I've only used `time' on large scores to get an idea, as with small scores it's difficult to tell. I did a few runs again this morning and have gotten rid of the exception for key signatures (it does not help at all). I think that beams help, but I'm honestly not even sure...it fluctuates a lot and I'm having trouble getting a clean read. I am going to delete all of the exceptions (save slurs, which does help). Have you profiled it? That will let you see which function(s) are adding the extra time. Having said that, there are two places that I can think of which *might* speed things up: - you return a lot of vectorBox in stencil-intergrate.cc. This might mean that a lot of things get copied (not sure about this -- c++11 is supposed to help here). It might speed things up if you pass around const vectorBox instead. I did this. I'm not sure if it results in better performance, but it can't hurt looks cleaner. - the skylines you generate are a lot more complicated than they need to be. For example, you approximate beams with 11 horizontal segments. If you were to implement my suggestion about turning line segments into skylines, you could represent a beam with 1 sloped segment. This is true. I have a test case with 1200 hairpins (12 staves, 100 hairpins a piece) and this brings the compilation time down from about 19.9' to 19.5' on average. So there's definitely a performance increase. The issue I'm having is figuring out a good way to implement this so that it maintains a meaningful notion of what horizon padding is. For example, if two skylines are merged with different horizon paddings, do they retain the horizon paddings of the old grobs (harder to code) or take the horizon padding of the new grob (easier to code)? Or both - do they retain the old and tack on the new? These ideas are currently ill defined but would need to be solidified. I'm an advocate of the horizon padding of the new grob (or prob) only ever kicking in and forgetting the previous ones, operating under the assumption that if someone wants to hardcode an earlier horizon padding upstream for a given skyline, it'd be better to tack the padding onto the boxes that make the skyline and not the skyline itself. Thoughts? New grob sounds good. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Sun, Feb 19, 2012 at 11:59 AM, David Kastrup d...@gnu.org wrote: m...@apollinemike.com m...@apollinemike.com writes: I've now optimized the crap out of this sucker and cached as much as I can cache. I'm not sure the caching is of much help. What kind of information would save recalculation? For example, I get the sense that the new key signature skyline function is not much faster than the old, which means that either the lookups of cached accidental skylines or the merging of these skylines to create the signature takes a lot of time. Merging sounds like O(n^2) unless one takes precautions. No, it's O(n + m). (m is the length of the other skyline). Building a skyline from scratch is O(n log n). However, there may be room for more heuristics that speed things up (see non_overlapping_skyline, which resulted in a measurable speedup). ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Sun, Feb 19, 2012 at 1:22 PM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 19, 2012, at 10:31 PM, Joe Neeman wrote: On Sun, Feb 19, 2012 at 11:59 AM, David Kastrup d...@gnu.org wrote: m...@apollinemike.com m...@apollinemike.com writes: I've now optimized the crap out of this sucker and cached as much as I can cache. I'm not sure the caching is of much help. What kind of information would save recalculation? For example, I get the sense that the new key signature skyline function is not much faster than the old, which means that either the lookups of cached accidental skylines or the merging of these skylines to create the signature takes a lot of time. Merging sounds like O(n^2) unless one takes precautions. No, it's O(n + m). (m is the length of the other skyline). Building a skyline from scratch is O(n log n). However, there may be room for more heuristics that speed things up (see non_overlapping_skyline, which resulted in a measurable speedup). If you get a chance to look over the entirety of the patch w/ your speed-up glasses on, I'd appreciate it. I know it looks like a lot, but the gist of it is that there are two main vertical-skylines functions (ly:grob::vertical-skylines-from-stencil and ly:grob::vertical-skylines-from-element-stencils) and the other skyline functions are (supposed to be) speed ups (ly:key-signature::vertical-skylines is probably the heftiest one). Lemme know if in any of these things you see places where I may be creating bottlenecks, where Scheme code may be slowing things down, where I'm passing around too-large data structures, needless recalculation (if it winds up being a lot of recalculation - I know I do some in beam.cc w/ ly:beam::vertical-skylines, for example, but I'm not sure how much this slows things down). [Sorry, forgot to reply all...] I think you're going about things in the wrong order. I think that the first goal should be to make the code clear and correct. (In fact, if your code were done but slow, you could push it to master but with skylining disabled for most grobs by default. That way, people could test it and give feedback. They could even enable skylining on more grobs if they didn't mind the performance hit.) Then you should profile and benchmark it to figure out which parts need to be faster (use ./configure --enable-profiling). For example, do you know that making special cases for beams and key signatures actually helps? Having said that, there are two places that I can think of which *might* speed things up: - you return a lot of vectorBox in stencil-intergrate.cc. This might mean that a lot of things get copied (not sure about this -- c++11 is supposed to help here). It might speed things up if you pass around const vectorBox instead. - the skylines you generate are a lot more complicated than they need to be. For example, you approximate beams with 11 horizontal segments. If you were to implement my suggestion about turning line segments into skylines, you could represent a beam with 1 sloped segment. I would encourage you to do the second part _before_ profiling, since I think it would make the code cleaner. The first part, though, you definitely shouldn't do unless you know that it's a problem. By the way, could you update your git branch please? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Feb 16, 2012 at 11:42 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 16, 2012, at 9:31 PM, Joe Neeman wrote:
On Thu, Feb 16, 2012 at 3:14 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 16, 2012, at 11:40 AM, joenee...@gmail.com wrote:
The buildings are in increasing order, so this should work:
Real last_end = -infinity_f;
for (...)
{
if (i-y_intercept_ -infinity_f)
return last_end;
last_end = i-end_;
}
return infinity_f;
Hey,
I know this is a lame question, but how would one write the reverse
iterator. I tried using reverse_iterator and g++ barfs, and I can't use
the same syntax one would use in a for loop w/ a vector.
That's a bit hard to say without knowing what you tried... did you use
rbegin() and rend()?
Yup - I more or less copied the example from cplusplus.com. As an
experiment, try writing a reverse iterator in that file to the tune of:
for (listBuilding::reverse_iterator i = buildings_.rbegin (); i !=
buildings_.rend (); ++i)
Anywhere in a function. You should see a compiler error.
How about -- instead of ++?
I fixed it, though, by reversing a copy of the list and iterating forward
through it.
That's still linear time, though...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Feb 16, 2012 at 11:42 PM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 16, 2012, at 9:31 PM, Joe Neeman wrote:
On Thu, Feb 16, 2012 at 3:14 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 16, 2012, at 11:40 AM, joenee...@gmail.com wrote:
The buildings are in increasing order, so this should work:
Real last_end = -infinity_f;
for (...)
{
if (i-y_intercept_ -infinity_f)
return last_end;
last_end = i-end_;
}
return infinity_f;
Hey,
I know this is a lame question, but how would one write the reverse
iterator. I tried using reverse_iterator and g++ barfs, and I can't use
the same syntax one would use in a for loop w/ a vector.
That's a bit hard to say without knowing what you tried... did you use
rbegin() and rend()?
Yup - I more or less copied the example from cplusplus.com. As an
experiment, try writing a reverse iterator in that file to the tune of:
for (listBuilding::reverse_iterator i = buildings_.rbegin (); i !=
buildings_.rend (); ++i)
Anywhere in a function. You should see a compiler error.
Yup, which is fixed by changing reverse_iterator to const_reverse_iterator.
The hint was in the error message:
no known conversion for ... 'std::_List_const_iteratorBuilding' to
'const std::_List_iteratorBuilding'
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Feb 16, 2012 at 3:14 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
On Feb 16, 2012, at 11:40 AM, joenee...@gmail.com wrote:
The buildings are in increasing order, so this should work:
Real last_end = -infinity_f;
for (...)
{
if (i-y_intercept_ -infinity_f)
return last_end;
last_end = i-end_;
}
return infinity_f;
Hey,
I know this is a lame question, but how would one write the reverse
iterator. I tried using reverse_iterator and g++ barfs, and I can't use
the same syntax one would use in a for loop w/ a vector.
That's a bit hard to say without knowing what you tried... did you use
rbegin() and rend()?
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Mon, Feb 13, 2012 at 4:48 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 13, 2012, at 5:41 AM, Joe Neeman wrote: On Thu, Feb 9, 2012 at 9:50 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 7, 2012, at 6:47 PM, m...@apollinemike.com wrote: I did some experiments with caching that are up on: dev/skylines-cached Hey all, Fresh branch up at dev/skylines-cached. This patch should only increase compilation time of a LilyPond score by 1-2 seconds for every minute. Wow, that's quite some work you've done. I haven't read it carefully yet, but here are some broad suggestions/comments: You can thank inclement weather and late trains! Regarding your comment in axis-group-interface.cc:802, if it gets called twice, there's a bug (usually caused because we've asked for the extent of a cross-staff grob before line-breaking has happened). I'm fine with trying to detect the bug and continue, but I think there should be a programming_error (at least for NDEBUG builds; see the way cyclic dependencies are reported in grob-property.cc). The reason the function is called twice is because it'd be called through Axis_group_interface::calc_skylines and then again via Hara_kiri_group_spanner::calc_skylines, potentially before one of these finishes to execute. It doesn't seem like this could be related to a line breaking problem. In my experience, it usually is. What happens is that calc_skylines asks for the y-extent of some cross-staff grob. In order for that grob to find its extent, it needs to know how far apart the staves are, which depends on the height of the axis-group, and so you have a cyclic dependency. But even if line-breaking isn't the /reason/ for the cyclic dependency, your comment indicates that there /are/ cyclic dependencies, which are bugs and should therefore have programming errors. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Tue, Feb 14, 2012 at 1:55 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 14, 2012, at 9:44 AM, Joe Neeman wrote: On Mon, Feb 13, 2012 at 4:48 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 13, 2012, at 5:41 AM, Joe Neeman wrote: On Thu, Feb 9, 2012 at 9:50 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 7, 2012, at 6:47 PM, m...@apollinemike.com wrote: I did some experiments with caching that are up on: dev/skylines-cached Hey all, Fresh branch up at dev/skylines-cached. This patch should only increase compilation time of a LilyPond score by 1-2 seconds for every minute. Wow, that's quite some work you've done. I haven't read it carefully yet, but here are some broad suggestions/comments: You can thank inclement weather and late trains! Regarding your comment in axis-group-interface.cc:802, if it gets called twice, there's a bug (usually caused because we've asked for the extent of a cross-staff grob before line-breaking has happened). I'm fine with trying to detect the bug and continue, but I think there should be a programming_error (at least for NDEBUG builds; see the way cyclic dependencies are reported in grob-property.cc). The reason the function is called twice is because it'd be called through Axis_group_interface::calc_skylines and then again via Hara_kiri_group_spanner::calc_skylines, potentially before one of these finishes to execute. It doesn't seem like this could be related to a line breaking problem. In my experience, it usually is. What happens is that calc_skylines asks for the y-extent of some cross-staff grob. In order for that grob to find its extent, it needs to know how far apart the staves are, which depends on the height of the axis-group, and so you have a cyclic dependency. Actually, before I respond fully to your e-mail, I just want to make sure we're talking about the same comment. I'm looking at Finding extents may have trigged another skyline lookup, which will have done the shifting. In this case, we simply add the boxes. Is that it? Actually, I was referring to a comment that has since disappeared: -because this loop results in the looking up of extents, it may trigger -the calling of this function a second time before the first one finishes -to execute. thus, the outside-staff-priority may be set to false. that -is why this check is necessary. but actually I preferred your older code (plus a programming_error) to the current one. A cyclic dependency is a bug, so better to catch it early than to allow it and try to correct afterwards. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
On Thu, Feb 9, 2012 at 9:50 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Feb 7, 2012, at 6:47 PM, m...@apollinemike.com wrote: I did some experiments with caching that are up on: dev/skylines-cached Hey all, Fresh branch up at dev/skylines-cached. This patch should only increase compilation time of a LilyPond score by 1-2 seconds for every minute. Wow, that's quite some work you've done. I haven't read it carefully yet, but here are some broad suggestions/comments: Regarding your comment in axis-group-interface.cc:802, if it gets called twice, there's a bug (usually caused because we've asked for the extent of a cross-staff grob before line-breaking has happened). I'm fine with trying to detect the bug and continue, but I think there should be a programming_error (at least for NDEBUG builds; see the way cyclic dependencies are reported in grob-property.cc). Since you seem to be expanding the scope of skylines, you may want to add some more flexible constructors instead of doing everything with boxes. For example, it should be easy to add a skyline constructor that builds a skyline from a collection of line segments. Then you can approximate beziers with line segments instead of boxes. I think I even had some code for this lying around, but I can't find it now... add_grobs_of_one_priority looks ok, but a bit complicated. It would be simpler if you got rid of the boxes altogether and only used skylines. You could hardcode ly:grob::vertical-skylines-from-stencil as a default for vertical-skylines in the same way that ly:grob::stencil-height is hardcoded as a default for Y-extent. Then you can assume that every grob has a skyline. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Gets vertical skylines from grob stencils (issue 5626052)
Could you publicize work-in-progress patches like this as a git branch instead of a Rietveld issue? Git branches are easy for reviewers to check out, fast-forward, revert, etc. That way, people can offer broad comments. When the patch is finished (ie. you can't think of anything you need to change), then upload it to rietveld, where it's easy to make specific, in-line comments. Avoiding rietveld until the patch is done will also prevent the situation where someone makes a bunch of detailed comments to lines that you're in the middle of changing anyway. Cheers, Joe On Sat, Feb 4, 2012 at 1:28 PM, mts...@gmail.com wrote: Reviewers: , Message: Sorry in advance for the whitespace errors. This patch provides a generic framework for building vertical skylines out of boxes by traversing through a stencil. It currently only implements skylines for three stencil types (draw-line, named-glyph, and glyph-string) and can do more for other glyphs. It is modular, so as skyline estimation improve for a given stencil, that function can be worked on alone w/o touching the other parts of stencil-integral.scm. The implementation for glyph-string is ugly and slightly incorrect for y heights of these stencils...it would be infinitely easier if the stencil could contain information about y extents, but unfortunately, PangoGlyphGeometry does not carry height information. This error does not have a bearing on the visual results in this patch, but it'd be good to find a way to make the dimensions exact. I'm also not sure that line thickness is tacked on correctly for the draw-line boxes, but it seems to yield correct results. Cheers, MS Description: Gets vertical skylines from grob stencils Please review this at http://codereview.appspot.com/**5626052/http://codereview.appspot.com/5626052/ Affected files: A input/regression/tuplet-**bracket-vertical-skylines.lyhttp://tuplet-bracket-vertical-skylines.ly A input/regression/volta-**bracket-vertical-skylines.lyhttp://volta-bracket-vertical-skylines.ly M lily/axis-group-interface.cc A lily/box-scheme.cc M lily/include/box.hh M lily/include/skyline.hh M lily/skyline-pair.cc A lily/skyline-scheme.cc M lily/skyline.cc M lily/stencil-scheme.cc M lily/tuplet-bracket.cc M lily/volta-bracket.cc M scm/define-grobs.scm M scm/lily.scm A scm/stencil-integral.scm __**_ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/**listinfo/lilypond-develhttps://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds some info about pure properties to the CG. (issue 5364048)
Bah, I just wrote out a nice reply on the codereview site and it got eaten... On Fri, Nov 18, 2011 at 12:03 AM, m...@apollinemike.com m...@apollinemike.com wrote: On Nov 16, 2011, at 2:19 AM, joenee...@gmail.com wrote: http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1888 Documentation/contributor/programming-work.itexi:1888: taken from the stencil. Actually, the requirement is different: the print function must not have any side effects. The print function doesn't necessarily have to deliver the same result at all stages in the compilation process. For example, if some side-effect modifies the font size of a grob mid-compilation, then note-head::print will deliver a stencil of a different height. Then I misunderstood what pure means in lily-speak. I thought that a pure function had the dual condition that it (a) always return the same value for a given begin and end range; and (b) not trigger any side effects. Are there any cases where pure functions do deliver different results for the same range before line breaking? And, if not, would this even be conceivable/desirable? I can't think of a situation where it's desirable, but it's certainly conceivable. If I write lily code that, for whatever reason, has a callback which changes Slur 'height-limit then Slur::calc_pure_height will also change. We tend to avoid the use of set_property after the translation step, so this sort of thing is unlikely; the point is, though, that the pure callback itself doesn't worry about such things. It just tries to avoid side-effects, and if something else with side effects messes with grob properties then the pure callback can change its value accordingly. Lastly, the idea of not trigger any side effects is something that I grok more than I understand. Is there any way to communicate what it means to not trigger side effects (i.e. never calls (or results in the calling of) set_property on another property with a pure estimation, etc.) to someone who doesn't know what these side effects are? The main side effects in lilypond are set_property, set_object and suicide. These are easy to avoid; the trickier part is that any call to get_property could conceivably trigger a callback that will itself have side effects. http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1901 Documentation/contributor/programming-work.itexi:1901: @end itemize I think the preceding four lists can be understood as follows: if you have a Grob and you want to estimate its height, what can you do? - If its Y-extent callback is pure, just use it (pure-functions) - If its Y-extent callback is ly:grob::stencil-height and the stencil callback is pure, then it's safe to use ly:grob::stencil-height (pure-print-functions) - If we have a manually-created pure version of its Y-extent callback, use that (pure-conversions-alist and pure-print-to-height-conversions) I agree, but is this not clear from the document as it stands and, if not, how should it be modified so that it is clear? My biggest worry is clarity, as I often don't understand what I'm saying, so I'd imagine that others will have an even harder time. I'm not sure which version is better for new readers. It's just that you're explaining these lists in terms of what they contain, while I find it easier to think of them in terms of their role in call-pure-function (which also helps to explain why we would bother to have these lists in the first place). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: countdown to 20110928
Issue 1846: Improves horizontal spacing of axis groups that SpanBar grobs traverse - R 4917046 I haven't heard back from Joe yet, who had some reservations, and I don't want to push this without his blessing. Sorry, didn't realize you were waiting on me. It looks fine to me now. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 155: parentheses include accidentals and dots. (issue 5047048)
Thanks, I've re-uploaded it and it seems to work now. Joe On Mon, Sep 19, 2011 at 10:19 PM, mts...@gmail.com wrote: Hey Joe, For some reason, the scm files say Upload in progress. This may come from a MIME type issue for scm files (upload.py doesn't know that scm files correspond to Scheme language files). I forget how to fix this, but I know the fix has been suggested somewhere on the list. Cheers, MS http://codereview.appspot.com/5047048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On Mon, Sep 19, 2011 at 9:35 PM, David Kastrup d...@gnu.org wrote:
Colin Campbell c...@shaw.ca writes:
Issue 935: Enhancement: optional arguments in music functions - R
5023044
Cancel countdown. I am still fuzzing with avoiding O(n^2) rules for n
syntax classes, and trying to cater for multiple optional arguments in a
row. Doing both is a challenge requiring quite a bit of cleanup, and
applying the current patch would be a step backward. Hope to get
something working soon. I have a working version right now, but don't
like to leave ~80 shift/reduce conflicts (basically 2n with n being the
number of terminal symbols that may start an argument).
Have you considered adding a special syntax for optional arguments?
Like \foo[opt]{mandatory} in tex...
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improves horizontal spacing of axis groups that SpanBar grobs traverse. (issue 4917046)
On Tue, Aug 30, 2011 at 8:58 AM, Mike Solomon mike...@ufl.edu wrote: On Aug 30, 2011, at 5:53 PM, joenee...@gmail.com wrote: Correct me if I'm wrong, but this is my understanding: wherever there's a SpanBar, you're creating SpanBarStubs between every relevant pair of staves. These don't actually get printed; they're just there for the pure-height (because the SpanBar height is pretty much the whole system, so it doesn't tell you where the gaps are). Yes. If that's correct, I have two broad comments: it's worth commenting somewhere (span-bar-stub-engraver.cc, maybe) that the purpose of SpanBarStub is for pure-height only. Will do. But more importantly, isn't SpanBar now obsoleted by SpanBarStub? That is, you can just remove the SpanBar altogether and print the SpanBarStubs. Mmm...you're not unright, but I'd prefer to do that in another patch if that's OK. It'd require a lot of deleting and moving around, and I'd first like to make sure that these stubs are the code base and bug free for a while before I deprecate an entire grob (and figure out how to deal with the syntax changes that come with said deprecation). Ok, then lgtm. Probably worth putting in a comment that we intend to remove SpanBar. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Does better polynomial calculations for avoid objects. (issue 4860042)
On Tue, Aug 23, 2011 at 12:36 AM, Mike Solomon mike...@ufl.edu wrote: On Aug 23, 2011, at 6:55 AM, joenee...@gmail.com wrote: http://codereview.appspot.com/4860042/diff/1/lily/bezier.cc File lily/bezier.cc (right): http://codereview.appspot.com/4860042/diff/1/lily/bezier.cc#newcode239 lily/bezier.cc:239: return p.minmax (sol[LEFT][0], sol[RIGHT][0], d != LEFT); On 2011/08/19 07:03:50, MikeSol wrote: On 2011/08/18 21:36:45, joeneeman wrote: If there are multiple intersections with (say) r, then Polynomial::solve doesn't seem to return them in any useful order. So sol[RIGHT][0] is really just an arbitrary solution, isn't it? True, but this seems no worse than line 81 where ts[0] is returned. Not that this is a good excuse... Right, but what really bothers me is that you're then using sol[RIGHT][0] as though it means something. So what this function seems to do (suppose ax=X_AXIS) is to take an arbitrary point where the curve intersects x=r and an arbitrary point where the curve intersects x=l and then finds the maximum y value of the curve between those two points. True. A well-formed slur should never retrograde along the X-axis, and thus, the size of sol[LEFT] and sol[RIGHT] should be 1 after filtering out all values less than 0 and greater than 1. I think that the programming errors in the current patch should do the trick. Is it so difficult to just make the solution general? Assuming axis is Y_AXIS and d is UP, the maximum must appear either at a critical point of the y-axis polynomial or when the x-axis polynomial is equal to either l or r. You can filter the critical points to make sure the x coordinate is within the correct interval, and then filter everything to make sure that the parameter is between 0 and 1. You'll have no more than 8 points left and you take the one with the largest Y coordinate. I realize that it's unlikely to trigger, at least in the way that Lilypond currently uses this code, but I do feel that code in a file called bezier.cc should work for bezier curves in general. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile debug package in Debian
On Fri, Jul 22, 2011 at 1:32 PM, Federico Bruni fedel...@gmail.com wrote: Il giorno gio, 21/07/2011 alle 23.26 +0700, Joe Neeman ha scritto: If the debugging information were installed, there would be more information inside the (). Since Debian doesn't seem to have a package for it, the easiest way to get debugging information may be to compile guile yourself. I've downloaded the sources in the debian repository: # apt-get build-dep guile-1.8 $ apt-get source guile-1.8 $ ./configure --enable-guile-debug You don't need --enable-guile-debug here (it enables some internal guile stuff, which is independent from the debug symbols that I want). But you'll need to add --disable-error-on-warning; your compiler is probably newer than the one that built the Debian package, and it's a little more strict with warnings. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: guile debug package in Debian
On Wed, Jul 20, 2011 at 12:42 PM, Federico Bruni fedel...@gmail.com wrote: Il giorno mar, 19/07/2011 alle 18.19 -0600, Colin Campbell ha scritto: I'm pretty sure the stuff you need is in the guile-1.8-dev package, Federico. On my Ubuntu 11.04, the package contains files such as debug.h and debug-malloc.h among others. Ok, thanks. That's a bad news for Joe, because I had it installed when I generated the backtrace with gdb. No, I don't think the debugging information is there. In the backtrace you sent me, you'll notice that functions in lilypond show their arguments: #19 0x08214a91 in Score::book_rendering (this=0x84e5538, layoutbook=0x859e220, default_def=0x8575248) at /home/fede/lilypond-master/lily/score.cc:160 while functions from guile just show an empty pair of parentheses (even when the function takes some arguments): #13 0xb7f2a9f1 in scm_call_1 () from /usr/lib/libguile.so.17 If the debugging information were installed, there would be more information inside the (). Since Debian doesn't seem to have a package for it, the easiest way to get debugging information may be to compile guile yourself. If you install it in /usr/local (which should be the default) and you ensure that /usr/local/bin precedes /usr/bin in your PATH, then re-./configure lilypond and rebuild so that it will use the new guile. Cheers, Joe Maybe there's something I can do in gdb to improve the backtrace? This is what I've done: gdb out/bin/lilypond run ../input/regression/midi/key-initial.ly bt These are the guile packages on my system (i flag shows the packages installed): $ aptitude search guile p dico-module-guile - RFC 2229 compliant modular dictionar v guile - p guile-1.6 - The GNU extension language and Schem p guile-1.6-dev - Development files for Guile 1.6 p guile-1.6-doc - Reference and tutorial documentation p guile-1.6-libs - Main Guile libraries p guile-1.6-slib - Guile SLIB support i A guile-1.8 - GNU extension language and Scheme in i guile-1.8-dev - Development files for Guile 1.8 p guile-1.8-doc - Documentation for Guile 1.8 i A guile-1.8-libs - Core Guile libraries v guile-1.8-slib - i A guile-cairo - Guile bindings for Cairo i guile-cairo-dev - Guile bindings for Cairo, developmen p guile-db - Berkeley DB module for Guile v guile-doc - i guile-g-wrap - scripting interface generator for C p guile-gnome2-canvas - Guile bindings for libgnomecanvas i guile-gnome2-dev - Guile GObject binding support librar p guile-gnome2-gconf - Guile bindings for GConf i A guile-gnome2-glib - Guile bindings for GLib p guile-gnome2-gnome - Guile bindings for libgnome p guile-gnome2-gnome-ui - Guile bindings for libgnome p guile-gnome2-gtk - Guile bindings for GTK+, libglade, P p guile-gnome2-vfs - Guile bindings for GnomeVFS p guile-gnutls - the GNU TLS library - GNU Guile bind i guile-library - Library of useful Guile modules p guile-pg - Guile bindings for the PostgreSQL cl v libguile-dev - p libguile-ltdl-1 - Guile's patched version of libtool's p libgv-guile - Guile bindings for graphviz p mailutils-guile - GNU mailutils Guile interpreter and p xchat-guile - Guile scripting plugin for XChat ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: where X-extent of noteheads is set?
2011/7/17 Janek Warchoł lemniskata.bernoull...@gmail.com: I've searched in note-head.cc, note-column.cc, note-heads-engraver.cc but found nothing... I believe it defaults to ly:grob::stencil-width (probably in grob.cc). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: fixes for annotate-spacing
The patch at http://codereview.appspot.com/4724041/ fixes the output of annotate spacing in a few ways: - Fixes annotate-spacing to use the new spacing names. - Annotates spacing between staves as well as spacing between systems. - Fixes some collisions between annotations. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: anchor-alignment in line-spanner.cc : is this vestigial?
On Tue, Jun 14, 2011 at 9:40 PM, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, I see that the line-spanner print function looks for something that is called anchor-alignment (git blame insinuates that it was Joe who added this). This alignment, so far as I can see, is used nowhere in the code (nor is its use documented). Is it vestigial, and if so, can I nix it? It was originally used to align the trill part of a trill spanner correctly. The point is that you can ask, say, to align the left (or right) end of the trill with the anchor point instead of the center. The code to use anchor-alignment seems to be still there (line-spanner.cc:300), but given that the anchor-alignment variable is neither set nor documented, probably no one would miss it if you removed it. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Close or document the stretchability=0 backdoor?
On Fri, May 27, 2011 at 10:44 PM, Keith OHara k-ohara5...@oco.net wrote: One of the special-cases in the LilyPond code is confusing me. ( This special-case code is in Page_layout_Problem::get_fixed_spacing(). ) If the flexible-vertical-spacing variable 'stretchability is defined, but has value 0.0, such as: *-*-spacing = #'((basic-distance . 16) (stretchability . 0) (padding . -100) (minimum-distance . 0)) then a) the staves will not stretch to fill extra space (documented and sensible) b) the staves will not compress, making basic-distance serve as minimum-distance (not documented, and I don't know if this it is done consistently) c) some people expect padding to be ignored, per Carl's comment on issue 1654 (not documented and I can't find it in the code history) It seems to me that one could achieve (b) by setting minimum-distance equal to basic-distance. It is less cumbersome, however, to say \override VerticalAxisGroup #'staff-staff-spacing #'stretchability = #0.0 than to look up whatever basic-distance happens to be. This backdoor really confuses me, however, in cases like the definition of Lyrics in egraver-init.ly. \override VerticalAxisGroup #'nonstaff-nonstaff-spacing = #'((basic-distance . 0) (minimum-distance . 2.8) (padding . 0.2) (stretchability . 0)) Why is basic-distance smaller than minimum-distance? What distance should I expect in tight spacing (and a single-line parent staff like a drum staff) ? What is stretchability = 0 supposed to do ? I don't think it was originally supposed to do anything, but it turned out to be a useful way to force a fixed spacing. With this application in mind, I think (b) and (c) are both appropriate, and that the distance should be the maximum of basic-distance and minimum-distance. So in the definition above, basic-distance could be anything less than 2.8 and the effect would be the same. I'm not 100% attached to this, though, so if you want to change something specific then don't be shy... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
this silly bug about thinking non-cross-staff beams are cross-staff
Here's a patch: http://codereview.appspot.com/4564041 I don't think this has a specific bug number, although it's at least mentioned in the comments for 1043. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
no anonymous functions in define-grobs.scm?
The attached patch fixes issue 1300, but I'm wary of it because define-grobs.scm:23 says WARNING: don't use anonymous functions for initialization. Does anyone know why that is? Normally I'd use an ly:simple-closure instead of an anonymous function, but that doesn't work because or is a macro... Cheers, Joe diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm index 84c3f72..2383469 100644 --- a/scm/define-grobs.scm +++ b/scm/define-grobs.scm @@ -2121,7 +2121,10 @@ (TextScript . ( (avoid-slur . around) - (cross-staff . ,ly:script-interface::calc-cross-staff) + (cross-staff . ,(lambda (g) + (or + (ly:script-interface::calc-cross-staff g) + (ly:side-position-interface::calc-cross-staff g (direction . ,DOWN) (extra-spacing-width . (+inf.0 . -inf.0)) (outside-staff-priority . 450) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pure properties
On Wed, May 25, 2011 at 1:05 AM, m...@apollinemike.com m...@apollinemike.com wrote: On May 24, 2011, at 11:08 AM, Joe Neeman wrote: A pure callback is one that has no side-effects. In define-grobs.scm, you will find a list of pure callbacks, along with an associative list that allows you to substitute a non-pure callback for a pure one. Pure callbacks are important for spacing and page-breaking, particularly pure Y-extent and Y-offset callbacks. For example, a slur cannot know its true Y-extent until after the page breaks, line breaks, and horizontal spacing have been completed. But we need to know its Y-extent while computing the page breaking, so we can see if things fit on a page without collisions; hence ly:slur::pure-height. Cheers, Joe Thanks Joe! So, if I understand you correctly, ly:slur::pure-height provides a side-effectless approximation that is useful for other functions, whereas the real height is what is calculated after all of the line breaking has been done? Is there ever a case, then, where the approximated pure property differs so greatly from the actual property that the erroneous first-pass approximation leads to bad typsetting? Yes. Usually it leads to either an overfull or an underfull page. We had a lot of these bugs after the new page-breaking code was introduced, but I haven't seen any for a while now. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Pure properties
A pure callback is one that has no side-effects. In define-grobs.scm, you will find a list of pure callbacks, along with an associative list that allows you to substitute a non-pure callback for a pure one. Pure callbacks are important for spacing and page-breaking, particularly pure Y-extent and Y-offset callbacks. For example, a slur cannot know its true Y-extent until after the page breaks, line breaks, and horizontal spacing have been completed. But we need to know its Y-extent while computing the page breaking, so we can see if things fit on a page without collisions; hence ly:slur::pure-height. Cheers, Joe On Tue, May 24, 2011 at 10:31 AM, m...@apollinemike.com m...@apollinemike.com wrote: Hey all, I think I've asked this question before, but I can't find the response - sorry if I'm repeating myself! Could someone please send me a paragraph-long response about what pure properties are and how/when/why they're used? The more sequential, the better (i.e. pure properties are defined in X for the purpose of doing Y when lilypond hits function Z). git grep shows the word `pure' all over the place, and I feel kinda stupid not knowing what pure means in the LilyPond lingo. I'm writing a patch right now that allows LilyPond to do multiple passes through a score to fix several spacing issues I've run into, and before taking it on seriously I'd like to fill this gap in my knowledge of the program. Cheers, Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
On Mon, Mar 21, 2011 at 8:11 PM, Keith OHara k-ohara5...@oco.net wrote: On Sat, 19 Mar 2011 22:46:51 -0700, Joe Neeman joenee...@gmail.com wrote: It might cause problems if pure is true. When the method is called with pure, it shouldn't cause any side effects. For a concrete example, this will mess up if you have Staff Lyrics with affinity down Staff that sometimes disappears Lyrics with affinity up Staff Unfortunately, if I protect the assignment to the property with an if (!pure), I am letting the page-breaking planning rely on the user-requested affinities, and then changing them for the page-layout phase. The boolean 'pure' asks explicitly that we keep the state unchanged, but there was always an implicit expectation that certain properties are unchanging. I don't quite understand this comment. The only effect of set_property is to prevent the warning from being triggered more than once per system. In fact, the layout would be completely unchanged even if you removed the whole if(after_affinity before_affinity) block. So why does it matter if we condition set_property on something? On Mon, 21 Mar 2011 19:22:49 -0700, joenee...@gmail.com wrote: Wouldn't a comment be better then? Yep. I'll add a comment next time I have Linux up. The only effect of the original code was to give warning, not to change the effective affinity, demonstrating that nothing explodes if 'staff-affinities increase'. Do you remember what the warning intended to protect against? I think it was just to let the user know not to expect a sane layout. The serious problem (coming up again in issue 1569) occurs when staff-affinity of the first or last non-staff points to a spaceable staff that is not present in the system. It seems this needs to be caught one or two layers up, in distribute_loose_lines() or maybe better in Align_interface::internal_get_minimum_translations() So I'll tidy up this small issue, but let's start looking at the problem of unrequited affinity of loose lines at the top/bottom of the system. I think the problem is that not enough space is being reserved in the first pass (ie. the non-loose lines part) of the layout and so the loose lines don't fit. Align_interface::internal_get_minimum_translations may be responsible, but it isn't actually used for distances between systems, so it's also worth investigating bottom_skyline_. Unfortunately, I'm going backpacking starting tomorrow, but I'm happy to answer questions once I get back (Sunday). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
On Mon, Mar 21, 2011 at 11:18 PM, Keith OHara k-ohara5...@oco.net wrote: On Mon, 21 Mar 2011 23:06:12 -0700, Joe Neeman joenee...@gmail.com wrote: Unfortunately, if I protect the assignment to the property with an if (!pure), I am letting the page-breaking planning rely on the user-requested affinities, and then changing them for the page-layout phase. The boolean 'pure' asks explicitly that we keep the state unchanged, but there was always an implicit expectation that certain properties are unchanging. I don't quite understand this comment. The only effect of set_property is to prevent the warning from being triggered more than once per system. In fact, the layout would be completely unchanged even if you removed the whole if(after_affinity before_affinity) block. So why does it matter if we condition set_property on something? In a typical case, the effect is after-set_property(staff-affinity, DOWN) and then when get_spacing_spec is called to determine the next spring, working through the (non)staffs in the system, it will look up the staff affinity we just set for use as before_affinity, thus the next spring is changed. The code in the if(after_affinitybefore_affinity) block does change the output for the example at the head of issue 1555. Ok, good point. In that case, a better way to avoid too many warnings might be just to add a static bool to check if a warning has already been issued. Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)
On Sat, Mar 19, 2011 at 7:03 PM, mts...@gmail.com wrote:
LGTM.
I can't think of a case where updating `after' would cause problems -
this seems like a good solution.
It might cause problems if pure is true. When the method is called with
pure, it shouldn't cause any side effects. For a concrete example, this
will mess up if you have
Staff
Lyrics with affinity down
Staff that sometimes disappears
Lyrics with affinity up
Staff
because the staff that sometimes disappears will trigger the warning
_before_ line breaking (with pure set to true). This can be fixed by
adding
if (!pure)
{
warning (...);
after_affinity = before_affinity;
}
because there isn't really a need to print out the warning every time the
pure version is called.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
On Sat, Mar 5, 2011 at 10:18 PM, Mike Solomon mike...@ufl.edu wrote: Hey all, After a bit of back and forth w/ Han Wen, I have drummed up a way to split this up such that it can be part of LilyPond in two phases. It follows his suggestion to push all of the non-balloon-related stuff first, and to push that second. It will set the stencil property of FootnoteItem and FootnoteSpanner to #f in define-grobs.scm. This means that whatever people write for the annotation part of the footnote will be swallowed up and not used, whereas the note part on the bottom of the page will be printed. If anyone has arguments for pushing this whole thing in its entirety, let me know. I am in favor of that for the reasons I stated in my previous e-mail, but I also realize that big chunks of code pushed all at once can make bug tracking interminable. If not, the plan is to push the non-balloon-related stuff today, let it simmer for a few days, and then push the balloon related stuff used for the in-document annotations. I will make a nice long commit message detailing this so that, hopefully, experimental users don't waste hours figuring out what happened to their non-appearing annotations. Alternatively, if anyone feels that I should split this up but that I am splitting it up the wrong way, please let me know. That sounds fine to me. Do you have a patch showing the part you are going to push first? I was happy with the spacing-related code up until your break-visibility changes, but if you're going to include anything since then, I'd like to have another quick look (I have to catch a plane in 12 hours; if you put up your patch before then, I'll have a look right away). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements footnotes in LilyPond (issue4245062)
On Sat, Mar 5, 2011 at 11:57 PM, Mike Solomon mike...@ufl.edu wrote:
On Mar 5, 2011, at 7:19 AM, Joe Neeman wrote:
On Sat, Mar 5, 2011 at 10:18 PM, Mike Solomon mike...@ufl.edu wrote:
Hey all,
After a bit of back and forth w/ Han Wen, I have drummed up a way to split
this up such that it can be part of LilyPond in two phases. It follows his
suggestion to push all of the non-balloon-related stuff first, and to push
that second. It will set the stencil property of FootnoteItem and
FootnoteSpanner to #f in define-grobs.scm. This means that whatever people
write for the annotation part of the footnote will be swallowed up and not
used, whereas the note part on the bottom of the page will be printed.
If anyone has arguments for pushing this whole thing in its entirety, let
me know. I am in favor of that for the reasons I stated in my previous
e-mail, but I also realize that big chunks of code pushed all at once can
make bug tracking interminable.
If not, the plan is to push the non-balloon-related stuff today, let it
simmer for a few days, and then push the balloon related stuff used for the
in-document annotations. I will make a nice long commit message detailing
this so that, hopefully, experimental users don't waste hours figuring out
what happened to their non-appearing annotations. Alternatively, if anyone
feels that I should split this up but that I am splitting it up the wrong
way, please let me know.
That sounds fine to me. Do you have a patch showing the part you are going
to push first? I was happy with the spacing-related code up until your
break-visibility changes, but if you're going to include anything since
then, I'd like to have another quick look (I have to catch a plane in 12
hours; if you put up your patch before then, I'll have a look right away).
Cheers,
Joe
Patch attached. The stuff that comes from your comments regarding
break-visibility is implemented in Balloon_interface::is_visible.
I find the return value of Balloon_interface::is_visible strange (first of
all, the name suggests that it should just be bool). For example, it returns
BEGINNING_OF_LINE if the footnote is visible and in the middle of the line
(but only if the parent has a break-visibility property). I might be missing
something, but it looks to me like you can get rid of this function, and
just set FootnoteItem 'break-visibility to
(lambda (grob)
(let ((parent (ly:grob-parent grob X))
(par-vis (ly:grob-property parent 'break-visibility))
(parent-visibility (if (vector? par-vis) par-vis #(#t #t #t
(vector
(vector-ref parent-visibility 0)
(vector-ref parent-visibility 1)
(and
(vector-ref parent-visibility 2)
(not (vector-ref parent-visibility 0))
(There's still a corner case here, because you need the footnote to be
visible if it is in the first column of the score...)
I don't like the interpolation stuff for spanner-placement. Why not just
restrict the valid values to -1 and 1? It seems that any other value doesn't
really have user-predictable behaviour anyway...
I think you have a bug in system.cc:281, because there is no guaranteed
order between the grobs whose rank is the ending column. In particular, the
one that appears at the beginning of the next line might appear first, and
then you will break prematurely. Maybe something like:
bool end_of_line_visible = true;
if (Spanner *s ...)
...
if (Item *item ...)
{
end_of_line_visible = (LEFT == item-break_status_dir ());
...
}
if (pos (int)start)
continue;
if (pos (int)end)
break;
if (pos == (int)end !end_of_line_visible)
continue;
...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
On Thu, Mar 3, 2011 at 3:08 AM, Mike Solomon mike...@ufl.edu wrote:
On Mar 2, 2011, at 8:05 AM, Mike Solomon wrote:
On Mar 2, 2011, at 7:23 AM, joenee...@gmail.com wrote:
I haven't had time to look at this carefully, but I'll have closer look
later. What I don't understand, though, is why this problem needs such
extensive changes. If it's just a matter of preventing repeated
footnotes at the beginning/end of a line, it should be enough to examine
footnote-get_column ()-get_rank ()
and possibly
footnote-get_parent (X_AXIS)-get_property (break-visibility)
when you're constructing a Line_details.
This may work - I honestly don't know. I'll look into doing it this way.
I had a chance to mull over it a little bit.
When I compile the following minimal example from Neil:
\new Staff \with { \consists Footnote_engraver }
\relative c' {
\footnoteGrob #'TimeSignature #'(0 . 2) foo bar
c1
}
as I populate the grob vector, pacifier prints to the command line tell me
that all 3 time signatures have a rank of 0 and yield true for is_visible
().
I guess that's because TimeSignature is always break-visible. In any case,
you can tell which TimeSignature is which by looking at
Item::break_status_dir.
As a general remark about the order of things, the line breaking and page
breaking are finalized at the same time. Therefore you shouldn't rely, in
page breaking, on any of the line breaking having been done.
The only way I can think of weeding the fake ones out is by killing the
ones with no x-extent. Your suggestion does, however, seem to tie into
cases like:
\new Staff \with { \consists Footnote_engraver }
\relative c' {
c1 \time 3/4 \break \pageBreak \footnoteGrob #'TimeSignature #'(0 . 2)
foo bar c2.
}
So one point to make here is that more than one TimeSignature is actually
visible, and you probably only want one footnote to show up. So filtering on
visibility isn't quite enough; you also need to decide which one should have
a footnote if the grob falls on a line break. In any case, I think that all
the information you need is available at the time Line_details is
constructed: you can check the break-visibility and break_status_dir of each
grob, and you can check
whether they fall on the line break by looking at their column's rank.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
On Thu, Feb 24, 2011 at 12:31 PM, Mike Solomon mike...@ufl.edu wrote: On Feb 23, 2011, at 5:14 PM, joenee...@gmail.com wrote: http://codereview.appspot.com/4213042/diff/2001/lily/constrained-breaking.cc File lily/constrained-breaking.cc (right): http://codereview.appspot.com/4213042/diff/2001/lily/constrained-breaking.cc#newcode555 lily/constrained-breaking.cc:555: SCM footnotes = paper-c_variable (footnotes); As you mentioned in your comment to Reinhold, this has some issues. If you want to get footnotes from markups, you could try adding a footnotes_ field to Stencil (modifing Stencil::add_stencil to concatenate the footnote lists) and then return a blank stencil with some footnotes_ from your footnotes markup command. Then when you create a Prob, you can get its footnotes by reading them from the stencil. But I'm not sure this will work and I think it will take a fair amount more effort anyway. Since the rest of the patch is almost ready, maybe it's better to do that in a separate patch. I fail - I've been trying for 2 hours to implement something like this, and it doesn't work. It's making me thing that a 2.15 task may be redefining how when paper systems are represented internally such that Stencils can better talk to their Probs. I've done everything, from working with the expr_ field to various contortions of the output def, and I can't get it up and running :( Yeah, you don't want to modify the output def (most of the internals of the backend don't happen in a predefined order, so modifying a global structure like an output def is fraught with peril). Did you try adding an extra field (in C++) to Stencil? If you add - SCM footnotes_ to Stencil, - scm_gc_mark (footnotes_) to Stencil::mark_smob (for SCM garbage collection) - footnotes_ = scm_append (footnotes_, s.footnotes_) to Stencil::add_stencil - a scheme function ly:stencil::make-footnote which takes a stencil and creates an empty stencil with the given stencil in its footnote list then the footnotes should be accessible from the stencil when you make the Prob. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Reduces algorithm time by prefinding footnoted grobs (issue4213042)
On Thu, Feb 24, 2011 at 2:49 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Wed, Feb 23, 2011 at 11:11 PM, Joe Neeman joenee...@gmail.com wrote: - SCM footnotes_ to Stencil, - scm_gc_mark (footnotes_) to Stencil::mark_smob (for SCM garbage collection) - footnotes_ = scm_append (footnotes_, s.footnotes_) to Stencil::add_stencil - a scheme function ly:stencil::make-footnote which takes a stencil and creates an empty stencil with the given stencil in its footnote list then the footnotes should be accessible from the stencil when you make the Prob. I hope this is just a hack, to add footnotes to Stencil... Ok, so maybe this isn't a good idea. What about creating a new version of Text_interface::interpret_markup that recurses through the markup looking for footnotes? Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Draws a line above footnotes (issue4167063)
On Wed, Feb 23, 2011 at 3:14 PM, Mike Solomon mike...@ufl.edu wrote: On Feb 22, 2011, at 7:17 PM, joenee...@gmail.com wrote: On 2011/02/22 15:23:00, MikeSol wrote: On 2011/02/22 01:05:49, joeneeman wrote: Have you checked the performance of this? This part is linear and so it makes break_into_pieces quadratic. Also, you can make it simpler by iterating through all-elements instead of recursing through elements. I've made the change to iterate through all-elements, but I still need to measure the performance of the algorithm. How would I do this? The change to all-elements was just for simplicity; I still think it will be quadratic. You can do a profiling build with ./configure --enable-conf=prof --enable-profiling --disable-optimising make conf=prof (and the binary will be out-prof/bin/lilypond). You can also just time lilypond on a largish score (ie. multiple minutes of processing time). You can find such scores on the mailing list if you don't have one; Hu Haipeng often sends them. Or you can try Valentin's opera, but that's more like multiple hours of processing time... You're right - it takes a long time :( Perhaps it'd be wise to make a footnote switch that allows users to opt-out of this slowness. Better just to make it faster :). What if you add a vectorGrob* to System with all the footnoted grobs? The first time get_footnotes_in_range is called, you do the search, populate the vector and sort it according to column rank. From then on, you respond to get_footnotes_in_range by doing a binary search for the upper and lower bounds. Alternatively, is there a grob that I can acknowledge during the translation process that will always exist and will be easily accessible from the systems? If so, I can just use the pointer group interface to create a grob array of footnoted grobs. If you'd rather use an engraver to collect the footnotes, you could just catch all the footnoted items in Score_engraver. You'll still need to sort the array and use binary searches, though. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pushing patches
On Sun, Feb 13, 2011 at 1:32 PM, Graham Percival gra...@percival-music.cawrote: Hey guys, could you push your patches that have passed review? 1211 Optimizations for pure-heigh approximations Done ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Valgrinding lilypond
Guile's garbage collection generates many valgrind warnings (although a quick google suggests that they've been improving the situation). I've attached a suppression file that eliminates many of the bogus warnings. Cheers, Joe On Mon, Jan 31, 2011 at 5:52 AM, Reinhold Kainhofer reinh...@kainhofer.comwrote: Due to the crash with the part-combiner (which I cannot reproduce, unfortunately), I'm currently taking a closer look at lilypond with valgrind. 1) Somehow the Rhythmic_head interface generates a Conditional jump or move depends on uninitialised value(s) warning (none of the other ADD_INTERFACE calls does, only Rhythmic_head): ==1979== Conditional jump or move depends on uninitialised value(s) ==1979==at 0x409F42C: scm_gc_mark (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40DA964: scm_i_symbol_mark (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x409F227: scm_gc_mark_dependencies (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x409F44B: scm_gc_mark (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x409F4F9: scm_mark_locations (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40F5511: scm_threads_mark_stacks (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x409F539: scm_mark_all (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x409E54B: scm_i_gc (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40A02AA: ??? (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40A079F: scm_gc_malloc (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40DAA0C: ??? (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40DAED4: scm_i_make_string (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40DB21D: scm_from_locale_stringn (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x40DB274: scm_from_locale_string (in /usr/lib/libguile.so.17.3.1) ==1979==by 0x8103144: add_interface(char const*, char const*, char const*) (grob-interface.cc:40) ==1979==by 0x81ECA21: Rhythmic_head_init_ifaces() (rhythmic-head.cc:62) ==1979==by 0x810E99F: ly_init_ly_module(void*) (guile-init.cc:45) This is from running only valgrind --trace-children=yes lilypond without any arguments or files to process, so that happends during initialization. The offending string in scm_from_locale_string is the description, i.e. Note head or rest. in rhythmic-head.cc. I fail to see any different to other interfaces, which do not trigger such a warning. Any idea what might be wrong here? 2) The example for the 2.13.47 crash posted to the bug list does not crash here, but running it through valgrind shows a lot of warnings like the following: ==1739== Use of uninitialised value of size 4 ==1739==at 0x81D084A: Prob::mark_smob(scm_unused_struct*) (prob.cc:127) ==1739==by 0x409F211: scm_gc_mark_dependencies (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409F44B: scm_gc_mark (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409F4F9: scm_mark_locations (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x40F5511: scm_threads_mark_stacks (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409F539: scm_mark_all (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409E54B: scm_i_gc (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x40A02AA: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x81554AB: Moment::smobbed_copy() const (moment.cc:58) ==1739==by 0x81640EF: ly_music_length(scm_unused_struct*) (music- scheme.cc:32) ==1739==by 0x4096748: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4095612: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4095811: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4094C5A: scm_dapply (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x40934A7: scm_apply (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4098A10: scm_call_1 (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4036713: scm_srfi1_map (in /usr/lib/libguile-srfi-srfi-1- v-3.so.3.0.2) ==1739==by 0x4096813: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4095612: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4095811: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4095612: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4095811: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4094C5A: scm_dapply (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x40934A7: scm_apply (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x4098A10: scm_call_1 (in /usr/lib/libguile.so.17.3.1) ==1739== Uninitialised value was created by a stack allocation ==1739==at 0x409E424: scm_i_gc (in /usr/lib/libguile.so.17.3.1) or ==1739== Use of uninitialised value of size 4 ==1739==at 0x4086735: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409F211: scm_gc_mark_dependencies (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409F44B: scm_gc_mark (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409F4F9: scm_mark_locations (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x40F5511: scm_threads_mark_stacks (in
Re: Valgrinding lilypond
On Mon, Jan 31, 2011 at 11:57 AM, Reinhold Kainhofer reinh...@kainhofer.com wrote: Am Montag, 31. Januar 2011, um 20:09:01 schrieb Joe Neeman: Guile's garbage collection generates many valgrind warnings (although a quick google suggests that they've been improving the situation). I've attached a suppression file that eliminates many of the bogus warnings. Yes, I know about the garbage collection creating many warnings (Thanks for that hand-crafted suppression file). That's why I only looked at stacktraces that also include lilypond functions. In particular, the warnings (spurious or not?) containing calls like: ==1739==by 0x409F539: scm_mark_all (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x409E54B: scm_i_gc (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x40A02AA: ??? (in /usr/lib/libguile.so.17.3.1) ==1739==by 0x81554AB: Moment::smobbed_copy() const (moment.cc:58) ==1739==by 0x81640EF: ly_music_length(scm_unused_struct*) (music- scheme.cc:32) appear ONLY with Jay Anderson's test case (thread Segfault 2.13.47 on bug- lilypond), but not with any other file I tried. So I thought that might give an indication about where the problem lies (like the part-combiner causing a mess in some scheme structures or so). That's still in guile's garbage collection. The fact that lilypond code appears in the stack trace just means that some lily code triggered the collection. It could be that only Jay's test case created garbage in the right pattern to trigger garbage collection just there. The only times I've successfully used valgrind to find a bug in lilypond has been with a lilypond function at the top of the stack trace. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Coding style
On Thu, Jan 13, 2011 at 7:19 PM, David Kastrup d...@gnu.org wrote:
Hi,
in note-collision.cc I read the following:
Direction d = UP;
do
{
vectorGrob* clashes (clash_groups[d]);
vector_sort (clashes, Note_column::shift_less);
}
while ((flip (d)) != UP);
Uh, is there any reason not to just write
vector_sort (clash_groups[UP], Note_column::shift_less);
vector_sort (clash_groups[DOWN], Note_column::shift_less);
I find it somewhat strange to make a loop for two simple function calls.
Sure, you can go ahead and change that. Maybe at some point there was more
code in the loop...
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1268 in lilypond: [PATCH] span-bar problem
On Sat, Jan 8, 2011 at 4:13 AM, Benkő Pál benko@gmail.com wrote: Good idea! I have to figure out the centering issues and how to convert SCM to Interval, but this is a nice way. robust_scm2interval ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1268 in lilypond: [PATCH] span-bar problem
On Sun, Jan 2, 2011 at 6:33 PM, Benkő Pál benko@gmail.com wrote: hi Joe, need to be careful about what happens when bar-size is set. Currently, your patch will break (for example) input/regression/drums.ly because it ignores bar-size. well, I think extent shouldn't be computed from size as it loses information, but the other way round. That's true, but we currently allow users to override bar-size (for example in percussion parts). With your current patch, if the user overrides bar-size, then Bar_line::calc_bar_size and Bar_line::calc_bar_extent will give conflicting results (I was wrong earlier when I said that this would affect the printed bar line, but I still think it's bad for the functions to conflict). AFAICS the intent of the span bar code is to draw lines not between staves but from line to line, and my patch reverts this. of course there's no difference in general, but there is if bar lines are to have different extent than that of their staff; and there is a further difference whether the bar is shorter or longer than the staff: if longer, there may be no point in using span bars at all; if shorter, then perhaps span bars are better placed just between staves (see spantest5.ly). I don't think the current intention is documented anywhere. If you want to fix a policy now, that's ok with me. I still don't know exactly how should spantest3 behave (spantest5 makes me feel it works acceptably), neither what should happen if different bar types are connected (see spantest4.ly - I hope this is farthest from a real world case of all my tests). I removed the center setting code and that (with my patch still active) made my example perfect; however, the attached complementary test (with bar lines only within staff, not between them) failed, but it's perfect with current center setting (independently whether my original patch is active or not). Since Bar_line::compound_barline is used in both BarLine and SpanBar, you will need to find some solution that works for both cases. It won't be as simple as just enabling or disabling the centering code. I moved the centering code from compound_barline to print, and this way all regtests are OK and all my spantests are good or at least acceptable. Thanks, this patch looks good. Just a couple of things I'd like to see: - a comment explaining the positioning of span-bars (ie. between bar-lines or between staves?) - agreement between bar-size and bar-extent. There are two solutions I can see, but feel free to invent your own: - deprecate the bar-size property and use bar-extent from now on. This will require a convert-ly rule. - unset bar-size by default (in scm/define-grob-properties.scm). In calc_bar_extent, check to see if bar-size is set. If it is, use it. Otherwise, use the staff extent Here are a couple other suggestions that I think would improve the code. I'd be happy to commit your patch without them because they reflect problems with the existing code rather than problems with your patch. But if you have time, it would be nice :) - Shouldn't Bar_line::print use bar-extent rather than bar-size? That seems more natural. - The centering issue regarding compound_barline still seems strange. Wouldn't it be nicer if compound_barline took Real bottom and Real top (or maybe Interval) parameters (instead of Real h) and drew a bar line whose Y-extent stretched from bottom to top? That seems like a more intuitive API to me (and unlike the current one, it's self-documenting). Thanks for your work, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: what's up with optimal-page-breaking-hstretch.ly
The current output looks ok to me. You can recover the 2.12 output by increasing the page-spacing-weight parameter, but I think the current output still captures the point of the test. Horizontally stretched means that the ideal horizontal spacing would be to use 1 system per page, but lilypond will use two on the first page because it strikes a better balance between vertical and horizontal spacing. The remark about the raggedness of the second page is important because ragged spacing affects the page breaking as well as the final page layout. Were the last page not ragged, lilypond would try to place more systems on it so that the page would be better filled (you can check that I'm not lying by changing ragged-last-bottom to ##t.) Cheers, Joe On Tue, Jan 4, 2011 at 6:00 AM, James Bailey derhindem...@googlemail.comwrote: Compiling this with 2.12.3 and 2.13.45 yields (to my eye) rather different results. I personally cannot tell if the systems are horizontally stretched or not. They appear to be centered. Or should this illustrate that only the systems on the first page are vertically stretched? Regardless, in 2.13, only one system is on the second page, so I don't think any ragged settings will be obviously apparent. Am I completely off here? Can someone explain what I* should* be seeing, and then we can work out if it is displaying correctly. Thanks, James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 1464 (was: a plea to new contributors)
On Sun, Jan 2, 2011 at 2:14 AM, Matthias Kilian k...@outback.escape.dewrote:
On Sat, Jan 01, 2011 at 02:10:04PM +0100, Matthias Kilian wrote:
I don't know why gdb doesn't find paper-column.hh, but anyaway...
it looks like Item::get_column() returns NULL, because its parent's
get_column() returns NULL (I checked that the parent on the X_AXIS
itself is not NULL).
Bisected to this one (cc'd Neil):
commit 6d28aebbaaab1be9961a00bf15a1ef93acb91e30
Author: Neil Puttock n.putt...@gmail.com
Date: Mon Sep 6 22:49:28 2010 +0100
Fix metronome alignment.
Don't align on KeySignature unless explicitly requested via
'break-align-symbols and make order of 'break-align-symbols
significant.
* remove `key-signature' from 'break-align-symbols
* acknowledge break_alignment, and set this as X-parent
instead of break_aligned, but only if found break_aligned
is visible
* add regression test to test ordering
* tweak existing test to reflect change in default for
'break-align-symbols
[...]
I tried the diff below, which `fixed' the segfault, but it may be
completely wrong (I'm currently not familiar with the LilyPond code
at all). Unfortunately, I don't have a new enough ImageMagick on my
system, so I can't run the regression tests.
diff --git a/lily/metronome-engraver.cc b/lily/metronome-engraver.cc
index 0a41fc9..e34c0ad 100644
--- a/lily/metronome-engraver.cc
+++ b/lily/metronome-engraver.cc
@@ -95,7 +95,10 @@ Metronome_mark_engraver::acknowledge_break_aligned
(Grob_info info)
safe_is_member (g-get_property (break-align-symbol),
text_-get_property (break-align-symbols))
Item::break_visible (g))
-support_ = g;
+{
+ support_ = g;
+ text_-set_parent (g, X_AXIS);
+}
}
In your original backtrace, is the X_AXIS parent of the Item in frame #2
0x0? If so, I'm fine with the patch.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: systems-per-page and page-count do not work together
On Fri, Dec 31, 2010 at 2:38 AM, Reinhold Kainhofer reinh...@kainhofer.comwrote: Am Donnerstag, 30. Dezember 2010, um 20:35:57 schrieb Reinhold Kainhofer: It seems that if you specify both systems-per-page and page-count, then lilypond will disregard page-count. Instead of stretching the notes, it will simply use less pages than desired and cram the notes together. Yes, optimal-page-breaking.cc had: /* TODO: the interaction between systems_per_page and page_count needs to be considered. */ This is now fixed in git. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Simplification of live-elements-list, why not?
On Sun, Nov 14, 2010 at 5:19 PM, Boris Shingarov b...@shingarov.com wrote: In scm/output-lib.scm, the (internally used) function live-elements-listis defined like this: (define (live-elements-list me) (let* ((elements (ly:grob-object me 'elements)) (elts-length (ly:grob-array-length elements)) (live-elements '())) (let get-live ((len elts-length)) (if ( len 0) (let ((elt (ly:grob-array-ref elements (1- len (if (grob::is-live? elt) (set! live-elements (cons elt live-elements))) (get-live (1- len) live-elements)) Any specific reason why not just filter on the is-live? predicate? Doesn't filter just work on plain scheme lists? elements is a grob-array object. Of course, if filter doesn't work on such objects it might be better to write a version of filter rather than replicating it many times. Also, is there a real difference between grob::is-live? and ly:is-live?predicates? (I would be inclined to get rid of grob::is-live? version...) I couldn't find ly:is-live? ... Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: applied default spacing rules provided by Keith O Hara
On Fri, Nov 12, 2010 at 7:04 AM, Reinhold Kainhofer reinh...@kainhofer.comwrote: What I don't really understand why the stretchability of the StaffGrouper in staves/scores contexts seems to have a completely different unit than the stretchability defined in the \paper block. I would have expected that if I set e.g. the stretchability between the staves of a StaffGroup to the same value as the stretchability in system-system-spacing, then all staves on the page would be equally spaced, whether they belong to the same or to different systems... It seems that I have to use a value ~10 times as large for the system-system-spacing stretchability... If you set 'space and 'stretchability to the same value, then this should be true. Since your system-system-spacing 'space is smaller than your between-staff-spacing 'space, some of the stretchability value will go towards compensating for that difference. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: follow-up to report 22
On Fri, Nov 5, 2010 at 4:28 PM, Valentin Villenave valen...@villenave.netwrote: On Fri, Nov 5, 2010 at 10:29 PM, David Kastrup d...@gnu.org wrote: David seemingly is quite incapable of bringing his meaning across, so instead of substituting your own, just quote him. Indeed. As you may have guessed, I added your name to that sentence as an afterthought, only to make it clear that I did agree with what you said earlier. In this regard, I could have quoted your former emails in their entirety :-) I am very grateful to Carl for having posted and pushed his patch, and I'm all for conflict resolution. However, I also have to mention that to me, this issue is not solved by any means. I made clear what my intentions were in the first place, and I apologized to whomever might have felt offended by some of the words I used; however none of the suggestions I made were as much as acknowledged by any member or administrator of the -hackers mailing list. Is it to say that I should now follow Graham's advise: Ask questions. If you get no reply, then ask again. If you still get no reply, ask if you can quote somebody as refusing to answer? What has changed thanks to Carl, is that -hackers is now accounted for in the LilyPond documentation. It certainly is appropriate as a first step, and I can understand that discussing anything further may be seen as a non-issue, or at least an issue that isn't nearly as important as getting 2.14 out of the door. So, now is as good a time as any to give up. While I probably haven't chosen the Right Way™ to ask (although I didn't, and still don't, see any other options), what I was really asking for was some reassuring signs from the development team (meaning: the -hackers members). I received none. What sort of signs would you find reassuring? I'm a member of -hackers. I've probably sent two emails to the list in the four or so years that I've been a member. Nevertheless, I think it's useful to have around. For one thing, the traffic is so low that I actually *read* the emails on it, whereas I often miss emails to -devel unless someone CCs me. I don't have any particularly strong opinions about what the list policies should be, but I am in favor of keeping it. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: follow-up to report 22
On Fri, Nov 5, 2010 at 6:48 PM, Valentin Villenave valen...@villenave.netwrote: On Sat, Nov 6, 2010 at 1:18 AM, Joe Neeman joenee...@gmail.com wrote: What sort of signs would you find reassuring? Greetings Joe, Well, your answer is one, for starters :) What I meant by reassuring signs is pretty much any reactions from the development team acknowledging that there might be an issue (or something that might be perceived as such) with the way things have been going so far. More specifically, I was referring to the few questions I raised and suggestions I made earlier. I'm a member of -hackers. I've probably sent two emails to the list in the four or so years that I've been a member. Nevertheless, I think it's useful to have around. For one thing, the traffic is so low that I actually *read* the emails on it, whereas I often miss emails to -devel unless someone CCs me. Good point. That would apply to any other low-traffic mailing-list, though (and doesn't explain why the archives, no matter how old, need to be private). If the archives were public, it might deter people from speaking frankly. Obviously, everyone knows by now that we've had a thread discussing David; had there been public archives (or a plan to make them public in the future), that conversation would have probably gone off-list. Which defeats the purpose of having such a list in the first place. I don't have any particularly strong opinions about what the list policies should be, but I am in favor of keeping it. Again, I do not strongly object against keeping it either. So, a temporary list of -hackers members would include Han-Wen, Jan, Graham, (possibly Mats?), John, Reinhold, yourself... and counting (this is me playing journalist, as Graham would say). I doubt anyone objects to having a public list of the -hackers members. If we do create such a list, it's probably more efficient just to get a list from the list administrator rather than sleuthing around. Correct me if I'm wrong, but I am under the impression that this list is but a thing from the past. It would explain why old-time senior developers, as Graham calls them, are still members, but not new developers who have _only_ been around for less than, what? three years? That sounds about right. Still, there's some kind of a paradox: what you guys are telling us is basically nobody really uses this mailing list... but let's keep it anyway. (Which is exactly what I was already told several years ago.) Anyway, if you find it useful, then by all means do keep it. But it would be a pity to keep it just in case, regardless of what it, for all intents and purposes, may make the LilyPond project look like from where regular contributors are standing. (Again, I'm speaking for myself and aren't assuming that my point of view is shared by anyone else.) Do you really think that having a private mailing list damages the project? That is, assuming that we are open about its existence/purpose/whatever? Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.14 release, or GOP now?
On Sat, Oct 23, 2010 at 8:22 PM, Graham Percival gra...@percival-music.cawrote: We're about 10-20 hours of work away from having 0 Critical issues. On one hand, that sounds great; we're almost there! On the other hand, we've been in this state for the past month. I'm not seeing a lot of excitement and work towards 2.14. Ok, I get the hint. The most worrying part of 1240 (ie. comment #5) is fixed in git and I can finish closing it this evening. I can tweak the defaults so that 1285 looks nicer, but I'm not sure that it's really critical any more (basically, the height-estimation routines in 2.13 are more accurate and so the spacing routine is capable of doing tighter spacing than it was in 2.12). No ETA for 1252 yet, but I'll work on it... Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: default-next-staff-spacing question
Suppose you have an orchestral score with several staff groups and you set next-staff-spacing for the flute part. If there is a part where only the flute and strings play, then your next-staff-spacing will apply for the spacing between the flute part and the violin part. If you had set default-next-staff-spacing instead, then StaffGrouper 'after-last-staff-spacing would have applied instead (which is probably what you want). Cheers, Joe On Mon, Oct 11, 2010 at 12:02 AM, Mark Polesky markpole...@yahoo.comwrote: When would I ever need to set default-next-staff-spacing? I can't think of a case where this property (as described in the docs) is ever needed, since I can always just set next-staff-spacing. Can someone explain? Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
On Wed, Oct 6, 2010 at 1:26 AM, Mark Polesky markpole...@yahoo.com wrote: Well, so many extensive replies to respond to! It's great, but it makes for a long post, and I do hope the thread participants read to the end; there's a lot of relevant stuff for everyone here. Thanks. * * * * * * * * * * Joe Neeman wrote: I would argue that the baseline is more natural then the bottom. Moreover, using the baseline as a reference point will result in more even spacing of multiple consecutive lines of markup. Okay, that's a good point, so I agree -- baseline is better than bottom. But do you agree with Carl and Trevor that we should always use the same reference point for markups? I was specifically proposing to use the bottom of the upper markup and the top of the lower markup for between-title-spacing, but Carl argued eloquently against it. Carl's argument is probably much more solid than mine, but just for the record, what do you think? I don't care so much about one versus two reference points (although the current code only works with one), but I do think that the reference points should not depend on any ascenders or descenders. I've noticed that in many traditionally-engraved scores, the distance from the bookTitleMarkup baseline to the first system seems to be *independent* of the distance from the scoreTitleMarkup baseline to the first system. For example, say score1 has title/subtitle/etc. in the usual place (top center), and piece/opus also in the usual place (flush left and flush right just above the top system), and the top system has no protruding skyline. Now score2 has all the same titling but the top system has a really high note just before the rightmost barline. To prevent a collision between the last note and the opus, LilyPond will shift the first system down. Fine. But what I've noticed in the classic scores is that in this situation, the top system is not shifted down, but rather the opus is shifted *up*. This is an important difference! It means that the placement of the top system is determined by the bookTitleMarkup, and the scoreTitleMarkup is determined by the top system. And it usually looks better this way (and more consistent from score to score). I guess I wouldn't be surprised if Joe says that this would be more trouble than it's worth*, since it seems to go against the whole pattern of the current spacing algorithm, but I think it would be a big step towards fully professional-quality scores. *and if he says it would be easy, well that would just make my day... I won't say it's more trouble than it's worth, but I don't think it's trivial. In lilypond-spacing-backend terms, I think you want to treat the opus markup as a loose line. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: attachment points for vertical spacing dimensions
On Tue, Oct 5, 2010 at 11:09 AM, Mark Polesky markpole...@yahoo.com wrote: WRT the flexible vertical spacing dimensions, the upper attachment points for 'space and 'minimum-distance currently align with the Y-coordinate of the origin (0,0) of the upper item. For systems this is the middle line of the nearest staff, and for markups this is the highest point of the markup. In the newest docs (NR 4.1.2 as of yesterday), these are called reference points. I think that most of the resulting dimensions are what the user would naturally expect them to be, except when the upper item is a title/markup. In these cases, I think the most natural attachment point would be the *bottom* of the upper markup. I would argue that the baseline is more natural then the bottom. Moreover, using the baseline as a reference point will result in more even spacing of multiple consecutive lines of markup. This applies to 3 of the 8 flexible vertical dimensions: * after-title-spacing * between-title-spacing * bottom-system-spacing The proposed change to after-title-spacing needs no comment. For between-title-spacing however, I should mention that if the upper attachment point (of 'space and 'minimum-distance) is moved to the bottom of the upper markup, then the 'padding value is basically rendered redundant. This is not actually true (even if we change the refpoint to the bottom) because minimum-distance measures the distance from the refpoint of the markup to the *refpoint* of the next system, while padding measures the distance to the *top* of the next system. In that case, 'padding would only influence the spacing if it were larger than 'minimum-distance, and making 'padding larger than 'minimum-distance is generally pointless since that in turn would render 'minimum-distance redundant. That being said, I don't think this is a problem; the spacing behavior would still be more natural IMO. And a simple explanation for this unique case could be added to the docs. Of the three, bottom-system-spacing is slightly more complicated, since it currently controls the spacing below systems *and* markups, when either is the last on a page. So the natural attachment point for systems would remain the same, but would be shifted to the lowest Y-coordinate for markups (ideally). Personally, I think we should add a new variable to control the spacing between a markup and the bottom margin. We could call it bottom-markup-spacing for now, but see this post for my proposed variable renaming: This is easy enough to add (and the naming seems fine to me). Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)
On Sun, Oct 3, 2010 at 11:26 AM, Carl Sorensen c_soren...@byu.edu wrote: On 10/2/10 10:50 PM, Joe Neeman joenee...@gmail.com wrote: On Sat, Oct 2, 2010 at 8:08 PM, carl.d.soren...@gmail.com wrote: On 2010/10/03 02:49:30, Mark Polesky wrote: On 2010/10/02 16:32:06, Carl wrote: I don't think so. I think 'padding is added as a rigid space interval, hence my saying that it is added to the layout item above. 'space should begin below 'padding IIUC. The attachment point of 'space doesn't depend on 'padding (or 'minimum-distance). If you think in terms of springs, the beginning of one spring is always glued to the end of the previous one. 'padding and 'minimum-distance are only useful in determining the minimum lengths of the springs. What is the difference between 'padding and 'minimum-distance, then? They both add minimum-length constraints to the spring. The length of a spring is constrained to be larger than minimum-distance and it is constrained to be large enough so that there is at least 'padding white space between the actual stencils. If you like, you can think of minimum-distance as being attached to the same attachment point as the spring (eg. middle staff line), while padding is attached to the bottom-most part of the stencil. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)
On Sun, Oct 3, 2010 at 10:59 AM, markpole...@gmail.com wrote: I've uploaded a new patch set for review, but I still have some questions. First, some questions for Joe Neeman: Joe, with commit 7d410b9 (from 2009-12-17), in NR 4.4.1 Vertical spacing inside a system - Spacing between staves, you wrote: If unset, stretchability defaults to space - minimum-distance. This isn't quite accurate: actually, our ideal springs have two different spring constants, one for compressing and one for stretching. The default stretchability is (space - minimum-distance) for compressing and space for stretching (the stretching one is probably more important in practice). But 4 months later, with commit d701703 (2010-04-20), in lily/spacing-basic.cc, you wrote: By default, the spring will have an inverse_stretch_strength of space+min_dist. Is this a contradiction? Could you confirm the default calculation of 'stretchability? (Unfortunately, I don't speak C/C++). This is for horizontal spacing, not vertical spacing. Also, the comment means to say: if not for the next line of code, the default _would be_ space+min_dist, Also, I rewrote the 'stretchability entry; can you double-check that there's nothing erroneous/misleading? Should I remove the +inf.0 bit? +inf.0 will cause a programming_error (and it will be ignored). Internally, we use 1e7 for an almost infinitely stretchable spring. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)
On Sun, Oct 3, 2010 at 4:36 PM, markpole...@gmail.com wrote: Latest patch set up. Okay to push? - Mark http://codereview.appspot.com/2316042/ It's ok with me. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's with the spacing code?
On Sat, Oct 2, 2010 at 5:56 AM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org writes:
With the current code, a score that used to take 5 pages now takes 8,
really really spaced out.
I don't see that we can release a version of Lilypond that takes up
horrifically more space than the previous not-skyline-based code.
Making use of the skyline instead of the bounding box should never lead
to results taking _more_ space.
The recent checkin makes for somewhat better results. Obviously, the
assumption of non-overlap now leads to a reverse problem:
\repeat unfold 480 { c'^\markup { longword anotherone } }
This contrived example shows two more issues: issue 1 is that we are
estimating too short right now.
Ok, but the heights here are impossible to estimate accurately because we
don't know how much overlap there will be unless we do the horizontal
spacing. One possible improvement would be to assume overlap only if the
markups are in the same Paper column.
Issue 2 is more disconcerting: even if things worked like intended, the
visual relationship between Note and markup gets lost.
Issue 1 could be addressed by improving the coarse pre-pagebreak
estimate: make sure that the total _area_ of markups fits on the page.
With the sort of juggling achieved by markup positioning, that could
actually be not all too far from the truth.
The problem is that this sort of optimally dense packaging is
detrimental to making the score understandable. There is a point in
time where instead of juggling with the markup stacking, one needs to
bite the bullet and push the notes somewhat more apart.
Sure, but writing down a good algorithm for deciding when to do this doesn't
seem easy. At some point, I think it's reasonable to ask the user for a
little manual help (eg. extra-spacing-width).
The latter is likely not material for a release soon, as the mode of
operation is pretty much working as intended. But improving the
bounds of height estimate would seem desirable.
Sure, but the bigger priority is to get the existing estimates working with
RehearsalMarks.
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: NR 4.1.2: Reorganize vertical dimensions. (issue2316042)
On Sat, Oct 2, 2010 at 8:08 PM, carl.d.soren...@gmail.com wrote: On 2010/10/03 02:49:30, Mark Polesky wrote: On 2010/10/02 16:32:06, Carl wrote: When laying out a page, LilyPond makes a stack of the layout items (staves, lyrics lines, chordnames, etc.) on the page, with a variable spacing item between each pair of layout items. When calculating the desired location of each layout item, the code treats the page as if the layout items were rigid blocks and the spacing items were springs, and the whole assembly of blocks and springs is made to fit in the space of the page. In order to make it fit, the springs will be stretched or compressed. The spacing variables affect the size and strength of the springs, as well as the size of the rigid blocks. 'padding is added to the rigid block above. 'space determines the size of the spring -- it's the space that would be used if no squeezing or stretching would be required to fit the systems together. 'stretchability determines the strengths of the springs. Higher values of 'stretchability make the spring weaker; lower values of stretchability make the spring stronger. 'minimum-space is the shortest-possible length of the spring. When the space between the two layout items reaches 'minimum-space, the two layout items can be placed no closer together. I like this a lot. But I think it's misleading to say that 'padding is added to the rigid block above, because this implies that 'space is measured from the bottom of the 'padding block, whereas 'space should be measured (IIUC) from what I called the reference point of the upper item, and when the upper item is a title or markup, that reference point is the lowest point of the title/markup. So at least in that case, the upper Y-coordinates of 'padding and 'space would be the same. Is that right? I don't think so. I think 'padding is added as a rigid space interval, hence my saying that it is added to the layout item above. 'space should begin below 'padding IIUC. The attachment point of 'space doesn't depend on 'padding (or 'minimum-distance). If you think in terms of springs, the beginning of one spring is always glued to the end of the previous one. 'padding and 'minimum-distance are only useful in determining the minimum lengths of the springs. These 2 paragraphs still leave 'stretchability somewhat abstract, but this other line from Carl so far is the most promising explanation: penalty = [(proposed actual space) - (space)]/stretchability Trevor pointed out that the absolute value of 'stretchability doesn't matter. It's just that if one space has twice the 'stretchability of another, it will be twice as far from the 'space value. So it's ratios of 'stretchability of the different spaces that makes a difference. However, I think it is possible (although I haven't checked) that lower values of stretchability will allow less stretching to try to fit a page, because they should raise the penalty value for an equivalent amount of stretching. Trevor is correct here. The page-breaking routines use a simple and fast heuristic for figuring out where to break pages. All of these spacing variables are only used for the page-layout (after the page-breaking has decided where the breaks go). I think we're a lot closer to a suitable explanation. We still need to go through and agree what the most natural reference points are, and then make sure the code agrees with that. Maybe. It may be that the most natural reference points aren't easily available. The springs are always attached to the (0, 0) coordinate relative to each staff or markup. That is, each staff or markup draws itself and returns some stencil. The spacing code just attaches to the (0, 0) coordinate of that stencil. For staves, it's the middle staff line (unless you fiddle with line-positions). For markups, it used to be the baseline (I think). As long as the various drawing routines can be altered so that the stencil is drawn relative to its most natural reference point, then the spacing code will handle it. I think we should document what we have, and make enhancement requests for what we would *like* to have. I don't think the exercise of write the documents for what we wish we had and then change the code to match is the best way to proceed. But if Joe's ok with it, then my opinion is irrelevant. I don't have a strong opinion on this point. If you want to document the desired behaviour and add a critical issue, I'll probably be able to fix it in a reasonable time frame. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
