Re: Fixes position of mensural c clef (issue 6503091)
I think some of the confusion could be avoided by running all mf files through expand(1). This is a good idea, and I will do so after Phil has done his work. I'm really bewildered that it is apparently so hard for many contributors to format and indent new code in the same manner as the surrounding code. Is this lack of experience? Is this ignorance? Is it arrogance? I would rather keep this neutral from any accusation of ignorance or arrogance -- in *both* directions. I could easily argue it either way. Certainly. Note that I don't *accuse* anyone, especially not Phil. I'm grateful that he's working on the code, but I'm really astonished about his replies. 1. reject any offers of help from contributors who do not follow the existing formatting. 2. educate each contributor individually, go through multiple rounds of each patch to adjust the formatting, etc. 3. use an automatic formatting tool. 4. combine 2 and 3: use an automatic formatting tool for most of the code style, but still require some additional manual formatting (and go through a few rounds of reviews if necessary). I favor either 3 or 4; we are not in a position to be gratuitously rejecting patches, and having finicky manual formatting will discourage some contributors. I fully agree. Since we have no support for (3) yet, I will do a bit of (2), and I really hope that Phil can bear with me :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)
On Fri, 07 Sep 2012 09:23:08 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: On 7 sept. 2012, at 09:34, k-ohara5...@oco.net wrote: Having the invisible Grobs taking up space will confuse the innocent. I tried to add comments about this in the source - perhaps the CG needs an invisible grob bit, as we have StemStubs and SpanBarStubs as well. People who have read the source code and contributors guide are not the innocent. In measure 36 of my example, it seems I used a text script for custom fingering placement. That 4 moves to avoid the SlurStub. (How would you put it back where it belongs, as a user? ) \override TextScript #'avoid-slur = #'inside But, looking at the output, the 4 is /already/ inside the slur, so why would anybody think to try that? These invisible grobs pushing things around would cause confusion in released code. http://codereview.appspot.com/6498077/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
release 2.16.1
Can you announce here the release of 2.16.1 at least a week before the actual release? So translators will have time to complete their works. I have a patch which will be ready next week and I hope it won't miss next stable release. Thanks -- Federico ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: release 2.16.1
Federico Bruni fedel...@gmail.com writes: Can you announce here the release of 2.16.1 at least a week before the actual release? So translators will have time to complete their works. I have a patch which will be ready next week and I hope it won't miss next stable release. No danger. By far the most important regressions requiring a release of 2.16.1 are the line_count fixes, and those have not been completed and have not seen exposure in an unstable release yet. I don't see the point in releasing 2.16.1 without them, so there are still at least several weeks of buffer. In the mean time, I am investigating garbage collection problems: the needs-work problems of issue 2815 URL:http://code.google.com/p/lilypond/issues/detail?id=2815 point to parts of the parse stack keeping marked objects around after their proper logical demise, possibly in areas allocated with alloca and considered released by Bison's parse stack management: this might have always been the case, or be related to other fixes I want to cherry-pick because of performance reasons, but the patch in 2815 might exacerbate it. We also have no clue about the GhostScript-related problems, but it does not appear like there is active work going on, so that is, somewhat unfortunately, not something considered delaying 2.16.1. So the collection and selection of patches into the stable branch is proceeding quite leisurely at the current point of time. I don't expect a release of 2.16.1 before end of September. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)
On 2012/09/06 23:24:04, Ian Hulin (gmail) wrote: On 2012/09/06 18:07:53, dak wrote: When we go Guilev2, we don't want to search for all the backward compatibility. So I'd say you use something like #if GUILEV1 for splicing in the compatibility stuff, and define it as either 0 or 1 in lily-guile.hh, depending on the conditional you use here. Once we decide to go Guilev2 proper, we rip out the definition in lily-guile.hh, and all uses of GUILEV1 will bomb out. That way we at least don't overlook the compatibility crutches. Nice idea, but probably better to define the macro in guile-compatibility.hh, which lily-guile.hh pulls in. I can then use as complementary GUILEV2 macro which will be needed for the Guile V2-specific bits in main.cc. Sounds like a plan. I guess neither of us are fond of the old use of undocumented (and by now deprecated, as opposed to module-variable) internal Guile functions. We disagree about what to replace it with: I would use the Scheme functions, saving the need for distinguishing Guilev1/Guilev2, you want to use the C functions and keep different versions for Guilev1 and Guilev2. If you implement the compatibility in the manner I propose (with your modification), we are sure that the ugly code does not stick around after going Guilev2-only. So that's ok with me as well. Having the GUILEv1 macro temporarily defined will also help the transition elsewhere, and we should probably also use a similar strategy at the Scheme level. http://codereview.appspot.com/6458159/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Heinrich Ignaz Franz Biber
Folks, due to the discussion about funny accidental placements in music written for strings with scordatura, I had a closer look at the Rosary Sonatas from Biber. As a result, I'm playing the 14th sonata with my daughter in a concert[1], among other pieces :-) In case you like baroque music which sounds like Irish folk tunes, you might listen to this nice recording: http://www.youtube.com/watch?v=O2vZPX9oTr0 Werner [1] Sept. 30th, 17:00, Lutherkirche Hörde, Dortmund ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
On 08/09/12 10:17, Werner LEMBERG wrote: due to the discussion about funny accidental placements in music written for strings with scordatura, I had a closer look at the Rosary Sonatas from Biber. As a result, I'm playing the 14th sonata with my daughter in a concert[1], among other pieces :-) Wonderful, wonderful music. Very best wishes for your concert. :-) Actually, it's been in the back of my head for a while that those pieces could be a great demo for Lilypond, particularly in respect of being able to generate both written and sounding-pitched parts for violin from the same material without any stupid tricks. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes position of mensural c clef (issue 6503091)
A quick note to Werner. 1) apologies for being rather brusque, but I'd pretty much killed my self getting this sorted - the original code had some very odd calculation methods in it, and it's the first time I'd ever touched metafont. Your follow up is helpful - please ignore my recent comment on Google - I'm minus a monitor at present and working on a little used laptop and don't have mail at present, so I'm not working linearly in time. I'll look at changing the lengths - I was aware of a slight difference, although actually I'm not certain it's that important - these are machine drawn glyphs intending to replicate hand-drawn clefs from the 15th century. How important is 0.1 staff space? As for the indents, I now understand what you're saying. I use Gedit and by default for mf files it puts tabs at 4 spaces, and so the indenting looked completely awry. IMHO mixing tabs and spaces is a really bad idea for that reason - different editors indent different ways. I just tidied a few of the more obvious ones near my code, but will get rid of those once I have a working monitor. As for the overlaps. Ditto I'll look at that. The original code calculated end points in a very odd way - it allowed, for example, of different amounts of shift between the breves, and then ignored that in the calculation of the decorations. I'll see if I can improve this. http://codereview.appspot.com/6503091/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Development releases
It was my plan to try to do a development release about every 2 weeks - running on a Sunday. This Sunday would have been the first. However, my large screen monitor has just died and I've nicked the one from my wife's computer, and as a result I'm on a very much smaller desktop that I'm used to. I do realise that Unix started on 80 characters, but I'd prefer my normal environment to do stuff (i.e. Gub compile and upload) with which I'm not too familiar - I like to have loads of space to type in one window while reading the CG in another. Therefore, unless there are screams of pain - the next release (2.17.2) will be next Sunday, the 16th (or will possibly start on the 15th). -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Solving Issue 185 RhythmicStaff squishing chords should produce single notes
This is a follow-up on a discussion from the issue tracker comments at http://code.google.com/p/lilypond/issues/detail?id=185, where I suggested a kludgy fix for a favorite LilyPond pet peeve of mine. I am interested in making it less kludgy. As I am new to the LilyPond codebase, please bear with some ignorance. Some context: My original proposal http://codereview.appspot.com/6495107 Make RhythmicStaff show single notes for chords (issue 185) RhythmicStaff uses Pitch_squash_engraver to move all note heads to a common vertical position. With chords, at least two problems arise: (1) As all notes from one chord collide now, so some of them used to be moved aside. Hence, for each chord, two adjacent note heads would appear in the output. (2) For chords with dotted duration, Dot_column_engraver would put one dot per note head into a DotColumn, where they would be spaced apart. So for every note in the chord, one separate dot would be visible. Solve (1) by explicitly setting X-offset to 0 for squashed note heads in the Pitch_squash_engraver. Solve (2) by replacing Dot_column_engraver with a new Squashed_dot_column_engraver. This variant puts only at most one dot per time step onto a DotColumn, and marks any further ones as transparent. * d...@gnu.org comprehensibly suggested instead: Wouldn't it make sense to let the Pitch_squash_engraver suicide all duplicate grobs at a time step? It would actually be even better if it could just kill the respective events before other engravers even get to see them. Also it would seem that only duplicates in the same Voice should be squashed. and later Maybe we need an engraver listening to Stems and shooting all NoteHeads except the first per stem. This should take place before collision resolution. but I fail to find an exploitable connection between stems and chords. As far as I understand, Stems are grouped with note heads into NoteColumns by Rhythmic_column_engraver only, which operates at Voice level, hence too late. Judging from this engraver, it looks to me like one could implement a Chord_thinout_engraver at Voice level simply by acknowledging rhythmic_heads and killing all but the first per timestep. But I need this functionality at Staff level. (One could include such an engraver into all Voice contexts, but trigger it with a Staff-level property. Sounds kludgy again.) So far, the most viable route to me seems to make use of this ...an acknowledger is called not just with a grob but also with the originating engraver instance announcing the grob, and so one can indeed figure out the originating context of an announcement _if_ the grob is produced from a Voice-level engraver instance. to write a Staff-level Chord_thinout_engraver that still works per voice. Is that the way to go? Other ideas? Best regards, Johannes Rohrer ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote: There's one thing worth clarifying: when i say syntax changes, i mean changes in how user input looks like. So a renaming of a command is a syntax change to me (despite the fact that no grammar rules change). That's probably confusing - what word should i use when i mean changes in how user input looks like? No idea. What we have under the umbrella of syntax discussion contains three things: lexical units, grammar and vocabulary, mostly implemented in lexer.ll, parser.yy, and *.ly respectively. In order to keep syntax predictable, we want to be able to solve most problems just by extending the vocabulary. That means that lexical units and grammar should be as generic, powerful, and simple as possible. Specialized lexical modes take power from the vocabulary. We want to avoid them as much as possible given our historic constraints. I completely agree with this. I have been giving some people a hard time in this discussion, but that is primarily for wanting to mess with either lexer.ll or parser.yy. As long as you don't that, I will not object fiercely to what syntax proposal anyone comes up with. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
Actually, it's been in the back of my head for a while that those pieces could be a great demo for Lilypond, particularly in respect of being able to generate both written and sounding-pitched parts for violin from the same material without any stupid tricks. Indeed, typesetting the first few bars of one of the Biber sonatas, together with correct MIDI output, would yield a very nice example. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
Han-Wen Nienhuys hanw...@gmail.com writes: On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote: There's one thing worth clarifying: when i say syntax changes, i mean changes in how user input looks like. So a renaming of a command is a syntax change to me (despite the fact that no grammar rules change). That's probably confusing - what word should i use when i mean changes in how user input looks like? No idea. What we have under the umbrella of syntax discussion contains three things: lexical units, grammar and vocabulary, mostly implemented in lexer.ll, parser.yy, and *.ly respectively. In order to keep syntax predictable, we want to be able to solve most problems just by extending the vocabulary. That means that lexical units and grammar should be as generic, powerful, and simple as possible. Specialized lexical modes take power from the vocabulary. We want to avoid them as much as possible given our historic constraints. I completely agree with this. I have been giving some people a hard time in this discussion, but that is primarily for wanting to mess with either lexer.ll or parser.yy. As long as you don't that, I will not object fiercely to what syntax proposal anyone comes up with. Actually, is there a particular reason we are generating a C parser rather than a C++ parser? The implications regarding marking and garbage collection of semantic values are rather awful. Probably historic because Bison did not use to come with C++ skeleton files? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
Werner LEMBERG w...@gnu.org writes: Actually, it's been in the back of my head for a while that those pieces could be a great demo for Lilypond, particularly in respect of being able to generate both written and sounding-pitched parts for violin from the same material without any stupid tricks. Indeed, typesetting the first few bars of one of the Biber sonatas, together with correct MIDI output, would yield a very nice example. Three staffs: true pitch, scordatura, tablature. Entry would be presumably in true pitch plus string number (where not in lowest terms). -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss (was: modern-straight-flag)
On Thu, Sep 6, 2012 at 7:28 AM, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: Has anyone ever actually engaged with any major publishers to identify the factors that are of interest to them in engraving software, and the features that Lilypond would have to implement in order to meet their requirements? I have in the past talked with people from Henle; also, Schirmer has a style guide that you can order as a book. My overall impression is that they are primarily interested in: * Strict adherence to their publisher style * Delivering printed parts on a low budget. Once the edition is printed, there is little reason to keep the files around, and in some cases (due to editing PS output), it's not useful at all. Music publishers (at least a few years ago) are still very much focused on putting ink on dead trees in large quantities in the most uniform and cost-efficient way possible, a business model which makes ever less sense in the digital age. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
On Sat, Sep 8, 2012 at 12:00 PM, David Kastrup d...@gnu.org wrote: Han-Wen Nienhuys hanw...@gmail.com writes: On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote: There's one thing worth clarifying: when i say syntax changes, i mean changes in how user input looks like. So a renaming of a command is a syntax change to me (despite the fact that no grammar rules change). That's probably confusing - what word should i use when i mean changes in how user input looks like? No idea. What we have under the umbrella of syntax discussion contains three things: lexical units, grammar and vocabulary, mostly implemented in lexer.ll, parser.yy, and *.ly respectively. In order to keep syntax predictable, we want to be able to solve most problems just by extending the vocabulary. That means that lexical units and grammar should be as generic, powerful, and simple as possible. Specialized lexical modes take power from the vocabulary. We want to avoid them as much as possible given our historic constraints. I completely agree with this. I have been giving some people a hard time in this discussion, but that is primarily for wanting to mess with either lexer.ll or parser.yy. As long as you don't that, I will not object fiercely to what syntax proposal anyone comes up with. Actually, is there a particular reason we are generating a C parser rather than a C++ parser? The implications regarding marking and garbage collection of semantic values are rather awful. Right; all that should go away with guile v2 though, which uses Boehm GC Probably historic because Bison did not use to come with C++ skeleton files? Correct. The best we had was the pure_parser option. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
Han-Wen Nienhuys hanw...@gmail.com writes: On Sat, Sep 8, 2012 at 12:00 PM, David Kastrup d...@gnu.org wrote: Han-Wen Nienhuys hanw...@gmail.com writes: On Fri, Sep 7, 2012 at 4:42 AM, David Kastrup d...@gnu.org wrote: There's one thing worth clarifying: when i say syntax changes, i mean changes in how user input looks like. So a renaming of a command is a syntax change to me (despite the fact that no grammar rules change). That's probably confusing - what word should i use when i mean changes in how user input looks like? No idea. What we have under the umbrella of syntax discussion contains three things: lexical units, grammar and vocabulary, mostly implemented in lexer.ll, parser.yy, and *.ly respectively. In order to keep syntax predictable, we want to be able to solve most problems just by extending the vocabulary. That means that lexical units and grammar should be as generic, powerful, and simple as possible. Specialized lexical modes take power from the vocabulary. We want to avoid them as much as possible given our historic constraints. I completely agree with this. I have been giving some people a hard time in this discussion, but that is primarily for wanting to mess with either lexer.ll or parser.yy. As long as you don't that, I will not object fiercely to what syntax proposal anyone comes up with. Actually, is there a particular reason we are generating a C parser rather than a C++ parser? The implications regarding marking and garbage collection of semantic values are rather awful. Right; all that should go away with guile v2 though, which uses Boehm GC Wrong. If the parse stack sits in an automatic or heap array, no garbage collector in the world has a chance of knowing that values beyond the hand-implemented stack pointer are stale, will never get read again, should not be marked, and can be collected. Believing in magic will only get us so far. Probably historic because Bison did not use to come with C++ skeleton files? Correct. The best we had was the pure_parser option. Ok. I'll probably change that after cross-checking with the unfortunately non-orthogonal GLR parser option that might facilitate moving the complexity for dealing with ambiguities from the grammar to the parser generator. Given the current grammar complexity, not an option to be lightly discarded. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Uses horizontal skylines in accidental placement (issue 6489086)
On 8 sept. 2012, at 08:46, k-ohara5...@oco.net wrote: On 2012/09/08 05:28:02, Keith wrote: now I measure it 2% /faster/ than master. Of course that makes no sense. I got confused of which executable I had when switching between patches. This patch is still about 6% slower than master, buy maybe worth it. Also, 'accidental-single-double.ly' is broke for me as well with starting with patch set 2, so nothing mysterious there. (It works if I just bypass the test for restore-first.) http://codereview.appspot.com/6489086/ OK - I'll be able to fix all the broken stuff on Monday or Tuesday. ~Mike ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Approximates cross-staff slurs in VerticalAxisGroup vertical-skylines. (issue 6498077)
On 8 sept. 2012, at 09:06, Keith OHara k-ohara5...@oco.net wrote: On Fri, 07 Sep 2012 09:23:08 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: On 7 sept. 2012, at 09:34, k-ohara5...@oco.net wrote: Having the invisible Grobs taking up space will confuse the innocent. I tried to add comments about this in the source - perhaps the CG needs an invisible grob bit, as we have StemStubs and SpanBarStubs as well. People who have read the source code and contributors guide are not the innocent. Ah, ok. I can put the idea of stubs in the docs too - this is an entirely comprehensible concept for those who understand basic engraving principles, as this is how engravers reserve space in many cases. They use physical objects that take up space but are never printed to block other objects. In measure 36 of my example, it seems I used a text script for custom fingering placement. That 4 moves to avoid the SlurStub. (How would you put it back where it belongs, as a user? ) \override TextScript #'avoid-slur = #'inside But, looking at the output, the 4 is /already/ inside the slur, so why would anybody think to try that? These invisible grobs pushing things around would cause confusion in released code. Hmm...will think it over. I agree with you that it's confusing - I think that a combination of documentation and perhaps warnings would help users with this. Cheers, MS http://codereview.appspot.com/6498077/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: new mailing list: lilypond-syntax-explorations
On 07/09/12 01:14, Graham Percival wrote: On Mon, Sep 03, 2012 at 08:15:27PM +0100, Graham Percival wrote: For the past 6 days, we've performed an experiment: can we have a On Thursday, I will create a new mailing list, with the tentative name lilypond-syntax-explorations. Alternate name suggestions are welcome. I'm re-thinking the name. It's not ideal to pinpoint syntax in the list name, since this could be a useful venue to discuss other ideas[1]. I'm now leaning towards: lilypond-loony-bin Other possibilities are: lilypond-free-discussion lilypond-random-discussion lilypond-explorations lilypond-loonies % Canadian joke: our $1 coin is a loonie % http://en.wikipedia.org/wiki/Loonie How about lilypond-language-discussion as it's sort of about how we can extend/develop/rationalise the LilyPond markup language[1] to produce beautifully engraved scores. Cheers, Ian [1] I mean the whole LilyPond language, not just the \markup stuff. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes position of mensural c clef (issue 6503091)
On 2012-09-08 08:11, Werner LEMBERG wrote: 1. reject any offers of help from contributors who do not follow the existing formatting. 2. educate each contributor individually, go through multiple rounds of each patch to adjust the formatting, etc. 3. use an automatic formatting tool. 4. combine 2 and 3: use an automatic formatting tool for most of the code style, but still require some additional manual formatting (and go through a few rounds of reviews if necessary). I favor either 3 or 4; we are not in a position to be gratuitously rejecting patches, and having finicky manual formatting will discourage some contributors. I fully agree. Since we have no support for (3) yet, I will do a bit of (2), and I really hope that Phil can bear with me :-) Is it really such a big deal if the code formatting is not perfectly consistent in every little detail? In particular, I would favor option 5. (relax 2 a bit) educate each contributor individually when giving feedback about the patch. Don't insist on a new patch for formatting alone, but tell the submitter that (s)he should (i.e. following the RFC terminology strongly recommended, but not absolutely required) fix the indentation before applying. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
[GLISS] Music functions using keyword parameters?
This is just a toe-in-the-water enquiry.
Given the work David put in to allow optional music function parameters
in the 2.16 release, how much work would it be able to do something like
\afterGrace :#note d1 :#grace { c16[ d]} :#fraction 15/16
or
\afterGrace :#fraction 15/16 :#note d1 :#grace { c16[ d]}
Notes:
Both the above would produce the same output.
I've used the default Scheme keyword introducer ':#' for the keyword.
I know currently \afterGraceFraction needs to be defined in Scheme
as
#(define afterGraceFraction (cons 15 16))
to do this rather than use a rational.
Is this feasible?
Is this desirable?
Specifically, does it cause huge disruption with the current
parser/lexer code.
Thoughts please? Especially welcome from those who've got down and dirty
with the parser code.
Cheers,
Ian
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
Indeed, typesetting the first few bars of one of the Biber sonatas, together with correct MIDI output, would yield a very nice example. Three staffs: true pitch, scordatura, tablature. Entry would be presumably in true pitch plus string number (where not in lowest terms). Why tablature? A digital scan of the original manuscript/print can be seen here: http://daten.digitale-sammlungen.de/~db/0002/bsb00020682/images/ It's a violin part using a G-clef, together with a basso continuo staff. Werner inline: slash.png___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2758. ly_module_lookup caused deprecation warnings with Guile V2.06. (issue 6458159)
On 2012/09/08 09:13:17, dak wrote: On 2012/09/06 23:24:04, Ian Hulin (gmail) wrote: On 2012/09/06 18:07:53, dak wrote: When we go Guilev2, we don't want to search for all the backward compatibility. So I'd say you use something like #if GUILEV1 for splicing in the compatibility stuff, and define it as either 0 or 1 in lily-guile.hh, depending on the conditional you use here. Once we decide to go Guilev2 proper, we rip out the definition in lily-guile.hh, and all uses of GUILEV1 will bomb out. That way we at least don't overlook the compatibility crutches. Nice idea, but probably better to define the macro in guile-compatibility.hh, which lily-guile.hh pulls in. I can then use as complementary GUILEV2 macro which will be needed for the Guile V2-specific bits in main.cc. Sounds like a plan. I guess neither of us are fond of the old use of undocumented (and by now deprecated, as opposed to module-variable) internal Guile functions. We disagree about what to replace it with: I would use the Scheme functions, saving the need for distinguishing Guilev1/Guilev2, you want to use the C functions and keep different versions for Guilev1 and Guilev2. If you implement the compatibility in the manner I propose (with your modification), we are sure that the ugly code does not stick around after going Guilev2-only. So that's ok with me as well. Having the GUILEv1 macro temporarily defined will also help the transition elsewhere, and we should probably also use a similar strategy at the Scheme level. I'll upload another patch-set. Unfortunately things may slow down at my end again as I'm back teaching and starting another round of mind-bending meds. Cheers, Ian http://codereview.appspot.com/6458159/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] Music functions using keyword parameters?
Ian Hulin i...@hulin.org.uk writes:
This is just a toe-in-the-water enquiry.
Given the work David put in to allow optional music function parameters
in the 2.16 release, how much work would it be able to do something like
\afterGrace :#note d1 :#grace { c16[ d]} :#fraction 15/16
or
\afterGrace :#fraction 15/16 :#note d1 :#grace { c16[ d]}
Notes:
Both the above would produce the same output.
I've used the default Scheme keyword introducer ':#' for the keyword.
Uh no. The default would be '#:'. In order not to introduce yet
another special case in the lexer, using ##: from LilyPond would seem to
make sense.
I know currently \afterGraceFraction needs to be defined in Scheme
as
#(define afterGraceFraction (cons 15 16))
to do this rather than use a rational.
Sigh. Why not just use an ordinary optional argument here? 15/16 in
LilyPond syntax gets translated to (cons 15 16) anyway. The actual
problem right now is that a mandatory argument after a non-present
optional argument needs to be closed music. With \afterGrace, not
being able to use a simple note without braces would be embarrassing.
But that's on the agenda to fix.
Is this feasible?
Likely.
Is this desirable?
Unlikely.
Specifically, does it cause huge disruption with the current
parser/lexer code.
Pretty much. The lexer could remain unchanged when heeding the above
change suggestion. The parser would be invasive. Probably somewhat
straightforward, but invasive. Keyword arguments would likely have to
come first.
Thoughts please? Especially welcome from those who've got down and
dirty with the parser code.
The stuff for matching LilyPond arguments to signatures would have to be
reworked. Not as much messing with the parser as with the parser
support code (like define-music-function, and the syntax constructors).
I don't like the consequences on the syntax. We have sort of a
keyword interface in unquoted strings, like \tweak takes as an
optional argument. Meddling with true keywords causes more fine
distinctions than I care for. I think that it is saner to try matching
semantics to the existing optional arguments, and I think that this will
become reasonably straightforward in the case of \afterGrace once the
closed issue disappears. Actually, I think that if you don't use an
optional fraction but rather a _duration_, the please be closed issue
might possibly be absent with the current code base. I don't promise
that this might not change transitorily, however, so it would probably
not make much sense to design a possibly inferior interface based on
that.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
On Sat, Sep 8, 2012 at 12:27 PM, David Kastrup d...@gnu.org wrote: No idea. What we have under the umbrella of syntax discussion contains three things: lexical units, grammar and vocabulary, mostly implemented in lexer.ll, parser.yy, and *.ly respectively. In order to keep syntax predictable, we want to be able to solve most problems just by extending the vocabulary. That means that lexical units and grammar should be as generic, powerful, and simple as possible. Specialized lexical modes take power from the vocabulary. We want to avoid them as much as possible given our historic constraints. I completely agree with this. I have been giving some people a hard time in this discussion, but that is primarily for wanting to mess with either lexer.ll or parser.yy. As long as you don't that, I will not object fiercely to what syntax proposal anyone comes up with. Actually, is there a particular reason we are generating a C parser rather than a C++ parser? The implications regarding marking and garbage collection of semantic values are rather awful. Right; all that should go away with guile v2 though, which uses Boehm GC Wrong. If the parse stack sits in an automatic or heap array, no garbage collector in the world has a chance of knowing that values beyond the hand-implemented stack pointer are stale, will never get read again, should not be marked, and can be collected. Believing in magic will only get us so far. Can you clarify? Boehm GC should also be inspecting the stack for what might be pointers to memory that cannot be reclaimed. See also http://www.gnu.org/software/guile/manual/html_node/Conservative-GC.html if your point is that some blocks will not be GC'd, then that is nothing new; pre-1.8 guile does not guarantee that, and in general conservative GC cannot guarantee that. Conservative GC is problematic if the heap is large compared to the address space; everything then starts looking like a pointer. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
Werner LEMBERG w...@gnu.org writes: Indeed, typesetting the first few bars of one of the Biber sonatas, together with correct MIDI output, would yield a very nice example. Three staffs: true pitch, scordatura, tablature. Entry would be presumably in true pitch plus string number (where not in lowest terms). Why tablature? To illustrate the power of LilyPond for extracting information useful for music theory and understanding. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [GLISS] why the hell all this fuss
Han-Wen Nienhuys hanw...@gmail.com writes: On Sat, Sep 8, 2012 at 12:27 PM, David Kastrup d...@gnu.org wrote: No idea. What we have under the umbrella of syntax discussion contains three things: lexical units, grammar and vocabulary, mostly implemented in lexer.ll, parser.yy, and *.ly respectively. In order to keep syntax predictable, we want to be able to solve most problems just by extending the vocabulary. That means that lexical units and grammar should be as generic, powerful, and simple as possible. Specialized lexical modes take power from the vocabulary. We want to avoid them as much as possible given our historic constraints. I completely agree with this. I have been giving some people a hard time in this discussion, but that is primarily for wanting to mess with either lexer.ll or parser.yy. As long as you don't that, I will not object fiercely to what syntax proposal anyone comes up with. Actually, is there a particular reason we are generating a C parser rather than a C++ parser? The implications regarding marking and garbage collection of semantic values are rather awful. Right; all that should go away with guile v2 though, which uses Boehm GC Wrong. If the parse stack sits in an automatic or heap array, no garbage collector in the world has a chance of knowing that values beyond the hand-implemented stack pointer are stale, will never get read again, should not be marked, and can be collected. Believing in magic will only get us so far. Can you clarify? Boehm GC should also be inspecting the stack for what might be pointers to memory that cannot be reclaimed. It does not help. If I have SCM stack[100] indexed by int stackpointer with a current value of 42, Boehm GC has no way of knowing that stack[43]..stack[100] will never get used again because every increment of stackpointer will be accompanied with overwriting the respective stack entry. See also http://www.gnu.org/software/guile/manual/html_node/Conservative-GC.html if your point is that some blocks will not be GC'd, then that is nothing new; pre-1.8 guile does not guarantee that, and in general conservative GC cannot guarantee that. Conservative GC is problematic if the heap is large compared to the address space; everything then starts looking like a pointer. It also does not help with any stack implementation that does not clean out cells as they become unused by virtue of the stackpointer moving across them. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
David Kastrup dak at gnu.org writes: Werner LEMBERG wl at gnu.org writes: Actually, it's been in the back of my head for a while that those pieces could be a great demo for Lilypond, particularly in respect of being able to generate both written and sounding-pitched parts for violin from the same material without any stupid tricks. Indeed, typesetting the first few bars of one of the Biber sonatas, together with correct MIDI output, would yield a very nice example. Three staffs: true pitch, scordatura, tablature. Entry would be presumably in true pitch plus string number (where not in lowest terms). ... and then a music function inspired by those that figure string-number for tablature to generate the false-pitches for scordatura. On the other hand, the existing sources are manuscripts written in false-pitch, so writing a function to convert from false-pitch to true-pitch would make initial entry easier. There are some tricks required either way. Since staff-positions correspond to scale steps one-to-one, a natural LilyPond kind of pseudo-scordatura would have the staff lines and ledger lines at un-equally-spaced positions -- distorting the staff lines to represent the tuning but leaving the note-head positions alone. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)
http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm#newcode178 scm/bar-line.scm:178: ;; the default distance between centre of dots is composed of Have you considered working entirely in staff-positions? .. placing repeat dots at the first pair of positions with at least a full staff-position gap for each dot. Then style changes (tiny, heavy staves for miniature scores, or widely-spaced tabStaff that really should have fatter repeat-dots) will not change the position of the dots. http://codereview.appspot.com/6488097/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)
On 2012/09/08 18:54:07, Keith wrote: http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6488097/diff/3001/scm/bar-line.scm#newcode178 scm/bar-line.scm:178: ;; the default distance between centre of dots is composed of Have you considered working entirely in staff-positions? .. placing repeat dots at the first pair of positions with at least a full staff-position gap for each dot. Then style changes (tiny, heavy staves for miniature scores, or widely-spaced tabStaff that really should have fatter repeat-dots) will not change the position of the dots. I agree with Keith that ignoring the various thicknesses altogether would likely make things more predictable. http://codereview.appspot.com/6488097/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)
ok, thinking about a new patch. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes position of mensural c clef (issue 6503091)
I fully agree. Since we have no support for (3) yet, I will do a bit of (2), and I really hope that Phil can bear with me :-) Is it really such a big deal if the code formatting is not perfectly consistent in every little detail? In particular, I would favor option 5. (relax 2 a bit) [...] My `a bit of (2)' is exactly your (5). Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Heinrich Ignaz Franz Biber
It's a violin part using a G-clef, together with a basso continuo staff. Oops, please ignore the attached image. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: Typos to LM - Fundamental and tweaks.itely (issue 6497103)
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/fundamental.itely
File Documentation/learning/fundamental.itely (right):
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/fundamental.itely#newcode2921
Documentation/learning/fundamental.itely:2921: f16 ees f d g aes g f ees
d e8 ees16 f ees d |
Sorry James, the tie was correct. It's
the pitch that was wrong - should be ees8 ~
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/tweaks.itely#newcode1701
Documentation/learning/tweaks.itely:1701: be necessary to override this
automatic behavior. This can be done for
Don't need 2 spaces here
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/tweaks.itely#newcode1702
Documentation/learning/tweaks.itely:1702: whole sections of music or
even for an individual note. The property
... or here
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/tweaks.itely#newcode1703
Documentation/learning/tweaks.itely:1703: which controls this behavior
is the @code{direction} property of each
... or here
http://codereview.appspot.com/6497103/diff/1/Documentation/learning/tweaks.itely#newcode1705
Documentation/learning/tweaks.itely:1705: number of ready-made commands
which avoid your having to code explicit
... or here
http://codereview.appspot.com/6497103/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)
I guess you are thinking we bring the dots inside the staff if there is at least one staff-postion of space for each dot (as in 2-line percussion staves) and continue to move them closer to the center if we find locations with at least two-staff-positions of space for each dot, or more space than we have found so far. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes position of mensural c clef (issue 6503091)
I was aware of a slight difference, although actually I'm not certain it's that important - these are machine drawn glyphs intending to replicate hand-drawn clefs from the 15th century. How important is 0.1 staff space? This is not the point. Your are changing the shape without documenting this fact. And the problem is not 0.1 staff space but loosing the vertical symmetry for no good reasons. I use Gedit and by default for mf files it puts tabs at 4 spaces, and so the indenting looked completely awry. Good goodness! This is a plain wrong default. If in doubt, *always* use 8 spaces for a tab. This is UNIX standard since the very beginning. Everything else is evil. IMHO mixing tabs and spaces is a really bad idea for that reason - different editors indent different ways. Hmm, the rule `1 physical tab = 8 spaces' is standard on UNIX boxes since 30 years? 40 years? As for the overlaps. Ditto I'll look at that. The original code calculated end points in a very odd way - it allowed, for example, of different amounts of shift between the breves, and then ignored that in the calculation of the decorations. I'll see if I can improve this. Thanks. http://codereview.appspot.com/6503091/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes position of mensural c clef (issue 6503091)
- Original Message - From: lemzw...@googlemail.com To: philehol...@googlemail.com; w...@gnu.org; gra...@percival-music.ca; m...@philholmes.net Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Saturday, September 08, 2012 9:52 PM Subject: Re: Fixes position of mensural c clef (issue 6503091) I was aware of a slight difference, although actually I'm not certain it's that important - these are machine drawn glyphs intending to replicate hand-drawn clefs from the 15th century. How important is 0.1 staff space? This is not the point. Your are changing the shape without documenting this fact. And the problem is not 0.1 staff space but loosing the vertical symmetry for no good reasons. My point is that there is no vertical symmetry in hand-drawn 15C clefs, so there is no point it trying to recreate it in 21C machine drawn clefs. Whoever created the original clef made it arbitrarily symmetrical, with no justification, so changing this needs no other justification. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)
sorry, I'm confused. do we want to support - NR 2.5.1 style 2-line percussion staves (setting both line-count and staff-space to 2 instead of setting just line-positions to (-2 2))? - default TabStaff's (even line-count, 1.5 staff-space)? if we want to support both of those without changing dot size, calculations cannot be based on line-positions only, staff-space must be considered. if we consider staff-space, issue 2648 must be taken care of. http://codereview.appspot.com/6488097/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change defaults for dot spacing in repeat sign to accommodate tab staves (issue 6488097)
On Sat, 08 Sep 2012 15:26:21 -0700, benko@gmail.com wrote: do we want to support - NR 2.5.1 style 2-line percussion staves (setting both line-count and staff-space to 2 instead of setting just line-positions to (-2 2))? - default TabStaff's (even line-count, 1.5 staff-space)? if we want to support both of those without changing dot size, calculations cannot be based on line-positions only, staff-space must be considered. I suggest you consider both the gaps between line-positions (prefer gap of 2 staff-positions) and the full range of line-positions (prefer to have repeat dots within the staff) If someone writes tablature and wants a staff-space = 2 for some reason, he probably want the repeat dots in their usual positions. (His choice on whether to also increase the dot size.) If someone writes 2-line percussion somewhat more narrow, he will probably want the repeat dots inside the staff. http://codereview.appspot.com/6488097/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
