Re: Fixing issue 786 (lyric extenders) again
> Yes, I am top-posting I notice that issue 786 was just marked as critical. I sent the following message to -devel four weeks ago but never received a response. I'd appreciate advice on how to write messages that are more responder-friendly. Chris Snyder wrote: Issue 786, which was caused by a patch I submitted back in March, was recently re-opened with another case of an extender being completized too early. Looking at the example, it's easy to spot what's going on. The fix, however, looks to me to be less straightforward. Some background: The original patch fixed an issue where an extender would go too long (sometimes to the end of the score) when the lyrics ended before the associated voice. This was because extenders were only completized when the next event in the Lyrics context came along, which would never occur if the Lyrics block ended with an extender. My original patch added a check to see if the voice was in a melisma and to completize the extender if not. One problem this caused (original issue 786) was with manual melismata, which the melisma_busy(voice) function doesn't know about (and can't - it doesn't know about Lyrics contexts at all, nor should/could it, since multiple Lyrics contexts can be associated with one voice). This was fixed by changing the Lyric_engraver to add empty LyricText objects. The Extender_engraver checks both melisma_busy and for the presence of an empty LyricText object, and only completizes the extender if neither is true (as well as another check to fix issue 800). The case that caused issue 786 to be reopened, however, poses yet another problem. It is more general than just happening with beamed notes - I've verified the same behavior with slurs and ties as well. It happens whenever an automatic melisma (beam, slur, tie) is followed by a manual one (underscore in Lyrics). Looking at the checks I added, it's obvious what's happening: On the last note of the automatic melisma, melisma_busy returns false, but the empty LyricsText object won't occur until the next moment, so the Extender_engraver thinks it should completize the extender. Under the scheme as it exists now, the Extender_engraver would have to somehow check for an empty LyricText object occurring in the future. This doesn't seem to me to be the correct approach. Alternatively, I've thought of another solution that seems to be more elegant than this growing list of checks for various cases: what if the parser created an empty LyricText object at the end of each Lyrics block? That would solve the original issue I fixed back in March in a way that would allow us to revert that part of the Extender_engraver to the way it was before my original patch. Before I try to learn how the parser works, does this seem like an acceptable approach? Thanks, -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixing issue 786 (lyric extenders) again
Issue 786, which was caused by a patch I submitted back in March, was recently re-opened with another case of an extender being completized too early. Looking at the example, it's easy to spot what's going on. The fix, however, looks to me to be less straightforward. Some background: The original patch fixed an issue where an extender would go too long (sometimes to the end of the score) when the lyrics ended before the associated voice. This was because extenders were only completized when the next event in the Lyrics context came along, which would never occur if the Lyrics block ended with an extender. My original patch added a check to see if the voice was in a melisma and to completize the extender if not. One problem this caused (original issue 786) was with manual melismata, which the melisma_busy(voice) function doesn't know about (and can't - it doesn't know about Lyrics contexts at all, nor should/could it, since multiple Lyrics contexts can be associated with one voice). This was fixed by changing the Lyric_engraver to add empty LyricText objects. The Extender_engraver checks both melisma_busy and for the presence of an empty LyricText object, and only completizes the extender if neither is true (as well as another check to fix issue 800). The case that caused issue 786 to be reopened, however, poses yet another problem. It is more general than just happening with beamed notes - I've verified the same behavior with slurs and ties as well. It happens whenever an automatic melisma (beam, slur, tie) is followed by a manual one (underscore in Lyrics). Looking at the checks I added, it's obvious what's happening: On the last note of the automatic melisma, melisma_busy returns false, but the empty LyricsText object won't occur until the next moment, so the Extender_engraver thinks it should completize the extender. Under the scheme as it exists now, the Extender_engraver would have to somehow check for an empty LyricText object occurring in the future. This doesn't seem to me to be the correct approach. Alternatively, I've thought of another solution that seems to be more elegant than this growing list of checks for various cases: what if the parser created an empty LyricText object at the end of each Lyrics block? That would solve the original issue I fixed back in March in a way that would allow us to revert that part of the Extender_engraver to the way it was before my original patch. Before I try to learn how the parser works, does this seem like an acceptable approach? Thanks, -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
CG improvements-collector position (was: [frogs] Frog's Lament)
Graham Percival wrote:
Despite my agreements to both paragraphs above, I agree more with
the first than the second. Namely, I don't see the point of
keeping a list of stuff to add to the docs; that's a recipe for
not getting anything done.
I think that can depend on a particular person's work habits. I won't
dispute that making lists often serves as a substitute for actual work;
other times, however list-making can serve as a catalyst. I know that I
work much better when I have a list of tasks, divided into
manageable-sized portions, that I can tick off as I get work done. Many
"life hacking" self-help gurus also suggest such strategies (such as
zenhabits.net's "Most Important Tasks" for each day).
Add stuff directly to the CG. If you really can't figure out what
somebody talking about, just add something like
-
Han-Wen wrote something about contexts and accessing property
data? @uref{http://lilypond-user-mailist/01234123.html}
-
to the docs. But get it into the actual docs, not yet another
random webpage or issue list.
The problem I see here is that there will be many times when the content
of the documentation improvement isn't the only issue - rather, there is
a question as to what part of the CG is the appropriate place (maybe the
appropriate section isn't even written or outlined yet) - or at times
the CG isn't the appropriate place at all (perhaps code comments in some
cases, etc.).
The process of deciding on the appropriate place for the content, and
then writing it, takes time - not a lot for each incident, but enough
that each issue can't be addressed immediately. Therefore, the issues
would start piling up in whatever personal tracking method I use (in the
absence of a public issue tracker, I'd probably just create a "CG TODO"
IMAP folder). Why not make such a list public to give others the
opportunity to contribute?
Here's the crux of my argument: I'm offering my time in a way that I
think will be beneficial to LP. In the worst outcome - my fading away
after contributing nothing other than another list of TODO's (not going
to happen, but I understand that you don't know me well enough to
believe me) - nothing will have been lost, and no Jan- or Han-Wen-hours
- LP's most valuable assets - will have been wasted.
-Chris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Frog's Lament
Valentin Villenave wrote: May I suggest using the existing tracker on bugs.lilynet.net? That would be excellent. Thanks. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [frogs] Frog's Lament
Graham Percival wrote: On Thu, Nov 26, 2009 at 11:12:26PM +0100, David Kastrup wrote: We are not talking about explaining concepts to potential contributors in private. We are talking about explanations happening on the developer list. Those can be skimmed off into documentation, without requiring all too much advance knowledge, because they were written for the sake of people without all too much knowledge. I agree COMPLETELY. Are you volunteering? Perhaps it would be worth of another task master just to tick any such article with the potential "more useful than existing docs" into a list, I agree COMPLETELY. Are you volunteering? It seems to me that such a list would best be maintained in a bug-tracker of some sort (though IMHO not the official issue tracker due to the noise it would generate). Since I'm obviously not up to the task of attempting to fix code indentation, I'd like to volunteer for the task-master job, starting by setting up an issues tracker. My initial thought is that it would be prudent to set up another Google Code project where this tracker could be housed. If the PTB would instead prefer a different solution, let me know. I'll wait for official guidance before proceeding. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code formatter
Graham Percival wrote: Whatever. You're giving up. All this time I've spent trying to help you on this was wasted. I'm sure that more experienced developers list are either laughing at me, or shaking their heads sadly... "oh that Graham, he's trying to help the beginners, but he still doesn't understand that it's just not worth it" I'm not giving up. I would be happy to find and configure the proper tooling - automating it, even - if given a consistent, consensus-driven style standard - which doesn't currently exist. I'd be happy to start posting messages to the mailing list with subjects like "Allow tabs in source code?" and "Bracket alignment," but I don't think many people would appreciate the noise. Also, it seems to me that, on some issues at least, the discussion has already occurred and is deadlocked. You're approaching this as if it's a technical issue. As of now, it's not. I don't have the standing in the community to resolve the social issues that must be dealt with first. As an aside, there is a Windows binary available for download from the astyle website. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code formatter
Graham Percival wrote: I know that you're thinking "this is ridiculous", but unless somebody does it, newbies will continue to face this difficulty. This job won't get done by itself. Yes, I do think it's ridiculous. As I understand, you're saying, "go find a tool that makes the code conform to a standard we haven't defined yet." I've found such a tool. I'm sure it's already installed on all of the developers' machines. For more information, run "man cat". Windows users can probably use "type" instead. Why should I (or anyone else) spend so much time wrangling with a formatting tool to get it to comply with what I think the standard is (or should be), only to be told, "Sorry, that standard isn't acceptable"? Shouldn't the standard be set first? If so, I contend that, as Bertalan says, "Someone, a lead architect should decide upon rules." I feel I'm already being pretentious - imagine me trying to tell Han-Wen and Jan how to format their whitespace. Again agreeing with Bertalan, I think we need some fascism here. I don't see how this will ever be accomplished via a "grassroots" effort. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code formatter
Graham Percival wrote: 1) running astyle will change lines of code. This makes the history harder to look at... if we want to know who wrote a particular line (say, "there seems to be a bug here; hey Joe, why did you write "if (x = 3)" ?"), then it will appear that *you* were the last person to change that line of code. Even if all you did was run astyle on it. That seems to me to be unavoidable - or at least not worth the cost (investigating whitespace-aware diff tools, etc.) of avoiding it. Since the commit message would be "Automated formatting cleanup" we would just go to the previous commit in the tree (looking back on the Frogs list discussion, I see that you suggested exactly that). 2) many programmers view code style in a highly personal, quasi-religious manner. ... ...Han-Wen and Jan have different views... If the standard isn't even completely defined then how could the job of code janitor be given to an inexperienced Frog? It seems to me that no one can solve this problem until an official LilyPond coding standard is fully set in stone. In the meantime, newbies are left wondering what code style they should adhere to (perhaps having to predict which dev will be looking at a particular patch). Any automatic tool will probably result in everybody having to give up at least one closely-held belief (whether it's the supremacy of tabs, or lining arguments up after an opening brace, or how a switch/case command looks, or whatever). So when you propose a tool, we need to know what it will change. And for all those changes, we need to be convinced that it's an ok change. I'm going to "come out of the closet" here, in a manner - I'm primarily a Java programmer. I don't think I can count on both hands the number of personal formatting preferences (not to mention an intense dislike of C++ - but I'm not about to touch *that* dead horse) I've suspended in order to contribute. I'm not complaining about this - as a newcomer, it's my duty to adhere to established standards - but I'd like to know what the standards are. Sometimes, the automatic tool will just make existing badly-formatted code meet our own standards. In other cases, it *will* change the standards. Some of us won't care; others will care deeply. I know I'm not in a position to credibly admonish those that have put countless hours into what's essentially a labor of love, but it seems to me that these personal holy wars often get in the way of real productivity (the amount of time you've expended responding to me, for instance). It looks to me that 99% of the coding style is agreed upon - is the 1% really worth all of this frustration? How about a compromise for tabs vs. spaces: even lines use spaces, odd lines use tabs. I'm sure we could create an emacs rule for that. (since you don't know me very well, let me assure you that the former paragraph was written with tongue firmly implanted in cheek) Thanks, and sorry for taking up everyone's time. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Code formatter
Graham Percival wrote: I'm afraid that you won't get many positive responses until you look at the previous discussion about this issue. Again, the main developers have been bitten by people in the past asking many questions, spending hours explaining things to them, but then ultimately giving up and disappearing. Before I started looking at formatters, I did search lilypond-devel and the issues tracker, but didn't come up with them (other than an issue for automatically formatting .ly files). It looks like I didn't do an extensive enough search or use the correct terms. The issue that Neil linked to brought me up to speed (I wasn't even aware that the frogs had their own mailing list). I don't want to be discouraging, but most people won't take you seriously unless you prove that you've done your research. I'm sorry, I know this *does* sound discouraging... but we have had *years* of experience with people not following through. You know the expression "once bitten, twice shy?" for us, it's "ten times bitten, twenty times shy". Understood, and I realize that I haven't exactly proven myself in this community yet. I'm also comfortable enough here now that I'm not taking your response personally. I'm sorry to be discouraging -- again, I think this would be a *fantastic* project, especially if it handles scheme as well -- but it will be a *lot* more work than you're envisioning at the moment. There is one thing that bugs me about this discussion (and others) - it seems like sometimes improvements are rejected as being "not good enough," even if they're still an incremental improvement. Wouldn't running all of the C++ code through astyle still be an improvement over the current situation? It wouldn't prevent future formatting mistakes and it wouldn't help with the Scheme and ly code, but it would still be a step in the right direction. Thanks, -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Code formatter
After the on-going discussion that included talk about formatting, I did a quick search for automatic code formatters, starting with one for the C++ code (I think it's reasonable to expect to use a different formatter for each programming language). I came across one - astyle http://astyle.sourceforge.net - that has the GNU style built in and is painless to use. I gave it a try, and it seems to work quite well. I'd be willing to run all of the C++ code through astyle and provide a patch, but it seems like it would be easier if someone with push access to git would do it. Any takers? -Chris -- Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quit [now definitely O/T]
Hi Carl, Thanks for the response. I had one of those "should I want to take that message back?" moments after sending my previous message - I regret the confrontational tone I took at times. Carl Sorensen wrote: Thanks for your contributions. I'm sorry for whatever part I've played in discouraging you. Thanks. I've appreciated your patience the few times we've interacted, and I agree with Graham (at the risk of turning this into a "praise Carl" thread) that you do excellent work with shepherding new developers. I assume you're talking about the issue 415 stuff, ... So please, pick up your code again, and try to get the patch for 415 into shape so that it can be applied. Joe will help you, I'm sure. And Han-Wen isn't trying to keep you out; he's just trying to keep the code up to standard. We really do *like* patches, even if sometimes it doesn't seem so. Looking back at the thread, it does look to me now that I took Han-Wen's response too personally and I ended up tuning out a lot of the rest of the conversation. I revisited the branch I was working on, and - not surprisingly after eight months - it could not be cleanly rebased. I'll try to take a look at it, but it will take me a while to get back up to speed on it. I think my experience does illustrate the care necessary in shepherding new developers. I think the LilyPond developer community would do well to treat newbies with kid gloves - contributing to a project for the first time can be intimidating. The Frogs program is a good step, but it's not very well publicized. If we had a perfect code-formatting tool, we could just run the files through the tool. But we don't. I vaguely remember some discussion on this at one point, but I can't find anything in the mailing list archives. I'd like to do some investigating as to what tools are available - it would save a lot of headache. I realize that it seems like jumping through mindless and unnecessary hoops. I've been there (had patches rejected because of bad indentation) and I remember the pain it was to completely reindent the file (as part of that process I learned to use the automatic indentation in vim). But my code is easier to read (which is *really* important for Scheme code IMO), so it's worth the hassle. I'm not going to argue against the benefits of readable code - I agree wholeheartedly (as my wife, who has done some first-draft engraving for me, can attest, I'm a stickler for formatting). It is difficult, however, to write code in a different style than the code right before and after the area I'm working on - especially since I was previously unfamiliar with the GNU style. However, a lot of the code is difficult to follow - when is stop_translation_timestep called in engravers, for instance? It took me a while to understand that it will be called even due to rhythms in other voices besides the one the engraver is interested in. I didn't even know that. I hope we can get this documented. Would you be willing to take a stab at how events are passed to engravers (or how various routines inside an engraver are called from outside the engraver)? Perhaps this could be part of a developer tutorial that details creating a new engraver from scratch? I'm envisioning a LM-equivalent for the CG with the same relationship that the LM has to the NR (the full names of which must not be named). "Thanks for your willingness to help. Unfortunately, we don't have a lot of documentation for that right now. And I can't think of a good discussion that took place on lilypond-devel, but you might find something if you search the archives. The recommended way to figure out how LilyPond works is to read the source. As you do, you may find some more specific questions to ask. Please feel free to come back with any further questions." Unfortunately, this is often abbreviated as "Our entry point is in main() (lily/main.cc)..." - I'm thankful that verbiage has not been carried over to the new site. I hope this hasn't come across as defensive. I'm sincerely trying to help. Thanks. I appreciate your willingness to put up with me. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Quit [now definitely O/T]
As a frequent LilyPond user (25-50% of my day job) and aspiring contributor, I'd like to throw in my two cents (USD, so not worth much - sorry). Over the past year, I've submitted patches on occasion for possible inclusion in the trunk. On one occasion (accidentals in chords not spaced properly), I spent quite a bit of time implementing a solution proposed by one core developer, which took quite a bit of time (including a steep learning curve, which I'll discuss below), only to have another core developer reject it out of hand as being the wrong approach. The rejection left a bad taste in my mouth - it was fairly terse, and didn't acknowledge the wasted effort I had expended. Not surprisingly, I haven't found the motivation to touch that code again. Over the past couple of days, I've been working on fixing a couple of bugs that were caused by an earlier bug fix I submitted (that was accepted). Joe Neeman has given me very constructive comments and asked for reasonable improvements. At times, however, I've been struck by the level of perfection required for patches such as mine, which seem to be much higher than the current code. For instance, I was asked to correct some indentation - never mind the fact that the code right around my patch was indented incorrectly (I thought about fixing the whole file, but didn't want to add noise to the patch set). As I mentioned above (and others have mentioned), the learning curve for developing is quite steep. I applaud the effort by Graham et al to improve the documentation, especially the Contributor's Guide, which has been a big help even in its incomplete form. However, a lot of the code is difficult to follow - when is stop_translation_timestep called in engravers, for instance? It took me a while to understand that it will be called even due to rhythms in other voices besides the one the engraver is interested in. A common response to questions about the code is to RTFlilypond-devel_archives, which can be helpful. The problem that I've found here is that often I'll find outdated discussions that describe the code as it worked in 2001 instead of now, and it's difficult to determine when the behavior changed. I understand the frustration inherent in helping newbies (until you've had to explain to an 85-year-old customer how to find the Start menu in Windows, you haven't seen anything), and I understand that a big problem is the lack of person-hours to improve the developer documentation. However, a change in tone could go a long ways toward recruiting and maintaining developers - instead of "RTFlilypond-devel, n00b!" how about, "Thanks for your willingness to help. Unfortunately, we don't have a lot of documentation for that right now. There were some discussions on lilypond-devel about it a while back that should give you some guidance, though be aware that the behavior changed in the fall of 2004, so disregard anything before that. And feel free to come back with any further questions." Of course, my accusation doesn't apply to all of the LilyPond developers, some of whom have been very helpful and pleasant to work with. The reason that I'm still hanging around, however, is a testament more to the quality of the product than to any welcoming atmosphere in the community. (sorry if this message doesn't thread well - I couldn't figure out a good place in the conversation to reply to directly) Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 800 (extender ending early if other voices present)
Joe Neeman wrote: > Now I'm even more confused. get_current_note_head finds a note head > (from the associatedVoice) that ends strictly after the current moment. > We only check melisma_busy if get_current_note_head finds something. > Therefore, we will only check melisma_busy if we are in the middle of a > note. Am I missing something? Nope - that's how I understand it as well. The problem is that melisma_busy always returns false if we're mid-note, necessitating the additional check. > To answer your original question, btw, I have a slight preference for > leaving melisma_busy as-is and modifying the call site. I've worked out a solution that seems to work. It's now included in my Rietveld issue for bug 786. -Chris Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixing issue 800 (extender ending early if other voices present)
>> 1) Change melisma_busy() to return true if in the middle of a note >> 2) Alternatively, add the check in >> Extender_engraver::stop_translation_timestep instead > > I'm confused: isn't the current check in > Extender_engraver::stop_translation_timestep? For solution #2, I meant that we can add a check in Extender_engraver::stop_translation_timestep to see if we're in the middle of a note, in addition to the melisma_busy() call (since melisma_busy() doesn't currently do such a check). Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fixing issue 800 (extender ending early if other voices present)
I've done some work towards fixing issue 800, and at least now understand what's happening: The patch that introduced the bug added a check in Extender_engraver::stop_translation_timestep() to check if the current voice was in the middle of a melisma (calling melisma_busy(voice) ) and, if not, completizing the extender. This fixed the neverending-extender bug, but introduced issue 800. The reason that this is happening is not simply because there's another voice, but specifically because of the rhythm in the second voice: Extender_engraver::stop_translation_timestep() is called after the second beat in the measure, while the first voice is in the middle of the dotted quarter-note. At this point, melisma_busy() returns false - it apparently doesn't know how to handle being in the middle of a note. It seems to me that there are two possible ways to address this: 1) Change melisma_busy() to return true if in the middle of a note 2) Alternatively, add the check in Extender_engraver::stop_translation_timestep instead Any guidance on which approach is preferable? Thanks. -- Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Span_arpeggio patch
Carl Sorensen wrote: > Way back in January (10 months ago!!!), Chris Snyder was working on a patch > for spanned arpeggios. > > <http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/19682> > > I was asked to shepherd this process, but I have apparently dropped > the ball on doing so. You didn't drop the ball - the patch I submitted was rejected as being the wrong approach. I offered to do a second take on it, but never finished (I got overwhelmed trying to wade through everything). I could give it another shot - I'm more familiar with the LilyPond code now. Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes issue 786, "Extenders in lyrics stop prematurely if a single underscore is found."
> I can't verify #800 here; the extender's still too short. You're right - I assumed 800 would be fixed because it looked like it was the same issue, but it seems unrelated. I've done some investigation, and am stumped so far. > Can you check lyric-melisma-manual.ly? > > I've just run a regression test check and there's a missing hyphen > following "Ky", though the melisma is correct (see attached image). I'm working on it; I fixed the hyphen issue, but now there are a bunch of other lyrics that are spaced wrong. I'll keep investigating. Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue #786 (lyric extenders completing too early)
Reinhold Kainhofer wrote:
> I have not really thought it through, but would that work with the
> following code in lyric_engraver.cc:
>
> if (melisma_busy (voice)
> && !to_boolean (get_property ("ignoreMelismata")))
>text_->set_property ("self-alignment-X",
> get_property("lyricMelismaAlignment"));
>
> There is the ignoreMelismata property, which makes Lilypond ignore all
> melismata. If melisma_busy would return True for "_", would this
> affect the skipped note? Or in other words, does the processing of "_"
> rely on the code above or not.
>
> And then there is the Lyric_combine_music_iterator::start_new_syllable
> function. would that still work?
I thought of another potential problem: Does melisma_busy know about
Lyrics contexts at all? Perhaps I'm barking up completely the wrong tree
here.
Chris Snyder
Adoro Music Publishing
1-616-828-4436 x800
http://www.adoromusicpub.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue #786 (lyric extenders completing too early)
Valentin Villenave wrote: > seeing your work getting forgotten is understandably frustrating, but > I'm afraid this is but a consequence of our lack of resources (people, > time, energy). I *could* mark the issue as "started" if you do provide > us with a possible way to address the problem, not necessarily a patch > but even pseudocode that someone can help you implement. That *might* > give it more visibility -- but please keep in mind that there are > currently 290 open issues in our tracker. Hi Valentin, I didn't mean to express any frustration with the process - I just figured that it probably got lost amidst a lot of bug updates on bug-lilypond. My goal at the moment with this bug is to decide whether it's an issue with the code form my patch or an issue with the melisma_busy() function. I'm happy to try to address the problem further, but need some guidance as to where I should be looking - should melisma_busy() know about the melisma being extended with underscores in the lyrics, or should an additional check be added in the extender engraver? Thanks, Chris -- Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Issue #786 (lyric extenders completing too early)
I posted a comment about this issue a while back, but it seems that it
was drowned out by other bug updates.
The issue is that when underscores are used to extend a melisma, the
extender line does not continue over the melisma as it should. Here's
what I wrote about it:
I've done some looking into this, and am not sure of the best way to fix
this. My original patch (the one that caused the regression) added the
following code:
if (!melisma_busy (voice))
{
completize_extender (pending_extender_);
pending_extender_ = 0;
}
The more I think about it, the more I think that the patch is correct -
if melisma_busy is intended to behave like I think it should. The
documentation for the melisma_busy function doesn't make it clear, but I
would expect, based on its name, that it should return true whenever the
associated lyrics context is in the middle of a melisma. Since single
underscores extend the melisma ("You can define melismata entirely in
the lyrics, by entering _ for every extra note that has to be added to
the melisma." --LNR 2.1.3), the fix would therefore be to alter the
behavior of the melisma_busy function.
Thanks,
-Chris
--
Chris Snyder
Adoro Music Publishing
1-616-828-4436 x800
http://www.adoromusicpub.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue #612 still not fixed
Joe Neeman wrote: > The problem IIRC is that the solution I had suggested to Chris wasn't > acceptable (with good reason) to Han-Wen. Chris understandably doesn't > seem too keen on throwing his work away and starting again with another > idea of mine. Part of the reason I haven't followed up yet is because of the initial discouragement, but right now it's mainly due to lack of time - I have a home improvement project that's gone far longer than it should have, and I'm exhibiting at a couple of American Guild of Organists conventions for my company (I frequently hear comments about the quality of the engraving, BTW). I'm still intending to follow up on it at some point, but I don't see myself having much available time until August. -Chris -- Chris Snyder Adoro Music Publishing 1-616-828-4436 x800 http://www.adoromusicpub.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space)
On Saturday, March 28, 2009, Joe Neeman wrote:
> The problem is that the current support for conditional accidentals is
> insufficient if there are multiple accidentals, not all of which are
> tied (see bug 612). The reason is that the positions of all the
> accidentals can change completely when an accidental is added or
> removed. So I think we need to run the whole layout algorithm twice,
> once with the conditional accidentals and once without, and I suggested
> that copying all of the accidentals is the simplest way to do it. I
> realize that this goes against the convention of only cloning items in
> the breakable columns, but I don't see another way to do it; the
> formatting of such accidentals seems to be completely tied to their
> break status which justifies copying them for the same reason that we
> copy items in the breakable columns.
The only other way I see to do it would be to have each accidental
actually store two sets of spacing properties, and reference the correct
one depending on line-breaking. This approach doesn't seem any better to
me than what you've proposed.
>> I've glossed over the patch, and I am less than enthused: it seems to
>> add a lot of special casing and duplicate code for the reminder and
>> normal accidentals, and I have seen very dubious constructs like
>> get_property("accidental-grob") rather than get_object.
>
> I'll review the code shortly; I agree that it should be get_object.
I changed the get_object calls to get_property because the accidental-grob
callback I added to notehead to return the correct accidental grob wasn't
being called. What is the difference between objects and properties,
anyways?
Thanks,
-Chris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tied accidentals in chords still taking up space
I've uploaded my patch to Rietveld:
http://codereview.appspot.com/28134
(lilypond-devel is cc'd, but the main address on my Google account is
different than the one I use here, so I'm not sure if messages it's
sending to the list will go through)
Joe Neeman wrote:
> I think you should do it as soon as you clone() the accidental (in
> Accidental_placement::add_accidental perhaps?).
I couldn't do it there because the accidental_placement didn't have a
full family tree going back to a system. I changed accidental_engraver
to create both copies of the accidentals, and announced them there.
> That would be better, yes. You can determine which accidental is the
> right one using the same logic as Accidental::print. Note that this
> logic is only valid after the line-breaking has taken place, so you
> should note that in the documentation in scm/define-grob-properties.scm.
That approach worked well. I had to change all of the
get_object("accidental-grob") calls to get_property to have the callback
get called, though I'm not really sure what the difference between those
two functions is otherwise.
> In Accidental::print, are the correct accidentals committing suicide?
> You might need to change the logic there.
That was the problem.
> I can't think why the accidentals would be printed over the noteheads,
> though. You might get a clue if you check the value of
> ape->grobs_[j]->relative_coordinate(common[X_AXIS], X_AXIS) after
> accidental-placement.cc:397.
The reason that the accidentals were being printed over the noteheads is
that the wrong accidentals were being printed. Those incorrect
accidentals should never have the possibility of being printed, so they
had no spacing calculations done to them. Everything worked fine once I
told the correct accidentals to commit suicide and announced the copied
accidentals properly.
Thanks,
-Chris
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tied accidentals in chords still taking up space
Joe Neeman wrote:
> On Thu, 2009-03-26 at 10:26 -0400, Chris Snyder wrote:
>> Joe Neeman wrote:
> It's not necessary to announce every grob (for example, of the three
> copies of every breakable grob, only the middle-of-line copy gets
> announced). The code for creating these non-announced grobs is in
> Item::copy_breakable_items. In particular, you need the
> get_root_system(original_grob)->typeset_grob(cloned_grob) line to give
> your clone a layout_.
That makes sense - when does this announce need to happen? Right now, I
have it checking accidentals during calculate_positioning_done to see if
they have layouts, and announcing them if not. Is this acceptable?
> This is a bit tricky. To do this properly, you might need to add a
> Note_head::get_accidental function that has the logic for finding the
> right accidental (you could create a new property,
> "break-reminder-accidental-grob", for the new copy). Then you'd need to
> change every place that does get_object("accidental-grob") to use the
> new function; there aren't very many such places. It should be safe to
> just pick one copy if you want to put this off until later.
How about making the accidental-grob property point to a callback? I'm
not sure if it's better or not, but I figured I'd consider the
possibilities.
I've gotten to the point where the spacing is being calculated
correctly. However, it's not printing the correct accidentals - after a
line break, there's a space where the accidentals should be, then
accidentals printed over the noteheads. I've confirmed that the
misplaced accidentals are the copies that aren't supposed to be printed,
and the correct accidentals are not being printed.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tied accidentals in chords still taking up space (was: Issue 415 in lilypond: Hidden accidental of tied note still takes space)
Joe Neeman wrote: > [explanation of spacing code...] > One solution might be the following, which involves modifying only > accidental-placement: make 2 copies of every accidental, one for the > start-of-a-line case and one for the middle-of-a-line case (so the > start-of-a-line accidentals would be, in the terminology of > Accidental_placement::split_accidentals, the break_reminder accidentals > and the real_accidentals while the middle-of-a-line accidentals would > have copies of only the real_accidentals). Run the accidental layout > algorithm (currently in Accidental_placement::calc_positioning_done, but > you'll want to move it to a different function and make > calc_positioning_done call it twice) twice, once for each set of > accidentals. Then modify Accidental_placement::get_relevant_accidentals > to return one of the sets of accidentals. I've looked into this approach, and have a few questions: I tried cloning the accidentals in Accidental_placement::add_accidental, but that led to a segfault later on while trying to calculate the X-extent of the cloned accidental, since its layout_ was null. From what I can tell, this is because the cloned grob was never announced. Perhaps I should modify accidental-engraver as well, and have it create two copies there, passing them both to Accidental_placement::add_accidental? Which copy of the accidental should be put into the accidental-grob property of the note head? Thanks, -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[patch] Lyric extenders
Last month I sent a patch to the list dealing with lyric extenders. Since it seems to have gotten lost in the deluge of list traffic, I'm re-sending it, this time posting it on Rietveld: http://codereview.appspot.com/28052 Thanks, -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
2.13.0 source archive
When I browse the download site, the source for 2.13.0 is at http://download.linuxaudio.org/lilypond/sources/v2.13 rather than http://download.linuxaudio.org/lilypond/sources/v2.13/lilypond-2.13.0.tar.gz. Perhaps someone did a "cp lilypond-2.13.0.tar.gz [...]/sources/v2.13 before creating the v2.13 directory? -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Patch: Fix lyric extenders to end properly
I'm attaching a patch that fixes lyric extenders to end properly in some
cases where they hadn't been. Basically, if an extender was at the end
of a Lyrics section, while the voice continued further, the extender
line was not ended correctly. In some cases, I've had it continue for a
single extra note. In others, it's continued all the way to the end of
the music. I've run into this issue quite a few times when I've had to
add some text because one vocal part has an alternate rhythm for a
couple of measures.
As I understand the code, extenders are stopped when the next Lyric
event comes along. Since these situations do not have another lyric
after the extender, the extender goes for too long. My patch adds a
check to make sure that the notes the extender sees are still part of a
melisma, and completes the extender upon encountering the first note
that is not (i.e. the last note of the melisma).
This bug is described in Issue #331, but the two test-cases provided
there work properly in recent versions. I've created a test-case that
demonstrates the problem with the latest code in master:
http://temp.mvpsoft.com/ly/lyric_extender/
Two result pngs are included: one with 2.13.0 (current master as of a
half-hour or so ago) and one with my patch applied.
I have a case in a bigger score where the extenders go for pages and
pages too long, but I haven't been able to boil that down to a precise
test-case. I have verified, however, that this patch fixes that instance
as well.
Thanks. I look forward to any comments.
-Chris Snyder
>From ae36a3f6e79ce3a15d4e254a8919108b9feed440 Mon Sep 17 00:00:00 2001
From: Chris Snyder
Date: Tue, 24 Feb 2009 13:02:17 -0500
Subject: [PATCH] Fix lyric extenders to end properly when there are notes but no more lyrics.
---
lily/extender-engraver.cc |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/lily/extender-engraver.cc b/lily/extender-engraver.cc
index f3f711d..d29f5a3 100644
--- a/lily/extender-engraver.cc
+++ b/lily/extender-engraver.cc
@@ -98,6 +98,11 @@ Extender_engraver::stop_translation_timestep ()
{
Pointer_group_interface::add_grob (pending_extender_,
ly_symbol2scm ("heads"), h);
+ if (! melisma_busy(voice))
+ {
+ completize_extender (pending_extender_);
+ pending_extender_ = 0;
+ }
}
}
else
--
1.5.6.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Carl D. Sorensen wrote: > I think if you want to have two spanned arpeggios at the same music moment > with different kinds of arpeggio symbol, you need to use \tweak instead of > \override. > > I wouldn't worry about that for now. That's not my main concern - how would two (or more) spanned arpeggios be differentiated, so that the engraver would know which ones to connect to which? There'd need to be some kind of syntax to specify which spanned-arpeggio an individual arpeggio belongs to. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Carl D. Sorensen wrote: > Sounds to me like we have a winner. Chris, will you take on this task? I > think you'll find that the people on -devel are happy to answer coding > questions. Everybody wants more people who can fix/modify LilyPond code, so > we're all happy to help somebody get up to speed. I was afraid that would happen. I'll take it on; I've looked at this section of the code enough that I have somewhat of an idea what's going on, so this would be a good place to start. One thought: perhaps this would be a good time to fix the current inability to have spanned and non-spanned arpeggios in the same point in time? The first issue with this would be the notation: I'd propose adding a \spannedArpeggio command alongside of the \arpeggio command and removing the connect-arpeggios property. Span_arpeggio_engraver could then be included by default in the Score context, since it would be harmless unless \spannedArpeggio's are used. The question is then: what about two spanned arpeggios at once? We'd need some kind of identifier mechanism (\spannedArpeggio="xx" ?). That starts to get ugly. Thanks. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
(a caveat to the following message: I'm still learning how the LilyPond code is organized - please gently correct me when necessary) Joe Neeman wrote: > My approach can work at the same granularity as \set connectArpeggios. > That is, if the Span_arpeggio_engraver is at the PianoStaff level (which > it is by default) then you can override PianoStaff.Arpeggio #'stencil to > affect only the Arpeggios in that PianoStaff. The issue for me with this approach is that the NR instructs the reader to use the \arpeggioXx macros. I think your initial suggestion was to do the overrides at the Score.Arpeggio level instead of the PianoStaff.Arpeggio level. Modifying the macros to either of those approaches produces issues, however: Score-wide leads to potential issues with much bigger scores (such as orchestral scores), while modifying it at the PianoStaff level makes the macros not work in any non-PianoStaffs (at least I assume that would be the case - I haven't tested it). > I should probably explain my objection to the original approach: every > time we set a user-overrideable variable in an engraver, we make it > impossible for the user to set that variable directly. What's more, > there is no indication in the automatically-generated docs that the > user's override would be ignored. Maybe it's a contrived example, but if > someone does > > \override Voice.Arpeggio #'stencil = #foo > \override PianoStaff.Arpeggio #'stencil = #bar > > then they might wonder why the spanned arpeggio has a "foo" stencil even > though it is created in the PianoStaff context. That is true. I'm guessing, though, that most users - even moderately advanced ones (the category I would describe myself as being in) - don't even think to use \override commands in this case, since the NR gives instructions for using the very convenient \arpeggioXx macros. The current caveat in the NR (1.3.3: "The parenthesis-style arpeggio brackets do not work for cross-staff arpeggios.") could be changed to instruct users to use \override commands rather than the macros. > I think Han-Wen's approach is the "real" solution, but it's also a bit > more work. You could create a new SpanArpeggio grob that gets Arpeggios > as children and has, as default properties, callbacks that check the > children. You need to decide what happens, though (this is also an > admittedly pretty negligible problem with Chris's original patch) if two > "child" arpeggios have different stencils: what happens to the span > arpeggio? I agree that Han-Wen's approach is better from an architectural standpoint. I'd be willing to undertake such an endeavor if everyone agrees that it would be desirable, as long as no-one minds the occasional possibly-inane question on -devel. I think the problem you mention with both approaches (which I did recognize when I was making the patch) is a non-issue - LilyPond should not be expected to produce sensible output from non-sensible input, such as a spanned arpeggio comprised of arpeggios of different styles. I think that throwing up a warning would be the most desirable outcome. Thanks. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Carl D. Sorensen wrote: > Can you make a brief regression test that shows why this patch is desirable? > Joe seems to feel like it's unnecessary, because you can set the > span-arpeggio style by setting Score.Arpeggio #'stencil. Well, I put together a regression test, but it's not exactly "brief" (I demonstrated all of the approaches). The files are here: http://temp.mvpsoft.com/ly/arpeggios/ There are four tests: arpeggio-1.png: Using standard \arpeggioXx commands (without the patch) [*] arpeggio-2.png: Joe's idea arpeggio-3.png: Joe's idea extended to actually modifying the \arpeggioXx commands [*] arpeggio-new.png: the first test again with my patch applied. The starred versions were rendered flawlessly. Joe's way, however, required some non-intuitive \revert commands, as \arpeggioXx had no effect after the \override Score.Arpeggio commands, even if they were in different staves. Explanation of desired output: First chord: Connected, normal Second chord: Connected, bracket Third chord: Unconnected, top bracket, bottom normal Fourth chord: Unconnected, top slur, bottom arrow-up > Is there a reason why somebody would want to have different arpeggio > stencils for different staffs? If not, then I think we ought to change > the predefined arpeggio commands to work on Score. Two possibilities: organ music (which I engrave a lot of) could require such a situation; even more likely is in orchestral music, where there are often a lot of independent parts. Those possibilities, plus the possibility that existing scores could be broken, suggests to me that modifying the \arpeggioXx commands is the least desirable approach. Given the minimal invasiveness of my patch, it seems to me that even the slight possibility of someone needing this functionality should support its inclusion. My patch also makes LilyPond handle connected arpeggios in an intuitive way (to me, at least), negating the need to add caveats in the documentation. I understand, however, the reason for your thoroughness in evaluating patches, and I appreciate the excellent-quality code that results. Thanks for your time. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Joe Neeman wrote: > In general, the best approach is to nag us from time to time. If we > don't like the patch, we'll say so; if you get no response, your email > probably just got stuck under a pile of other stuff. I was guessing that that was the case, given its proximity to the release of 2.12. I tried to nag as gently as possible, given my inexperience with this project. > That said, I'm not sure why this patch is necessary. I see that the > prebaked commands like \arpeggioBracket don't work on span arpeggios, > but the following does "work" without your patch: > [...] > \override Score.Arpeggio #'stencil = #ly:arpeggio::brew-chord-slur > [...] > I put "work" in quotation marks because the result looks quite horrible. > I think this is what the documentation meant when it said that > cross-staff arpeggios don't work with the slur-like look (unlike the > other sorts of brackets, the slur brackets take up more space when they > go cross-staff and this space isn't accounted for). Your example does make the issue more clear to me - it looks like the issue could also be solved by changing the \arpeggio[Bracket|Parenthesis|etc.] command, which overrides the property on Arpeggio instead of Score.Arpeggio. Changing those predefined commands, however, would have the adverse effect of altering arpeggios on different staves even when they are not being connected. Perhaps the solution lies in the documentation: how about adding information on altering spanned arpeggios using explicit \override's instead of the macros? If that sounds like a good plan, I'm willing to write the necessary instructions and examples. -Chris ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
On December 20, 2008, Chris Snyder wrote: > I did realize that the ly_symbol2scm call was not needed. I've > attached a new patch that does not include it. Is there any chance of my patch being accepted into master? What can I do to make the process easier? Thanks. -Chris Snyder ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Allow setting of arpeggio type for spanned arpeggios
Han-Wen Nienhuys wrote:
You should use get_property("stencil") unless you're doing something
special. Still better is to use a callback in the spanner which
copies the stencil from its children.
I originally tried get_property, but the result was that the spanned
arpeggio copied the exact stencil from the child arpeggio, resulting in
only part of the spanned arpeggio being drawn. It appears to me that
get_property causes the stencil callback to be executed (using the data
from the child arpeggio), while get_property_data got a reference the
callback, allowing it to be run later. I looked for documentation or
mailing list posts to figure out what was going on, but couldn't find
anything that explained to me the difference between the two functions.
Looking at the code in grob-property.cc, it appears to me that my
analysis is correct, but I wouldn't be surprised if I'm oversimplifying
things or just plain wrong.
The second option you gave does not appear to me to be possible without
changing the way that spanned arpeggios are constructed. Unless I'm
mistaken, spanned arpeggios are not aware of their children - the
Span_arpeggio_engraver steals the stems and side-support-elements from
the children and feeds them to the spanned arpeggio. It seems to me that
the strategy I implemented (stealing the stencil property from a child
and feeding it to the spanned arpeggio) fits this pattern.
I did realize that the ly_symbol2scm call was not needed. I've attached
a new patch that does not include it.
Thanks.
-Chris
>From 327618ff4ee5e1e275dfb461aa325510e3f21c97 Mon Sep 17 00:00:00 2001
From: Chris Snyder
Date: Sat, 20 Dec 2008 15:14:44 -0500
Subject: [PATCH] Altered spanned arpeggios to inherit the stencil property of an included arpeggio
(it isn't very smart - it just gets the property from the first arpeggio it finds)
---
lily/span-arpeggio-engraver.cc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lily/span-arpeggio-engraver.cc b/lily/span-arpeggio-engraver.cc
index 07958a8..9b5f0d6 100644
--- a/lily/span-arpeggio-engraver.cc
+++ b/lily/span-arpeggio-engraver.cc
@@ -61,6 +61,7 @@ Span_arpeggio_engraver::process_acknowledged ()
{
span_arpeggio_ = make_item ("Arpeggio", SCM_EOL);
span_arpeggio_->set_property ("cross-staff", SCM_BOOL_T);
+ span_arpeggio_->set_property ("stencil", arpeggios_[0]->get_property_data ("stencil"));
}
}
--
1.5.6.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Allow setting of arpeggio type for spanned arpeggios
I'm working on a score where I'd like to create a cross-staff vertical
bracket, which I have LilyPond engrave as a bracket-style arpeggio. This
was not possible because spanned arpeggios always used the default
stencil - the NR alludes to this in 1.3.3 under "Known issues and
warnings," where the following note is included: "The parenthesis-style
arpeggio brackets do not work for cross-staff arpeggios. " The note is
accurate, but not complete, as the parenthesis style isn't the only one
that doesn't work.
Wanting a solution, I figured this could be a good place for me to make
my first code contribution to LilyPond. The solution I came up with was
for the Span_arpeggio_engraver to copy the stencil property from one of
the included arpeggios. On some levels it feels slightly hack-ish
(perhaps because the patch ended up adding only one line of code - quite
the result after hours of work), but the functionality seems quite
elegant.
I've attached the patch according (I hope) to the standards set forth on
the LilyPond web site. Feedback (both code- and process-wise) would be
greatly appreciated. Thank you.
--
Chris Snyder
Adoro Music Publishing
1-616-828-4436 x800
http://www.adoromusicpub.com
>From 49ed7b275a9c83154e70dca0a32496d0ba3793fd Mon Sep 17 00:00:00 2001
From: Chris Snyder
Date: Thu, 18 Dec 2008 14:49:00 -0500
Subject: [PATCH] Altered spanned arpeggios to inherit the stencil property of an included arpeggio
(it isn't very smart - it just gets the property from the first arpeggio it finds)
---
lily/span-arpeggio-engraver.cc |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/lily/span-arpeggio-engraver.cc b/lily/span-arpeggio-engraver.cc
index 07958a8..adbd0b0 100644
--- a/lily/span-arpeggio-engraver.cc
+++ b/lily/span-arpeggio-engraver.cc
@@ -61,6 +61,7 @@ Span_arpeggio_engraver::process_acknowledged ()
{
span_arpeggio_ = make_item ("Arpeggio", SCM_EOL);
span_arpeggio_->set_property ("cross-staff", SCM_BOOL_T);
+ span_arpeggio_->set_property ("stencil", arpeggios_[0]->get_property_data (ly_symbol2scm ("stencil")));
}
}
--
1.5.6.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Slur collisions
During the course of engraving a fairly complex choral piece, I've run into quite a few slur bugs, including 307 (slur collision with tuplet bracket) and 379/586 (slur issues across line breaks). Hoping to be able to fix some of the issues myself and learn about the internals of LilyPond, I started out trying to fix bug 307. As I learned more about the slur code, however, I realized that I was in way over my head. It appears to me that the problem is that slurs currently have no way of avoiding lines (such as a tuplet bracket), but instead focus on avoiding points (such as a fermata). It seems to me that adding line-avoidance would be a good idea, but I don't have the expertise and understanding of the code necessary to implement such a far-reaching change. I've benefited greatly from LilyPond's excellent engraving capabilities. I'd like to give back - and it seems that the slur code is one of the areas of greatest need of attention. Since I do not have the expertise to do this, I'm willing to sponsor some work here - especially dealing with the issues named above. Would anyone be willing to tackle this? If so, what do you think would be a reasonable sponsorship amount? Thanks for producing such an excellent piece of software. I'd like to contribute, but feel that I can better contribute finances than code at this point. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
