spaces must be inserted around property commands?
NR 2.1.2 Entering lyrics: Lyrics explained states... Similarly, a period which follows an alphabetic sequence is included in the resulting string. As a consequence, spaces must be inserted around property commands: do not write \override Score.LyricText #'font-shape = #'italic but instead use \override Score . LyricText #'font-shape = #'italic Is this true? If so, I've been doing it the wrong way all along! This is not mentioned in 4.1.4 Tweaking methods: \override command which states... The general syntax of this command is: \override Context.LayoutObject #'layout-property = #value Somebody clear me up! Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: spaces must be inserted around property commands?
Well, it's only specific to Lyrics. Earlier in the section, it states: A word or syllable of lyrics begins with an alphabetic character, and ends with any space or digit… Any character that is not a digit or white space will be regarded as part of the syllable; one important consequence of this is that a word can end with }… Am 15.12.2008 um 09:02 schrieb Mark Polesky: NR 2.1.2 Entering lyrics: Lyrics explained states... Similarly, a period which follows an alphabetic sequence is included in the resulting string. As a consequence, spaces must be inserted around property commands: do not write \override Score.LyricText #'font-shape = #'italic but instead use \override Score . LyricText #'font-shape = #'italic Is this true? If so, I've been doing it the wrong way all along! This is not mentioned in 4.1.4 Tweaking methods: \override command which states... The general syntax of this command is: \override Context.LayoutObject #'layout-property = #value Somebody clear me up! Thanks. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: spaces must be inserted around property commands?
Mark Polesky wrote Monday, December 15, 2008 8:02 AM NR 2.1.2 Entering lyrics: Lyrics explained states... Similarly, a period which follows an alphabetic sequence is included in the resulting string. As a consequence, spaces must be inserted around property commands: do not write \override Score.LyricText #'font-shape = #'italic but instead use \override Score . LyricText #'font-shape = #'italic Is this true? If so, I've been doing it the wrong way all along! This is not mentioned in 4.1.4 Tweaking methods: \override command which states... Yes, this is true, but only for overrides which are entered *directly* in \lyricmode. It is not necessary for other overrides or for overrides entered as part of a variable which is then applied in \lyricmode. The general syntax of this command is: \override Context.LayoutObject #'layout-property = #value This is the general syntax, but the rider above needs to be applied when entering overrides directly in \lyricmode. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build failure
Op vrijdag 12-12-2008 om 06:18 uur [tijdzone -0800], schreef Graham Percival: Problem building the netpbm package. gcc doesn't seem to recognize the -flax-vector-conversions option, What happens if you remove that option? It would be nice if this option is only needed for gccs that are so new that they are too strict with vector conversions? We could then add some code like in gub/specs/librestrict.py but doens't gub download gcc itself to avoid specific-version compiler problems? Yes, but not for target/tools/*. Using a gub-compiled gcc there could be more robust, but would be a lot of work still, esp. bootstrapping this could be tricky. We still use all kinds of dependencies (glibc, zlib, whatnot from /usr to build tools/). Jan. -- Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: function lookup
So there is a distinction between parser keywords and music functions?
On Sun, Dec 14, 2008 at 12:43 PM, Neil Puttock n.putt...@gmail.com wrote:
Hi John,
2008/12/14 John Mangual john.mang...@gmail.com:
how would i go about looking up the scheme source code for a specific
function like transpose or tuple or key
It depends on whether the function is a parser keyword or music
function; if it's the latter (you can check this by looking at
appendix B.14, Identifiers) then you're most likely to find it in
ly/music-functions-init.ly.
In the case of keywords, you'll have to follow the trail from the
parser. For example, here's the parser entry for \transpose:
| TRANSPOSE pitch_also_in_chords pitch_also_in_chords music {
Pitch from = *unsmob_pitch ($2);
Pitch to = *unsmob_pitch ($3);
SCM pitch = pitch_interval (from, to).smobbed_copy ();
$$ = MAKE_SYNTAX (transpose-music, @$, pitch, $4);
}
The MAKE_SYNTAX macro calls the Scheme function transpose-music, which
you'll find in scm/ly-syntax-constructors.scm:
(define-ly-syntax-simple (transpose-music pitch music)
(make-music 'TransposedMusic
'element (ly:music-transpose music pitch)))
Regards,
Neil
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 11:25 AM, Trevor Bača trevorb...@gmail.com wrote:
6. Lily reads the terminal close } brace. Even here, I'm willing to bet,
Lily sees no reason to kill off the explicit named foo context. I bet Lily
reads the terminal close } brace and instead simply closes off the original
music *expression*. My guess would be that not until EOF does Lily finally
kill off the original named foo context.
EOF does not play any role in this. The parsing into trees of music
expressions is done beforehand, and the iteration is not connected
directly with the input file.
Each iterator contains a pointer to the context it delivers events to.
This pointer is actually reference counted, and a context is ended
when its reference count drops to zero.
== naked { } expressions DO NOT cause contexts to be instantiated at the
open { brace and destroyed at the close } brace.
Look for descend_to_bottom(). Generally, event chords (rests, notes,
lyrics) cause a bottom context (lyrics, voice, chordnames) to be
instantiated as child of the current context.
The iterator for { } (sequential) will change its context to the one
of its child if that child has a deeper level than the current one.
so,
\new Staff { c d }
the iterator for 'c' will create a Voice, the enclosing iterator will
change from Staff to Voice, since Voice is deeper nested in the
context tree.
This is a super long-winded way of me coming around to Carl's mental model:
Try not to form mental models. Use the source instead.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Reinhold Kainhofer: However, I'm now running into the next problem: Lilypond's configure claims it is missing guile! - From the log file: configure:8270: checking for scm_boot_guile configure:8326: i686-linux-gcc -I/home/lilypond/gub/target/linux- x86/build/lilypond-git.sv.gnu.org--lilypond.git-master -o conftest -O2 - finline-functions -g -pipe -I/home/lily pond/gub/target/linux-x86/root/usr/include -Wl,--as-needed conftest.c - L/home/lilypond/gub/target/linux-x86/root/usr/lib -lguile -lgmp -ldl 5 conftest.c:8:1: warning: PACKAGE_NAME redefined conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libltdl.so.3: undefined reference to `__stack_chk_f...@glibc_2.4' collect2: ld returned 1 exit status configure:8332: $? = 1 [...] configure:10752: checking for pango_ft2_font_map_create_context configure:10808: i686-linux-gcc -I/home/lilypond/gub/target/linux- x86/build/lilypond-git.sv.gnu.org--lilypond.git-master -o conftest -O2 - finline-functions -g -pipe -I/home/lil ypond/gub/target/linux-x86/root/usr/include/python2.4 - I/home/lilypond/gub/target/linux-x86/root/usr/include/pango-1.0 - I/home/lilypond/gub/target/linux-x86/root/usr/include/free type2 -I/home/lilypond/gub/target/linux-x86/root/usr/include - I/home/lilypond/gub/target/linux-x86/root/usr/include/glib-2.0 - I/home/lilypond/gub/target/linux-x86/root/usr/lib/gli b-2.0/include-Wl,--as-needed -Wl,-rpath -Wl,\$$ORIGIN/../lib conftest.c - L/home/lilypond/gub/target/linux-x86/root/usr/lib -lpangoft2-1.0 -lpango-1.0 - lfreetype -lz -lfontcon fig -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -ldl 5 conftest.c:8:1: warning: PACKAGE_NAME redefined conftest.c:2:1: warning: this is the location of the previous definition /home/lilypond/gub/target/tools/root/usr/lib/libexpat.so.0: undefined reference to `__stack_chk_f...@glibc_2.4' collect2: ld returned 1 exit status Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlyXTqjEwhXvPN0RAuqvAJ9q4WcwBo5rdIOefwE/QGE8Q37q+wCfXi5q Iav13eE6fRLaCRV+QGuUkbk= =xmTM -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Problem with GDP doc build on kainhofer.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 06:20:21 schrieb Carl D. Sorensen: I've noticed that there's a problem with the doc build on kainhofer.com. Yes, the build has been failing for some days already. I'm doing a clean build now... Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRjD8TqjEwhXvPN0RAhvoAKDIDr7rYiK+0xLpGPUFQ7wmPdB88wCgpGRJ vHuaA4+7fuLiV7iEK4IkIQE= =eygV -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Building LilyPond with GUB on a 64bit machine with 32bit OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen: Op zaterdag 13-12-2008 om 01:59 uur [tijdzone +0100], schreef Reinhold Kainhofer: Unfortunately, gmp does not build there, since the configure check seems to think it is on a 64-bit platform: Is this with GUB3? It's the checkout of git://github.com/janneke/gub.git checking size of mp_limb_t... 4 You can look in configure.ac for the test with this text configure: error: Oops, mp_limb_t is 32 bits, but the assembler code in this configuration expects 64 bits. and fix or disable it. Searching the web and the mailing lists a bit more revealed that there is an undocumented environment variable, which one can use to force a given ABI: ABI=32 make lilypond It's not ideal that gmp doesn't detect this automatically, but at least now it builds correctly. However, I'm now running into the next problem: Lilypond's configure claims it is missing guile! Here's the output: [...] checking for guile-config... i686-linux-guile-config checking i686-linux-guile-config version... 1.8.5 checking guile compile flags... -I/home/lilypond/gub/target/linux- x86/root/usr/include checking guile link flags... -L/home/lilypond/gub/target/linux-x86/root/usr/lib - -lguile -lgmp checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... no checking for scm_boot_guile... no checking GUILE rational bugfix... ok [...] checking for guile... guile checking for guile... /home/lilypond/gub/target/tools/root/usr/bin/guile [...] config.status: creating config.make config.status: creating config.hh config.status: config.hh is unchanged ERROR: Please install required programs: libguile (libguile-dev, guile-devel or guile-dev package). Strange enough, on that same machine the nightly binary and docs builds work fine and detect guile just fine... The configure output of the current git master (using the system-wide installed guile) is: [...] checking for guile-config... guile-config checking guile-config version... 1.8.5 checking guile compile flags... -pthread checking guile link flags... -pthread -lguile -lltdl -Wl,-Bsymbolic-functions - -lgmp -lcrypt -lm -lltdl checking libguile.h usability... yes checking libguile.h presence... yes checking for libguile.h... yes checking for scm_boot_guile in -lguile... yes checking for scm_boot_guile... yes checking GUILE rational bugfix... ok [...] checking for guile... guile checking for guile... /usr/bin/guile So, apparently the guile built by gub is missing scm_boot_guile or some link flag Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlhsTqjEwhXvPN0RApAyAJ9MuLyiQu3M0xmn2pQ2+2PQxQIYOACeNlAG iiE7n2bGfUUQA8uUWOeqjnU= =/7rL -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LP's staff lines are thinner than Henle...
On 12/14/08 11:45 PM, Mark Polesky markpole...@yahoo.com wrote: LM 1.1 Background - Engraving states: our staff lines... are also much thicker than lines in the computer edition. In both the HTML and PDF versions, LilyPond's staff lines are in fact the thinnest when compared. I've included a png to make this easier to see. In the HTML version, the distance from top to bottom staff line of the LP example was smaller than the other 2, but even when scaling the LP example to match the other 2 (as I've done here) the LP lines are still the thinnest. The PDF example is magnified about 300 times. Can someone explain this? - Mark The staff lines on your other examples have been broadened by anti-aliasing. The staff line on the LilyPond example have not been, because it's a vector drawing. So your comparision is not apt. I have not viewed the originals to make any judgement of them. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LP's staff lines are thinner than Henle...
Years ago I made a 4800dpi film in a printshop. It was surprisingly different than a 600dpi laser-print. So to make a fair comparison one should print pages with the same professional technology and see. Bert Carl D. Sorensen wrote: On 12/14/08 11:45 PM, Mark Polesky markpole...@yahoo.com wrote: LM 1.1 Background - Engraving states: our staff lines... are also much thicker than lines in the computer edition. In both the HTML and PDF versions, LilyPond's staff lines are in fact the thinnest when compared. I've included a png to make this easier to see. In the HTML version, the distance from top to bottom staff line of the LP example was smaller than the other 2, but even when scaling the LP example to match the other 2 (as I've done here) the LP lines are still the thinnest. The PDF example is magnified about 300 times. Can someone explain this? - Mark The staff lines on your other examples have been broadened by anti-aliasing. The staff line on the LilyPond example have not been, because it's a vector drawing. So your comparision is not apt. I have not viewed the originals to make any judgement of them. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: gub3 build failure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Montag, 15. Dezember 2008 schrieb Jan Nieuwenhuizen: Op vrijdag 12-12-2008 om 06:18 uur [tijdzone -0800], schreef Graham Percival: Problem building the netpbm package. gcc doesn't seem to recognize the -flax-vector-conversions option, What happens if you remove that option? It would be nice if this option is only needed for gccs that are so new that they are too strict with vector conversions? We could then add some code like in gub/specs/librestrict.py I've now upgraded the server to kubuntu intrepid, so I can't test this any more... With intrepid (gcc 4.3.x instead of 4.2.4 in hardy) the netpbm builds without problems. Cheers, Reinhold - -- - -- Reinhold Kainhofer, Vienna University of Technology, Austria email: reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/ * K Desktop Environment, http://www.kde.org, KOrganizer maintainer * Chorvereinigung Jung-Wien, http://www.jung-wien.at/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJRlOSTqjEwhXvPN0RAtGaAJsH+QgOFs2Qq4JydFDB6R4Mjp9gjACfcJTc bhcWsgbxhrYjApMWiLfSJ54= =vgL9 -END PGP SIGNATURE- ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: spaces must be inserted around property commands?
On Mon, Dec 15, 2008 at 10:15 AM, Trevor Daniels t.dani...@treda.co.uk wrote: This is the general syntax, but the rider above needs to be applied when entering overrides directly in \lyricmode. This is already documented, but making it clearer is on my TODO-list for when I get a life (ETA 2 weeks or so). Cheers, Valentin ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
thin bar lines are thinner than Henle...
While browsing the introductory docs I noticed that in those showing 'us' vs 'them' vs 'Henle' thin bars were same line thickness as staff lines in 'us' and 'them', but slightly thicker in 'Henle'. Perhaps some discussion would strengthen our claims. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 7:18 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Try not to form mental models. Use the source instead. Unfortunately, not very many of us understand the source completely, and so we need mental models to work in LilyPond. Of course, our mental models will be incorrect in some detail, and we'll need to revise them from time to time. But even if we use the source, we'll have to make mental models of the source, and those may be incorrect as well. Maybe I'm the only person who doesn't understand the full source code, but I doubt it. Certainly developers should understand the source code when they modify it, and understanding the source code is preferable to an incorrect mental model, but the idea of documentation is to allow users to form correct mental models about program operation WITHOUT reading the source code. So I believe that we SHOULD form mental models, based on the docs and our experiences, and whenever there's a weakness in the mental model, it points to a place to improve the docs. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen c_soren...@byu.edu wrote: On 12/15/08 7:18 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Try not to form mental models. Use the source instead. Unfortunately, not very many of us understand the source completely, and so we need mental models to work in LilyPond. Of course, our mental models will be incorrect in some detail, and we'll need to revise them from time to time. sure, but if you spend a lot of time and effort on theorizing (like Trevor did), you might as well invest that time effort into looking at the source code itself. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
2008/12/15 Carl D. Sorensen c_soren...@byu.edu: On 12/15/08 7:18 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Try not to form mental models. Use the source instead. Unfortunately, not very many of us understand the source completely, and so we need mental models to work in LilyPond. Of course, our mental models will be incorrect in some detail, and we'll need to revise them from time to time. I have a question for the few developers that in some degree do understand the source code and are able to hack it, fix bugs, implement new features, etc. Is the code properly commented, so that (thinking on the future) new people can learn from it without having to figure out all the time what does each function, file etc. do? Sure, I can look at it and say, but I want the opinion of skilled programmers. If not, is there any chance of this to improve? -- Francisco Vila. Badajoz (Spain) http://www.paconet.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR-snippet for tick barline
2008/12/14 Reinhold Kainhofer reinh...@kainhofer.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just saw the git commit to update input/lsr/tick-bar-lines.ly I suppose it would be easier / better to use \set Score.defaultBarType = ' globally instead of explicit \bar ' for each barline... Ah yes, I couldn't for the life of me remember the correct property for this; I wasted time playing around with whichBar and 'glyph for some reason. I guess my brain wasn't in gear yesterday, what with this *and* reviewing patches that had already been sorted. :) Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 09:26:15PM +0100, Francisco Vila wrote: Is the code properly commented, so that (thinking on the future) new people can learn from it without having to figure out all the time what does each function, file etc. do? Sure, I can look at it and say, but I want the opinion of skilled programmers. If not, is there any chance of this to improve? In my (somewhat limited) experience, no matter how good the documentation for source code, getting involved in a large project is always easier if you have a mentor. There's always little details or tricks that a person can pass along that never make it into the source docs... and besides, a mentor can tailor his answers directly to your questions, rather than the general info that you'd find in documentation. That's why I was hoping that somebody would offer to be the Frogmeister (you can have a non-silly name if you want!). People willing to spend time fixing bugs would gain a mentor to guide them towards a better understanding of the source code, and the mentor would gain more people fixing bugs in lilypond (which in turn leads to a better program which presumably the mentor is using :). Sure, we could ask a skilled developer to spend 50 hours writing better source docs... but I don't think that's a good trade-off. Their time is so limited, and the number of potential developers is so small, that I think that personal mentorship is the best way to go. Now, if one of those new developers wants to spend 5 hours a week carefully documenting what he's learned about the internals while fixing bugs, I certainly wouldn't object. But of course, that developer needs to consider the trade-offs involved: more bug fixes? Writing translations? Documenting the source code? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changing snippets in the documentation
Hi Carl, The make web choked on trying to run a lilypond snippet. I looked at the snippet, and the reason that lilypond choked was because the snippet was the *old* version of the snippet, not the new version of the snippet. So the last lines of the make web output aren't likely to be helpful. If there are helpful lines in the output, they would be likely to show up somewhere above, where snippets are extracted from the .itely files. The old snippets were in the translations; running update-snippets.py copied the syntax changes over from user. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 6:25 AM, Trevor Bača trevorb...@gmail.com wrote:
On Sun, Dec 14, 2008 at 9:10 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Mon, Dec 15, 2008 at 12:18 AM, Trevor Bača trevorb...@gmail.com wrote:
... even though contexts do not literally nest! (Even though their iterators
inherit from one another.)
So, to resume, this leads to the following situation:
EXPRESSIONS:
* exhibit syntactic nesting
* do not exhibit 'visual nesting' (or, maybe, 'properties nesting')
CONTEXTS:
* do not exhibit syntactic nesting
* do exhibit 'visual nesting' / 'properties nesting'
Or maybe a better way of saying it:
EXPRESSIONS:
* exhibit syntactic nesting
* do not store grob properties
CONTEXTS:
* do not exhibit syntactic nesting
* do store grob properties
Hm. I think I get it now. Much thanks to everyone. If anyone sees more details
missing from my working-out process, please correct.
Trevor.
I'd say it differently:
EXPRESSIONS:
Establish the timing of music-events relative to one another
So there is no difference between
{ {c4 d} {e f} {g a}}
and
{c4 d e f g a }
Similarly, there is no difference between
{
{\override myObject #'prop = #value c4 d}
{\override myObject #'prop = #new-value e f}
{g a}
}
and
{
\override myObject #'prop = #value c4 d
\override myObject #'prop = #new-value e f
g a
}
Both expressions cause the first override to apply to the current context
starting and the moment of the note c4 and the second override to apply
starting at the moment of the note e.
Note that those overrides will apply to ALL OBJECTS OF TYPE myObject IN THE
CURRENT CONTEXT, starting at those times.
So
{ c4 d \override myObject #'prop = #value e f}
{ g4 a b c}
will have the overrides applied to the e, f, b, and c, but not g4 and a.
This is because it's the music moment, not the source file relative
location, that defines the applicability of the overrides.
CONTEXTS:
Provide the evaluation environment (my words, not Han-Wen's) in which all
music events will be evaluated when it's time to put them in the output
stream (midi file or printed page).
All properties that matter but are not tied to a particular grob reside in
a context that contains the grob. They may be tied to the immediate
context containing the grob (e.g. Voice, for NoteHead) or may come from
a context above the current context in the heierarchy (e.g. the Staff that
contains the Voice that contains the notehead).
The confusion comes in because, if there is no appropriate context
available, when LilyPond sees a music expression it will automatically
create a context. And there is nothing in the input syntax that tells you
when the context will be created. So I continue to get surprised from time
to time if I don't explicitly instantiate all contexts.
I think your discussion about naked music expressions is illuminating, but
also potentially confusing. It's not naked expressions that cause the
challenge, but expressions that occur at a point in the music stream (not
the input stream) where no appropriate context exists, therefore requiring
LilyPond to create one.
So if we look at your example 2:
%%% VOICE-RESOLUTION EXAMPLE 2 %%%
\version 2.11.57
{
\new Voice = foo {
\override Voice.NoteHead #'color = #red
g'8
a'8
b'8
c''8
}
d''8
e''8
f''8
g''8
}
%%% END EX 2 %%%
Looking in music stream (not input stream) order:
1a instantiate Voice foo (this takes no musical time). Oops, we don't have
a Staff context to hold foo, so we'll need to create one.
1b Make an override to the notehead color (this also takes no musical time)
1c engrave g'8 (this is the first thing that takes musical time)
2 engrave a'8
3 engrave b'8
4 engrave c''8
Now we're done with the music expression explicitly created in voice foo
5 engrave d''8 -- and since we have a voice foo, just keep on with it.
6 engrave e''8
7 engrave f''8
8 engrave g''8
In contrast, we have Example 2+1 Note:
%%% EX 2 + 1 NOTE %%%
{
c'8
\new Voice = foo {
\override Voice.NoteHead #'color = #red
g'8
a'8
b'8
c''8
}
d''8
e''8
f''8
g''8
}
%%% END EX 2 MOD %%%
Looking at this in music stream order we have
1. engrave c'8. Oops, we don't have a Voice context to engrave c'8.
Therefore we need to create a Voice context for c'8. And since we don't
have a Staff to hold the Voice, we'll need to create a Staff context as
well.
2a. create a new Voice context called foo, and assign the next expression
to voice foo. (no musical time)
2b. engrave g'8 in foo context
3. engrave a'8 in foo context
4. engrave b'8 in foo context
5. engrave c''8 in foo context
Now I'm done with the music expression that was assigned to Voice foo.
6. engrave d''8. It goes in the Voice context that we were using
before we
Re: Scheme function to print out active Voice context during interpretation?
2008/12/15 Carl D. Sorensen c_soren...@byu.edu: I'd say it differently: EXPRESSIONS: Establish the timing of music-events relative to one another CONTEXTS: Provide the evaluation environment (my words, not Han-Wen's) in which all music events will be evaluated when it's time to put them in the output stream (midi file or printed page). very well said. The confusion comes in because, if there is no appropriate context available, when LilyPond sees a music expression it will automatically In this case, the order of instantation depends on the order in the music expression, which helps people confuse context and music expressions too. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
[PATCH] Fix custom key signatures which use octave-specific accidentals
Hello, Please review: http://codereview.appspot.com/11052 Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 2:26 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
2008/12/15 Carl D. Sorensen c_soren...@byu.edu:
I'd say it differently:
EXPRESSIONS:
Establish the timing of music-events relative to one another
CONTEXTS:
Provide the evaluation environment (my words, not Han-Wen's) in which all
music events will be evaluated when it's time to put them in the output
stream (midi file or printed page).
very well said.
The confusion comes in because, if there is no appropriate context
available, when LilyPond sees a music expression it will automatically
In this case, the order of instantation depends on the order in the
music expression, which helps people confuse context and music
expressions too.
But it's the order in the music stream, not the input stream, isn't it?
Otherwise, why does
{
\new Voice=foo {
c
}
d
}
result in only a single voice being instantiated, but
{
d
\new Voice=foo {
c
}
}
result in two voices being instantiated?
Thanks,
Carl
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
code comments (was Re: Scheme function to print out active Voice context during interpretation?)
On Mon, Dec 15, 2008, Francisco Vila paconet@gmail.com said: I have a question for the few developers that in some degree do understand the source code and are able to hack it, fix bugs, implement new features, etc. Is the code properly commented, so that (thinking on the future) new people can learn from it without having to figure out all the time what does each function, file etc. do? Newbie to the project, but one who has been programming since 1968, this is something I have discussed at length with other experience programmers. I speak in general, have yet to delve into Lp code at all, so please forgive if this is already covered by a project policy or perhaps a gnu policy. Good code commenting is a challenging skill, at its best the comments on archived code should Be accurate, uptodate, not telling lies. Explain why someone would want to invoke the code Describe context for use - arguments in, side effects, value(s) returned. Cite sources for non-trivial algorythms used, if original, publish a white paper to the project which can be cited. In many cases comments will exceed the code itself. Line-by-line comments are sometimes useful but should give information beyond the obvious. In a language like postscript the expected state of the stack is ofen a useful comment. Some projects embed text for documentation and help files with the code itself to encourage parallel maintenance. -- Dana Emery ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen c_soren...@byu.edu
wrote:
On 12/15/08 7:18 AM, Han-Wen Nienhuys hanw...@gmail.com wrote:
Try not to form mental models. Use the source instead.
Unfortunately, not very many of us understand the source completely, and
so
we need mental models to work in LilyPond. Of course, our mental models
will be incorrect in some detail, and we'll need to revise them from time
to
time.
sure, but if you spend a lot of time and effort on theorizing (like
Trevor did), you might as well invest that time effort into looking
at the source code itself.
I think both are good: wanton speculation taken together with digging
through source.
:-)
I've been digging through source this morning ... and I'm understanding much
better ... but still unable to resolve at least one example, which I've
included at the end of this message.
What I've found so far:
* There are 22 -iterator.cc files with Music_iterator being the base class
from which the others all directly (or, more usually, indirectly) inherit.
(Simple_music_iterator, Music_wrapper_iterator and Sequential_iterator are
all popular choices to derive from, too, but all three inherit from
Music_iterator at base.) Concrete iterators exist to iterate over regular
stuff like EventChord and and 'simple music' (which parser.yy makes me think
means basically notes and rests). Iterators also exist to iterate over more
complex music expressions like grace music, time-scaled music, voltas, and
music expressions passed to the \unfold command. My understanding of this
flock of iterators available in the C++ source is as a type of realization
of the visitor pattern that separates traversal from other activities like
calculation and modification.
* Additionally, both the comments at the head of music-iterator.hh and
Erik's thesis make it clear that the object over which the different
iterators iterate is a (conceptual) queue of music events *that all happen
at the same moment*. That is, when it comes time to iterate, the first thing
that happens is that the entire context tree (starting from the Global
context and proceeding all the way to bottom-level voice contexts) are
*prepared* for Moment 0; then iterators iterate over all events that happen
at Moment 0 *no matter at which level of the context tree those different
events occur*. This helps because I was assuming (wrongly) earlier that
iteration would be a depth-first search starting from the root of the
expression tree; if that were the case then each context would be visited
before any of its children. But, in fact, section 9.4 of Erik's thesis says
One of the consequences of a OneTimeStep stream event, is that all contexts
are visited in a post-order tree walk; i.e., each context is visited after
all its children have been visited. I haven't been able to verify this in
the code, however.
* I've also found that a pronouncement like \new Voice { c'4 } is actually
THREE expressions. The \new Voice is actually a music expression all by
itself (of type ContextSpeccedMusic). There is a
Context_specced_music_iterator defined in an eponymous .cc file and
inheriting from Music_wrapper_iterator. The purpose of the
Context_specced_music_iterator is to descend to the one (and only one) child
that each ContextSpeccedMusic like \new Voice music have: something like
Sequential is the usual option. So the parser (which I only understand
vaguely) decomposes \new Voice { c'4 } into three expressions with \new
Voice parsed as ContextSpeccedMusic, with { } parsed as Sequential, with
c'4 parsed as EventChord (I think). Further, the parser builds the
resulting music expression such that ContextSpeccedMusic is the parent of
Sequential which is, in turn, the parent of EventChord.
* Also, all parsing is done before any iteration is done.
* OK, so based on this understanding, can somebody please correct my
understanding of the parsing (not the iteration, just the parsing) of the
following expression (which is the same as my original example #2):
{
\new Voice {
c'8 c'8 c'8 c'8
}
d'8 d'8 d'8 d'8
}
If I'm understanding how the parser works, then what should result here is a
music expression that looks like this:
Global
V
\new Score
V
\new Staff
V
\new Voice
V
Sequential
V
\new Voice, d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
If I'm counting correctly, that's 15 total nodes in the expression tree.
Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
Staff and the first \new Voice are all created implicitly.
I know that the next part in the process is iteration. But I want to stop
and check my understanding here: am I understanding the output
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 3:12 PM, Trevor Bača trevorb...@gmail.com wrote:
On Mon, Dec 15, 2008 at 2:09 PM, Han-Wen Nienhuys hanw...@gmail.com wrote:
On Mon, Dec 15, 2008 at 5:25 PM, Carl D. Sorensen c_soren...@byu.edu wrote:
On 12/15/08 7:18 AM, Han-Wen Nienhuys hanw...@gmail.com wrote:
Try not to form mental models. Use the source instead.
Unfortunately, not very many of us understand the source completely, and so
we need mental models to work in LilyPond. Of course, our mental models
will be incorrect in some detail, and we'll need to revise them from time
to
time.
sure, but if you spend a lot of time and effort on theorizing (like
Trevor did), you might as well invest that time effort into looking
at the source code itself.
I think both are good: wanton speculation taken together with digging through
source.
:-)
I've been digging through source this morning ... and I'm understanding much
better ... but still unable to resolve at least one example, which I've
included at the end of this message.
What I've found so far:
* There are 22 -iterator.cc files with Music_iterator being the base class
from which the others all directly (or, more usually, indirectly) inherit.
(Simple_music_iterator, Music_wrapper_iterator and Sequential_iterator are all
popular choices to derive from, too, but all three inherit from Music_iterator
at base.) Concrete iterators exist to iterate over regular stuff like
EventChord and and 'simple music' (which parser.yy makes me think means
basically notes and rests). Iterators also exist to iterate over more complex
music expressions like grace music, time-scaled music, voltas, and music
expressions passed to the \unfold command. My understanding of this flock of
iterators available in the C++ source is as a type of realization of the
visitor pattern that separates traversal from other activities like
calculation and modification.
* Additionally, both the comments at the head of music-iterator.hh and Erik's
thesis make it clear that the object over which the different iterators
iterate is a (conceptual) queue of music events *that all happen at the same
moment*. That is, when it comes time to iterate, the first thing that happens
is that the entire context tree (starting from the Global context and
proceeding all the way to bottom-level voice contexts) are *prepared* for
Moment 0; then iterators iterate over all events that happen at Moment 0 *no
matter at which level of the context tree those different events occur*. This
helps because I was assuming (wrongly) earlier that iteration would be a
depth-first search starting from the root of the expression tree; if that were
the case then each context would be visited before any of its children. But,
in fact, section 9.4 of Erik's thesis says One of the consequences of a
OneTimeStep stream event, is that all contexts are visited in a post-order
tree walk; i.e., each context is visited after all its children have been
visited. I haven't been able to verify this in the code, however.
* I've also found that a pronouncement like \new Voice { c'4 } is actually
THREE expressions. The \new Voice is actually a music expression all by
itself (of type ContextSpeccedMusic). There is a
Context_specced_music_iterator defined in an eponymous .cc file and inheriting
from Music_wrapper_iterator. The purpose of the Context_specced_music_iterator
is to descend to the one (and only one) child that each ContextSpeccedMusic
like \new Voice music have: something like Sequential is the usual option.
So the parser (which I only understand vaguely) decomposes \new Voice { c'4
} into three expressions with \new Voice parsed as ContextSpeccedMusic,
with { } parsed as Sequential, with c'4 parsed as EventChord (I think).
Further, the parser builds the resulting music expression such that
ContextSpeccedMusic is the parent of Sequential which is, in turn, the parent
of EventChord.
* Also, all parsing is done before any iteration is done.
* OK, so based on this understanding, can somebody please correct my
understanding of the parsing (not the iteration, just the parsing) of the
following expression (which is the same as my original example #2):
{
\new Voice {
c'8 c'8 c'8 c'8
}
d'8 d'8 d'8 d'8
}
If I'm understanding how the parser works, then what should result here is a
music expression that looks like this:
Global
V
\new Score
V
\new Staff
V
\new Voice
V
Sequential
V
\new Voice, d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
If I'm counting correctly, that's 15 total nodes in the expression tree. Eight
atomic nodes and seven internal nodes. The Global, \new Score, \new Staff and
the first \new Voice are all created
Re: LP's staff lines are thinner than Henle...
On Mon, Dec 15, 2008 at 02:07:35PM -0800, Mark Polesky wrote: I'm intentionally making a big deal out of this because this is the text on page 2 of the manual, and disingenuous claims are off-putting to new users. We're trying to sell a product, but our pitch is unconvincing and maybe a little suspicious. Thanks for looking into this. My initial thought is that we should print out our flat (at 4800dpi or whatever), then scan that printout. This would avoid any pdf-png confusion, as well as presenting a more unified comparison. (well, it would if we could print it on the same paper as the Henle and Barenreiter flats used) However -- and I really hate asking people to delay things when they're enthusiastic -- could you wait a few weeks until GOP starts? With Christmas and preparing for 2.12, this isn't the best of times to fiddle with such details. In addition, the entire Engraving essay will be removed from the LM, put somewhere else, and quite possibly be rewritten from scratch as part of GOP. (that said, we will probably retain the comparison of flats, so perhaps there's no point waiting before producing the scans) Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
Hi Trevor,
On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača trevorb...@gmail.com wrote:
* OK, so based on this understanding, can somebody please correct my
understanding of the parsing (not the iteration, just the parsing) of the
following expression (which is the same as my original example #2):
{
\new Voice {
c'8 c'8 c'8 c'8
}
d'8 d'8 d'8 d'8
}
If I'm understanding how the parser works, then what should result here is a
music expression that looks like this:
Global
V
\new Score
V
\new Staff
V
\new Voice
V
Sequential
V
\new Voice, d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
If I'm counting correctly, that's 15 total nodes in the expression tree.
Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
Staff and the first \new Voice are all created implicitly.
I know that the next part in the process is iteration. But I want to stop
and check my understanding here: am I understanding the output of the parser
correctly at this point?
I'm pretty sure this would be the result *after* iteration.
The parser output can be visualized with \displayMusic. So your
example would look like this, using your convention above:
Sequential
VV
\new Voice d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
After this, the iteration process starts, proceeding moment by moment
and making sure everything is placed in the correct context. Then you
would end up with a tree that looks like the one you posted. I
believe the implicit creation of contexts happens during iteration.
(I could be completely wrong, but it makes sense to me).
-Patrick
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 8:12 PM, Trevor Bača trevorb...@gmail.com wrote:
* OK, so based on this understanding, can somebody please correct my
understanding of the parsing (not the iteration, just the parsing) of the
following expression (which is the same as my original example #2):
{
\new Voice {
c'8 c'8 c'8 c'8
}
d'8 d'8 d'8 d'8
}
If I'm understanding how the parser works, then what should result here is a
music expression that looks like this:
Global
V
\new Score
V
\new Staff
V
\new Voice
V
Sequential
V
\new Voice, d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
If I'm counting correctly, that's 15 total nodes in the expression tree.
Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
Staff and the first \new Voice are all created implicitly.
I know that the next part in the process is iteration. But I want to stop
and check my understanding here: am I understanding the output of the parser
correctly at this point?
No. the \new Staff and \new Score are created at iteration time. Look
for path_to_acceptable_context().
Also, you can use the \displayMusic music function to get to the parse tree.
--
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: I know that the next part in the process is iteration. But I want to stop and check my understanding here: am I understanding the output of the parser correctly at this point? No. the \new Staff and \new Score are created at iteration time. Look for path_to_acceptable_context(). and to be extra clear, it's the Staff and Score contexts that get created. The expression is not modified during iteration. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 6:21 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: On Mon, Dec 15, 2008 at 10:20 PM, Han-Wen Nienhuys hanw...@gmail.com wrote: I know that the next part in the process is iteration. But I want to stop and check my understanding here: am I understanding the output of the parser correctly at this point? No. the \new Staff and \new Score are created at iteration time. Look for path_to_acceptable_context(). and to be extra clear, it's the Staff and Score contexts that get created. The expression is not modified during iteration. OK, got it. Will check path_to_acceptable_context( ). -- Trevor Bača trevorb...@gmail.com ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On Mon, Dec 15, 2008 at 6:09 PM, Patrick McCarty pnor...@gmail.com wrote:
Hi Trevor,
On Mon, Dec 15, 2008 at 2:12 PM, Trevor Bača trevorb...@gmail.com wrote:
* OK, so based on this understanding, can somebody please correct my
understanding of the parsing (not the iteration, just the parsing) of the
following expression (which is the same as my original example #2):
{
\new Voice {
c'8 c'8 c'8 c'8
}
d'8 d'8 d'8 d'8
}
If I'm understanding how the parser works, then what should result here
is a
music expression that looks like this:
Global
V
\new Score
V
\new Staff
V
\new Voice
V
Sequential
V
\new Voice, d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
If I'm counting correctly, that's 15 total nodes in the expression tree.
Eight atomic nodes and seven internal nodes. The Global, \new Score, \new
Staff and the first \new Voice are all created implicitly.
I know that the next part in the process is iteration. But I want to stop
and check my understanding here: am I understanding the output of the
parser
correctly at this point?
I'm pretty sure this would be the result *after* iteration.
The parser output can be visualized with \displayMusic. So your
example would look like this, using your convention above:
Sequential
VV
\new Voice d'8, d'8, d'8, d'8
V
Sequential
V
c'8, c'8, c'8, c'8
After this, the iteration process starts, proceeding moment by moment
and making sure everything is placed in the correct context. Then you
would end up with a tree that looks like the one you posted. I
believe the implicit creation of contexts happens during iteration.
(I could be completely wrong, but it makes sense to me).
OK, and Han-Wen confirms what you're saying, too.
Much appreciated. Going back to look at more code now ...
--
Trevor Bača
trevorb...@gmail.com
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
feature req: slur versions of \repeatTie and \laissezVibrer
feature req: slur versions of \repeatTie and \laissezVibrer When a (non-initial) volta alternative starts with a note tied from the end of the volta, we can use \repeatTie to correctly display the half-tie, but it seems there's no way of displaying a half-slur when the alternative contains a note slurred from the volta (ie. there's no \repeatSlur). One issue would be that the half-slur would need to look backwards for the beginning of the alternative because the slurred-to note wouldn't necessarily be the first note of the alternative. Similarly, when a (non-final) volta alternative ends with a note tied back to the beginning of the volta, we can use \laissezVibrer to fake a half-tie. There seems to be no trick for faking a half-slur when the alternative contains a note slurred back to the beginning of the volta. In this instance the issue would be that the half-slur would need to look forward to find the end of the alternative since the repeat sign doesn't necessarily follow the slurred note immediately -- the slur would need to go past other notes until the repeat sign is reached. However, if an implementation were even plausible (I have no idea), I wouldn't propose \laissezVibrerSlur since that's nonsensical. Perhaps \repeatSlurRight? WARNING: the following may be preposterous. Since the \laissezVibrer half-tie trick is semantically wrong, we could introduce \repeatTieRight. While we're in that ballpark, we could introduce \laissezVibrerLeft -- I have seen French editions (Messiaen?) where chords held across measures have left- and right-sided l.v. ties. And then there are the phrasing slurs... Assuming these additions, we're left with: \repeatTie \repeatTieRight \repeatSlur \repeatSlurRight \repeatPhrasingSlur \repeatPhrasingSlurRight \laissezVibrer \laissezVibrerLeft Amid this new constellation of commands, perhaps \repeatTie, \repeatSlur, and \repeatPhrasingSlur would be less vague if they were called \repeatTieLeft, \repeatSlurLeft, and \repeatPhrasingSlurLeft? Yikes. As always, curious to know your thoughts. - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: feature req: slur versions of \repeatTie and \laissezVibrer
here's a ly file and png (attached) to help visualize.
- Mark
This will generate 2 warnings:
warning: unterminated slur
warning: cannot end slur
\version 2.11.65-1
\relative {
\time 2/4
\repeat volta 2 { f4( e~ }
\alternative { { e f) } { e\repeatTie d) } }
\bar |.
}
\relative {
\time 2/4 f( e~
\repeat volta 2 { e f) }
\alternative { { f( e\laissezVibrer } { f2 } }
\bar |.
}
attachment: repeat_slurs.png___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Scheme function to print out active Voice context during interpretation?
On 12/15/08 1:26 PM, Francisco Vila paconet@gmail.com wrote: 2008/12/15 Carl D. Sorensen c_soren...@byu.edu: On 12/15/08 7:18 AM, Han-Wen Nienhuys hanw...@gmail.com wrote: Try not to form mental models. Use the source instead. Unfortunately, not very many of us understand the source completely, and so we need mental models to work in LilyPond. Of course, our mental models will be incorrect in some detail, and we'll need to revise them from time to time. I have a question for the few developers that in some degree do understand the source code and are able to hack it, fix bugs, implement new features, etc. Is the code properly commented, so that (thinking on the future) new people can learn from it without having to figure out all the time what does each function, file etc. do? Sure, I can look at it and say, but I want the opinion of skilled programmers. If not, is there any chance of this to improve? In my opinion, the code is written sufficiently well that if you're willing to spend the time you can eventually get up to speed. There are very few comments, but there are good function names, good variable names, and good consistency. For me, the biggest thing missing is an overall sense of the architecture. It's alluded to in Erik Sandberg's thesis, and you can kind of get it figured out with the source code and the ongoing discussions. But it's still a bit challenging to get into starting from scratch. As far as the prospects for improving the situation, I'd say they're not great. It seems to me that remedying the situation would require a major time investment, and provide no new functionality, just improved accessibility for an unnamed future round of developers. If we had somebody who was interested in getting into the internals and also interested in documenting things, then I think the situation might change. But I have no idea who that person might be. Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
why is Dutch the default language for note-entry?
Why is Dutch the default language for note-entry? English uses the fewest keystrokes. For comparison, here's a measure from Chopin's Fantasie-impromptu: English: r16 gs( a gs fss gs cs e ds cs ds cs bs cs e gs) Dutch: r16 gis( a gis fisis gis cis e dis cis dis cis bis cis e gis) 49 keystrokes in English compared with 62 in Dutch. English allows for 20% less typing in this example. I think the LM / NR should at least mention that. - Mark p.s. Incidentally, in keys with fewer accidentals, the languages with the most keystrokes are Arabic/ Catalan/Spanish/Italian/Portuguese/Flemish. In keys with many accidentals, Swedish is the worst. More Chopin... Arabic/Catalan/Italian: r16 sold( la sold fadd sold dod mi red dod red dod sid dod mi sold) Catalan/Spanish/Portuguese: r16 sols( la sols fass sols dos mi res dos res dos sis dos mi sols) Flemish: r16 solk( la solk fakk solk dok mi rek dok rek dok sik dok mi solk) Swedish: r16 giss( a giss fississ giss ciss e diss ciss diss ciss biss ciss e giss) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: why is Dutch the default language for note-entry?
Mark Polesky wrote: Why is Dutch the default language for note-entry? Because the originators of LilyPond are Dutch. -David English uses the fewest keystrokes. For comparison, here's a measure from Chopin's Fantasie-impromptu: English: r16 gs( a gs fss gs cs e ds cs ds cs bs cs e gs) Dutch: r16 gis( a gis fisis gis cis e dis cis dis cis bis cis e gis) 49 keystrokes in English compared with 62 in Dutch. English allows for 20% less typing in this example. I think the LM / NR should at least mention that. - Mark p.s. Incidentally, in keys with fewer accidentals, the languages with the most keystrokes are Arabic/ Catalan/Spanish/Italian/Portuguese/Flemish. In keys with many accidentals, Swedish is the worst. More Chopin... Arabic/Catalan/Italian: r16 sold( la sold fadd sold dod mi red dod red dod sid dod mi sold) Catalan/Spanish/Portuguese: r16 sols( la sols fass sols dos mi res dos res dos sis dos mi sols) Flemish: r16 solk( la solk fakk solk dok mi rek dok rek dok sik dok mi solk) Swedish: r16 giss( a giss fississ giss ciss e diss ciss diss ciss biss ciss e giss) ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
