Scope of scheme defines in Lilypond projects
Hi I'm wanting to write some globally accessible scheme functions / procedures (defines) for my lilypond project but the documentation on such seems a bit limited. I.e. Do \header, \page and other contexts introduce new variable scopes (assuming yes here)? If so, how can scheme functions and variables be defined globally for access in all such scopes within a lilypond project? Can anyone point me in the right direction here. Thank you in advance. S Mack Attached is a example of a scheme module I want to include globally in a lilypond project and whose public defines I want to access in my lilypond project in \header, \score, \book and other contexts within the project. The idea is that I can collect all credit and song title information into a single include file for easier collation and management by maintainers and to reduce duplication of credits across all the music sheets in the project / book. Would be used via... #(load "init/credits.scm") #(use-modules (init credits)) credits.scm Description: Binary data NB: Currently have 50+ music sheets completed, most versing text has been added, and the results are quite impressive. The project will eventually encompass collating some 300+ music sheets into one book. Lilypond does an excellent job of rendering each music sheet. Most friends find it hard to believe such a program is available, and for "FREE"! Thank you to all of you who have contributed so much to enabling such a top class product to be produced and made freely available. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
New template for 'lilypond' made available
Hello, gentle maintainer. This is a message from the Translation Project robot. (If you have any questions, send them to .) A new POT file for textual domain 'lilypond' has been made available to the language teams for translation. It is archived as: http://translationproject.org/POT-files/lilypond-2.13.48.pot Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. Below is the URL which has been provided to the translators of your package. Please inform the translation coordinator, at the address at the bottom, if this information is not current: http://lilypond.org/download/sources/v2.13/lilypond-2.13.48.tar.gz We can arrange things so that translated PO files are automatically e-mailed to you when they arrive. Ask at the address below if you want this. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling error with 'unknown' directory 'cs'
On Thu, Feb 10, 2011 at 10:57:36PM -0700, Colin Campbell wrote: > On 11-02-10 10:47 PM, James Lowe wrote: > >You need to run > > ../configure > >again, due to build system changes for new languages. It's /just/ > >possible that you might need to delete your build/ dir and start > >again, but running ../configure should be enough. > > > >--- > > > >Unfortunately it wasn't. > > > >I did also did a make clean ; make doc-clean and (even re-run configure) > >then started again, left it run overnight and it still failed.. Words of wisdom: don't ever try make clean make doc-clean it's a complete waste of time. If you ever suspect that "make clean" might help, then just save yourself the agony and nuke your build/ dir and start from fresh. > >Has anyone else actually done a clean doc/web build since all those > >translations were merged? I always nuke my build/ dir, and I never noticed the slightest problem. I've built the docs several times since then, including the 2.13.49, release candidate 2. > As it happens, I've been having all *sorts* of fun trying to get a > clean local build of the docs so I can finish off those patches of > Reinhold's. I can build lily both from gub and directly from the > command line in lilypond-git. > Make doc has so far choked every time > I've tried this week, even after nuking lilypond-git and the > .lilypond-fonts.cache-2. ? that's very odd. What kind of error message did you see? > I'm re-running a make doc after a sudo make install, make install has nothing to do with a doc build. There is absolutely no need for a lilypond contributor to run make install. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling error with 'unknown' directory 'cs'
On 11-02-10 10:47 PM, James Lowe wrote: Hello From: Graham Percival [gra...@percival-music.ca] Sent: 10 February 2011 19:47 To: James Lowe Cc: lilypond-devel@gnu.org Subject: Re: compiling error with 'unknown' directory 'cs' On Thu, Feb 10, 2011 at 02:36:58PM +, James Lowe wrote: I've just done a git pull from this morning and tried to do a 'make ; make doc' and get an error You need to run ../configure again, due to build system changes for new languages. It's /just/ possible that you might need to delete your build/ dir and start again, but running ../configure should be enough. --- Unfortunately it wasn't. I did also did a make clean ; make doc-clean and (even re-run configure) then started again, left it run overnight and it still failed.. :( So now because I won't be able to do much until this evening at the earliest, I've just nuked my whole lilypond-git dir and completely started again from scratch and left it running. I might as well as I have nothing to lose now - shame, I would have liked to get that Titles patch done before the weekend. Has anyone else actually done a clean doc/web build since all those translations were merged? James As it happens, I've been having all *sorts* of fun trying to get a clean local build of the docs so I can finish off those patches of Reinhold's. I can build lily both from gub and directly from the command line in lilypond-git. Make doc has so far choked every time I've tried this week, even after nuking lilypond-git and the .lilypond-fonts.cache-2. I'm re-running a make doc after a sudo make install, wondering about path issues: it's working on snippets and announcing itself as 2.13.50 but even with 6GB and -j3 I'll not see results 'til the morning. I'll let you know what happens, and I'll give it another try at the office in my VM environment. 'Night all Colin -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: compiling error with 'unknown' directory 'cs'
Hello From: Graham Percival [gra...@percival-music.ca] Sent: 10 February 2011 19:47 To: James Lowe Cc: lilypond-devel@gnu.org Subject: Re: compiling error with 'unknown' directory 'cs' On Thu, Feb 10, 2011 at 02:36:58PM +, James Lowe wrote: > I've just done a git pull from this morning and tried to do a 'make ; make > doc' and get an error You need to run ../configure again, due to build system changes for new languages. It's /just/ possible that you might need to delete your build/ dir and start again, but running ../configure should be enough. --- Unfortunately it wasn't. I did also did a make clean ; make doc-clean and (even re-run configure) then started again, left it run overnight and it still failed.. :( So now because I won't be able to do much until this evening at the earliest, I've just nuked my whole lilypond-git dir and completely started again from scratch and left it running. I might as well as I have nothing to lose now - shame, I would have liked to get that Titles patch done before the weekend. Has anyone else actually done a clean doc/web build since all those translations were merged? James ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Thanks! Regtests look fine, and there's nothing obviously wrong with the code. However, none of the scm files managed to get uploaded. I remember hearing about problems about this, and the CG now contains: - Note: Some installations of git-cl fail when uploading a patch set that includes a .scm file. When this happens, it can generally be fixed by editing the file ‘/etc/mime.types’. Add a line to this file containing text/x-script.scheme scm. - on page: http://lilypond.org/doc/v2.13/Documentation/contributor/commits-and-patches#uploading-a-patch-for-review Could you try going that, then uploading again? http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour notice for modal transformations and page optimization
On Thu, Feb 10, 2011 at 10:06:55PM +0100, Benkő Pál wrote: > > Add Modal transformations > > http://codereview.appspot.com/4126042/ > > I think > http://codereview.appspot.com/4079064/ > is newer. Thanks, I have updated the issue in the google tracker. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Uploaded. Please check if it is all right now. 2011/2/10 Felipe Gonçalves Assis : > Hi, > > In fact, yesterday's "make key cancellations independent of extraNatural" > introduced a simple conflict with my patch, which I have just resolved. > > Other files were automatically merged. > > After some testing, I will upload a new patch-set. > > Regards, > Felipe > > On 10 February 2011 16:13, wrote: >> Sorry, I still can't apply this cleanly to git master. Are you sure you >> did a rebase? (I admit that I'm not totally certain about how to do >> this, but I've seen people in lilypond-devel talking about it -- maybe >> look through the mailing list archives for tips?) >> >> At the moment, I see failures in >> lily/key-engraver.cc >> and warnings in >> lily/parser.yy >> ly/engraver-init.ly >> scm/translation-functions.scm >> >> >> http://codereview.appspot.com/3789044/ >> > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCHES: 48-hour notice for modal transformations and page optimization
> Add Modal transformations > http://codereview.appspot.com/4126042/ I think http://codereview.appspot.com/4079064/ is newer. p ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme : compiling text and score sequences
Wow, nice ! Thanks a lot, this really helps :-p "LaTeX-like" text footnotes are nearly done. After doing these footnotes and endnotes, I will probably try to implement drop caps support. (My secret wish is to get rid of lilypond-book...) Regards, Bertrand ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCHES: 48-hour notice for modal transformations and page optimization
These are the last two "overdue" patches to review, so the frantic pace of reviewing will tail off in the next week. I'm hoping to settle down on 2 patches, twice a week, with 72 hours for each announcement. 6pm, Saturday 12 Feb, 2011. Add Modal transformations http://codereview.appspot.com/4126042/ Various caching optimizations during pure-height calculations. http://codereview.appspot.com/4129043/ Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Better support for beat slashes (multi-slash & mixed duration). (issue212048)
No complaints, and I just double-checked that the regtest is ok. Please push. http://codereview.appspot.com/212048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: compiling error with 'unknown' directory 'cs'
On Thu, Feb 10, 2011 at 02:36:58PM +, James Lowe wrote: > I've just done a git pull from this morning and tried to do a 'make ; make > doc' and get an error You need to run ../configure again, due to build system changes for new languages. It's /just/ possible that you might need to delete your build/ dir and start again, but running ../configure should be enough. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
compiling error with 'unknown' directory 'cs'
Hello, I've just done a git pull from this morning and tried to do a 'make ; make doc' and get an error -- make: Entering an unknown directory make: *** cs: No such file or directory. Stop. make: Leaving an unknown directory make[2]: *** [WWW-1] Error 2 rm out-www/weblinks.itexi -- I am using an 'out of tree' method to compile (in a 'build' dir as per the CG). I wonder if this is because a typo where it should be 'css' not 'cs' - I only am guessing because of the recent CSS emails/changes, that have been talked about. James <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Hi, In fact, yesterday's "make key cancellations independent of extraNatural" introduced a simple conflict with my patch, which I have just resolved. Other files were automatically merged. After some testing, I will upload a new patch-set. Regards, Felipe On 10 February 2011 16:13, wrote: > Sorry, I still can't apply this cleanly to git master. Are you sure you > did a rebase? (I admit that I'm not totally certain about how to do > this, but I've seen people in lilypond-devel talking about it -- maybe > look through the mailing list archives for tips?) > > At the moment, I see failures in > lily/key-engraver.cc > and warnings in > lily/parser.yy > ly/engraver-init.ly > scm/translation-functions.scm > > > http://codereview.appspot.com/3789044/ > ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision scoring (issue4174043)
Werner LEMBERG writes: > [Resending to lilypond-devel since it doesn't appear to have reached > the list (it's missing in > http://lists.gnu.org/archive/html/lilypond-devel/2011-02/)] > >> I tried this patch on half a dozen piano and orchestral scores and >> saw no bad side-effects. > > The attached image (from > IMSLP00014-Beethoven__L.v._-_Piano_Sonata_14.pdf) shows another > solution – smaller beams – to avoid the crossing of beams and stems. > Maybe this can be implemented too? It would appear to make sense mostly when the stems have been shrunk ridiculously. In that case, putting some "perspective" thinning on the beams might work out. However, multiple beams (anything but eighths) would then stop aligning sensibly with the staff lines. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision scoring (issue4174043)
[Resending to lilypond-devel since it doesn't appear to have reached the list (it's missing in http://lists.gnu.org/archive/html/lilypond-devel/2011-02/)] > I tried this patch on half a dozen piano and orchestral scores and > saw no bad side-effects. The attached image (from IMSLP00014-Beethoven__L.v._-_Piano_Sonata_14.pdf) shows another solution $(Q#|(B smaller beams $(Q#|(B to avoid the crossing of beams and stems. Maybe this can be implemented too? Werner <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1278: Arrow notation for quarter-tones. (issue3789044)
Sorry, I still can't apply this cleanly to git master. Are you sure you did a rebase? (I admit that I'm not totally certain about how to do this, but I've seen people in lilypond-devel talking about it -- maybe look through the mailing list archives for tips?) At the moment, I see failures in lily/key-engraver.cc and warnings in lily/parser.yy ly/engraver-init.ly scm/translation-functions.scm http://codereview.appspot.com/3789044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision scoring (issue4174043)
> I tried this patch on half a dozen piano and orchestral scores and > saw no bad side-effects. The attached image (from IMSLP00014-Beethoven__L.v._-_Piano_Sonata_14.pdf) shows another solution $(Q#|(B smaller beams $(Q#|(B to avoid the crossing of beams and stems. Maybe this can be implemented too? Werner <>___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Fwd: Broken link
Translation: there are some broken links on the website on the german version. and kudos to the doc editors, "Hartelijk dank voor de ontwikkeling van Lilypond! Anders als veel andere notatieprogrammas voelt het aan als een "labor of love". Zelfs de dokumentatie is een plezier om te lezen. Vooral zo doorgaan!" "Thank you for the development of LilyPond! Unlike many other notation programs it feels like a "labor of love". Even the documentation is a pleasure to read. Keep up the good work!" -- Forwarded message -- From: Martin & Brigitte Bijl-Schwab Date: 2011/2/9 Subject: Broken link To: han...@xs4all.nl Goedemorgen Han Wen, Op de Duitse website van Lilypond (http://lilypond.org/development.de.html) zijn er een paar broken links bijvoorbeeld: Die Entwicklung von LilyPond ist eine ziemlich komplizierte Angelegenheit. Um neuen Mitarbeitern zu helfen und das ganze System (ziemlich) stabil zu halten, haben wir ein Handbuch für Entwicklungsarbeiten geschrieben (nur auf Englisch). Beitragen (geteiltes HTML) - das Handbuch wird auf viele HTML-Seiten aufgeteilt. (kleiner Download für jede Seite) Beitragen (großes HTML) - das Handbuch auf einer großen HTML-Seite. (großer einmaliger Download, 500 kB) Beitragen.pdf - das Handbuch als PDF-Datei. (großer einmaliger Download, 2.8 MB) Hartelijk dank voor de ontwikkeling van Lilypond! Anders als veel andere notatieprogrammas voelt het aan als een "labor of love". Zelfs de dokumentatie is een plezier om te lezen. Vooral zo doorgaan! Martin Bijl-Schwab Luzern, Zwitserland -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Various caching optimizations during pure-height calculations. (issue4129043)
LGTM. http://codereview.appspot.com/4129043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Dynamics context prevents \RemoveEmptyStaves to work
2011/2/9 Xavier Scheuer :
> %% Reported by 胡海鹏 - Hu Haipeng
> %% http://lists.gnu.org/archive/html/lilypond-user/2011-02/msg00179.html
> %%
> %% [empty] Dynamics context prevents \RemoveEmptyStaves to work
> %%
> %% We should have a way to remove empty Dynamics contexts as well
> %% and \RemoveEmptyStaves should remove PianoStaff if both staves and
> %% Dynamics are empty.
> %%
Like this?
\layout {
\context {
\Dynamics
\RemoveEmptyStaves
}
}
Cheers,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 404 for renamed css stylesheets
2011/2/10 Phil Holmes : > Thanks. Now doing a search to try another check to see if there are any > other references I could have missed. > > Where is the location/file that gives the error, please? I read it on the daily 404 report from lilypond-cvs announce-only list (sorry, it is not archived) popularity page [referrer]... 475 /images/sarabande http://www.bloggen.be/thesecretofmusic/ a very popular 404!. Continued: 100 /doc/v2.13/Documentation/extending/lilypond.css http://www.lilypond.org/doc/v2.13/Documentation/extending/displaying-music-expressions http://www.lilypond.org/doc/v2.13/Documentation/extending/introduction-to-scheme http://www.lilypond.org/doc/v2.13/Documentation/extending/scheme-sandbox http://www.lilypond.org/doc/v2.13/Documentation/extending/scheme-variables http://www.lilypond.org/doc/v2.13/Documentation/extending/scheme-simple-data-types http://www.lilypond.org/doc/v2.13/Documentation/extending/scheme-compound-data-types etc., and 100 /doc/v2.13/Documentation/extending/lilypond-mccarty.css http://www.lilypond.org/doc/v2.13/Documentation/extending/displaying-music-expressions http://www.lilypond.org/doc/v2.13/Documentation/extending/introduction-to-scheme http://www.lilypond.org/doc/v2.13/Documentation/extending/scheme-sandbox http://www.lilypond.org/doc/v2.13/Documentation/extending/scheme-variables etc. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 404 for renamed css stylesheets
- Original Message - From: "Francisco Vila" To: "Phil Holmes" Cc: "LilyPond-Devel list" Sent: Thursday, February 10, 2011 10:47 AM Subject: 404 for renamed css stylesheets Hello, Still some references left to the old lilypond-mccarty.css file: python/auxiliar/postprocess_html.py , line 154 which cause not_found errors in our website. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com Thanks. Now doing a search to try another check to see if there are any other references I could have missed. Where is the location/file that gives the error, please? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme : compiling text and score sequences
Hello,
to work with foot- or end-notes its good to know the current position in
music - of course this doesn't make sense for a paragraph of pure text ;-)
So I digged for a way to fetch the current position in music - these are
only some hints for me to remember and perhaps for you to try:
--snip--
\version "2.12.3"
show = #(define-music-function (parser location name) (string?)
(make-music 'ApplyContext
'origin location
'procedure
(lambda (c)
(let*
((cbn (ly:context-property c 'currentBarNumber))
(cbn (if (not (number? cbn)) 0 cbn))
(cmp (ly:context-property c 'measurePosition)))
(display name)
(display (format " Measure ~a at ~a/~a (~a/~a)\n"
cbn
(ly:moment-main-numerator cmp)
(ly:moment-main-denominator cmp)
(ly:moment-grace-numerator cmp)
(ly:moment-grace-denominator cmp)))
music = #(define-music-function (parser location name) (string?)
#{
\relative c' {
\show #$name s1*0 \show #$name c2. \show #$name r4 d \show #$name
e \show #$name f
}
#})
\score {
<<
\music #"A"
{ s2. \music #"B" }
>>
}
--snip--
This simply prints out the current position in the music. The name
string is for looking at the order of processing the music.
I will have another look on this later.
Best regards,
Jan-Peter
On 09.02.2011 22:38, Bertrand Bordage wrote:
Thanks Jan-Peter !
I agree with your idea of using asterisks instead of numbers when
annotating scores (but for text, numbers seems more elegant).
For the moment, I will try to do LaTeX-like footnotes for markuplines.
Indeed, this would be a good solution for now :
- A column of footnotes on each page of markuplines
- Endnotes for the musical parts. Maybe without any sign on the score,
but with a reference to the score name, the current bar number and the
instrument name in the list of endnotes, like in Ricordi's critical
notes. This will avoid the parallel music parsing issue. And it looks
sooo classy ;-) (or boring)
Then I'll have a deeper look on this parsing issue.
Any help would be welcome :o)
Regards,
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 4174043 ready for review
On Feb 10, 2011, at 7:50 AM, Han-Wen Nienhuys wrote:
> On Thu, Feb 10, 2011 at 9:54 AM, m...@apollinemike.com
> wrote:
>
>> I think that the problem with doing the collision avoidance in the quanting
>> reveals itself around line 341 of beam-quanting.cc
>> if (collisions_.size ())
>> region_size += 2;
>> Here, I get the sense that you are expanding the region size of the quanting
>> if there is the possibility of collision. I feel that this will actually
>> work against the goal that you had previously set: namely, to avoid
>> unnecessary quants if possible. By moving the beam out of the collision
>
> On the contrary: avoiding unnecessary quants for normal cases makes it
> possible for us to use brute force on exceptional situations like by
> knees of collisions.
OK - I see what you mean, but I'd have to follow it in the code better. Where
does this happen?
>
>> region before the quanting (in beam.cc, for example), which would do similar
>> stuff to that which you have written around line 151, you would eliminate
>> having to expand the region size and you'd be able to catch problems that
>> your code doesn't currently catch. That said, your code does catch a great
>> deal of stuff - I ran 10 or so tests against the algorithm and not many of
>> them diverged (those that did are attached, prefixed ms or mike for me and
>> hw for you).
>
> I only see one page in both pdfs? If you can send me code as .ly, I
> can add them to the my regtest, to have more cases.
I'll try my best to have this done by tomorrow night (frantically composing!)
>
>> However, those that did diverge do come up in actual rep -
>> what worries me is that your code (as I understand it) cannot, by virtue of
>> how its made, catch several examples from the contemporary repertoire that I
>> threw up on that website (notably the Boulez and Crumb) without increasing
>
> I don't see anything by Crumb. The boulez example is actually a
> straight flag (left), and a beam with normal stem on the left.
>
I don't have the link and password handy, but I remember that I was thinking of
the boulez as an unfinished beam. You're right that the actual example is a
straight flag, but if someone did that with a beam, it'd be fair game for
collision avoidance. You're right about the crumb (I have that snippet on my
Desktop & am looking @ it now) - that is a mistake on my part. I'll go back on
Sunday and see if I can find the actual collision.
>> the region size to something very large.
>> I still advocate the solution in http://codereview.appspot.com/4131044 for
>> all the reasons I mention above: I feel that it actually takes less time by
>> never expanding the region size and can catch more results.
>> Mostly, I think that having two developers doing more or less the same thing
>> is a potential waste of time. My understanding of Lilypond is many orders
>> of magnitude inferior to yours, and I assumed (and am still assuming) that
>> your work on this problem is addressing an issue that I fundamentally don't
>> get. My critique above still stands, which I why I am still advocating my
>> code, but it could be that with a couple tweaks, your code could address
>> those issues as well.
>
> My criticism centers on
>
> + if ((pressure[UP] > 0) && (pressure[DOWN] > 0))
> +{
> + warning ("Cannot resolve beam collision.");
> + return posns;
> +}
>
> ie. if you are dealing with polyphonic music, where the middle voice
> will have notes under and over it, your technique does not work.
>
I don't think that bit of code does what you think it does.
From my technique:
<>
That's the best I can do in polyphonic stuff. I think it addresses your
concern.
> That said, there may be place for both techniques: if you could detect
> that a note+stem is pushing the beam far out of its original position,
> you could add an offset. This offset adding code could be very dumb,
> because the fine points of finding the best solution will be handled
> by the beam quanting anyway.
I completely agree - I feel that my solution does exactly this (adds a general
offset that is fine tuned in the quants). Read it over again if you get the
chance - do you think that it adequately addresses the polyphonic concern you
have?
>
>> Cheers,
>> MS
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> I only received 2 pdf files, was that intentional?
>
> --
> Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: issue 4174043 ready for review
On Thu, Feb 10, 2011 at 9:54 AM, m...@apollinemike.com
wrote:
> I think that the problem with doing the collision avoidance in the quanting
> reveals itself around line 341 of beam-quanting.cc
> if (collisions_.size ())
> region_size += 2;
> Here, I get the sense that you are expanding the region size of the quanting
> if there is the possibility of collision. I feel that this will actually
> work against the goal that you had previously set: namely, to avoid
> unnecessary quants if possible. By moving the beam out of the collision
On the contrary: avoiding unnecessary quants for normal cases makes it
possible for us to use brute force on exceptional situations like by
knees of collisions.
> region before the quanting (in beam.cc, for example), which would do similar
> stuff to that which you have written around line 151, you would eliminate
> having to expand the region size and you'd be able to catch problems that
> your code doesn't currently catch. That said, your code does catch a great
> deal of stuff - I ran 10 or so tests against the algorithm and not many of
> them diverged (those that did are attached, prefixed ms or mike for me and
> hw for you).
I only see one page in both pdfs? If you can send me code as .ly, I
can add them to the my regtest, to have more cases.
> However, those that did diverge do come up in actual rep -
> what worries me is that your code (as I understand it) cannot, by virtue of
> how its made, catch several examples from the contemporary repertoire that I
> threw up on that website (notably the Boulez and Crumb) without increasing
I don't see anything by Crumb. The boulez example is actually a
straight flag (left), and a beam with normal stem on the left.
> the region size to something very large.
> I still advocate the solution in http://codereview.appspot.com/4131044 for
> all the reasons I mention above: I feel that it actually takes less time by
> never expanding the region size and can catch more results.
> Mostly, I think that having two developers doing more or less the same thing
> is a potential waste of time. My understanding of Lilypond is many orders
> of magnitude inferior to yours, and I assumed (and am still assuming) that
> your work on this problem is addressing an issue that I fundamentally don't
> get. My critique above still stands, which I why I am still advocating my
> code, but it could be that with a couple tweaks, your code could address
> those issues as well.
My criticism centers on
+ if ((pressure[UP] > 0) && (pressure[DOWN] > 0))
+{
+ warning ("Cannot resolve beam collision.");
+ return posns;
+}
ie. if you are dealing with polyphonic music, where the middle voice
will have notes under and over it, your technique does not work.
That said, there may be place for both techniques: if you could detect
that a note+stem is pushing the beam far out of its original position,
you could add an offset. This offset adding code could be very dumb,
because the fine points of finding the best solution will be handled
by the beam quanting anyway.
> Cheers,
> MS
>
>
>
>
>
>
>
>
>
>
I only received 2 pdf files, was that intentional?
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision scoring (issue4174043)
> The problem is that this requires another layer of code. The
> collision code works for beams individually. For this to be
> resolved like this, there needs to be coordination between the two
> beams. This is much harder, because many such collisions may be
> chained together, eg.
>
> <<
>{ s8 c[ c] c[ c] s8 } \\
>{ c[ c] c[ c] c[ ] }
> >>
Hmm. What about adding some commands to restrict such collosion
resolution horizontally? I'm quite sure that most of the problems are
local, and the user knows in advance where it happens so that it can
be tagged with, say, \startFullBeamCollisionHandling and
\stopFullBeamCollisionHandling.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision scoring (issue4174043)
2011/2/10 Werner LEMBERG :
>
>> I tried this patch on half a dozen piano and orchestral scores and
>> saw no bad side-effects.
>
> The attached image (from
> IMSLP00014-Beethoven__L.v._-_Piano_Sonata_14.pdf) shows another
> solution �#| smaller beams �#| to avoid the crossing of beams and stems.
> Maybe this can be implemented too?
The problem is that this requires another layer of code. The
collision code works for beams individually. For this to be resolved
like this, there needs to be coordination between the two beams.
This is much harder, because many such collisions may be chained
together, eg.
<<
{ s8 c[ c] c[ c] s8 } \\
{ c[ c] c[ c] c[ ] }
>>
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
404 for renamed css stylesheets
Hello, Still some references left to the old lilypond-mccarty.css file: python/auxiliar/postprocess_html.py , line 154 which cause not_found errors in our website. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Beam collision engraver in lilypond
"m...@apollinemike.com" writes: > I like the tunable idea. > > Perhaps a grob property named `avoids' that is a list of pairs, kinda like: > > '((bar-line . #t) (time-signature . #f) (note-head . #t)) etc... > > Then, we could use has_interface to weed out grobs for which we don't > want to collision detect. > > As to your question: in scores by Ligeti, Bartok, and Schoenberg, and > Xenakis, bar lines are not avoided. I cannot come up with an example > off the top of my head where bar lines are avoided. I should think that the problem with avoiding a bar line would be that if you have a continuous off-beat grouping, it would add a visual accentuation to those beams that are trying to avoid the bar line. Since one point of off-beat groupings is to basically _ignore_ the bar line in execution, singling out the cross-bar beams visually is not likely to help the performer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
