Re: Issue 1320: Rewriting bar-line::print
Am 21.03.2012 11:43, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: Anyway, I don't get the case statement right - am I too stupid? Stupid enough to follow my advice without checking the manual first (or afterwards). Looking in the Guile manual, it turns out that case uses eqv? for checking equality. guile (eqv? x x) #f guile So you need to revert to cond here and use string=. Or employ assoc in some form. Ok, thanks – I'll use cond. Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Rewriting bar-line::print
Am 21.03.2012 21:39, schrieb Nicolas Sceaux: Le 20 mars 2012 à 09:39, Marc Hohl a écrit : Hello list, I want to rewrite most if not all definitions currently settled in lily/bar-line.cc in scheme. Please see the attached file for my progress so far; I don't get any error messages, but no bar lines either :-( Is this a feasible approach? What am I currently doing wrong? I've done something like that, to create baroque repeat bars, and suggested repeat bars: https://github.com/nsceaux/nenuvar/blob/master/common/custom-bars.ily That's great stuff! Thanks for the link – now the whole stuff becomes clearer again. Regards, Marc Nicolas ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vertical spacing - skyline integrals
On Wed, Mar 21, 2012 at 11:31 PM, Werner LEMBERG w...@gnu.org wrote: Looks right: The area between horizontal skylines should influence the spacing. However, I think we need a parameter to adjust the amount of influence. I'm not sure what you mean. I mean that some people probably want a more rigid spacing, only slightly influenced by the area inbetween. This is a matter of taste [...] I would like to have an additional parameter, say, system-system-spacing #'rigidity = X where X is a number between 0 and 1. Value 1 essentially means no skyline integrals, while value 0 exactly the opposite. Maybe. We'll see when there is some working code. I'd like to have as few parameters as possible, to make things simpler (within reason). I've identified two potential problems that may appear, and ideas for solutions: www.anonstorage.net/PStorage/621.skyline-integrals-teeth-marked.pdf www.anonstorage.net/PStorage/328.integrals-pitfall-two-marked.pdf A possible solution is to `dampen' the skyline for the area computation, this is, to apply the beam logic to the skyline. For example, this -- | | | | - becomes this: - \ \ \ \ That's what i meant (for the first problem). thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vertical spacing - skyline integrals
On Mar 22, 2012, at 9:05 AM, Janek Warchoł wrote: On Wed, Mar 21, 2012 at 11:31 PM, Werner LEMBERG w...@gnu.org wrote: Looks right: The area between horizontal skylines should influence the spacing. However, I think we need a parameter to adjust the amount of influence. I'm not sure what you mean. I mean that some people probably want a more rigid spacing, only slightly influenced by the area inbetween. This is a matter of taste [...] I would like to have an additional parameter, say, system-system-spacing #'rigidity = X where X is a number between 0 and 1. Value 1 essentially means no skyline integrals, while value 0 exactly the opposite. Maybe. We'll see when there is some working code. I'd like to have as few parameters as possible, to make things simpler (within reason). On that subject - Joe has a good API model in place and I have written the bulk of the code that eventually uses it - we've been back and forth a bit on details of the implementation but the ideas are more or less in place. I'll give you the heads up once we have something that works! Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vertical spacing - skyline integrals
On Thu, Mar 22, 2012 at 9:38 AM, m...@apollinemike.com m...@apollinemike.com wrote: On that subject - Joe has a good API model in place and I have written the bulk of the code that eventually uses it - we've been back and forth a bit on details of the implementation but the ideas are more or less in place. I'll give you the heads up once we have something that works! Great, thanks! Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't reload initialization files when processing multiple files (issue 5874044)
Reviewers: Graham Percival, Message: On 2012/03/22 03:43:47, Graham Percival wrote: This feels like a dangerous change. Obviously we don't /want/ bleed-through of parameters or memory from one file to the next, but I would be shocked if we don't have any of that right now. Don't overestimate the issue. What is involved here is bleedthrough from init.ly, namely from one parser incarnation to the next. Any bleedthrough in scm is left unchanged. It turns out that git grep hash ly appears surprisingly sufficient for diagnosing the bleedthrough we are actually seeing. Bleedthrough is from destructively changed data. That means hashtables need to be either unchanged by user code, or reset each time. The same holds for everything else of course, like destructively modified alists and output definitions and what else. But there is a rather surprising absence of those. We'll just get reports dribbling in over a few weeks. I doubt it. The only situation where bugs can show is when multiple files are being compiled at once. That is not the usual command line usage. So reports can be basically about a) documentation differences b) problems with lilypond-book documents I doubt we'll get to see anything outside of lilypond-book usage. Note that we already have bleedthrough potential in .scm (which we apparently managed to keep under control). My original plan was to split the various init files into parts that need to be rerun every time, and parts that can be preloaded once. But it turned out that the need to be rerun stuff basically concerned output definitions, and cloning them looked feasible. Description: Don't reload initialization files when processing multiple files There should probably be something approaching an option for that. It should mostly speed up the regtests. It helps make doc less than expected, but probably still some. Please review this at http://codereview.appspot.com/5874044/ Affected files: ly/init.ly scm/lily.scm Index: ly/init.ly diff --git a/ly/init.ly b/ly/init.ly index 6546ed422aa676bffd633bacf013b9c8e7086e9b..7a49103b476208a48bd7e2931827b343da286465 100644 --- a/ly/init.ly +++ b/ly/init.ly @@ -6,8 +6,42 @@ \version 2.15.18 -\include declarations-init.ly +#(if (not (pair? lilypond-declarations)) + (ly:parser-include-string parser + \\include \declarations-init.ly\)) +%% We need to save the variables of the current module along with +%% their values: functions defined in the module might refer to the +%% variables + +#(if lilypond-declarations + (if (pair? lilypond-declarations) +(begin + (for-each + (lambda (p) + (let ((var (cadr p)) + (val (cddr p))) + (variable-set! var + (if (ly:output-def? val) + (ly:output-def-clone val) + val)) + (module-add! (current-module) (car p) var))) + lilypond-declarations) + (note-names-language parser default-language) + (use-modules (srfi srfi-1))) +(module-for-each + (lambda (s v) + (let ((val (variable-ref v))) + (if (not (ly:lily-parser? val)) + (set! lilypond-declarations + (cons +(cons* + s v + (if (ly:output-def? val) + (ly:output-def-clone val) + val)) +lilypond-declarations) + (current-module #(ly:set-option 'old-relative #f) #(define toplevel-scores (list)) Index: scm/lily.scm diff --git a/scm/lily.scm b/scm/lily.scm index 0c20c148b20a5ec56066379eaee887eeab20bf8b..64c403b0749432e55df286cae181876a3a1cebde 100644 --- a/scm/lily.scm +++ b/scm/lily.scm @@ -845,6 +845,8 @@ PIDs or the number of the process. (dump-profile lily-run-total '(0 0) (profile-measurements))) failed)) +(define-public lilypond-declarations '()) + (define (lilypond-file handler file-name) (catch 'ly-file-failed (lambda () (ly:parse-file file-name)) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: vertical spacing - skyline integrals
On 22 March 2012 09:05, Janek Warchoł janek.lilyp...@gmail.com wrote: www.anonstorage.net/PStorage/621.skyline-integrals-teeth-marked.pdf I like this one - sounds for me like a good solution :) Łukasz ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatic beaming in melismas
2012/3/22 Janek Warchoł janek.lilyp...@gmail.com: The current behavior is bad, because it mixes two different things: melismas themselves and how they are represented. If i use either slurs or manual beams for melismas, i'm hardcoding some redundant (or at least partially redundant) information into my source file. For example, if i specify melismas using either slurs or manual beaming, i cannot easily make an automatic keyboard reduction using previously entered vocal variables, or change melisma representation to other style. What i suggest would be quite the opposite: every melisma should be indicated using a melisma command, and *then* user can decide how he wants melismas to look like: should every melisma be automatically marked with a slur, or a dotted slur, or should beaming be used for it, or something different (or nothing at all). For (specifically) vocal scores, slurs are not redundant to indicate melismas. Melismas are indicated in the score by slurls, so slur equals melisma. It is also very convenient to type. We are talking about modern-style vocal music. But I agree on it would be good to separate both so to ease reusing of that music in other contexts. Of course, a shorter (preferably one-character) command name should be chosen. \melisma and \melismaEnd is too much typing. It is standard policy of lilypond's syntax to have meaningful names for commands and you can always define your shorter commands. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatic beaming in melismas
On Thu, Mar 22, 2012 at 12:37 PM, Francisco Vila paconet@gmail.com wrote: 2012/3/22 Janek Warchoł janek.lilyp...@gmail.com: What i suggest would be quite the opposite: every melisma should be indicated using a melisma command, and *then* user can decide how he wants melismas to look like: should every melisma be automatically marked with a slur, or a dotted slur, or should beaming be used for it, or something different (or nothing at all). For (specifically) vocal scores, slurs are not redundant to indicate melismas. Melismas are indicated in the score by slurls, so slur equals melisma. Not always. Sometimes they're also used for portamento between syllabes. But I agree on it would be good to separate both so to ease reusing of that music in other contexts. Glad that we agree here. Also, one all-purpose melisma command would be simpler to understand for users. Of course, a shorter (preferably one-character) command name should be chosen. \melisma and \melismaEnd is too much typing. It is standard policy of lilypond's syntax to have meaningful names for commands and you can always define your shorter commands. well, we don't have a \slur and \slurEnd commands. Aslo, melismas appear so often that i think the syntax should be standarized. But i'm not at all against having both full name and shortcut, similarly to -\staccato and -. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatic beaming in melismas
2012/3/22 Janek Warchoł janek.lilyp...@gmail.com: well, we don't have a \slur and \slurEnd commands. Aslo, melismas appear so often that i think the syntax should be standarized. But i'm not at all against having both full name and shortcut, similarly to -\staccato and -. Totally agreed. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regular patchy staging
A bit late answer, sorry... On Sat, Mar 3, 2012 at 2:58 PM, Graham Percival gra...@percival-music.ca wrote: On Sat, Mar 03, 2012 at 09:56:33AM +0100, Janek Warchoł wrote: GrahamDavid, when i said that i'd like to make Patchy more user-friendly i meant to make it so straightforward that these questions wouldn't have been asked. Have you read http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ? Janek, tell me exactly which step in that process is unclear. Making vague claims of it should be more user-friendly does not help. There's nothing unclear in that process. I just think that all this could be automated (turned into one step run this command), and i'll gladly do this automation - when i have some time (estimated date: summer). sorry for not being more helpful, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrected style of comments (issue 5862052)
Are the changes to .gitignore intentional? http://codereview.appspot.com/5862052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatic beaming in melismas
Le 22/03/2012 20:20, Jean-Charles Malahieude disait :
Le 22/03/2012 20:08, David Kastrup disait :
Jean-Charles Malahieudelily...@orange.fr writes:
The main problem in this case, in my opinion, is that you can't even
build a shortcut for combining melisma and autobeaming, since beaming
is *prefix* and melisma *postfix*.
Beaming is prefix?
just tried :
mbY = { \autoBeamOn \melisma } % melisma beaming = Yes
mbN = { \melismaEnd \autoBeamOff } % melisma beaming = No
\score {
\new Staff
\set Staff.autoBeaming = ##f
\new Voice = melody \relative c' {
\time 3/4
f4 g8 \mbY f e f\mbN
\autoBeamOn e8( d \autoBeamOff e2)
}
\new Lyrics \lyricsto melody {
One -- two -- three __ }
}
oops! too fast
I mean in fact that it would be more useful to have \melisma behave like
\autoBeamOn: there will now will happen a melisma
Cheers,
Jean-Charles
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)
On Wed, Mar 21, 2012 at 9:37 AM, Julien Rioux julien.ri...@gmail.com wrote: On Wed, Mar 21, 2012 at 1:39 AM, joenee...@gmail.com wrote: http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py File scripts/lilypond-book.py (right): http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639 scripts/lilypond-book.py:639: global_options.include_path.insert (0, inverse_relpath (original_dir, global_options.output_dir)) Wouldn't it be easier if you just added the absolute path to original_dir? It would be easier, but I think the proposed patch is a better implementation. Using absolute paths makes the document less portable and prone to errors caused by any weird characters that a user might have in the names of parent directories. Absolute paths also didn't play well with lilypond on Windows (see http://code.google.com/p/lilypond/issues/detail?id=2209 ). While I didn't test the suggested patch on Windows yet, I will do so very soon. Regards, Julien http://codereview.appspot.com/5846075/ So after some testing, this looks good with python on windows, too. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Automatic beaming in melismas
On Thu, Mar 22, 2012 at 8:03 PM, Jean-Charles Malahieude lily...@orange.fr wrote: Le 22/03/2012 13:00, Janek Warchoł disait : On Thu, Mar 22, 2012 at 12:37 PM, Francisco Vila wrote: Melismas are indicated in the score by slurs, so slur equals melisma. Not always. Sometimes they're also used for portamento between syllabes. I then use a phrasing slur: a4\( \melisma b8 c\) \melismaEnd I did that, too. But sooner or later you'll stumble upon a piece where both portamento slur and phrasing slur happen simultaneously. Sure, there are workarounds - but what we need is a semantically correct solution, not a workaround. Using logical and structurally correct solutions is one of the most important advantages of LilyPond. On Thu, Mar 22, 2012 at 8:08 PM, David Kastrup d...@gnu.org wrote: Jean-Charles Malahieude lily...@orange.fr writes: The main problem in this case, in my opinion, is that you can't even build a shortcut for combining melisma and autobeaming, since beaming is *prefix* and melisma *postfix*. Beaming is prefix? manual beaming is of course postfix, but what we need here is \autoBeamOn/Off, and that isn't a postevent. (we need autobeaming, because in long melismas notes aren't beamed all together. In long melismas notes are beamed almost like they would be done using autobeaming). cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
casual contributors (was: patch going unpushed)
On Fri, Mar 23, 2012 at 08:18:26AM +1100, Peter Chubb wrote: Hi Graham, Graham We don't really have a frog meister, so nobody is taking Graham responsibility for pushing I have another patch waiting, that depends on the first. Is there supposed to be a procedure for casual contributers to follow? No. If that sounds scary, then you have the right reaction. Or rather -- yes, there *is* a procedure. You're supposed to show up, then the frog meister should contact you with any details you missed (such as using our git-cl). Then you're supposed to upload a patch, and the frog meister should keep track of your patch and take care of all the details. But since we don't have a frog meister, this falls down. So yes, you've been doing everything right. We simply don't have anybody who is willing to do ~30 minutes of admin work per week to help casual contributors. (and for the record: no, I am not willing to do that role. I know that I'm the expert on this subject, having mentored over 20 people in lilypond in the past, but I am not at willing to do that job right now) The other open-source projects (QEMU, Linux Kernel, uClinux) I contribute to set up a Maintainer for each subsystem, and patches are submitted to that person to get pushed. In lilypond development, the frog meister is our name for maintainer. But without somebody willing to do that job, we're SOL. I don't really want to get much more involved in LilyPond than I am already --- I'm involved in two other open source projects (QEMU and Linux Kernel at present) that take up most of my (little) free time. --- but if you wanted to give me commit access, I could undertake to maintain articulate. Quite understandable. I'll probably give you push access in a few weeks, but that won't solve the general problem faced by casual contributors. To be frank, I'm using you to highlight this problem. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: casual contributors (was: patch going unpushed)
Hello On 22 March 2012 23:37, Graham Percival gra...@percival-music.ca wrote: On Fri, Mar 23, 2012 at 08:18:26AM +1100, Peter Chubb wrote: Hi Graham, Graham We don't really have a frog meister, so nobody is taking Graham responsibility for pushing I have another patch waiting, that depends on the first. https://lists.gnu.org/mailman/listinfo/lilypond-devel I've offered to shepherd this new patch. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: casual contributors (was: patch going unpushed)
On Thu, Mar 22, 2012 at 11:40:43PM +, James wrote: Graham We don't really have a frog meister, so nobody is taking Graham responsibility for pushing I have another patch waiting, that depends on the first. https://lists.gnu.org/mailman/listinfo/lilypond-devel I've offered to shepherd this new patch. That doesn't solve the general problem, though. I mean, ok. Peter is now taken care of. James is Peter's mentor in lilypond terms [1]. But what happens when the next casual contributor comes along, and we all stand around whistling with our hands in our back pockets? We should have somebody who takes care of contributors without dedicated mentors. In mathematical/logical terms, we need a barber who shaves everybody who does not shave themselves. I shouldn't need to get involved when there's a new contributor, much less a known+experienced contributor like Peter! [1] http://lilypond.org/doc/v2.15/Documentation/contributor/mentors - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)
I'm seeing old chunk mismatch for this patch. Could you try uploading it again to a new rietveld issue? http://codereview.appspot.com/5846075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120325
For 20:00 MST Sunday March 24 Critical: Issue 2272 http://code.google.com/p/lilypond/issues/detail?id=2272: Long monosyllabic words collide with barlines - R5843063 http://codereview.appspot.com/5843063/ Enhancement: Issue 2310 http://code.google.com/p/lilypond/issues/detail?id=2310: Patch: some comments and complaints on the code - R5862052 http://codereview.appspot.com/5862052/ Issue 2425 http://code.google.com/p/lilypond/issues/detail?id=2425: Patch: Don't reload initialization files when processing multiple files - R5874044 http://codereview.appspot.com/5874044/ Maintainability: Issue 2412 http://code.google.com/p/lilypond/issues/detail?id=2412: Online website uses old /web/about/browser-language location - R5870043 http://codereview.appspot.com/5870043/ Other: Issue 1690 http://code.google.com/p/lilypond/issues/detail?id=1690: old announcements+changes on website - R5843069 http://codereview.appspot.com/5843069/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't reload initialization files when processing multiple files (issue 5874044)
On 2012/03/22 09:14:34, dak wrote: Don't overestimate the issue. What is involved here is bleedthrough from init.ly, namely from one parser incarnation to the next. Any bleedthrough in scm is left unchanged. ah, I misunderstood that part. Ok, in that case I feel much better about the patch. :) http://codereview.appspot.com/5874044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A new home for browser-language (issue 2412). (issue 5870043)
LGTM. Somebody might complain that the translations of misc/ should go in their respective directories, but I think that's overkill, and I'd really like to get this patch in. Removing old /web/ is finally within reach! :) http://codereview.appspot.com/5870043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracks old announcements, news and changelogs. (issue 5843069)
Awesome work as always. There's some unintended (and bad) changes to GNUmakefile.in. It's also missing the changelog and announcement for 2.14, but that can get added in a different patch. The important thing is to get this infrastructure pushed. http://codereview.appspot.com/5843069/diff/8001/GNUmakefile.in File GNUmakefile.in (right): http://codereview.appspot.com/5843069/diff/8001/GNUmakefile.in#newcode287 GNUmakefile.in:287: test-baseline: You didn't mean to remove these lines. http://codereview.appspot.com/5843069/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
