Re: Fixes all black bars in NR (issue 6345088)
An even better solution would be for Texinfo to support these characters. - Just saying - I wouldn't expect any Lily developers to be working on that! Well, some years ago I've added UTF-8 infrastructure support to texinfo (based on the LaTeX code); additionally, I've written the CJK package for LaTeX to support various east Asian scripts, so I think I have some competence here. There are *zero* chances that CJK support (probably based on my package) will ever be added to texinfo for the original tex or pdftex engine. It took more than 10 years that the texinfo team changed from Knuth's CM fonts to the EC fonts so that a broader range of European scripts are available. Main reason for such a conservative behaviour is backwards compatibility. With XeTeX and luatex, native CJK support (looking at the character set) is trivial. However, neither engine is supported by texinfo natively, but this may change. It should be not too difficult to add some macros for proper Greek and Cyrillic (within the lilypond framework), and I will have a look if time permits. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Scheme bar line interface (issue 6305115)
Marc, please don't throw the whole 2533 issue stuff out; look at the latest version at http://codereview.appspot.com/6431044 in particular bar-line.cc and repeat-sign.ly. I really don't mind if your patch goes before mine (it would even be better - why push a change to a file that is to be thrown out by the next commit), but I do mind that (some of) those cases work right, and unfortunately I'm far less fluent in Scheme than in C++. http://codereview.appspot.com/6305115/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Graham Percival wrote Tuesday, July 24, 2012 10:09 AM ** Summary Let’s decide whether to try to stabilize the syntax or not. We /should/ try to stabilize the syntax, but trying to do this at exactly the time when David is straightening out the parser seems a bad idea. As yet we do not know where the parser changes may lead eventually. ** Stability or not? Stabilizing a language is a tricky process. If you do it too early, then you’re stuck with whatever mistakes or poor design decisions. Exactly. We should wait until David's parser changes settle out. 2. Define a subset of input as being stable for the 3.x branch. We add regression tests for that subset of notation and forbid running convert-ly on those files. At the moment, I imagine that the subset would consist of at most Notation sections 1.1 Pitches, 1.2 Rhythms, and the overall file organization; nothing else. Changes to input other than that subset are fine. I'd be happy to see a start being made on this now, in spite of my comments above, but we must delay the actual release of the definitive syntax-stable version until we have confidence the parser changes have stabilized. The task David has set himself is difficult enough without his being hamstrung by a premature release imposing further constraints on the parser. Predicting the effect those constraints might have on the parser is pretty well impossible. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
David Kastrup dak at gnu.org writes:
Keith OHara k-ohara5a5a at oco.net writes:
The pre-defined \cm is acted only in limited contexts -- the same
contexts where we are allowed to type decimal numbers without a leading #.
We would like those contexts to be even more narrow, immediately after the
'=' operator.
I don't see why one would not want that for function arguments. What's
good for assigning to variables is good for assigning to function
arguments.
I suspect that I do not want naked decimal numbers as function arguments
because they get confused with other notation.
If I make a function
\dichrom3D { c4 d e f } 3.7
that engraves a passage so that the notes appear to float 3.7 staff-spaces
above the paper when viewed with red/cyan 3D glasses,
then if I use it on an isolated note \dichrom3D e 2.9
I get a dotted-half-note e floating 9.0 staff-spaces above the page.
Lilypond's grammar today uses \dichrom3D e #2.9 to segregate the arguments.
I think I prefer the freedom to sloppily write { indent = 2.\mm }
to the freedom to drop the # when mixing decimal numbers with music.
Decimal numbers do not seem to mix well in LilyPond music, so I say restrict
them to where we use them: the first token after an assignment operator '='
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Scheme bar line interface (issue 6305115)
Am 26.07.2012 09:51, schrieb benko@gmail.com: Marc, please don't throw the whole 2533 issue stuff out; look at the latest version at http://codereview.appspot.com/6431044 in particular bar-line.cc and repeat-sign.ly. I really don't mind if your patch goes before mine (it would even be better - why push a change to a file that is to be thrown out by the next commit), but I do mind that (some of) those cases work right, and unfortunately I'm far less fluent in Scheme than in C++. http://codereview.appspot.com/6305115/ I wanted to contact you anyway – I'd propose that you remove these parts of your patch; when your algorithm is right (I have no doubt about that), I can do the c-scheme translation and do this part of work for you, including the regtest. For me, it was important that my patch reflects the status-quo of the bar line stuff; changes will be far easier to do in the future. What do you think? Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Scheme bar line interface (issue 6305115)
On Thu, 26 Jul 2012 00:51:56 -0700, benko@gmail.com wrote: Marc, please don't throw the whole 2533 issue stuff out; look at the latest version at http://codereview.appspot.com/6431044 in particular bar-line.cc and repeat-sign.ly. I really don't mind if your patch goes before mine (it would even be better - why push a change to a file that is to be thrown out by the next commit), but I do mind that (some of) those cases work right, and unfortunately I'm far less fluent in Scheme than in C++. I had suggested that Marc incorporate pending changes to the bar-line code if he is confident in them, but it does seem cleaner make one commit a simple re-implementation of C to Scheme, with the same functionality. He is not really throwing out the issue-2533 stuff, because that stuff is not in the code base at the moment. You will just have to cooperate with Marc or another Scheme programmer, if the re-implementation goes in first. If it really turns out to be harder for the group to modify the code in Scheme than it was in C, then the reason for Marc's patch would prove to be wrong and we can just go back to C. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Scheme bar line interface (issue 6305115)
Am 26.07.2012 10:31, schrieb Keith OHara: On Thu, 26 Jul 2012 00:51:56 -0700, benko@gmail.com wrote: Marc, please don't throw the whole 2533 issue stuff out; look at the latest version at http://codereview.appspot.com/6431044 in particular bar-line.cc and repeat-sign.ly. I really don't mind if your patch goes before mine (it would even be better - why push a change to a file that is to be thrown out by the next commit), but I do mind that (some of) those cases work right, and unfortunately I'm far less fluent in Scheme than in C++. I had suggested that Marc incorporate pending changes to the bar-line code if he is confident in them, but it does seem cleaner make one commit a simple re-implementation of C to Scheme, with the same functionality. He is not really throwing out the issue-2533 stuff, because that stuff is not in the code base at the moment. You will just have to cooperate with Marc or another Scheme programmer, if the re-implementation goes in first. If it really turns out to be harder for the group to modify the code in Scheme than it was in C, then the reason for Marc's patch would prove to be wrong and we can just go back to C. I had already implemented Páls work on repeat signs *before* his patch was reverted, so reimplementing this in scheme should be straightforward. ... and wait until you see what will be possible with barlines when part 2 of issue 1320 is out ;-) Stay tuned! Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On Thu, Jul 26, 2012 at 09:02:38AM +0100, Trevor Daniels wrote: Graham Percival wrote Tuesday, July 24, 2012 10:09 AM Let’s decide whether to try to stabilize the syntax or not. We /should/ try to stabilize the syntax, but trying to do this at exactly the time when David is straightening out the parser seems a bad idea. As yet we do not know where the parser changes may lead eventually. tl;dr: we agree on the actual what we will do, but disagree on the reasons behind it. :) I actually think that David's work on the parser makes this is the perfect time to do GLISS. - the code should match our desired language specification, not the other way around. Do we want to allow numbers like 0.37 which do not begin with a leading 0? that's not a code question, that's a language question. Of course the language design should be heavily influenced by the implications for the computer implementation (i.e. parser and lexer), so I don't think we would be able to have this discussion without David's expertise on the matter. - straightening out the parser is going to lead to some breakage in (complicated and/or badly written) scores. That may lead to some understandable frustration from some users, but if we're running GLISS at the same time, that gives them some hope that things will settle down. I'd be happy to see a start being made on this now, in spite of my comments above, but we must delay the actual release of the definitive syntax-stable version until we have confidence the parser changes have stabilized. The task David has set himself is difficult enough without his being hamstrung by a premature release imposing further constraints on the parser. Predicting the effect those constraints might have on the parser is pretty well impossible. I agree with delaying the definitive syntax-stable versions; I'm imagining something like a proposed stable syntax that must exist for 6 or 12 months without any change or quibbles before it's accepted as actually stable. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Trevor Daniels t.dani...@treda.co.uk writes: Graham Percival wrote Tuesday, July 24, 2012 10:09 AM ** Summary Let’s decide whether to try to stabilize the syntax or not. We /should/ try to stabilize the syntax, but trying to do this at exactly the time when David is straightening out the parser seems a bad idea. To be fair, it is not likely that David will stop straightening out the parser anytime soon. One problem with straightening out the parser, however, is that it is very much guided by remaining upwards compatible, and that individual changes breaking upward compatibility are hard to argue on their own merits. So the trend is to resolve ambiguities by adding complexity. That avoids compatibility issues for the time being. However, it means that the same amount of complexity for resolving ambiguities would need to get applied by convert-ly, text editors with syntax support for LilyPond, and tools importing LilyPond, all of which is not realistic. So the price of LilyPond retaining the ability to process almost anything it was able to process before and calling that the de facto standard is that everybody else gives up on LilyPond as a music description language. It also means that the moving target for full anecdotal backward compatibility (try supporting anything that may have worked at some point of time) gets more horrific the longer this goes on. As yet we do not know where the parser changes may lead eventually. Well, the expectation in the medium range is to solidify on music functions, and have a mechanism where there is just one kind of them, and just one kind of argument parsing. ** Stability or not? Stabilizing a language is a tricky process. If you do it too early, then you’re stuck with whatever mistakes or poor design decisions. Exactly. We should wait until David's parser changes settle out. Again: this is not going to happen anytime soon, and even if we are postulating that I am the only one working on the changes, they need to fit with some direction. At the current point of time, I am more or less factually dictator of the lexer/parser since a statement this is not doable from me will go uncontested. But the path of least resistance is a path where lots of mostly historical ambiguities, partly due to arbitrary design choices, get resolved with a considerable involvement of complexity. And defining the whole of what will compile at a current point of time as an archive language does not really work. 2. Define a subset of input as being stable for the 3.x branch. We add regression tests for that subset of notation and forbid running convert-ly on those files. At the moment, I imagine that the subset would consist of at most Notation sections 1.1 Pitches, 1.2 Rhythms, and the overall file organization; nothing else. Changes to input other than that subset are fine. I'd be happy to see a start being made on this now, in spite of my comments above, but we must delay the actual release of the definitive syntax-stable version until we have confidence the parser changes have stabilized. The task David has set himself is difficult enough without his being hamstrung by a premature release imposing further constraints on the parser. Predicting the effect those constraints might have on the parser is pretty well impossible. It has to be said that at the current point of time the main challenge in lexer/parser work is in the _lack_ of constraints. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
Keith OHara k-ohara5...@oco.net writes:
David Kastrup dak at gnu.org writes:
Keith OHara k-ohara5a5a at oco.net writes:
The pre-defined \cm is acted only in limited contexts -- the same
contexts where we are allowed to type decimal numbers without a leading #.
We would like those contexts to be even more narrow, immediately after the
'=' operator.
I don't see why one would not want that for function arguments. What's
good for assigning to variables is good for assigning to function
arguments.
I suspect that I do not want naked decimal numbers as function arguments
because they get confused with other notation.
That's not all that different for assignments.
If I make a function
\dichrom3D { c4 d e f } 3.7
that engraves a passage so that the notes appear to float 3.7 staff-spaces
above the paper when viewed with red/cyan 3D glasses,
then if I use it on an isolated note \dichrom3D e 2.9
I get a dotted-half-note e floating 9.0 staff-spaces above the page.
Lilypond's grammar today uses \dichrom3D e #2.9 to segregate the
arguments.
Not really. There is a complex interaction of closed and open music
expressions that can only be used in certain contexts in order to pick
things apart. Part of the reason is that some previously hardwired
constructs have been turned into music functions, and the hardwired
constructs permitted (or even demanded) using non-Scheme numbers, so it
is not an option for the music-function based ones to stop doing so.
I think I prefer the freedom to sloppily write { indent = 2.\mm } to
the freedom to drop the # when mixing decimal numbers with music.
There is no way you are going to write #2. \mm and have that produce a
meaningful output. Why don't you write { indent = 2\mm }? This is
really puzzling to me.
The problem is that _you_ know when you are in a mode for music, and
when not. Does your syntax-aware editor know? I find that it is even
hard to make sure LilyPond knows.
Decimal numbers do not seem to mix well in LilyPond music, so I say
restrict them to where we use them: the first token after an
assignment operator '='
So not inside of #{ ... #}? It is otherwise rather similar to the
after an assignment operator situation.
Convenience comes at a price, and it is a price future generations will
have to pay. The half-life of a parser might be smaller than that of
typical nuclear waste, but at some point of time somebody will actually
have to deal with the consequences.
In fact, giving up on LilyPond as an archivable format _is_ one of the
consequences. Defining an archivable subset may help, and we might warn
people that this subset's constraints will increasingly become a part of
LilyPond's realities, so they might want to converge to it before it
becomes inconvenient.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
David Kastrup wrote Thursday, July 26, 2012 10:01 AM
Keith OHara k-ohara5...@oco.net writes:
If I make a function
\dichrom3D { c4 d e f } 3.7
that engraves a passage so that the notes appear to float 3.7 staff-spaces
above the paper when viewed with red/cyan 3D glasses,
then if I use it on an isolated note \dichrom3D e 2.9
I get a dotted-half-note e floating 9.0 staff-spaces above the page.
I'm not sure I've followed all this discussion, but if it is or
becomes possible to write a music function like \dichrom3D
which /silently/ behaves differently if one of its real arguments
happens to begin with a sequence that can be interpreted as
a duration, then we've definitely gone astray.
Please tell me I've misunderstood something.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Thursday, July 26, 2012 10:01 AM
Keith OHara k-ohara5...@oco.net writes:
If I make a function
\dichrom3D { c4 d e f } 3.7
that engraves a passage so that the notes appear to float 3.7 staff-spaces
above the paper when viewed with red/cyan 3D glasses,
then if I use it on an isolated note \dichrom3D e 2.9
I get a dotted-half-note e floating 9.0 staff-spaces above the page.
I'm not sure I've followed all this discussion, but if it is or
becomes possible to write a music function like \dichrom3D
which /silently/ behaves differently if one of its real arguments
happens to begin with a sequence that can be interpreted as
a duration, then we've definitely gone astray.
Please tell me I've misunderstood something.
hup =
#(define-music-function (parser location m s) (ly:music? number?)
#{ \set Staff.middleCOffset = #s \applyContext #ly:set-middle-C!
#m \unset Staff.middleCOffset #})
\hup { c4 d e f } 4
already works.
\hup e4 2 is supposed to work as well, but apparently does not at the
moment. Probably something that needs fixing.
Using music functions in the context of layout definitions will require
in the worst case using
\notemode { ... }
in which case interpretation becomes unproblematic.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Thursday, July 26, 2012 10:01 AM
Keith OHara k-ohara5...@oco.net writes:
If I make a function
\dichrom3D { c4 d e f } 3.7
that engraves a passage so that the notes appear to float 3.7 staff-spaces
above the paper when viewed with red/cyan 3D glasses,
then if I use it on an isolated note \dichrom3D e 2.9
I get a dotted-half-note e floating 9.0 staff-spaces above the page.
I'm not sure I've followed all this discussion, but if it is or
becomes possible to write a music function like \dichrom3D
which /silently/ behaves differently if one of its real arguments
happens to begin with a sequence that can be interpreted as
a duration, then we've definitely gone astray.
Please tell me I've misunderstood something.
The _function_ does not behave differently. It is just that more
material belongs to the music expression argument.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 24/07/12 10:09, Graham Percival wrote: Let’s decide whether to try to stabilize the syntax or not. What type of project do we want LilyPond to be? What kinds of guarantees (or at least firm intentions) do we want to give to users with respect to lilypond 2 or 5 years from now being able to read their current ly files? As a first step, surely it's important to understand what are the typical sources of conversion problems, i.e. what kind of syntax changes can convert-ly not deal with? It seems to me that \override statements and custom-written Scheme inherently come with a may break in future health warning (especially the latter). I don't think improvements to the language should be held back for the sake of such explicit departures from default behaviour. Given that, LilyPond is not suitable as an archival format for music. That surely depends on whether your archive can also maintain earlier versions of LilyPond to compile its older files with. It can produce a great pdf when you first write the file, but the .ly files require regular maintenance if you want them to compile in the latest stable version of lilypond. How feasible is it for LilyPond to support a deprecation mechanism for syntax? E.g. so that when compiling you might get an error message, [such-and-such a syntax element] is deprecated syntax that will be removed from a future version of LilyPond. Use [new syntax] instead. Or alternatively, to simply maintain in LP the previous syntax as a separate option, so that for example lilypond file.ly -- uses the current standard syntax lilypond --deprecated file.ly -- uses the previous syntax ... so that either way you'd always have a means of compiling a LP file from the previous syntax version, but you'd also have a clear warning of where maintenance was required. This way you could build in a deprecation cycle for syntax changes which would minimize their impact. This is a problem for projects such as mutopia – a large fraction of their .ly files don’t compile with current lilypond. If that's already the case, then it shouldn't block further syntax changes _now_ if they are useful and the syntax can be stabilized on the basis of these changes. On a personal note, this is one of the biggest reasons I’ve given up on using lilypond personally. From 2001 to 2004 I got a minor in music composition. I carefully kept all my .ly files but foolishly did not preserve the pdfs. And now, 10 years later, I’m left with a bunch of music that I cannot generate sheet music for. Manually updating the .ly files would take hours or days; I’ve started this process a few times but always lost interest after a few files, since there’s no guarantee that I wouldn’t need to go through the same process in another few years. FWIW this is still a better archival status than Finale/Sibelius. In fact from what I recall, typical practice of professional engravers with these packages is to use the music software to produce a basic layout which they'd then tweak further in Adobe Illustrator. So the PDF/PostScript version would be the _only_ reliable archival copy. My personal preference is to stabilize a subset. It won’t solve all the user problems with manually updating ly files, but it would be a step in the right direction. If the process goes well, then we can have additional rounds of stabilization where we expand the stable subset. This seems like a good basic policy, but why not add the following caveat -- have a large test suite of different cases, including full scores provided by users (e.g. the whole Mutopia archive?), and allow syntax changes even to the subset if there is both a strong technical justification _and_ the developer can provide a convert-ly rule which demonstrably works across the whole test suite? After all, a breaking syntax change is only bad if it _can't_ automatically be fixed. My overall feeling on this is that while there are areas of standard modern musical notation [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] that aren't supported by LilyPond, it's difficult to guarantee syntax stability. So perhaps a first step is to define the subset of _musical_ notation that you want to provide stable support for. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1320: Scheme bar line interface (issue 6305115)
2012/7/26 Marc Hohl m...@hohlart.de: Am 26.07.2012 10:31, schrieb Keith OHara: On Thu, 26 Jul 2012 00:51:56 -0700, benko@gmail.com wrote: Marc, please don't throw the whole 2533 issue stuff out; look at the latest version at http://codereview.appspot.com/6431044 in particular bar-line.cc and repeat-sign.ly. I really don't mind if your patch goes before mine (it would even be better - why push a change to a file that is to be thrown out by the next commit), but I do mind that (some of) those cases work right, and unfortunately I'm far less fluent in Scheme than in C++. I had suggested that Marc incorporate pending changes to the bar-line code if he is confident in them, but it does seem cleaner make one commit a simple re-implementation of C to Scheme, with the same functionality. He is not really throwing out the issue-2533 stuff, because that stuff is not in the code base at the moment. You will just have to cooperate with Marc or another Scheme programmer, if the re-implementation goes in first. If it really turns out to be harder for the group to modify the code in Scheme than it was in C, then the reason for Marc's patch would prove to be wrong and we can just go back to C. I had already implemented Páls work on repeat signs *before* his patch was reverted, so reimplementing this in scheme should be straightforward. ... and wait until you see what will be possible with barlines when part 2 of issue 1320 is out ;-) Stay tuned! ok, thanks in advance to everyone! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 24/07/12 10:09, Graham Percival wrote: Let’s decide whether to try to stabilize the syntax or not. What type of project do we want LilyPond to be? What kinds of guarantees (or at least firm intentions) do we want to give to users with respect to lilypond 2 or 5 years from now being able to read their current ly files? As a first step, surely it's important to understand what are the typical sources of conversion problems, i.e. what kind of syntax changes can convert-ly not deal with? It seems to me that \override statements and custom-written Scheme inherently come with a may break in future health warning (especially the latter). I don't think improvements to the language should be held back for the sake of such explicit departures from default behaviour. Given that, LilyPond is not suitable as an archival format for music. That surely depends on whether your archive can also maintain earlier versions of LilyPond to compile its older files with. And earlier versions of GCC to compile its older LilyPond versions with. How feasible is it for LilyPond to support a deprecation mechanism for syntax? E.g. so that when compiling you might get an error message, [such-and-such a syntax element] is deprecated syntax that will be removed from a future version of LilyPond. Use [new syntax] instead. At some time, it will be removed or the warning is pointless. So this will not address the topic of bitrot for large mostly dormant bodies of music like Mutopia satisfactorily. Or alternatively, to simply maintain in LP the previous syntax as a separate option, so that for example lilypond file.ly -- uses the current standard syntax lilypond --deprecated file.ly -- uses the previous syntax If it was simply... My overall feeling on this is that while there are areas of standard modern musical notation [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] that aren't supported by LilyPond, it's difficult to guarantee syntax stability. So perhaps a first step is to define the subset of _musical_ notation that you want to provide stable support for. Sounds to me like that was what Graham proposed in the first place. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GOP2-2b - Stable 2.16.x releases (dictator) (probable decision)
Mostly unchanged from last week's proposal; I think we're pretty much decided on this, but we'll still have another week for final objections. http://lilypond.org/~graham/gop/gop_3.html ** Summary Let’s appoint David Kastrup as the “benevolent dictator” of the stable/2.16 git branch. *** Motivation (mostly copied from an email by David) Releasing a stable release brings progress to LilyPond users. LilyPond users are the most promising clientele for recruiting future developers. People start actively working with the versions they actually know and use. The less connections remain between the versions in the hand of the users and the current development source, the less likely their own work is suitable for eventual inclusion in LilyPond. So we want to avoid having stable versions that are quite outdated. Regressions and bugs are a bad thing: we want to avoid them. Detecting regressions and bugs is a good thing: we don’t want to create incentives to avoid detecting them. What makes detecting bugs a good thing? We gain the opportunity to fix them, and we gain knowledge, the opportunity to evaluate their severity. A stable release with severe bugs is a problem. A stable release with some bugs and regressions is pretty much unavoidable. Let’s accept that and leave it up to a human to judge whether bugs are are “severe” or not. ** Regressions (mostly copied from an email by Trevor) So far there have been c. 75 critical regressions under the current definition of ’critical’ since 2.14. All but one have been fixed, many of them promptly. This prompt attention IMO is due only to the fact that they were deemed to block a stable release. If the only criterion is that the release compiles the (extended) regtests satisfactorily, then I doubt that adequate attention will be directed to bugs discovered after the release that would be deemed critical on the current definition. That would seriously degrade the quality of our stable releases. To complete the discussion David and I were having about the possibility of using revert as an option to fix a critical bug, I looked at a few recent critical regressions, namely those which caused Release Canditates 6 and 7 to be abandoned. None of these could have been easily fixed by reversion, either because the fix was complicated, the original source was too old for revert to be safe, or the cause was external to LP. So reversion offers no easy answer. *** Details The policy is: David Kastrup has sole authority over what goes into stable/2.16 and which release(s) will have a version number of 2.16.x, until 2012 Dec 31. In more detail, this means: - he decides when to have 2.16.0. - Classification of issues as being “Critical” takes place as normal, but he (and only he) may remove that label or even ignore them completely and make a 2.16.x release despite Critical issues. - when he wants have release, he will ask somebody to build a release from the stable/2.16 branch. - he decides if, what, when to backport patches and have other 2.16.x releases. - translators do not merge or cherry-pick onto stable/2.16 unless specifically requested to do so. - nobody should merge or cherry-pick from stable/2.16, either. - If he decides to quit before 2012 Dec 31, then we will have a new discussion about how to deal with the situation. ** Further considerations This could be considered to be an experiment. It is time- and version-limited. In particular, - Development on git master continues as normal - in 2012 December, we will discuss what to do about the 2.16 branch in the future. - this policy does not forbid us from introducing 2.18 or 3.0 before 2012 Dec if we choose to do so. - this policy does not forbid us from developing other policies for the 2.18 or 3.0 releases. - additional discussion about regtests, GLISS, development roadmap, etc, are postponed until later. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
David Kastrup wrote Thursday, July 26, 2012 11:12 AM
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Thursday, July 26, 2012 10:01 AM
Keith OHara k-ohara5...@oco.net writes:
If I make a function
\dichrom3D { c4 d e f } 3.7
that engraves a passage so that the notes appear to float 3.7 staff-spaces
above the paper when viewed with red/cyan 3D glasses,
then if I use it on an isolated note \dichrom3D e 2.9
I get a dotted-half-note e floating 9.0 staff-spaces above the page.
I'm not sure I've followed all this discussion, but if it is or
becomes possible to write a music function like \dichrom3D
which /silently/ behaves differently if one of its real arguments
happens to begin with a sequence that can be interpreted as
a duration, then we've definitely gone astray.
Please tell me I've misunderstood something.
The _function_ does not behave differently. It is just that more
material belongs to the music expression argument.
That's splitting hairs. As far as the user is concerned
\dichrom3D e 3.1 and \dichrom3D e 2.9 would behave
very differently, unless I'm still missing something.
I don't relish writing user documentation to explain
this behaviour:
Warning: if a music function takes music and a real as
two arguments and the first argument does not have an
explicit duration the second argument must not begin
with 1, 2, 4, 8, ... or the result will surprise you.
In the past you've always been in favour of eliminating
surprises. Are you really proposing we should
implement this syntax?
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Thursday, July 26, 2012 11:12 AM
The _function_ does not behave differently. It is just that more
material belongs to the music expression argument.
That's splitting hairs. As far as the user is concerned
\dichrom3D e 3.1 and \dichrom3D e 2.9 would behave
very differently, unless I'm still missing something.
I don't relish writing user documentation to explain
this behaviour:
Warning: if a music function takes music and a real as
two arguments and the first argument does not have an
explicit duration the second argument must not begin
with 1, 2, 4, 8, ... or the result will surprise you.
It's much simpler than that. Expressions are greedy: what can become
a part of them, will. For that reason, it may make sense to enclose
simple music in braces, or it is likely to integrate durations and
postevents not intended for it.
For argument parsing it might be nice if { single-music-event } would
not turn into sequential music, similar to how #{ single-music-event #}
doesn't, so that you can make music arguments unambiguous without
causing them to be wrapped in sequential music.
In the past you've always been in favour of eliminating
surprises. Are you really proposing we should
implement this syntax?
\displayMusic c4-3
is existing syntax. Long-existing syntax. A total nuisance to support.
But it is not like there is much choice involved here. It has been
around eternities. Do you think all the backtracking folderol and
mode-switching and token-juggling that is going on in the parser
bypassing the basic LALR(1) algorithm has been implemented because I
consider it fun?
Indeed, on the user list we get complaints from really good aspiring
developers that there are still too many unnatural restrictions (what
you will call non-surprises) in connection with argument parsing.
If you can rely on strict greediness, that's an advantage. You might
want to call for a few more syntax errors. I am not sure they always
help.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP2-3 - GLISS or not
On 26/07/12 16:50, David Kastrup wrote: Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: How feasible is it for LilyPond to support a deprecation mechanism for syntax? At some time, it will be removed or the warning is pointless. So this will not address the topic of bitrot for large mostly dormant bodies of music like Mutopia satisfactorily. Indeed. But a well-defined deprecation cycle which gives an organization like Mutopia time to update its contents may be preferable to freezing LP syntax. After all, there's value in the contents of an archive like Mutopia being maintained over time. Engraved music needs fixing for many reasons -- errors, previously-unidentified performance issues, responses to new scholarship -- you don't want them to be just dumped there and left untouched. The PDFs are still there for the truly unmaintained documents, so it's not like you're fundamentally losing the archived music. My overall feeling on this is that while there are areas of standard modern musical notation [e.g. https://code.google.com/p/lilypond/issues/detail?id=1278 ] that aren't supported by LilyPond, it's difficult to guarantee syntax stability. So perhaps a first step is to define the subset of _musical_ notation that you want to provide stable support for. Sounds to me like that was what Graham proposed in the first place. No, Graham proposed freezing a subset of _Lilypond syntax_. I'm proposing that before doing any such thing it's important to look at Lilypond's musical coverage and ask if it is adequate enough to guarantee that the syntax can be stabilized. The microtonal notation issue I highlighted is relevant in this respect because it's almost guaranteed to involve a rewrite of how LP considers pitches and pitch alterations internally. In turn, that might impact all the way back up to a rewrite of LP syntax for those things. And it's a completely standard part of modern musical notation that is currently unsupported by Lilypond. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
scheme spanner in input/regression/scheme-text-spanner.ly not quote-proof
The text spanner implemented in scheme (which is also used as a basis
for David's measure counter engraver) seems to work fine in the regtest,
but apparently it is not quote-proof.
In particular, if you try call \addQuote on some music that contains
\schemeTextSpannerStart or \schemeTextSpannerEnd, then you get the
following warnings and the text spanner is not quoted:
scheme-text-spanner.ly:210:5: warning: Event class should be a list
a4
b\schemeTextSpannerStart c d |
scheme-text-spanner.ly:212:7: warning: Event class should be a list
a4 b
c\schemeTextSpannerEnd d |
So apparently the scheme way to add new event classes is not entirely
correct...
Sample file (regtest adapted to quote the music) is attached.
Any idea about the correct fix to this?
Thanks,
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
\version 2.15.31
\header {
texidoc = Use @code{define-event-class}, scheme engraver methods,
and grob creation methods to create a fully functional text spanner
in scheme.
}
#(define my-grob-descriptions '())
#(define my-event-classes (ly:make-context-mod))
defineEventClass =
#(define-void-function (parser location class parent)
(symbol? symbol?)
(ly:add-context-mod
my-event-classes
`(apply
,(lambda (context class parent)
(ly:context-set-property!
context
'EventClasses
(event-class-cons
class
parent
(ly:context-property context 'EventClasses '()
,class ,parent)))
\defineEventClass #'scheme-text-span-event #'span-event
#(define (add-grob-definition grob-name grob-entry)
(let* ((meta-entry (assoc-get 'meta grob-entry))
(class(assoc-get 'class meta-entry))
(ifaces-entry (assoc-get 'interfaces meta-entry)))
(set-object-property! grob-name 'translation-type? list?)
(set-object-property! grob-name 'is-grob? #t)
(set! ifaces-entry (append (case class
((Item) '(item-interface))
((Spanner) '(spanner-interface))
((Paper_column) '((item-interface
paper-column-interface)))
((System) '((system-interface
spanner-interface)))
(else '(unknown-interface)))
ifaces-entry))
(set! ifaces-entry (uniq-list (sort ifaces-entry symbol?)))
(set! ifaces-entry (cons 'grob-interface ifaces-entry))
(set! meta-entry (assoc-set! meta-entry 'name grob-name))
(set! meta-entry (assoc-set! meta-entry 'interfaces
ifaces-entry))
(set! grob-entry (assoc-set! grob-entry 'meta meta-entry))
(set! my-grob-descriptions
(cons (cons grob-name grob-entry)
my-grob-descriptions
#(add-grob-definition
'SchemeTextSpanner
`(
(bound-details . ((left . ((Y . 0)
(padding . 0.25)
(attach-dir . ,LEFT)
))
(left-broken . ((end-on-note . #t)))
(right . ((Y . 0)
(padding . 0.25)
))
))
(dash-fraction . 0.2)
(dash-period . 3.0)
(direction . ,UP)
(font-shape . italic)
(left-bound-info . ,ly:line-spanner::calc-left-bound-info)
(outside-staff-priority . 350)
(right-bound-info . ,ly:line-spanner::calc-right-bound-info)
(staff-padding . 0.8)
(stencil . ,ly:line-spanner::print)
(style . dashed-line)
(meta . ((class . Spanner)
(interfaces . (font-interface
line-interface
line-spanner-interface
side-position-interface))
#(define scheme-event-spanner-types
'(
(SchemeTextSpanEvent
. ((description . Used to signal where scheme text spanner brackets
start and stop.)
(types . (general-music scheme-text-span-event span-event event))
))
))
#(set!
scheme-event-spanner-types
(map (lambda (x)
(set-object-property! (car x)
'music-description
(cdr (assq 'description (cdr x
(let ((lst (cdr x)))
(set! lst (assoc-set! lst 'name (car x)))
(set! lst (assq-remove! lst 'description))
(hashq-set! music-name-to-property-table (car x) lst)
(cons (car x) lst)))
scheme-event-spanner-types))
#(set! music-descriptions
(append scheme-event-spanner-types
Re: GOP2-3 - GLISS or not
On Thu, Jul 26, 2012 at 06:31:50PM +0100, Joseph Rushton Wakeling wrote: Sounds to me like that was what Graham proposed in the first place. No, Graham proposed freezing a subset of _Lilypond syntax_. I'm proposing that before doing any such thing it's important to look at Lilypond's musical coverage and ask if it is adequate enough to guarantee that the syntax can be stabilized. I should add some more context. I've just remembered that we have a tutorial (don't ask me how I forgot), and that covers pretty much what I was thinking about really simple music. This isn't a formal proposal yet, but tomorrow or the day after I'll officially suggest something like: * stabilize an input syntax (not _necessarily_ the input syntax on these pages) for: http://lilypond.org/doc/v2.14/Documentation/learning/simple-notation http://lilypond.org/doc/v2.14/Documentation/learning/single-staff-notation with the following exceptions: - no beaming - no formatting of text - no articulations or fingerings - no ties or slurs plus a few additions: - setting a title and composer (but nothing else) - (implied) the general format of input files - create output in pdf and midi * schedule 4-6 months for discussion plus infrastructure work * after the discussion has ended, there will be a 6-month and/or 1-stable-release-cycle waiting period before absolutely finalizing that syntax. The microtonal notation issue I highlighted is relevant in this respect because it's almost guaranteed to involve a rewrite of how LP considers pitches and pitch alterations internally. In turn, that might impact all the way back up to a rewrite of LP syntax for those things. And it's a completely standard part of modern musical notation that is currently unsupported by Lilypond. I think we're talking about different things. Let's put it this way: do you think that we'll ever move away from c'4 being a quarter note for middle C ? That's the basic question here. It doesn't matter how lilypond represents c'4 internally (whether it uses grobs or contexts or lilypond rationals or scheme rationals or bits or trits or qubits). All we would be committing is that if the user enters c'4 it would produce a middle C (notwithstanding \relative mode). We could still have other methods of entering pitches (such as the current language method, or scheme methods, or chord-based stuff, etc); all we guarantee is that this one method will work in the future. Don't get me wrong, I think it's excellent to consider future possibilities such as microtonal notation. That's one of the reasons I think we should spend months and months discussing this, as well as having a huge waiting period before absolutely committing to even the most basic input. But whatever happens with contemporary notation, or gregorian chants, or what have you, I think that lilypond will always support basic classical and Romantic music, and I think that we can safely say we will always support c'4 . - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
On Thu, Jul 26, 2012 at 07:03:11PM +0200, David Kastrup wrote:
It's much simpler than that. Expressions are greedy: what can become
a part of them, will.
...
yuck?
\displayMusic c4-3
is existing syntax. Long-existing syntax. A total nuisance to support.
But it is not like there is much choice involved here. It has been
around eternities. Do you think all the backtracking folderol and
mode-switching and token-juggling that is going on in the parser
bypassing the basic LALR(1) algorithm has been implemented because I
consider it fun?
yuck.
Quick off-the-cuff estimate: ignoring all user code, what would we
lose if we forced expressions to explicitly require arguments,
i.e.
\displayMusic { c4-3 }
\displayMusic ( c4-3 )
(ignore the symbol-clash between existing uses of {}() )
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
David Kastrup wrote Thursday, July 26, 2012 6:03 PM
It's much simpler than that. Expressions are greedy: what can become
a part of them, will. For that reason, it may make sense to enclose
simple music in braces, or it is likely to integrate durations and
postevents not intended for it.
For argument parsing it might be nice if { single-music-event } would
not turn into sequential music, similar to how #{ single-music-event #}
doesn't, so that you can make music arguments unambiguous without
causing them to be wrapped in sequential music.
For argument parsing I'd prefer to make spaces significant.
The basic problem is having to parse a set of arguments with
no delimiters to separate them. This is never going to be easy
or satisfactory, given the complex existing syntax, and will lead
inevitably to user surprises. Keith spotted this one; I'd be
surprised if it were the only one.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Thursday, July 26, 2012 6:03 PM
It's much simpler than that. Expressions are greedy: what can become
a part of them, will. For that reason, it may make sense to enclose
simple music in braces, or it is likely to integrate durations and
postevents not intended for it.
For argument parsing it might be nice if { single-music-event } would
not turn into sequential music, similar to how #{ single-music-event #}
doesn't, so that you can make music arguments unambiguous without
causing them to be wrapped in sequential music.
For argument parsing I'd prefer to make spaces significant.
\longa. rather than \longa . ? I think that the duration identifiers
are the most likely candidates followed by spaces before dots. On the
other hand, they can't be confused with unsigneds.
As I said, I'd prefer having reals not end in dots. But chord modifiers
are a nuisance, anyway.
The basic problem is having to parse a set of arguments with no
delimiters to separate them. This is never going to be easy or
satisfactory, given the complex existing syntax, and will lead
inevitably to user surprises. Keith spotted this one; I'd be
surprised if it were the only one.
There are other things:
\displayMusic \displayMusic c-4
Is it
\displayMusic (\displayMusic (c-4))
or
\displayMusic ((\displayMusic c)-4)
or
(\displayMusic \displayMusic c)-4 ?
Stuff like that is not really easy to resolve.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
Graham Percival gra...@percival-music.ca writes:
On Thu, Jul 26, 2012 at 07:03:11PM +0200, David Kastrup wrote:
It's much simpler than that. Expressions are greedy: what can become
a part of them, will.
...
yuck?
\displayMusic c4-3
is existing syntax. Long-existing syntax. A total nuisance to support.
But it is not like there is much choice involved here. It has been
around eternities. Do you think all the backtracking folderol and
mode-switching and token-juggling that is going on in the parser
bypassing the basic LALR(1) algorithm has been implemented because I
consider it fun?
yuck.
Quick off-the-cuff estimate: ignoring all user code, what would we
lose if we forced expressions to explicitly require arguments,
i.e.
\displayMusic { c4-3 }
\displayMusic ( c4-3 )
(ignore the symbol-clash between existing uses of {}() )
Ignoring all user code, what would we lose? That does not even make
sense since the parser is the interface between user code and music
expressions. If we ignore all user code, we don't need a parser.
LilyPond input language is a compromise between expressivity and
readability. If everything needs parens, we are venturing into Scheme
territory.
Still, some compromises are more painful than others. If music
functions were simpler to parse, converters would have better chances to
do the right thing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [Lilypond-auto] Issue 2640 in lilypond: doc enhancement for \headers
On Thu, Jul 26, 2012 at 08:41:36PM +, lilyp...@googlecode.com wrote: Hm. Can't find one there, but there is one in input.itely; the very next example as it happens. This uses a8landscape, but that is not tall enough for Eluze's example. And a8 is not wide enough. a7 is ok, but contains a little blank space. a7landscape would be best, but this doesn't seem to exist. I'll go with a7 for now, unless you would like to advise me how to create a7landscape. Creating a7landscape would just be a single line of code to scm/paper.scm. Just search for a8landscape and I think you can figure out the rest. That said, I'm fine with plain a7. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: clarify \header variables (2640) (issue 6456047)
Reviewers: eluzew_gmail.com,
Message:
I believe this doc change should be ok, but as I
am unable to easily do a full doc build it would
be helpful if a reviewer could offer to test this
for me and check the new example looks correct.
Trevor
Description:
Doc: clarify \header variables (2640)
Revised example and text submitted by Eluse - thanks!
a7landscape paper size added to suit this example
Please review this at http://codereview.appspot.com/6456047/
Affected files:
M Documentation/notation/input.itely
M scm/paper.scm
Index: Documentation/notation/input.itely
diff --git a/Documentation/notation/input.itely
b/Documentation/notation/input.itely
index
fe0af3b5daf4aaddcf320def4da0602a2dfaaea9..608195ab15b44f9acdd5991f7508378005de9e5b
100644
--- a/Documentation/notation/input.itely
+++ b/Documentation/notation/input.itely
@@ -640,47 +640,78 @@ Notation Reference:
@node Default layout of book and score title blocks
@unnumberedsubsubsec Default layout of book and score title blocks
-The layout and formatting of title blocks are controlled by two
-@code{\paper} variables; @code{bookTitleMarkup} for the main
-@code{\header} title block and @code{scoreTitleMarkup} for individual
-@code{\header} blocks within a @code{\score}.
+This example demonstrates all @code{\header} variables:
-@lilypond[papersize=a6,quote,verbatim,noragged-right]
-\header {
- % The following fields are centered
- dedication = Dedication
- title = Title
- subtitle = Subtitle
- subsubtitle = Subsubtitle
- instrument = Instrument
-
- % The following fields are left-aligned on the left side
- poet = Poet
- meter = Meter
-
- % The following fields are right-aligned on the right side
- composer = Composer
- arranger = Arranger
-}
-
-\score {
- { s1 }
+@lilypond[papersize=a7landscape,quote,verbatim,noragged-right]
+\book {
\header {
-% The following fields are placed at opposite ends of the same line
-piece = Piece
-opus = Opus
+ % The following fields are centered
+dedication = Dedication
+title = Title
+subtitle = Subtitle
+subsubtitle = Subsubtitle
+ % The following fields are evenly spread on one line
+ % the field instrument also appears on following pages
+instrument = \markup \with-color #green Instrument
+poet = Poet
+composer = Composer
+ % The following fields are placed at opposite ends of the same line
+meter = Meter
+arranger = Arranger
+ % The following fields are centered at the bottom
+tagline = tagline goes at the bottom of the last page
+copyright = copyright goes at the bottom of the first page
+ }
+ \score {
+{ s1 }
+\header {
+% The following fields are placed at opposite ends of the same line
+ piece = Piece 1
+ opus = Opus 1
+}
+ }
+ \score {
+{ s1 }
+\header {
+% The following fields are placed at opposite ends of the same line
+ piece = Piece 2 on the same page
+ opus = Opus 2
+}
+ }
+ \pageBreak
+ \score {
+{ s1 }
+\header {
+% The following fields are placed at opposite ends of the same line
+ piece = Piece 3 on a new page
+ opus = Opus 3
+}
}
}
@end lilypond
-@c Is the bit about \null markups true? -mp
+Note that
+
+@itemize
+@item
+The instrument name will be repeated on every page.
+
+@item
+Only @code{piece} and @code{opus} are printed in a @code{\score}
+when the paper variable @code{print-all-headers} is set to
+@code{##f} (the default).
+@item
+@c Is the bit about \null markups true? -mp
Text fields left unset in a @code{\header} block are replaced with
@code{\null} markups so that the space is not wasted.
+@item
The default settings for @code{scoreTitleMarkup} place the @code{piece}
and @code{opus} text fields at opposite ends of the same line.
+@end itemize
+
@cindex breakbefore
Use the @code{breakbefore} variable inside a @code{\header} block
Index: scm/paper.scm
diff --git a/scm/paper.scm b/scm/paper.scm
index
e076d692a301dc0098d44fa5f8d9df556b8118d5..f482d9b9b79f8419af2fa48327a9314d4e7197d7
100644
--- a/scm/paper.scm
+++ b/scm/paper.scm
@@ -238,8 +238,9 @@
;; F4 used in southeast Asia and Australia
(f4 . (cons (* 210 mm) (* 330 mm)))
;; Used for very small @lilypond examples in the Documentation
-;; based on a8 size but landscape not portrait
+;; based on a8 and a7 sizes but landscape not portrait
(a8landscape . (cons (* 74 mm) (* 52 mm)))
+(a7landscape . (cons (* 105 mm) (* 74 mm)))
))
;; todo: take dimension arguments.
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
David Kastrup wrote Thursday, July 26, 2012 9:16 PM
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Thursday, July 26, 2012 6:03 PM
It's much simpler than that. Expressions are greedy: what can become
a part of them, will. For that reason, it may make sense to enclose
simple music in braces, or it is likely to integrate durations and
postevents not intended for it.
For argument parsing it might be nice if { single-music-event } would
not turn into sequential music, similar to how #{ single-music-event #}
doesn't, so that you can make music arguments unambiguous without
causing them to be wrapped in sequential music.
For argument parsing I'd prefer to make spaces significant.
\longa. rather than \longa . ?
Yup, no problem with that.
As I said, I'd prefer having reals not end in dots.
I'd be happy with that restriction too.
But chord modifiers are a nuisance, anyway.
I can see that, but do we ever need reals in chordmode?
The basic problem is having to parse a set of arguments with no
delimiters to separate them. This is never going to be easy or
satisfactory, given the complex existing syntax, and will lead
inevitably to user surprises. Keith spotted this one; I'd be
surprised if it were the only one.
There are other things:
\displayMusic \displayMusic c-4
Stuff like that is not really easy to resolve.
That would worry me less. Just choose one of your interpretations
and document it. Although if it is possible to use ( ) or { } to
clarify the order of evaluation that would be better.
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Syntax change proposal:
On 16 Jul 2012, at 02:02, David Kastrup wrote: I am currently in the process of moving parsing of durations and pitches into the lexer instead of the parser (because parser lookahead causes tricky problems, and things like c and c4 can't be parsed without lookahead: any number of ' and/or . may still follow). One really ugly problem is interpreting things like 4.. Looks like a duration, but then we have input/regression/dynamics-broken-hairpin.ly: line-width = 4.\cm From the microtonal point of view, a problem is that accidentals cannot currently be implemented as (post-fix) operators, which if it could, would also fix the parsing problem, I think. So for this feature to work, an expression like c#','4. (writing # for the Unicode musical sharp character, and for a microtonal Persian sori) should be parsed as: first finding the note name c, then switching to the context of accidentals, like # ' , etc., and when a digit is found, switching to the duration context. Names like cis are then in fact unnecessary. Hans ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20120729
For 23:00 MDT (taking Mrs. Patch Nanny for a steam train (1) excursion, with dinner, comedy and a robbery) Sunday July 29 Documentation: Issue 2401 http://code.google.com/p/lilypond/issues/detail?id=2401: NR 1.2.4 - Not working snippet in German translation - R 6447043 http://codereview.appspot.com/6447043/ Enhancement: Issue 2698 http://code.google.com/p/lilypond/issues/detail?id=2698: Patch: Syntax change: don't allow degenerate REAL -. - R 6446048 http://codereview.appspot.com/6446048/ Issue 2696 http://code.google.com/p/lilypond/issues/detail?id=2696: Patch: 4 issues related to rational duration factors. - R 6453044 http://codereview.appspot.com/6453044/ Ugly: Issue 2673 http://code.google.com/p/lilypond/issues/detail?id=2673: Volta improvements - R 6422061 http://codereview.appspot.com/6422061/ Cheers, Colin (1) http://www.absteamtrain.com/ -- 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
Issue 1650: Multiple header blocks shall be merged rather than replace a previous one (issue 6441058)
http://codereview.appspot.com/6441058/diff/1/lily/parser.yy File lily/parser.yy (right): http://codereview.appspot.com/6441058/diff/1/lily/parser.yy#newcode932 lily/parser.yy:932: /* Copy the new header fields, i.e. overwrite existing, but preserve unchanged ones */ I think this is the wrong way to do things since you can't refer to old header values when defining the new one. Instead, you should start with the definition you are adding things to, like LAYOUT and similar do. So that likely means that you need to change the definition of lilypond_header (or create several versions of it) to make it not start from an empty slate. http://codereview.appspot.com/6441058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 1650: Multiple header blocks shall be merged rather than replace a previous one (issue 6441058)
On 2012/07/27 05:09:22, dak wrote: http://codereview.appspot.com/6441058/diff/1/lily/parser.yy File lily/parser.yy (right): http://codereview.appspot.com/6441058/diff/1/lily/parser.yy#newcode932 lily/parser.yy:932: /* Copy the new header fields, i.e. overwrite existing, but preserve unchanged ones */ I think this is the wrong way to do things since you can't refer to old header values when defining the new one. Instead, you should start with the definition you are adding things to, like LAYOUT and similar do. So that likely means that you need to change the definition of lilypond_header (or create several versions of it) to make it not start from an empty slate. Actually, it looks like it just doing that: taking the old value and adding to it. So what it the problem you are trying to cure here? http://codereview.appspot.com/6441058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
