I like what you're doing here. I have a couple of comments on the regtests, and one on the definition of the dynamics.
Thanks, Carl http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely File Documentation/notation/expressive.itely (left): http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely#oldcode523 Documentation/notation/expressive.itely:523: @lilypond[verbatim,quote] I don't like eliminating the simple example. Having both the simple and complex example is much better, in my opinion. http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely File Documentation/notation/expressive.itely (right): http://codereview.appspot.com/2220041/diff/12001/Documentation/notation/expressive.itely#newcode539 Documentation/notation/expressive.itely:539: Scheme command, that takes any string or markup object as its argument. I prefer "through the scheme function @code{make-dynamic-script}" http://codereview.appspot.com/2220041/diff/12001/ly/dynamic-scripts-init.ly File ly/dynamic-scripts-init.ly (right): http://codereview.appspot.com/2220041/diff/12001/ly/dynamic-scripts-init.ly#newcode17 ly/dynamic-scripts-init.ly:17: % sfz = \dynamic sfz I view this list as defining the stuff that is acceptable for midi. If we're going to go this way (and I think it's probably good to go this way -- I like what you're doing), then we probably ought to put some kind of check for things that don't make midi sense. For example, ffffff, or pfpfpfp. I'm fine to go ahead and print the dynamics, but there ought to be a warning that says something like "dynamic cannot be represented in midi". And somewhere, we'll still need to have this equivalent list for midi-acceptable dynamics. http://codereview.appspot.com/2220041/ _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
