Re: OO and MIDI support
On Friday 05 October 2007, Hans Aberg wrote: On 5 Oct 2007, at 01:20, Graham Percival wrote: Midi support in lilypond is quite limited, and this is not likely to change in the near future. Might it possible to handle this by OO (object orientation)? The idea is that if objects can be defined (in pseudocode) turn := default: ... midi: ... short: ... quintuplet: ... ; And one then is able to write code like d8^\turn[staff-short,midi-quintuplet] if one in this position wants the turn to not be the defaults, but then the staff to be written in the short form, and MIDI be written as a quintuplets. The principle is quite general. So it might be useful for handing a number of problems. The enhanced MIDI support would emerge as a byproduct of this OO support. I don't understand all of this, but wouldn't it be possible to achieve most of this functionality with tags? You could just use \keepWithTag #'midi when creating midi, and then tag stuff with midi in the definition of \turn. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme code for extracting LilyPond header properties?
On Tuesday 09 October 2007, John Zaitseff wrote:
Dear Nicolas / LilyPonders,
I store a field in the header, lastupdated, in the form 09-Oct-2007;
the \parsed-date function converts that to something like 9 October,
2007:
% \parsed-date DATE - convert a DD-MMM- property to a fully printed
date #(define-markup-command (parsed-date layout props date) (symbol?)
Convert the property @var{date} containing a date in the
form DD-MMM- into a nicely formatted stencil output D ,
.
(let* ((datestr (chain-assoc-get date props)))
(interpret-markup layout props
(if (string? datestr)
(markup #:simple
(strftime %e %B, %Y (car (strptime %d-%b-%Y
datestr datestr
(Of course, I should rewrite that to make it somewhat more robust.
It works for me, however).
You may want to use SRFI-19 for this,
http://www.gnu.org/software/guile/manual/html_node/SRFI_002d19.html#SRFI_002d19
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SVG output sponsorship
On Wednesday 15 August 2007, Eduardo Vieira wrote: Citando Vivian Barty-Taylor [EMAIL PROTECTED]: I'm using various bits of graphics in this piece which aren't natively supported by Lilypond. Although I could add them all as EPS markups, the amount of time I would spend adjusting the positions of them makes it a lot easier to do it this way. Have you ever tried importing your ps file into Scribus? You could import and ungroup all the objects of your score, then you can adjust, move, or insert whatever object you want. Ah, now I remember, this is the way I used to do to convert ps - svg. IIRC, you sometimes need to do a round or two of ps2ps, eps2eps, pdf2ps, or similar to make scribus decode the ps correctly. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SVG output sponsorship
On Wednesday 15 August 2007, Vivian Barty-Taylor wrote: Thanks for that suggestion. Do you know where I can get the gnome backend, or do I just need to download the earlier version of Lilypond? IIRC, it's a compile-time option which by default is off (i.e., you need to recompile lily manually). However, I think there is a more general issue here about graphical notation in scores. I'm using various bits of graphics in this piece which aren't natively supported by Lilypond. Although I could add them all as EPS markups, the amount of time I would spend adjusting the positions of them makes it a lot easier to do it this way. The SVG option seemed the best because I don't lose image quality by converting to a bitmap, and also because Inkscape is a good piece of software. Again, if your only problem is to adjust offsets etc, then getting the gnome back-end to work may be a good solution for this problem too (i.e.: insert EPS markups without considering spacing offsets, then move them to the right spot using the gnome back-end). A problem here is that EPS images probably won't show up in the gnome back-end. IIRC, it's possible to store a bitmap preview in an EPS image; in this case it may be possible to hack the gnome back-end to extract display the preview. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SVG output sponsorship
On Sunday 12 August 2007, Vivian Barty-Taylor wrote: It seems to me that having reliable (bug-free) SVG output would be a big plus for Lilypond. At the present time, I have been unable to fix all the font problems (not sure whether this is Lilypond or Inkscape which is giving me trouble.) To get to where I am at I had to make a lot of changes by hand to the SVG file which is tedious. (Specifically, the italic sans-serif fonts still don't work.) The main advantage of the SVG output (I would suggest) is that small changes to positions of objects can be done in a WYSIWYG environment, instead of the current estimate-how-much-I-have-to-move-that-object/ add line of code/ re-process score/ find out I haven't moved it enough/ moved it too much/ change values of #'padding or #'extra-offset etc. etc. all of which is time consuming especially with big projects. This approach has a problem: Once you change a note (say, fix a typo) and need to re-run lilypond, you will have to redo all tweaks again. You may want to take a look at the experimental gnome back-end, which has existed for quite some time now (2.4 or 2.6, IIRC), but which for some reason never became popular. It offers a better solution to your problem: The score is displayed on the screen, and you can adjust spacing by drag-and drop, and save all modifications in a separate file (containing tweaks). This way you can still make musical corrections in the .ly file without having to redo all spacing tweaks (except, of course, if your musical corrections themselves affect spacing sufficiently to invalidate your tweaks). Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Fonts in SVG output
On Sunday 08 July 2007, Benjamin Esham wrote: Benjamin Esham wrote: I'm having some issues with Lilypond 2.10.x's SVG export. I seem to have fixed most (all?) of my font problems. I now have another problem, however. In order to submit one of LilyPond's SVGs to e.g. the Wikimedia Commons, it is necessary to convert all of its text into paths; that way, users need not have LilyPond's fonts in order to view the image correctly. Before converting text into paths in Inkscape, you must make sure that none of the text is contained within a group. Therefore, I started to process my file by selecting everything and issuing an Ungroup command. When I did so, the staff lines disappeared! Apparently every object in the file is in a one-element group. For some reason, ungrouping the staff lines made them disappear—they were still present, just not visible. I think there may be an Inkscape bug at play here too, since Select All couldn't find the lines, but on the LilyPond end... how can I get Lily to create a sane, usable SVG file? Any help is greatly appreciated here. There's another approach to the SVG output problem: You can take PDF or EPS output from lilypond, and try to turn it into SVG files. The postscript backend of lilypond is obviously more mature, and there exist converters from pdf/ps to svg. Free converters are a bit shaky, but for some lily versions I managed to convert .ly files into valid SVG via a chain of converters. Usually, you need to first expand fonts to curves using some ps2ps-like script, and then use pstoedit to convert to something that can be converted to svg. Unfortunately, most conversion tools are rather immature, so you will need some experimenting to make it work. IIRC, I managed to generate valid svg with this method for my master's thesis, using a lilypond version around 2.6. I don't remember the exact combination of commands that worked though. (I have vague memories that it may be good to start with pdf output and convert it back to eps) Here's a script that works for some subsets of ps (not lily's though), you can look at it for ideas: http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Electronics/Ps2svg.sh If you manage to find a fairly reliable path to convert the output of a recent lily version into wikipedia-usable SVGs, I'd be happy to know. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \times vs \tuplet (Was: Constructive Criticism and a Question)
On Monday 15 January 2007 10:25, Valentin Villenave wrote:
2007/1/14, Mats Bengtsson [EMAIL PROTECTED]:
Valentin Villenave wrote:
Tuplets are made with the minimalistic \t keyword.
Comments:
- If Erik's proposal to handle fractions such as 2/3 as a new
argument type is implemented, then it will be trivial to
define your own music function called \t within LilyPond.
I definitely do not think that it's a good idea to use such
heavily abbreviated command names by default in LilyPond
but on the other hand it's an excellent solution for you and
many others to add such a customized music function and
this specific example should be included as a standard example
in the documentation.
/Mats
Thank you Mats;
it would be indeed heavily abbreviated. But what about the second part
of my suggestion:
If you do not specify a tuplet argument, the argument last entered is
used for the next tuplet. The argument of the first tuplet in input
defaults to 2/3.
When you use the \times command, most of the time it's to use 2/3, or
to use some argument you've already been using. Is we keep \times, I
agree to say this command can't go without any argument. But if it
becomes \tuplet, why couldn't we implemement some default rule ?
Where
\times {f8 g a} doesn't mean anything,
\tuplet {f8 g a} makes sense, doesn't it ?
it's easy to write a separate function
\triplet {f8 g a}
for this purpose.
(IMHO, this would be a useful addition to the standard lily distribution)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Sunday 07 January 2007 04:55, [EMAIL PROTECTED] wrote:
. . . Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
I'm not very fluent in Scheme, so this is a naive question.
I presume that ratios like 3:2 (or 2/3) could be made into some kind of
object type (possibly a moment). So I could imagine that it would be
possible to write a Scheme function definition to cover a syntax like
\tupletSequence m:n #'( {...} {...} ... )
where the first argument is a moment and the second is a list of literal
music expressions. (And I suppose I'm too optimistic about that syntax;
probably those {...} would have to be sprinkled with # or $ or other
spices.) But there are some questions:
1) I don't see how this could accommodate the case where one of the music
expressions *were* a variable reference (\var) or *contained* a variable
reference.
Music functions are not macros; the arguments are evaluated before the
function is called. So \var always means to dereference a variable.
(I'm working on a system for 'music macros', which should make it possible to
delay the dereferencing of variables, this will mainly be useful to clean up
\relative)
2) Because the syntax \tupletSequence m:n { {...} {...} }
is nicer, it would be good if it could be written that way, but then the
second argument would not be a standard Scheme entity, so I don't see how
Scheme could handle it at all.
There is a distinction between Scheme functions and Music functions. Music
functions are invoked as \function arg1 arg2, while Scheme functions are
invoked in Scheme expressions, as #(function arg1 arg2). tupletSequence would
be a music function.
There are three types of arguments to music functions: Music, Markup and
Scheme. This suggestion would add another argument type 'fraction'. The
parser takes care of identifying argument types. Music arguments are notated
as music, so you can use {{c}{d}} syntax out-of-the-box. E.g., partcombine is
a music function.
In Scheme functions, you can use the #{ #} syntax to easily create music
expressions as arguments.
Can tupletSequence really be defined in pure Scheme, as long as the parser
is modified to recognize the object m:n or n/m (so that there would exist
a type-verification-name for the object m:n for use in defining Scheme
functions)?
yes, the only thing we need is a new parameter type.
BTW, one of the biggest problems (IMHO) in the lilypond language is that we
can't extend the parser to accept durations as parameters to music functions:
\foo c 4. is ambiguous; it's unclear whether the 4. is the c's duration, or
if it's a separate argument.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Friday 05 January 2007 22:53, [EMAIL PROTECTED] wrote:
. . . The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence
function would be implemented entirely in Scheme . . .
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
OK. Thank you for clarifying that. I understand, from your original
remarks, that (here) you have written just \tuplet in the interest of
brevity, and that the full form would be
\tupletSequence 3:2 {{c d e} {{f g} a} b c}
meaning
\tuplet 3:2 {c d e} \tuplet 3:2 {{f g} a} \tuplet 3:2 b \tuplet 3:2 c
yes, that's right.
which implies the following things:
a) tupletSequence is a Scheme function which just breaks up its
subexpressions naively, without any semantic analysis.
b) \tuplet is a real LilyPond function; it is identical to \times,
except that the notation 3:2 (meaning 2/3) would be allowed.
c) People would have to write \tupletSequence m:n { {...} {...} },
not \tuplet m:n { {...} {...} }.
yep, this is right (thanks for expressing it clearly).
d) Any semantic errors in the subexpressions would be reported by the
\tuplet function, not by the \tupletSequence Scheme function.
technically this is not correct (the \tuplet function doesn't detect semantic
errors), but in principle you're right (\tuplet and \tupletSequence actually
only create Music data structures, without performing semantic analysis;
most 'semantic errors' are detected either when these data structures are
further processed into typeset scores, or by the parser before the function
applications)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Friday 05 January 2007 09:22, [EMAIL PROTECTED] wrote:
. . . \tupletSequence 2/3 {{c d e} {f g a} {b c d}}
would just be a shorthand for
\tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
That would add a big semantic burden to the meaning of { and }.
Currently {{c d e} {f g a} {b c d}} means the same thing as
{c d e f g a b c d}.
It's not a problem. The { m1 m2 m3 } syntax is used for repeat alternatives
already, and the meaning is very clear: Each music expression between the
outer { } is a separate argument. Note also that the tupletSequence function
would be implemented entirely in Scheme, the parser would not be modified.
Examples:
I would hate to have to write the parser that would
figure out (reliably) what
{{c d e} {f g} {a b c}}
\tuplet {c d e} \tuplet {f g} \tuplet {a b c}
or
{{c d e} {{f g} a} b c}
\tuplet {c d e} \tuplet {{f g} a} \tuplet b \tuplet c
or
{{c8 d e} {f4 g a}}
\tuplet {c d e} \tuplet {f4 g a}
mean (as arguments to \tupletSequence). And if
\seq = {{a8 b c} {d8 e f}}
then, since LP macros are *not* string macros, what will the parser
do with the argument
{ {g8 f e} \seq {b8 a g} }
\tuplet {g f e} \tuplet \seq \tuplet {b a g}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tuesday 02 January 2007 22:29, [EMAIL PROTECTED] wrote:
... in irregular, tuplet-intensive music it may be sensible to create a
music function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support
fractions as music function arguments.
If I understand you correctly, this would involve specifying, one way or
another, the duration of each actual tuplet. Explicit specification of a
duration (other than by an external tupletSpannerDuration declaration) has
been suggested by another user, and IMO it would be a good idea, although
I gather that Han-Wen is not in favour of the idea.
No, \tupletSequence 2/3 {{c d e} {f g a} {b c d}} would just be a shorthand
for \tuplet 2/3 {c d e} \tuplet 2/3 {f g a} \tuplet 2/3 {b c d}
It is problematic to use durations to decide the scaling of a tuplet; this has
been discussed previously in this thread. E.g., if you scale 3 8th notes to
duration 4, then it is unclear whether it corresponds to factor 2/3 or 4/6.
But I have a question about how one would specify a duration. Specifying
durations in the way we usually think about them allows actual durations
that look like this:
1== 1
2... == 15/16
2.. == 7/8
2. == 3/4
4... == 15/32
4.. == 7/16
4. == 3/8
4== 1/4
(etc.)
so that only durations of the form
2^(p-1) / 2^q (where p q)
can be specified this way. But given the extravagancies of contemporary
music, wouldn't it be possible, for example, to have a tuplet where 4
eighth notes would be played over a time interval of 5 eighths --
\times 5/4 {c8 d e f}
Or does such a thing never happen? If it does, then the tuplet's
duration, equal to 5/8 here, cannot be expressed simply by a dotted-note
notation such as in the preceding list.
you could always write 1*5/8, which is a valid duration.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Monday 01 January 2007 20:57, Mats Bengtsson wrote:
Frédéric Chiasson wrote:
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the
same kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
Since it's easy to define your own function \triplet which
does the equivalent of \tuplet 3:2 ..., and since you could
give it a short name like \t, your proposal wouldn't save
much typing or increase the clarity compared to
\t {x x x} \t {y y y} \t {z z z}
In these situations with repetitive triplet patterns, I definitely
prefer the current kind of solution with
\set tupletSpannerDuration = #(ly:make-moment 1 4)
There is one problem with this: If the 'most common' tuplet duration is 1/4,
but you occasionally have a different tuplet with _longer_ duration, then
tupletSpannerDuration will break the long tuplet into several shorter
durations, unless you always remember to \unset tupletSpannerDuration all the
time.
So, in irregular, tuplet-intensive music it may be sensible to create a music
function for sequences of tuplets. In addition, it's IMHO a more
lilypondesque solution than tupletSpannerDuration, once we support fractions
as music function arguments.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Thursday 28 December 2006 11:13, Brett Duncan wrote:
Erik Sandberg wrote:
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g
ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with 12 below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which
can be tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what
you are doing to notate the music (i.e., multiplying durations with
8/12), just saying that a 12 should be displayed above would make it
difficult to maintain the .ly code.
Here's a different idea: instead of specifying the ratio for a tuplet or
set of tuplets, what about specifying the duration of a tuplet, and
letting LP determine what number appears over the beam?
For example, where we now use
\times 2/3 { a8 b c }
to get a triplet of three quavers in the time of two, instead have
\tuplet 4 { a8 b c }
LP can calculate the ratio (and hence what should appear over the
tuplet) from the time given before the {...} and the cumulative time of
the notes inside the {...}.
This would mean that users do not need to work out the ratio, they just
need to know how long the tuplet should last. Further to this idea would
be to allow an internal division inside the {...}, so that multiple
tuplets could be entered, maybe something like \tuplet 4 { a8 b c ! c4
a8 ! b8 c4 }. (I've used ! only for explaining the idea - I'm NOT
advocating it as the desired syntax.)
This would mean that for the Beethoven snippet in David Fedoruk's post,
instead of
bf16[d, f ef] \times 4/5 {d16[ ef f g a]} \times 8/12 {bf32[a c bf d c
bf a g f g ef]}
you would put
bf16[d, f ef] \tuplet 4 { d16 ef f g a ! bf32a c bf d c bf a g f g ef }
Just a thought!
Unfortunately, the number above does not always follow from the duration.
E.g., the factors 2/3 and 4/6 are mathematically equal, but give different
numbers. It is probably difficult to define when to use 4/6 and 2/3,
respectively (e.g., I guess {c8[ c16 c c8]} could have either a 3 or a 6
above it, depending on context)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Any way to turn off warning: ignoring too many clashing note columns?
On Saturday 18 November 2006 23:12, Trevor Bača wrote:
Hi,
So my question is: is there any way to turn off the clashing note
column warnings? I think this is the one place where one of Lily's
warnings truly is completely harmless and I feel safe turning it off.
More importantly, I really need to see any *other* warnings that Lily
generates, which is quite hard given the original sourcefile (which
runs many thousands of lines).
It would not be difficult to add a feature to disable warnings for specific
input spots, so you could write something like:
\new Voice { \noWarning e8 }
\new Voice { \noWarning c8 }
to suppress warnings only for the notes you have made strange tweaks to (I
don't have much time now, but you could ask Han-Wen if he likes the idea, and
if it's sponsorable).
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Saturday 23 December 2006 03:10, Frédéric Chiasson wrote:
Might it be possible to use
\tuplet 3:2 {x x x}
for the usual operation, and if we want to have many tuplets of the same
kind, to use
\tuplet 3:2 { {x x x} {y y y} {z z z} }
Might resolve the clarity problems.
Doesn't look good to me, syntax becomes unclear for cases like
\tuplet 3:2 { x {y y y } z }
However, it would IMHO be OK to write a separate music function with this
syntax, something like:
\tupletSequence 3:2 {{ x x x} {y y y} {z z z}}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Monday 25 December 2006 07:05, Joe Neeman wrote: On 12/21/06, Han-Wen Nienhuys [EMAIL PROTECTED] wrote: Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. Could you make 3:2 equivalent to #'(3 . 2)? Then - you don't need to introduce a new type - we could use x:y everywhere instead of the scary (it certainly was for me when I first started with lilypond) #'(x . y) With the current way the parser works, you'd probably be able to do something like #(ly:export '(x . y)); of course we can add a define-music-function style synonym on top of that, like #(make-fraction x y) BTW, I have some ideas to change the way SCM expressions work in the parser; unfortunately I haven't had the time to code lilypond for a very long time though, and other things are of higher priority. My idea is that the detection of types after ly:export should be carried out by the parser rather than lexer; this would allow a more intuitive behaviour of music macros the day they are implemented (it would be possible to delay the evaluation of inline SCM expressions) -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Monday 25 December 2006 06:32, David Fedoruk wrote:
Hello:
I've been watching this discussion or debate. There are two ways to
look at this problem. The first is from a programmer's point of view
where the programmer is experienced with some computer languages,
these days its upper level languages more and more. For these people,
lilypond typesetting code feels comfortable when it is syntactically
correct and when it makes sense in either computer or mathematical
terms. A mathematical algorithm is what they are used to seeing.
The other group has less mathematical knowledge, very little (very
little compared to a programmer working on a major project like
Lilypond) programming knowledge or experience. In all likelihood the
only thing that connects these people is the printed musical score.
At least in part I think these points have already been made. The
question that occurs to me as a novice Lilypond user (and one who
jumps in the deep end with complex scores!) is this: How will you
deal with other types of prolongation or compression of notes into one
or more beats or where the composers intentions are clear but they are
not immediately mathematically correct?
The example below is a single bar from a Beethoven Piano Sonata (Opus
31 number 3, 1st mvt. bar 53) in which two more out of the ordinary
examples occur next to each other. You will excuse any mistakes in
coding here, this doesn't render as it should.
upper = \relative c'' {
\clef treble
\key ef \major
\time 3
bf16[d f ef] \times 5/4 d16[ ef f g a] bf32[bf a c bf d c bf a g c g ef]
}
You can see how there are three beams, one for the notes in eaech
beat. The first and second beat are quite clear, but the third one has
eluded me as yet. The score has 12 thirty-second notes beamed together
with 12 below the note heads.
The printed score is clear to the performer. The Lilypond code I
suspect is far more complex. The only way that 12 thirty-second notes
will fit into one beat is if they are triplets, but in context, they
are not played or heard as triplets.
My only comment in this discussion is that the Lilypond code to
represent this short passage should be as clear as the printed score I
am reading.
try \times 8/12 { ... }
(by default, this will probably display as 12:8 above the notes, which can be
tweaked to just show 12)
IMHO, this is an argument for a mathematical notation: You must know what you
are doing to notate the music (i.e., multiplying durations with 8/12), just
saying that a 12 should be displayed above would make it difficult to
maintain the .ly code.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Wednesday 20 December 2006 10:58, Mats Bengtsson wrote:
Graham Percival wrote:
... hmm, what about allowing
\tuplet 3:2 {c8 d e} \tuplet { f e d}
Again, I definitely vote against! We already now have too many
optional constructs in the syntax, which causes more confusion than
it helps.
I also vote against this. AFAIK, this kind of repetition seldom happens for
other cases than 2/3 and 4/6; we can easily build music functions for those
cases (i.e., create a unary function \triplet etc.)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Wednesday 20 December 2006 07:51, Graham Percival wrote:
Han-Wen Nienhuys wrote:
Jonathan Henkelman escreveu:
I think Eriks point is actually well founded. The discussion started
with my discussion of trying to trim down the grammer complexity. Adding
syntax is not really in that direction.
Another option:
- add \tuplet 3:2 {.. }
- replace \times 2/3 by \times #'(2 . 3) ; this can be implemented with
a standard music function
Oh God no. It took me a year to get used to #'(2 . 3) -- I kept on
trying '#( and #( and #'(2.3)... every time I gave up after ten minutes
and found an example from the documentation to copy.
Scheme has rational numbers as a builtin type, so it _is_ possible to pass the
easy-to-type #2/3 as an argument to a music function (AFAIK, this is the only
case where scheme doesn't use polish notation).
Unfortunately, this would not work with \times: #2/3 and #4/6 are the same
rational number, but 2/3 and 4/6 are different tuplet fractions. Also, Scheme
rational numbers may not contain whitespaces, so #2 / 3 is not the same as
#2/3.
(hm.. for obvious mathematical reasons this solution doesn't work, but if it
WOULD have worked, it would have been a nice solution in a mathematical
sense)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tuesday 19 December 2006 15:25, Mats Bengtsson wrote:
Werner LEMBERG wrote:
\tuplet 3:2 {...}
One minor detail is that the name isn't exactly appropriate when you
do
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 {c8 d e f e d e f g f e d }
Well, in that case just stay with \times.
I thought the proposal was to completely get rid of \times and replace it
by \tuplet (which I think is a good idea). Just wanted to see if anybody
had any bright idea on a command name that's accurate also in this
special case.
What about:
\tuplets 2/3 {c8 d e f e d e f g f e d }
We could also make \tuplet and \tuplets differ on the iterator level, so that
the tupletSpannerDuration property affects \tuplets expressions but not
\tuplet expressions.
BTW, in this case it may be good to register the fraction as its own argument
type, so \tuplets and \tuplet are generic music functions, both with
signature
(tuplet-fraction? music?)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Thursday 21 December 2006 12:55, Han-Wen Nienhuys wrote: Erik Sandberg escreveu: BTW, in this case it may be good to register the fraction as its own argument type, so \tuplets and \tuplet are generic music functions, both with signature (tuplet-fraction? music?) it would be cool if we could pull this off, that would make \time generic too. Hm, if we do this together with the 2:3 syntax change, then we would suddenly be able to write: \time 4:3 which would be equivalent to: \time 3/4 That's a bit confusing. BTW, if we start adding new types, it would be nice to create a new 'type' data structure, to be used in function signatures. The data structure would contain a type-checking predicate, a name (displayed when type-check fails), and perhaps a type ID for the lexer. This would allow more complex types, e.g. 'sequential music', 'single note or chord', 'pair of numbers' (as in #'(1 . 3)), etc; perhaps the system could be used for define-context-properties.scm as well. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Thursday 21 December 2006 15:01, Han-Wen Nienhuys wrote:
Erik Sandberg escreveu:
On Thursday 21 December 2006 12:55, Han-Wen Nienhuys wrote:
Erik Sandberg escreveu:
BTW, in this case it may be good to register the fraction as its own
argument type, so \tuplets and \tuplet are generic music functions,
both with signature
(tuplet-fraction? music?)
it would be cool if we could pull this off, that would make \time
generic too.
Hm, if we do this together with the 2:3 syntax change, then we would
suddenly be able to write:
\time 4:3
which would be equivalent to:
\time 3/4
That's a bit confusing.
BTW, if we start adding new types, it would be nice to create a new
'type' data structure, to be used in function signatures. The data
structure would contain a type-checking predicate, a name (displayed when
type-check fails), and perhaps a type ID for the lexer. This would allow
more complex types, e.g. 'sequential music', 'single note or chord',
'pair of numbers' (as in #'(1 . 3)), etc; perhaps the system could be
used for
define-context-properties.scm as well.
be careful. If you introduce type, you will have to introduce subtypes as
well: seq-music is a subtype of music. Before you know, we'll be writing a
type inference engine.
I don't understand. Why isn't is sufficient to let typechecking be carried out
by an arbitrary user-defined turing-complete function? music and seq-music
don't need to share any code, the type inference engine machinery would be
voluntary AFAICS (seq-music's predicate would check that the object is a
Music and that it's of type SequentialMusic, and seq-music's name would
be sequential music).
And when it comes to parser, seq-music can just tell it that it expects a
Music, and typecheck after parsing. Alternatively, we create an independent
rule for seq-music which only accepts stuff on the form { }. This rule will
exist independently of the generic Music rule.
Or did I miss something?
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Constructive Criticism and a Question
On Tuesday 19 December 2006 10:57, Han-Wen Nienhuys wrote:
Werner LEMBERG escreveu:
I suppose you could add the command \times 3:2 {a b c} to do exactly
the same as \times 2/3 {a b c} [...]
If at all, then
\tuplet 3:2 {...}
I don't mind changing \times to \tuplet, and agree that the confusion with
\time is a bad thing. We could make \tuplet accept 3:2 2/3 and 3.
Since it is a change that can be accomodated with convert-ly, we wouldn't
even need a major version bump for it.
I think these changes sound scary, it is an additional hack in the parser
machinery. I think it would be cleaner if \times could be changed to a proper
music function, e.g. as
\tuplet 2 3 {...}
This would remove rules from the parser instead of adding them.
(Hm, my suggestion is not really in line with this discussion; I can agree
that \tuplet 2 3 would be easier to confuse with 3:2 than \tuplet 2/3 is).
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to use ^markup in a scheme function?
On Saturday 16 December 2006 23:40, Frédéric Chiasson wrote:
Thanks for the later answer, that is what i'm using and it works.
For the Lilypond code with the Scheme code, I just want to execute the
Lilypond code, so I should write :
(define-music-function (variables)
(let ((music #{ LilyPond code #}))
( (make-music music)
other Scheme code )))
?
no:
- music is already a music object, so no need for make-music.
- let returns the value of the last expression, read any scheme manual for
details.
So if you want to do side-effects, you'll want do do something like:
(define-music-function (variables)
(let ((music #{ LilyPond code #}))
(other Scheme code)
music))
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to use ^markup in a scheme function?
On Friday 15 December 2006 22:07, Frédéric Chiasson wrote:
Then, well, who can help me??
Frédéric
2006/12/15, Mats Bengtsson [EMAIL PROTECTED]:
I'm certainly not any expert in Scheme coding for LilyPond. Please
always keep the discussion on the mailing list, for the
benefit of yourself since you get access to the collected
expertise on the list and for the benefit of others who experience
similar problems.
/Mats
Quoting Frédéric Chiasson [EMAIL PROTECTED]:
Thanks, at last I understood how to do it?
One problem left, I copied the code displayed for \once \override
TextScript #'extra-offset = #$xy to put it in the code of the Slash
function. The code is compiled without errors, but there is no offset
produced. Why? Do I use the right prefixes for xy?
Also it is possible to use both LilyPond and Scheme code like this?
(define-music-function (variables)
#{
LilyPond code
#}
(Scheme code))
I think #{ #} simply produces a Music tree, so you can probably do
(define-music-function (variables)
(let ((music #{ LilyPond code #}))
(Scheme code using music)))
BTW, wouldn't it be possible to just do something like:
#{
\once \override TextScript #'extra-offset = #$xy
$note
\skip 1*0^\markup{\musicglyph #flags.ugrace}
#})
(that should work in most cases AFAICS)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond and editors
On Tuesday 12 December 2006 15:53, Bertalan Fodor wrote: Certainly not. Actually the java code is compiled to machine code at runtime. This is slower than precompiling, but the compiled code can run faster than its precompiled counterpart, because the runtime machine will have information about how often a certain part of the code is called, and those calls can be made inline. Running inline code is much faster than procedure calls. OK. Did you actually do benchmarking or similar? IIRC, the Java parts of openoffice are compiled to native code in Ubuntu's packages, for performance reasons, so it's not obvious what's best. I guess that memory consumption and startup time of most programs can decrease pretty much if they are compiled to native code. Also, IIRC there are options in gcc to optimise using profiling information; I don't know about gcj though. And gcc -O2 makes fair guesses on what to inline and not. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond and editors
On Saturday 09 December 2006 10:27, Bertalan Fodor wrote: Well, what is extremely important: development time is so little in Java and with JEdit (compared to any alternatives), that I won't change this platform. The price is that it will remain slow if you don't have much memory in the machine. I'm not a java expert, but wouldn't it get a lot faster if you compiled everything to native machine code (using gcj, for instance)? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: feature request: read standard input
On Tuesday 12 December 2006 03:24, Ed Stauff wrote: It sure would be helpful to have an option for reading the standard input, so I can pipe the output of a program that generates LilyPond code directly into LilyPond.exe. try: lilypond - -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme question on strict substitution
On Thursday 30 November 2006 21:32, [EMAIL PROTECTED] wrote:
Hello,
. . . one problem is that this [giving the syntax of each keyword] would
still just tell a small part of the full syntax.
I think it would give a big part of the full syntax, even if not the whole
picture. It would enable a user to know
(1) what type of arguments have to follow the keyword;
(2) whether (s)he has accidentally omitted one of the required
arguments (when debugging);
(3) whether (s)he should write a macro definition or a function
definition to specify a \whatever construct involving the
keyword;
(4) what the types should be in the event that (s)he winds up writing a
function definition.
Full or not, that's a lot of useful information. And I'm talking about
just a list of the syntax for each keyword, *not* the semantics. A syntax
specification can be short but still tremendously useful. Specification
of the semantics takes a lot of blah-blah, and nobody would have the time
to write up all the semantics.
Another problem is that the
rule I gave really was too simple. For example, you cannot say
^some text in a .ly file
without having a note in front of it, still you can define a macro
mytext = ^some text
and then use it as c \mytext
That's a general problem in LilyPond, knowing what kind of expression
constitutes a valid right-hand side of a macro definition. (I'm amazed
that the above definition works.)
A different but related problem concerns something I don't know the right
term for, something like context-free equivalence maybe: for example,
I can say
foo = \markup { \bold Zanzibar }
bar = \markup { Stand on \foo }
but I can't say
bar = \markup { Stand on \markup { \bold Zanzibar } }
You will object that I would have no *reason* to say that anyway,
but it nevertheless constitutes a toy example of non-transferability:
\foo is not equivalent to \markup { \bold Zanzibar }
despite the = sign in the macro definition, and that's surprising.
The reason for this is that foo is not a macro; it's a variable. Similarly, in
C you can write
int i = 5+9;
foo(i);
which is _not_ the same as the (invalid) expression
foo((5+9));
(this example is not exactly analogous to what you're trying, but it
illustrates that variables and macros are different things).
The special thing about 'markup' is that it isn't a function; it's rather a
special token that marks that the following code should be interpreted as
markups.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Music for the Martians?
On Thursday 23 November 2006 20:29, Arjan Bos wrote: On 23 nov 2006, at 3:10, Graham Percival wrote: I think this is referring to people with 6-fingers. Typing e8_1 means first finger; typing e8_1 prints 1 as a TextScript. But what are martians and why are they playing my music? Shouldn't this message simply state that a 6 is a strange number to indicate a finger with? Yes, but somebody was feeling creative when they wrote that code. :) What message do you propose to change it with? I thought about that and I know that it is non-sensical to have 6 in there as a finger indication. But I decided to put it in and it is right to put it in for my purpose, otherwise it wouldn't be in. So I feel that this message can be safely removed from lilypond. Oh, and 2.8 didn't have that message and I did not confuse myself with six fingers either there ;-) So please remove it, or if it is felt that it is a just message, please state that it something like: Warning: fingering notation for finger number n. Maybe also add a constructive hint, something like: Warning: fingering notation for finger number n. Did you intend to use \markup? where n is greater than 5, or 4 depending on the instrument being described. In guitar music, we normally only deal with four fingers as the thumb is at the other side of the neck. So here it would be appropriate to give the message at finger number 5. Since it's clearly instrument dependent, and lilypond doesn't know about the instrument that the music is intended for, it is a strong indication that you cannot tell when to display this warning. So this is in favour of removing it. BTW, I think I have heard of a professional pianist who had six fingers on one of his hands; he would have a valid excuse for writing 6. Luckily for him, it is fairly easy to manually \override Fingering.text to a similar function that doesn't give a warning. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: which language for programming
On Wednesday 22 November 2006 19:31, Joseph Wakeling wrote: Doug Wellington wrote: Why can't you communicate with others using VB and/or AppleScript? I would submit that it's easier to create a graphical application with VB than just about any other programming language. If you want to communicate via windows, menus, buttons, etc, what's easier than VB? (And heck, once you learn VB, you can leverage that to write scripts in MS Office apps if you're so inclined...) Simple---because with VB and/or AppleScript you are tying yourself to one platform, or at any rate biasing yourself heavily. If I write in Perl or Python or Ruby, or for that matter C or C++, code is much more portable. I think there are portable implementation of VB (IIRC Mono has one). However, I suppose that doesn't help much because AFAIU the main point with VB is that Microsoft wrote a nice IDE for it in which it easy to draw windowed applications, and that IDE is not portable AFAIK. I think the earlier poster who suggested going straight for Scheme may have a point. Not only is it the core language for working with Lilypond, but it's a Lisp dialect, and Lisp is both the grandaddy of programming and the most flexible language there is. See for example, http://www.paulgraham.com/icad.html Another thought struck me: there's a pedagogical point in using statically typed languages, because those language teach you never should store different types of objects in the same variable, which is good programming practise. Both python and scheme (and most other suggestions here) are dynamically typed languages. For this reason, Boo may be a good candidate (it's more-or-less a python clone with the addition of an intricate static typing system); its main drawback is that it's not commonly used yet. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Midi problem
On Tuesday 21 November 2006 23:37, Lasse Rempe wrote: First of all --- thanks for the help on the hairpintobarline question; my reply on that message doesn't seem to have gone through. I thought I had installed the most current LilyPond version, but clearly not :doh:. I've now installed LilyPond 2.10, and I seem to be getting problems with the \tempo command where I wasn't getting these before. Is this a bug, am I doing something wrong or was the correct handling of this changed? If the latter, what is the new method? Sorry if this is a known issue. The syntax has changed. You can try writing \tempo in a 2.8 and use convert-ly to see the new syntax, or alternatively you can read the Fine Manual. hth, -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: which language for programming
On Wednesday 22 November 2006 15:53, Bob Kline wrote: Ed Ardzinski wrote: If Lilypond is written in C++ (and I do see some hints of C type syntax when I use Lilypond) this *might* be a factor to consider. But... C and C++ are fairly complex languages and have steep learning curves. If you an abject beginner with programming I suggest starting out with Visual Basic and concentrating on trying to develop good programming practices. That will make a switch to a more difficult language easier. I thought I read somewhere that while Lilypond had originally been written in C++ it has since been reimplemented in Scheme, which is a dialect of Lisp. I would recommend Python as a good first language for learning to program. http://www.python.org In addition, Python is used for most lilypond-related tools (convert-ly, lilypond-book, etc), so if you want to start hacking lilypond it can be a good choice (plus it's in general very good as a first language, as other people already mentioned). Scheme is the language used for music functions in LilyPond; you can write Scheme code in a .ly file to manipulate music. So Scheme is good if you want to find a real use for your programming skills quickly. However, Scheme is considered by some people as difficult, as a side-effect of its extremely simple grammar. E.g., in order to express 3 + 8, you write (+ 3 8) in Scheme, this confuses some people. If you are mathematically minded, this should not be a problem. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Manual engraving video
On Wednesday 22 November 2006 09:20, Arvid Grøtting wrote: Joseph Haig josephhaig at gmail.com writes: Note the second comment: It will be a long time before this beautiful process can be replicated by computers. Erm ... It took Henle three years, from the video was made in 1997 until they stopped hand-engraving in 2000. Three years should not be a long time from a music publisher's point of view... The fact that they chose to switch to computer-engraving doesn't contradict that hand-engraving is far better; see: http://lilypond.org/web/about/automated-engraving/introduction.html -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hiding empty staves
On Monday 20 November 2006 18:40, Bob Kline wrote:
Erik Sandberg wrote:
The problem above, is that { } have different meanings in different
places: Usually { } means sequential music, but the { } after \score are
special: it starts with a _single_ music expression, followed by optional
\layout (etc) blocks. So you must make \override part of the music
expression, like:
\score {
\override Score.VerticalAxisGroup #'remove-first = ##t
\context ChoirStaff
\context Staff = women
\new Lyrics
\context Staff = men
\layout{...}
}
I apologize for being so slow to grok what's going on here, and I
appreciate the responses posted so far on this issue, but I still don't
get it. I have tried doing *exactly* what you're telling me to do here
(except for putting back in the missing to balance the delimiters
of the \context ChoirStaff chunk), and I'm still getting the blank staff
in the first system.
Hm, maybe it's the \clef bass; you could try to move it to where the music
starts. (not tested; it's just a guess)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hiding empty staves
On Friday 17 November 2006 22:28, Bob Kline wrote:
Andrew Longland-Meech wrote:
Thank you. I've got it now, even though it seems a bit illogical to put
one bit of layout in \layout and the other in with the notes, when they
both do a similar job!!
On Thu, 2006-11-16 at 10:53 -0800, Graham Percival wrote:
Andrew Longland-Meech wrote:
\override Score.VerticalAxisGroup #'remove-first = ##t
I don't understand where this should go. Is it in the \score section?
Or in the \layout section? Or in with the notes? Please can someone
guide me in the right direction?
Please see chapter 5 of the docs.
Could one of you have pity on a poor clueless user and give an example
showing where these two directives go? My attempts always end up with
the unwanted staff omitted on the second system of the music, but
included for the first system. Here's an example of what I'm trying:
\score {
\override Score.VerticalAxisGroup #'remove-first = ##t
\context ChoirStaff
\context Staff = women
\new Lyrics
\context Staff = men
\layout {
\context { \RemoveEmptyStaffContext }
}
}
I have looked at chapter 5 of the docs (I assume we're talking about the
chapter 5 in the latest released version of lp, rather than the versions
currently shipped with most Linux distros), and my poor brain just isn't
getting it, as I don't see the part that says *where* to put the
\override command.
The problem above, is that { } have different meanings in different places:
Usually { } means sequential music, but the { } after \score are special: it
starts with a _single_ music expression, followed by optional \layout (etc)
blocks. So you must make \override part of the music expression, like:
\score {
\override Score.VerticalAxisGroup #'remove-first = ##t
\context ChoirStaff
\context Staff = women
\new Lyrics
\context Staff = men
\layout{...}
}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pitch/ octave notation
On Thursday 16 November 2006 00:49, Han-Wen Nienhuys wrote: Erik Sandberg escreveu: On Wednesday 15 November 2006 13:25, Mads Sejersen wrote: 2006/11/14, Erik Sandberg [EMAIL PROTECTED]: Then he could use 4c8 instead, or does lilypond have any special meaning for prepended digits? hm, then maybe 8c4 is an even better choice (8th of pitch c4). I guessed that the request for c4 syntax for pitches is related to some musicological convention where c4 is the actual pitch name. I think it is something either from midi or MUSEDATA (aka. Cobol for musicologists). prepended and appended digits are the same due to whitespace being insignificant. c8 c4 c8 = c8 c 4c8 = c 8c4 c8 yes, but not if he implements the syntax using a preprocessor which doesn't ignore whitespace (i.e. something like s/\([0-8]+\)\([a-g]\)4/\2'\1/ ) -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pitch/ octave notation
On Tuesday 14 November 2006 16:50, Peter O'Doherty wrote: Hello, Is it possible to indicate pitches in the format c4 instead of c'? And if not, does anybody know of any plans to create this possibility? If you really need this, I'd recommend you to use sed or similar tool as a preprocessing step for your score. It should be fairly easy to lexically replace c4 with c', c5 with c'', etc. It will probably be confusing though, because you'll have to write c48 to indicate an eight note of pitch c', etc, and you won't be able to benefit from the \relative mode. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Pitch/ octave notation
On Wednesday 15 November 2006 13:25, Mads Sejersen wrote: 2006/11/14, Erik Sandberg [EMAIL PROTECTED]: On Tuesday 14 November 2006 16:50, Peter O'Doherty wrote: If you really need this, I'd recommend you to use sed or similar tool as a preprocessing step for your score. It should be fairly easy to lexically replace c4 with c', c5 with c'', etc. It will probably be confusing though, because you'll have to write c48 to indicate an eight note of pitch c', etc, Then he could use 4c8 instead, or does lilypond have any special meaning for prepended digits? hm, then maybe 8c4 is an even better choice (8th of pitch c4). I guessed that the request for c4 syntax for pitches is related to some musicological convention where c4 is the actual pitch name. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: LilyPondTool 2.10 demo
On Monday 13 November 2006 23:37, Bertalan Fodor wrote: For a flash demo of the new LilyPondTool release please look at http://www.organum.hu/fileadmin/lilypondtool/parser.html It demonstrates some of the most exciting features (instant errorchecking, instant help, instant point-and-click) Hi, Do you know if there is any free program which can decode this demo? I have tried two flash players, based on libflash 0.4.13 and swfdec 0.3.6 respectively, and neither one plays your demo. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: beam breaking in tuplets
On Monday 06 November 2006 09:25, Mats Bengtsson wrote:
Victor Eijkhout wrote:
So, if you want a limited scope, you can explicitly create a short-lived
context.
Here's an example that uses smaller note heads for one measure:
\relative c'{ c d e f \new Voice {\tiny g f e d } c d e d c1 }
/Mats
Mats, do you think it would be useful with an operator \newClone to clone the
current context? E.g.
\new Staff \with {\consists Foo_engraver bar=#'baz}
{ c d \tiny e f \newClone Staff { g f e d} c d e }
would be equivalent to:
\new Staff \with {\consists Foo_engraver bar=#'baz}
{ c d \tiny e f \new Staff \with {\consists Foo_engraver bar=#'baz} { \tiny g
f e d} c d e }
(I think such operator can come out as a side-effect of some work I'm doing)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: beam breaking in tuplets
On Monday 06 November 2006 12:59, Mats Bengtsson wrote:
Erik Sandberg wrote:
On Monday 06 November 2006 09:25, Mats Bengtsson wrote:
Mats, do you think it would be useful with an operator \newClone to clone
the current context? E.g.
\new Staff \with {\consists Foo_engraver bar=#'baz}
{ c d \tiny e f \newClone Staff { g f e d} c d e }
would be equivalent to:
\new Staff \with {\consists Foo_engraver bar=#'baz}
{ c d \tiny e f \new Staff \with {\consists Foo_engraver bar=#'baz} {
\tiny g f e d} c d e }
(I think such operator can come out as a side-effect of some work I'm
doing)
Would it even make sense to make this the default behaviour of \new?
At least, it would probably cause less surprise to a newbie than the
current implementation, in examples like:
\relative c'{ \tiny c d {e d} \\ {c b} }
You have a point here. Perhaps we could have a context property
cloneNewContexts, defaulted to #t for voices, which makes sure that contexts
creations in the current context clone the current context, if the context
types match. (so below, the context hierarchy would be Global-Score-Lyrics
where the inner Voice is created, hence no settings would be inherited; this
also means that the inner \new Voice should create a new staff implicitly).
I think the difficult thing is that the syntactical hierarchy of our input
language doesn't match the hierarchy of contexts.
On the other hand, it would probably make it less obvious for the advanced
user to predict exactly what LilyPond does, for example in situations like
\relative c' \new Voice{
c d e f
c1
\new Lyrics \lyricmode {
Some4 text
\new Voice \notemode { c d e2 }
{some more text }
}
}
where it's not obvious if the inner Voice context would inherit anything
from the outer one (maybe this is already crystal clear to you).
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Is Lilypond right for this need?
On Tuesday 31 October 2006 21:21, Cliff Pruitt wrote:
Thanks for the advice.
The suggestions would be great if I were more proficient at writing
out music in general. I think what I'm trying to figure out is the
best way to approximate the correct phrases quickly without taking
the time to be accurate. I'm very slow at determining music notation
and for me to actually work out the note durations for all of our
songs would take forever (I'm working of guitar lessons I had back
when I was in high school early college). I know HOW to work it
out (conceptually) but its a very slow unnatural process for me.
My main requirements are:
- Have a chord line up over the right word
Hm, there are mechanisms which should make it possible to align words to
chords, but it probably requires some nonstandard trickery. Probably you can
do something like
harmonies = \new ChordNames=harmonies \chordmode {
b2 f2 es2 f2/es % and so on ...
}
\score {
\harmonies
\new Lyrics \lyricsto harmonies { Over all the earth You reign on
high }
% so that lyrics can align to music in the context
\context { \ChordNames \alias Voice }
}
If rhythm is unimportant, you can try \cadenzaOn (turns off automatic
barlines), and then use \bar | to add bars.
- Multiple verses of lyrics under one line (staff) of chords
Ideally I would be able to format it as a chord in the given key (for
bass piano) optionally have another staff that shows chord names
transposed for use with a capo.
I think what I'm running into is just that your average run of the
mill rock guitar player (i.e. myself) is out of touch enough with the
correct way of reading writing music that it might be a difficult
switch for me. Its my deficiency, not the software.
I've managed to output a sample song with the correct chord / word
alignment, but the bar lines are in all kinds of chaotic places since
every syllable is (I'm assuming) interpreted as a quarter note. At
this point I'm down to trying to figure out a consistent method for
reducing everything to 32nd or 64th notes based on syllables, filling
whatever isn't used with rests just trying to write an app to
convert some simple text file into an .ly file.
Really Lilypond probably is overkill for what I need, but there isn't
anything else out there that does what I need any better. There's
not much out there for that stage between a word processor document
and the need for full blown sheet music.
Any other thoughts or suggestions are much appreciated, but I
understand if I'm just outside of the box here.
- Cliff
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: The importance of a graphical interface.
On Saturday 28 October 2006 20:19, Valentin Villenave wrote: Hello César ; Just a few words. As a matter of fact, I've switched to linux in the mean time I've switched to Lilypond... But we can't ask everyone to do so, and therefore I agree it indeed lacks a decent user interface ; especially when you're used to Mac/Windows world, and a bit lost when you find yourself in front of a command line Subversion has a nice solution to this problem, through tortoisesvn, which works as a plugin for windows explorer: By right-clicking on a directory, you can access a menu through which you can perform all common subversion tasks. Would it be useful to create a similar lilypond menu? I.e., when you right-click a .ly file, one of the available choices would be 'compile to PDF'. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: The importance of a graphical interface.
On Saturday 28 October 2006 18:41, Tomas Valusek wrote: Hello, it would be nice to be able to correct some things using mouse (most notably, slur shapes, system distances, markup positioning etc.) Shaping slurs using mouse is quite easy, but doing the same in .ly file is quite cumbersome. There has been support for something similar for a while now (since 2.6, IIRC). Nobody has used it yet, though. IIRC the relevant option is: lilypond -b gnome You can search mail archives for more info. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Polyphonic Tablature
On Monday 23 October 2006 12:08, Han-Wen Nienhuys wrote:
Mats Bengtsson escreveu:
Daniel Tonda wrote:
Just revised the code I proposed and you're right. I wasn't aware that
by using one could remove the \simultaneous. Less typing indeed.
Right! \simultaneous{...} is completely equivalent to ...
Actually, the following is exactly equivalent to your example:
I've added \simultaneous for consistency a long time ago, but maybe we
should just drop it?
in any case we could softcode it, I think.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \mark \default in 2.9.24
On Monday 16 October 2006 12:17, Paul Scott wrote:
This:
\version 2.9.24
{ c1 \mark \default }
nMark = \mark \default
gives:
[EMAIL PROTECTED]:~/music/test$ lilypond nmark.ly
GNU LilyPond 2.9.24
Processing `nmark.ly'
Parsing...#Prob: Music C++: Music((origin . #location
nmark.ly:3:5))((display-methods #procedure #f (mark)) (name .
MarkEvent) (types general-music mark-event event))
#Prob: Music C++: Music((origin . #location
nmark.ly:4:8))((display-methods #procedure #f (mark)) (name .
MarkEvent) (types general-music mark-event event))
I'll send this to the bug list if I haven't missed something in the
latest manual.
Sorry, my fault (I forgot to switch off some debug output). Fixed in CVS.
Thanks for reporting!
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: I would like to buy this enhancement (highly motivated buyer)
On Thursday 12 October 2006 18:22, Rick Hansen (aka RickH) wrote: Thanks for the suggestion Mats. My motivation for this is that I am currently writing some lesson material that reference full scores and would like to make a nice word processor document that flows, with illustrations embedded in the text, and the text flows around the illustrations, etc. (an old school typography look with no grids or tables). Something that really looks nice and has an artful use of typography and imbedded illustrations. I found that I needed dozens of music snippets from the original, and was wasting a lot of time massaging my already-completed-just-fine scores to put the excerpted notes into dedicated variables for re-use, tags, skiptypesetting, etc. Times having to do that for all the vertical staffs, lyrics, chord names, across the needed measures, amplified the work. Finally I threw my hands up in frustration and thought of how I would make such a document using just a simple typewriter and xActo knife. In this case, it is not sufficient to just use \tag etc., because if you do, each snippet will be treated as the first system, so time signature etc. will be displayed in each example. One solution for you could be to wrap the .ly code inside a .tely document, and use lilypond-book. Lilypond-book generates one individual .eps for each system, so if you just insert \breaks in the right spots, then it should give you what you want (this way, you will also get page breaks between systems in a natural way). Also, I hope you know about OOoLilypond; if not, please read the ML archives. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Making notes in Scheme?
On Sunday 15 October 2006 22:59, Marcus Macauley wrote:
Nicolas Sceaux wrote:
And because it's possible to manually type notes within a music function
in Scheme, e.g.:
function =
#(define-music-function (parser location var1) (integer?)
#{
c'4 d' e'
#})
It seems like it should also be possible to substitute variables for those
notes, such as:
#(define-music-function (parser location var1) (integer?)
#{
$firstnote #(list-ref notes 1) #(list-ref notes 2)
#})
From what I can tell, the key is the ly:music data type, but I don't
know how to to use that from within Scheme, if it's even possible, much
less how (if possible) to convert e.g. strings to ly:music.
The ly:export function may also have something to do with it, but if so,
I haven't figured out quite what.
normally, the return value of a scheme expression is thrown away by the
parser; ly:export is used to mark expressions that instead should be
interpreted as music. So what you wanted above is something like:
#(define-music-function (parser location var1) (integer?)
#{
$firstnote #(ly:export (list-ref notes 1)) #(ly:export (list-ref notes
2))
#})
Note that ly:export is built into make-music-function, so in that case you
don't have to worry about it.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: OOoLilyPond question
On Tuesday 10 October 2006 23:40, David Bobroff wrote:
Samuel Hartmann wrote:
Hi David,
So this error occurs in fragment mode if a \score {} block is
included. Feature or bug?
Feature; lilypond-book does the same. with fragment, you let lilypond-book
place a \score block around your snippet.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Swing Midi
On Wednesday 20 September 2006 22:55, Ted Walther wrote: On Wed, Sep 20, 2006 at 11:34:33AM -0500, David Greene wrote: If you want to do something more generic (something you can apply on any existing ly score), then you may want to consider using music streams. Music streams are a new concept in 2.9, and nobody has used them yet AFAIK. However, I can try to guide you if you're interested. (I would guess htat this solution can be coded entirely in Scheme) I'm very interested in this. I don't recall seeing anything about it in the manual -- maybe I missed it. Is there a description somewhere? I think I read elsewhere that \partcombine is supposed to be replaced by these same music streams. Are they documented anywhere? Will the new \partcombine be a wrapper on top of these music streams? Actually, music streams _are_ already used for partcombine (streams are converted to a format which partcombine uses, the plan is to change that format to a more powerful data structure). You can read my thesis (see link in my other reply on lily-devel) for more info. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Swing Midi
On Friday 15 September 2006 00:47, Han-Wen Nienhuys wrote:
David Greene wrote:
Hi everyone,
I searched the archives and found a few discussions about
generating swing-feel MIDI from straight eighths Lily
source but the most recent was from 2004.
I was thinking about writing a Scheme function to carve
up all of the durations into units of eighths, inserting
the proper ties to maintain longer notes. Then I could
imagine altering the durations as appropriate to implement
the swing feel.
If you want to make the programming easy, and if it's OK to sacrifice note
entry speed, then I'd recommend that you mark all swing notes somehow, e.g.
by putting them inside braces, two by two:
{ c c } { c c }
Then it's easy to write a music function that finds all SequentialMusics with
two elements, and which manipulates the durations of those elements.
If you want to do something more generic (something you can apply on any
existing ly score), then you may want to consider using music streams. Music
streams are a new concept in 2.9, and nobody has used them yet AFAIK.
However, I can try to guide you if you're interested. (I would guess htat
this solution can be coded entirely in Scheme)
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: sponsorship offer: \lyricsto with \partcombine
Citerar Ted Walther [EMAIL PROTECTED]: To typeset hymns with the same high quality that lilypond brings to other areas of music typesetting, I need to be able to use \lyricsto with \partcombine. What exactly do you want to do? If you want to align one lyric line to one voice, and another lyric line to another voice, then you can do something like: \partcombine \sopNotes \altoNotes \new Devnull=sop \sopNotes \lyricsto sop \sopLyrics \new Devnull=alto \altoNotes \lyricsto alto \altoLyrics Also, what would it cost to make the chord-threshold variable in part-combiner.scm/dtermine-split-list be settable inside a .ly file? A rewrite of partcombiner is on the todo. You can copy all the code from part-combiner.scm into your ly file, all you need to do is to add a # before each toplevel expression to make lily understand it. (you'll also have to re-define \partcombine etc. to make them use the new definitions) Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: functions in \with
On Monday 28 August 2006 13:55, Trevor Daniels wrote:
I'm happily creating and using music functions but so far my attempts to
define functions that can be used in \with or \context clauses have failed.
The suggested technique of making a void function using (make-music
'SequentialMusic 'void #t) doesn't seem to help.
What do you want to achieve, more precisely?
Note that \with uses a different lexical mode than music, so e.g. the
\override keyword does not produce a music expression when used inside \with.
You can probably perform operations on the whole \with block if you are
clever, by applying a funciton on the \new expression, like
\myFun \new Staff=foo \with {bla bla} {music}
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sponsored feature request--partially-tied chords
On Thursday 24 August 2006 17:39, Han-Wen Nienhuys wrote: Steve D wrote: On Tue, Aug 22, 2006 at 10:55:05AM +0200, Han-Wen Nienhuys wrote: it's easiest to add a property so you can do c e \tweak #'forbid-tie = ##t g bes cost: 65 EUR. Werner LEMBERG then asked: Just wondering what the much simpler syntax c~ e~ g b~ costs... Han-Wen Nienhuys responded: I can put it in for 35 eur extra, I hope. (the tie engraver is quite tricky, and handling c~ e~ offers more potential for bugs) After thinking about it for awhile, I agree with Werner and like his idea better also, if it can be done. Aside from being clear and simple (to the end user), it can save a lot of typing, especially because when lots of partially-tied chords appear in a piece of music as the result of a rhythmic or other motive. SO-- c~ e g bes~ would mean that only the c and b-flat would be tied c e g bes~ would mean that the whole chord would be tied c~ e g bes~~ would mean--well, LilyPond would issue an error message? The whole-chord tie would take precedence? ;-) After some thought, I agree with Werner (as usual), and I've changed the implementation to do this. Erik, can you look over my use of stream events vs. events in tie-engraver.cc? I have the feeling that the dichotomy between both is a bit ugly, but is there currently another way? With my last patch (which I sent a few weeks ago but without response -- was it lost?), 'articulations is converted to a stream event list when music is converted to event. Also, music_cause is eliminated. Should I resend the patch? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Sponsored feature request--partially-tied chords
On Friday 25 August 2006 11:45, Han-Wen Nienhuys wrote: Erik Sandberg wrote: With my last patch (which I sent a few weeks ago but without response -- was it lost?), 'articulations is converted to a stream event list when music is converted to event. Also, music_cause is eliminated. Should I resend the patch? yes, I think I lost it in the din. It's attached. This is a copy of the last patch, it's not a patch against the newest lily. === The attached patch makes a couple of further cleanups: - eliminate Grob_info::ultimate_music_cause, Grob_info::music_cause - possible bugfix in figured-bass-engraver: never decrement stop_moment - kill all remaining music refs in engravers; remove music.hh include from engraver.hh - use ASSIGN_EVENT_ONCE in engravers where appropriate - junk try_music in Translator, Translator_group, Context, Context_handle - small cleanup in part-combine-iterator; use an enum to distinguish between the outlet contexts. The only remaining part of the translator cleanup is, AFAIK, to remove obsolete translators. -- Erik es-060802-final-cleanups.diff.bz2 Description: BZip2 compressed data ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: \tagsOn, \tagsOff
On Friday 18 August 2006 22:39, Kieren MacMillan wrote: [ v2.9.14 ] Hello, all -- No, this isn't Karate Kid 5! ;-) This is a continuation of the thread setting up a very complex choral layout, with a possible feature request... I have a different suggestion which might solve your problem to some degree: You can split up music into short segments, and then align lyrics to a devnull context which you compose from those short segments. IIRC we discussed this on lily-user some time ago, search for devnull and lyricsto. I think we could solve all my multi-output issues -- and add a really powerful tool to the Lilypond kit -- if we had a \tagsOn (and maybe \tagsOff?) trigger, which would tell Score to listen (or not) to a given tag. I don't think your suggestion would work well with the current incarnation of \tag, because it's based on operations on music expressions. However, I think this can be an application of the new music stream architecture: We could add a layer of listeners between front-end and back-end, which filter out all events with specific tags; \tagsOn/Off would change those filters in interpretation-time. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategy - A Compromise
On Thursday 13 July 2006 12:04, Anthony Youngman wrote:
Might be an idea to look at Antlr then ...
I don't know how effective it would be, but part of the purpose behind
the v3 rewrite is to increase the number of languages that Antlr can
generate. If you can define the grammar in Antlr it could then chuck out
a lexer/parser written in Scheme :-) Is the current lily parser
hand-written?
no, it's written in bison. The lexer invokes an external parser to parse
Scheme expression when needed.
And yes, preservation of white space is apparently fairly easy.
Although, I'm half inclined to say that if you convert-ly a piece,
then it will or can output stuff according to a pretty print standard.
question is whether it's possible to write a grammar that is useful both for
convert-ly and paper production at once, or if it's a better idea to use a
simplified grammar for convert-ly. E.g.: in { \foo c4 c2 } it's difficult to
know whether c4 and/or c2 are parameters to the function foo, or if foo just
is a variable -- it might be that foo has been defined in an \included file.
For convert-ly purposes, it might be sensible to always treat \foo as a
variable, because that makes life simpler.
Take a look at Antlr - www.antlr.org. I'd go straight to v3, which is
due for release this summer. What you would need to do is define the
lily grammar using a BNF style notation (I think the technical term for
the style of grammar is LA or LLA). Antlr itself is written in Java -
run it over your grammar and it will spit out a lexer and parser for
you. You could either use the current C++ templates which would create
your lexer and parser in C++ for feeding the results to Scheme, or write
a bunch of Scheme templates and output the lexer and parser directly in
Scheme. I don't mean to teach grandma to suck eggs but it sounds (from
the implication that the parser is mixed-language) that you're not using
a compiler-compiler such as flex/Bison, PCCTS or Antlr.
And of course, going down this route, things head towards the typical
nix toolkit approach :-) Grammars to input lily ASTs in various
versions, grammars to output pretty printed or converted .ly files in
various versions, grammars to transform ASTs especially ones generated
from eg abc, Sibelius, Personal Composer files :-)
I think it's easier to import from other formats directly to .ly, or to a
known format such as MusicXML.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
Please always CC to the list. On 7/12/06, Ian Hawthorn [EMAIL PROTECTED] wrote: My 0.02c The lilypond language is still evolving. Recent changes in syntax have improved usablity. However at some point the improvements to be gained by further tinkering with the syntax will be outweighed by the nuisance factor of having to frequently update/rewrite scores. I don't think we are quite there yet as I still find the syntax awkward for certain things. But it will happen at some point. Yes? I think we need to look at tex as an example of the way forward. I have tex files which I wrote back in the mid 80s which still run just fine. The core of tex has been standard and static now for a very long time. Yet tex continues to evolve via its package structure. Maybe lilypond should look at doing this. If the size of the codebase is a problem, a package structure would help. I really have no need of weird medaevil musical notation, six line staves, guitar tablature, drum staves, strange clefs, notation for quarter tone notes, etc etc. Others may not need the capacity to deal with polyphony and lyrics which for me is essential. Yet every copy of lilypond comes with everything. A package structure would also help to manage the growth of the project. Features could be added by adding packages, and it would be clear who was supporting what. In addition to its package structure, tex also uses style files. lilypond could look to do the same. The templates now in the documentation look to me to be embryonic style files, and seem to want to evolve in that direction. Finally, I'd like to eventually see something analogous to latex for lilypond - a package providing higher level syntax to make score writing less technical for the average user. Ian H My 2 öre: - A precondition for much of what you suggest, is a stable API: If we decide a specific format for add-on packages, then all such packages will break as soon as we change the API. Right now, I'm working on introducing *two* new intermediate music representation formats to lily. I see this as an indication that it will take some time before it's time to define a stable API. - Package size is not a problem, as long as it doesn't grow insanely large (e.g., I wouldn't think it's sensible to multiply the package size by the number of previously released versions). - There are many problems to bridge; e.g., the syntax of lots of features (lyrics, figured bass) are built into the .ly language, so parser rules would have to be soft-codable. - I hope you know about LSR, the lilypond snippet repository. So far the LSR is rather small, which indicates that there is little public interest in building add-on packages to lily. Currently, there seems to exist few lily gurus (=people with so advanced knowledge that they could have written LaTeX-style add-on-packages). So far I think it's better if those people get involved in lily directly, and perhaps contribute some snippets to the LSR. As long as LSR doesn't contain a very large number of general utility .ly snippets, I don't think it makes much sense to invent an add-on package system. - I have the impression that Han-Wen is even more user-oriented than me (i.e., he doesn't add features without proof that users need them). So the best way of convincing _him_ that we need a system for add-on packages, is probably to get involved and try to write some packages yourself, using the (limited) mechanisms that exist. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategy - A Compromise
On Wednesday 12 July 2006 12:00, Colin Wilding wrote: This is an important dilemma for many users, I think - we want to have all the fixes and features in each new version, but find it frustrating when music produced in earlier versions needs time-consuming manual editing to upgrade. Can I suggest a compromise? I accept that Lilypond has been evolving rapidly and feel privileged to have been able to use it (and contribute comments) during that evolution. At some point, though, the evolution should slow down: the developers should feel happy with the basic structure and syntax and the users should be able to expect that music written for today?s version will look the same in tomorrow?s. What do you mean by 'the same'? Is it OK if the output suddenly looks better because a bug has been fixed? If yes, then you still have the problem that an upgrade may break your tweaks that work around layout bugs. If no, then development will be very difficult because all bugs have to be preserved. If there's sufficient community interest in maintaining and developing a conservative version of lilypond, then anyone can make a fork; however, I doubt any of the current developers would join. Lily is currently at a pretty early stage of development IMHO. How about making a resolution that from version 3.0 onwards Lilypond will be backwards-compatible: in other words, the current version will correctly display a file written in any earlier version 3.x without the need for conversion. I think 2.4 files are fairly forward compatible; there have been no major changes that I know of. There's also the question of what you mean by compatibility: Very advanced tweaks usually rely on the way lily's internals are organised, which may change over time. Since lily contains a Turing-complete programming language, for some language updates it is thereby _impossible_ to create a script that upgrades _all_ .ly files perfectly. There are also deprecated features that are dropped sometimes, this causes a kind of backward incompatibility. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategy - A Compromise
On Wednesday 12 July 2006 12:59, Anthony Youngman wrote: Something I thought of (having seen the comment about convert-ly using grep ...) It's not using grep, but it relies heavily on regexps (so it can somewhat fairly be compared to sed). I've got an on-off thing about writing a DATABASIC compiler (never mind) and have come across a tool called Antlr. It is a compiler-compiler and generates lexers, parsers and treeparsers. IF someone wants to put the effort in, it may (or may not be) easy to define various grammars to read in and chuck out different music formats. It sounds as though a lot of the problems (like the swap between and for example) would be easy. Especially given lilypond's structure it looks like it would be fairly easy to define grammars which can read in or chuck out different lily version syntaxes, even the \addLyrics / \oldAddLyrics thing maybe. I'd rather have a look at parsing expression grammars, see: http://en.wikipedia.org/wiki/Parsing_expression_grammar Seems to combine simplicity of regexps with the power of CFGs. Doesn't seem to be widely implemented though. Another way could be to go via the syntax expressions I'm working on: Instead of applying operations on .ly input, we could apply them to the parser's output, and then use some built-in version specific mechanism to convert finished files back to .ly. I thikn this would be both more reliable than convert-ly, and possibly easier to maintain, but some text formatting might be lost unless the syntax-expression-ly conversion is designed very carefully. Depending on how macros will be implemented, commands like \relative may be lost as well. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategy - A Compromise
On Wednesday 12 July 2006 17:22, Anthony Youngman wrote: I don't really understand grammars etc (which is why my DATABASIC thing is on/off :-). But from my experience with Antlr, I don't see why you should lose stuff. Your PEG article mentions ASTs. I don't see that converting a .ly file into an AST can be that hard. So, for example, we write a Antlr grammar that creates a lexer/parser that turns the .ly into an AST. We now write another grammar that converts the AST to a .ly file. A problem here is code duplication; it takes some effort to maintain two parsers instead of one. I think it will be difficult to automatically test that the current antlr parser corresponds well with the actual grammar the current lilypond version uses. I have been thinking about moving lily's entire parser out to Scheme; this way we could keep one old parser for each version, and use it to generate an AST, which then is converted nicely using rules written in Scheme (Scheme rocks when it comes to tree manipulation). I'm not sure if it's possible though. BTW: Will your solution handle whitespace nicely? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tetex 2.5 and lilypond 2.0
On Monday 10 July 2006 15:14, Laura Conrad wrote: My problem is that I have several major projects that are in lilypond 2.0. Even where convert-ly performs flawlessly (which it doesn't for a number of features, like multi-verse vocal music), By the way, there are plans to drop the old-lyric-combine compatibility altogether, so in order to upgrade to the next stable version, you'll have to rewrite all your old-style \addlyrics expressions manually. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tetex 2.5 and lilypond 2.0
On 7/11/06, Laura Conrad [EMAIL PROTECTED] wrote: Erik == Erik Sandberg [EMAIL PROTECTED] writes: Erik By the way, there are plans to drop the old-lyric-combine Erik compatibility altogether, so in order to upgrade to the next Erik stable version, you'll have to rewrite all your old-style Erik \addlyrics expressions manually. I'm not sure how this differs from what I have to do now. Do you mean that in addition to breaking multi-verse upgrading, you're also planning to break single-verse upgrading? I think so. The command that used to be \addlyrics, and which now is known as \oldaddlyrics, will be removed. \lyricsto (and hte new \addlyrics) will be the only ways to align lyrics. Before that happens, could someone rewrite abc2ly to use something that convert-ly will know what to do with? Or at least explain what that something would be? I don't know much about abc2ly, but it will have to produce \lyricsto expressions in order to work with 2.9. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: tetex 2.5 and lilypond 2.0
On Tuesday 11 July 2006 17:13, Laura Conrad wrote: Erik == Erik Sandberg [EMAIL PROTECTED] writes: Erik On 7/11/06, Laura Conrad [EMAIL PROTECTED] wrote: Erik == Erik Sandberg [EMAIL PROTECTED] writes: Erik By the way, there are plans to drop the old-lyric-combine Erik compatibility altogether, so in order to upgrade to the next Erik stable version, you'll have to rewrite all your old-style Erik \addlyrics expressions manually. I'm not sure how this differs from what I have to do now. Do you mean that in addition to breaking multi-verse upgrading, you're also planning to break single-verse upgrading? Erik I think so. The command that used to be \addlyrics, and Erik which now is known as \oldaddlyrics, will be Erik removed. \lyricsto (and hte new \addlyrics) will be the only Erik ways to align lyrics. I suppose I should be reading the fine manual more, but I've never figured out the difference between \oldaddlyrics and \addlyrics. In any case, my manual conversions use \addlyrics. \addlyrics will still be supported, only \oldaddlyrics will be junked. So according to what you say below, abc2ly will still work fine. I've never seen why convert-ly wouldn't be able to write that from the old output of abc2ly, but instead it writes: The reason why convert-ly can't handle oldaddlyrics, is that it is based on regexps, which makes it very difficult to move stuff far distances (such as across a \context Staff ... expression). -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
On 7/9/06, Fairchild [EMAIL PROTECTED] wrote: New scores could use new features and not have to work around the bugs of earlier versions. Older scores that have been carefully tuned, compensating for earlier bugs, would continue to produce the intended result without having to be overhauled. There would be no need to maintain multiple versions. This basically implies that all old versions of lily must be included in the new versions, so e.g. lilypond 2.10 will contain both version 2.10, 2.8, 2.6 and 2.4. Which means that the lilypond package grows by a factor 4. I think a better solution would be that you create a script locally, which parses the input ly file, reads the \version statement, and picks which lilypond version to use to compile your ly file. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
On 7/10/06, Fairchild [EMAIL PROTECTED] wrote: Erik - Thanks for contributing to this thread. It is attempting to deal with an important unresolved issue: seamless evolutionary transitioning of ly files. Your suggested solution requires n versions residing entirely in the user's machine, which would, as you point out, increase resident code by a factor of n. The code switching option requires parallel code only for features that are interpreted differently for different versions, only marginally increasing the size of the newer versions - far less size, and hassle, than retaining several versions. Different lily versions use different data structures and interfaces internally. If we would have n different versions of e.g. each engraver, and the interface between iterators and engravers would change a tiny bit (which it does now and then), then we would need to update n different versions of each engraver, which is n times as much work as now; it would also mean n times more testing, and n times more bugs. Keep in mind also that the .ly grammar changes between versions, so you will need to have a separate parser for each version. That said, you are of course welcome to write a patch that makes lily 2.9 support 2.4 files. My guess is that Han-Wen won't accept the patch, but if you really want the feature you can always fork the lilypond project, and start a lilypond-legacy project. BTW, if you're concerned about the extra size consumption that it requires to have n different versions, you could consider compressing your file system. If there is much code in common between lily versions, then a smart compression algorithm might detect this and reduce the extra space consumed. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
On Saturday 08 July 2006 18:58, Fairchild wrote: The 3.0 processor could note the 2.4 version flag and treat the ly file in the 2.4 way, maintaining upward compatibility without a need for convert-ly. In what way would that be different from installing two different versions of lily? If you don't want the bugfixes from 3.0, why do you upgrade to 3.0? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Chords with ()
On Saturday 08 July 2006 19:16, Ezequiel Sierra wrote: Any help with this? On Jul 7, 2006, at 8:59 AM, Ezequiel Sierra wrote: Does anybody can help me with this issue? On Jul 5, 2006, at 9:22 PM, Ezequiel Sierra wrote: What is the problem here? http://www.ezequielsierra.com/1.txt i did as told, still not working Unfortunately I don't have time for that at this moment, but perhaps you could try learning Scheme basics and read about tweaks in the manual, and then try to understand exactly what I meant in my previous suggestion, and finally try to correct the errors I made. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Chords with ()
On Wednesday 05 July 2006 07:19, Ezequiel Sierra wrote: How can i set it to all the chords? not just one? You could probably do something like: (untested) #(define (parenthesis-ignatzek-chord-names in-pitches bass inversion context) (make-markup #'line (list ( (ignatzek-chord-names in-pitches bass inversion context) and then use \set chordNameFunction = #parenthesis-ignatzek-chord-names (The (make-markup ..) syntax is probably incorrect, because I don't know that syntax by heart, but you can probably use displayMusic to figure out the correct syntax.) Erik On Jul 4, 2006, at 7:25 PM, Eduardo Vieira wrote: Hi! Check this message for an answer: http://lists.gnu.org/archive/html/lilypond-user/2005-11/msg00708.html - Original Message - From: Ezequiel Sierra [EMAIL PROTECTED] To: lilypond-user@gnu.org Sent: Tuesday, July 04, 2006 6:52 PM Subject: Chords with () Does anyone know how to put the chords inside () like, (A) (Em) Regards -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond store?
On Wednesday 05 July 2006 15:09, Stewart Holmes wrote: Yes. Harsh this may sound, but how much of the music on Mutopia would you be satisfied to print out, and use yourself? From a quick browse through various sections, I have to say that a large amount of the music on there is fairly poorly engraved. My proposition is for much more strict quality control... after all, nobody will pay money for music unless it looks professional. I suggest that you start a discussion thread on mutopia's mailing lists: If you have constructive ideas on how to create an archive of high-quality public domain notes, then I would strongly recommend you to use your ideas to improve mutopia; if that's not possible, use mutopia as a base for creating such an archive (i.e., fork the mutopia project). -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 'Slanted' fractions
On Monday 03 July 2006 16:48, Stewart Holmes wrote: I'm trying to do some guitar barring, which involves using the fraction 1/2. The markup /fraction gives me a fraction with one number vertically above the other. I'd quite like it so that the 1 is in the top left, the 2 in the bottom right, with a diagonal line inbetween. Is this possible in Lilypond? I think the easiest way is to use the string ½. (ok, I know, it's cheating) -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music definition change in 2.9.9 or thereabouts?
On Wednesday 28 June 2006 07:41, Paul Scott wrote:
Erik Sandberg wrote:
On Monday 19 June 2006 03:21, Paul Scott wrote:
This used to work in 2.8:
\version 2.9.9
KeyG = \key g \major
{ \KeyG a'' b'' g'' a'' }
Have any keywords been added or something that would break this?
This is now fixed in CVS. Thanks!
Thanks! I've been watching the thread. Any idea when a development
version with the fix will be ready?
Han-Wen will be away for another week, so you'll have to wait for a while.
Meanwhile, you can use:
KeyG = { \key g \major }
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music definition change in 2.9.9 or thereabouts?
On Monday 19 June 2006 03:21, Paul Scott wrote:
This used to work in 2.8:
\version 2.9.9
KeyG = \key g \major
{ \KeyG a'' b'' g'' a'' }
Have any keywords been added or something that would break this?
This is now fixed in CVS. Thanks!
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music definition change in 2.9.9 or thereabouts?
On Monday 19 June 2006 12:12, Han-Wen Nienhuys wrote:
Paul Scott schreef:
This used to work in 2.8:
\version 2.9.9
KeyG = \key g \major
{ \KeyG a'' b'' g'' a'' }
Have any keywords been added or something that would break this?
Erik has done some work on the parser, which might be the cause.
The problem is the difference between MUSIC_IDENTIFIER and EVENT_IDENTIFIER.
Right now, the latter can only be used for articulations, and after my parser
cleanups, no event-chord is created around \key.
I'm not quite sure what the proper solution is. The attached patch solves the
problem by renaming EVENT_IDENTIFIER to ARTICULATION_IDENTIFIER. The solution
is easy and it works AFAICT, but it relies on music-classes, whose fate is
uncertain. I did consider the following solutions as well:
1. Extend identifier-smob with type information (typically corresponding to
the return value of try_special_idetifiers). I think this will only move the
problem, because expressions like foo = #... must still be assigned a type
correctly.
2. unify MUSIC_IDENTIFIER with EVENT_IDENTIFIER. This has one problem: someone
will try
foo = -.
{ c2\foo d2 }
which (AFAICT) will put the dot above the d2
3. Whenever a variable is assigned music, wrap it in a dummy sequential_music.
Unclean.
--
Erik
Index: lily/parser.yy
===
RCS file: /sources/lilypond/lilypond/lily/parser.yy,v
retrieving revision 1.517
diff -u -r1.517 parser.yy
--- lily/parser.yy 13 Jun 2006 22:01:19 - 1.517
+++ lily/parser.yy 19 Jun 2006 22:04:17 -
@@ -262,7 +262,7 @@
%token scm CONTEXT_DEF_IDENTIFIER
%token scm DRUM_PITCH
%token scm DURATION_IDENTIFIER
-%token scm EVENT_IDENTIFIER
+%token scm ARTICULATION_IDENTIFIER
%token scm FRACTION
%token scm LYRICS_STRING
%token scm LYRIC_MARKUP_IDENTIFIER
@@ -1624,7 +1624,7 @@
m-set_spot (@$);
$$ = m-unprotect ();
}
- | EVENT_IDENTIFIER {
+ | ARTICULATION_IDENTIFIER {
$$ = $1;
}
| tremolo_type {
@@ -2392,10 +2392,10 @@
unsmob_music (*destination)-
set_property (origin, make_input (last_input_));
- bool is_event = scm_memq (ly_symbol2scm (event), mus-get_property (types))
+ bool is_articulation = scm_memq (ly_symbol2scm (articulation-event), mus-get_property (types))
!= SCM_BOOL_F;
- return is_event ? EVENT_IDENTIFIER : MUSIC_IDENTIFIER;
+ return is_articulation ? ARTICULATION_IDENTIFIER : MUSIC_IDENTIFIER;
} else if (unsmob_duration (sid)) {
*destination = unsmob_duration (sid)-smobbed_copy ();
return DURATION_IDENTIFIER;
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: music definition change in 2.9.9 or thereabouts?
On Tuesday 20 June 2006 00:07, Erik Sandberg wrote:
On Monday 19 June 2006 12:12, Han-Wen Nienhuys wrote:
Paul Scott schreef:
This used to work in 2.8:
\version 2.9.9
KeyG = \key g \major
{ \KeyG a'' b'' g'' a'' }
Have any keywords been added or something that would break this?
Erik has done some work on the parser, which might be the cause.
The problem is the difference between MUSIC_IDENTIFIER and
EVENT_IDENTIFIER. Right now, the latter can only be used for articulations,
and after my parser cleanups, no event-chord is created around \key.
.. and here's the corresponding regression test also.
--
Erik
\version 2.9.10
\header {
texidoc = Variables can be assigned articulations and events.
}
Articulation = -.
Event = \key g \major
{ \Event c''4-\Articulation }
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: barline problem
On Wednesday 14 June 2006 17:25, Stephen wrote: - Original Message - From: Dewdman42 [EMAIL PROTECTED] To: lilypond-user@gnu.org Sent: Tuesday, June 13, 2006 4:55 PM Subject: Re: barline problem Which gets us to the crux of the problem. Finale and lilypond use all of the nuances of postscript that they possibly can..perhaps even using parts of it that the PDF subset does not support very well. For this reason, all the PDF viewers I have tried look like crap. Sad. Your right, Lilypond does not produce PDF files, ghostscript does. So the only thing Lilypond could do is add additional hinting in the PostScript file as Hans has already suggested. And as you've already pointed out, what matters is how the music looks printed out. It is inadviseable to practice your instrument looking at the 72 dpi of the computer screen rather than a 300 dpi printed score. That's bad for your eyes. I think there exist music stands consisting of TFT displays nowadays, so good on-screen rendering is desirable to some extent. However, I'd advise to produce png output if you want to view output on screen; because pngs display a lot faster than pdf or ps, and The PDF files certainly are perfectly readable and legible, so therefore, I don't think it is sad or even undesireable to have the slight aliasing issues you see. After all, 72 dpi will always be inferior to 300 dpi no matter how you slice it. If Lilypond is optimized for 300 dpi, that is a good thing. btw, lily is optimized for 600 dpi iirc: the stems have slightly rounded edges, this is not visible on resolutions below 600dpi. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: barline problem
On Wednesday 14 June 2006 17:25, Stephen wrote: Your right, Lilypond does not produce PDF files, ghostscript does. So the only thing Lilypond could do is add additional hinting in the PostScript file as Hans has already suggested. And as you've already pointed out, what matters is how the music looks printed out. It is inadviseable to practice your instrument looking at the 72 dpi of the computer screen rather than a 300 dpi printed score. That's bad for your eyes. I think there exist music stands consisting of TFT displays nowadays, so good on-screen rendering is desirable to some extent. However, I'd advise to produce png output if you want to view output on screen: pngs are optimised for on-screen viewing regardless of which viewer you use, and they can probably be displayed a lot faster than pdf or ps can. The PDF files certainly are perfectly readable and legible, so therefore, I don't think it is sad or even undesireable to have the slight aliasing issues you see. After all, 72 dpi will always be inferior to 300 dpi no matter how you slice it. If Lilypond is optimized for 300 dpi, that is a good thing. btw, lily is optimized for 600 dpi iirc: the stems have slightly rounded edges, this is not visible on resolutions below 600dpi. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: old-style pedals working, but brackets not? [MINIMAL EXAMPLE]
On Tuesday 13 June 2006 16:00, Kieren MacMillan wrote: Hi, all -- I was able to reproduce the behaviour I'm seeing in the attached minimal example -- any help on the solution would be appreciated. FYI, this is probably not a minimal example. Usually you can shrink problematic examples down to 5 lines of code; the minimisation process is often useful to understand what's going wrong (e.g.: if you have verified that the Dynamics context in your example has anything to do with the problem, I would remove lines from the context definition, one by one, until there are no lines that are absolutely necessary to reproduce the problem). -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Recent user trying to find out how to mix music and text.
On Saturday 03 June 2006 10:51, Roderick Camelia wrote: Hi Everyone, I'm a recent user of Lilypond and currently writing a music theory book for popular music. I've downloaded the Lilypond system since I'm needing a way to print musical examples among the text. I've gotten as far as being able to make the notes appear in the PDF format. Now I need to find out if it's possible to copy the examples from my Adobe Reader 7.0 to my Openoffice.org 2.o Writer where I'm writing the text. (This text processor is compatible with MicroSoft Word.). On the Lilypond website there is advertised MIX MUSIC AND TEXT and it says further: with the lily-pond utility you can integrate music into LaTeX or HTML seamlessly. Can anyone explain to me how to achieve all of this? Thanks in advance. OpenOffice.org integration is not implemented, but it is available as a sponsored feature. See: http://lilypond-design.com/sponsor/open-features.html -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Object hierarchy in LilyPond?
On Monday 08 May 2006 19:30, Arjan Bos wrote: On 6 mei 2006, at 21:20, Mats Bengtsson wrote: Quoting Erik Sandberg [EMAIL PROTECTED]: On Tuesday 02 May 2006 09:06, Tomas Valusek wrote: Or the context hierarchy or which engravers are included in each context or which objects are created by which engraver (or context) or ... What I would like to see is a model of all the data being used within LilyPond, There's a lot of data used in lily. It would require quite some effort to build the model you're suggesting, and someone would need to maintain the model (which is changing all the time). I think all the current developers have better things to do, but I nothing stops you from writing such documentation. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Object hierarchy in LilyPond?
On Wednesday 10 May 2006 08:11, Simon Dahlbacka wrote: On 5/10/06, Erik Sandberg [EMAIL PROTECTED] wrote: On Monday 08 May 2006 19:30, Arjan Bos wrote: On 6 mei 2006, at 21:20, Mats Bengtsson wrote: Quoting Erik Sandberg [EMAIL PROTECTED]: On Tuesday 02 May 2006 09:06, Tomas Valusek wrote: Or the context hierarchy or which engravers are included in each context or which objects are created by which engraver (or context) or ... What I would like to see is a model of all the data being used within LilyPond, There's a lot of data used in lily. It would require quite some effort to build the model you're suggesting, and someone would need to maintain the model (which is changing all the time). I think all the current developers have better things to do, but I nothing stops you from writing such documentation. the only sane way to do such a thing would be to auto-generate the data by parsing the source or something so it would be updated with the click of a button. Personally, I don't have the extra time to build such a scraping tool.. Such documentation exists, see Program Reference in the manual. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Object hierarchy in LilyPond?
On Tuesday 02 May 2006 09:06, Tomas Valusek wrote: Hello, I'm trying to figure out an overall object hierarchy of LilyPond. The only way I've discovered so far is to traverse programmers guide and follow links. But this is very tedious, since if I want to get something done in non-default way, this approach is very confusing. Could someone please prepare series of charts starting at the reasonable abstract level and ending with hierarchy of all LilyPond object, contexts and however tha various LilyPond parts are named? I don't understand. Do you want to see, for each grob type, which tweakable grob properties it has? Or do you want to create a graph that shows which grobs that belong to which interfaces? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
On Thursday 04 May 2006 06:21, Arjan Bos wrote: Erik, That's a great document! I've read about half of it now and it does a very good job to explain to me how LilyPond works. And seeing the date on the title page, I think I have to congratulate you on your Masters Degree! Well Done! Thanks! Off topic, but are your music streams implemented in the current 2.9 branch? Working on it. From a structural point of view, it looks like a cleaner way of doing things. You might even add the syllables of lyrics to the music stream and do away with the current implementation. The implementation of lyricsto is one of the things that msuic streams happen to clean up; however, large parts of the current implementation are kept unchanged. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Macro pre-processing?
Citerar Rick Hansen (aka RickH) [EMAIL PROTECTED]: Macro pre-processors should generate source code, and stream it in, period. I just want to output strings into the input stream dynamically, that goes beyond \include files and offers concat, replacement of tokens, and some rudimentary logical constructs, etc. at PRE-compile-time, empasize at PRE-COMPILE-TIME. Why don't you use an existing general-purpose preprocessor (m4, cpp, gpp, ..)? Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Block diagram of LilyPond
On Saturday 29 April 2006 12:30, Tomas Valusek wrote: Hello, has anyone created a block diagram of LilyPond, which would show data flow, relationship between various modules, etc? It would be great help for obtaining global idea what LilyPond's about. I have a created one in my master thesis, see home.student.uu.se/ersa9195/report.pdf it is however incomplete because the thesis is quite unrelated to the back-end parts of lily (so it won't help you with grobs, for example). -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Macro pre-processing?
Citerar Graham Percival [EMAIL PROTECTED]:
Agreed. LilyPond is a domain-specific language. It is rather odd
that it is necessary to break out into a different language to do a
great many things.
2) Scheme *is* part of LilyPond language, using #, and scheme macro
and other
capabilities are indeed used. what do you think happens when one
writes:
pad = #(define-music-function (parser location padding music) (number?
ly:music?)
#{ \once \override TextScript #'padding = #$padding
$music #})
In Geoff's defense, this kind of construct _is_ more complicated (to an
end-user) than it needs to be -- why the define-music-function,
I agree. The topic pops up often enough to prove that the syntax _does_ scare
away users from using music functions. Even if users shoudln't need to be
prohibited by the syntax, they are.
why the
parser location (don't bother to explain it to me yet), etc. It
would be easier for users if we could just write
pad = #function (padnum) (number?) %{
\once \override TExtScript #'padding = #$padnum
%}
(of course, we'd still get complaints about the weird syntax)
Something like this can very easily be constructed with existing lilypond. It
sacrifices flexibility (you can only use music parameters), but is easier to
use and to understand:
foo = #(music-function 3 %{ c4 #1 r8 #2 g16 #3 %})
(foo takes 3 music parameters, #1 #2 and #3).
That said, my opinion is that users can live with it. Do the blind
copy-and-paste thing; change the TextScript to DynamicLineSpanner
or whatever you need; it's not a big deal.
I don't want to cut and paste things I don't understand; when I was new to lily
I didn't like grob property tweaking because I didn't understand where the ':s
came from. It's IMHO a good thing to abstract the syntax to a level where users
easily can understand what they are doing.
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Contexts (Was Re: Set vs. Override - I'm confused)
Citerar Tomas Valusek [EMAIL PROTECTED]: Hello, When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Context - another topic of my interest. It seems to me I haven't understood them fully yet. I generally know what they are for, but the role of them is not fully clear to me. You can read my master thesis if you like, it tries to explain the context concept (the appendix music streams for the impatient might be a good choice if you're in a hurry) http://home.student.uu.se/ersa9195/report.pdf BTW: Graham, feel free to incorporate anything you like from the report into the manual. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
Citerar Graham Percival [EMAIL PROTECTED]: On 26-Apr-06, at 10:36 PM, Michael Brennan wrote: David Feuer wrote: On 4/19/06, Erik Sandberg [EMAIL PROTECTED] wrote: In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. Actually it helps me, as a new user. When I first read the manual I didn't see any clear explanation of the difference, the docs could be more clear on that point. But when I realized that one was for grobs and the other for context, it became much clearer, for me it helps separating and understanding grobs and contexts. Great! You now officially know more about this area than me, because I don't have a clue when to use \override or \set. Please take a few minutes to send me some clarifications or additions for the manual: http://lilypond.org/web/devel/participating/documentation-adding Hm. Here's my understanding of it: You can say it's all about the granularity of the setting. \override manipulates settings which are specific to one graphical object/grob (e.g. a NoteHead). \set changes settings on a higher level, and can modify more than one type of grob. For example, fontSize is a context property (modified with \set) because it changes the behaviour of several different types of grobs (e.g., noteheads and rests). You can also change the fontsize of all noteheads only, by overriding a grob property of NoteHead grobs only. Or you can modify the fontsize of a single notehead using \tweak. You can notice that \set and \override use different syntaxes: \set ctx.prop = val \override ctx Grob.prop = val Rule of thumb is: If you can figure out a type of Grob that the tweak is specific to, then it's probably an \override. This rule requires a rough knowledge of which grob types that exist. The only way I know to get this knowledge is by reading the internals reference. Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Set vs. Override - I'm confused
On Tuesday 11 April 2006 23:56, Werner LEMBERG wrote: \set: set the value of a context property \override: set the value of a layout object property I've always wondered why it isn't possible to unify them... In 2.8 there's an essential difference between grob and context properties, which is visible for end-users: the \tweak command only makes sense on layout object properties, not on context properties. This difference might make it easier for new users to understand grob properties. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Macro pre-processing?
On Friday 07 April 2006 00:50, Geoff Horton wrote:
Just read sections 11.1.3 and 11.1.6 in the manual.
That's far more complicated than I want, and even further more
complicated than a musician who's not a computer programmer is going
to want to deal with--please note that those sections are in the
chapter on Interfaces for Programmers. Why should I have to know
Scheme and the details of LilyPond implementation if all I want to do
is save a little typing and come up with a less busy-looking input
file?
I agree with you that this would be nice.
LilyPond is powerful, and I'd like to see more of that power made more
easily accessible. I'm not asking for changes to the basic syntax at
all--anything I'd come up with would be a totally optional pre-pass
system.
I have plans to make some improvent to the parser, in order to make \relative
soft-codable. A side-effect of this will probably be that custom high-order
music functions can be written; for example, you could add a function
\define-function, to easily define a simple music function. It could work
something like this:
\define-music-function {\foo \x \y} { c8 \x d8 \y }
...
{ \foo e16 {f g} }
=
{ c8 e16 d8 {f16 g16} }
The usefulness of this kind of function is disputed among developers, so it
might not become part of the official lilypond distribution.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Undocumented \with syntax?
On Tuesday 04 April 2006 07.50, Rick Hansen (aka RickH) wrote:
\new Voice=Soprano
\with {
\consists Ambitus_engraver
} { myNotesGoHere }
...
The above example gets a compiler error, saying that the \with was
unexpected
Try using \context iso. \new.
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: HELP: Guitar Diagrams (chords)
On Wednesday 22 March 2006 01.37, Jannik Jeppesen wrote: Hi... I feel, I need to ask these questions again since they have not been answered, and I cant figure this out myself I want to make a page with only guitar diagrams like this cc7 dd7dmdm7 ee7emem7 gg7 aa7amam7 b7 You can try lilypond-book. If you really want everything aligned, then you can produce a table, where each cell contains a score with a single chord. Another way would be to use the proportional spacing which is new in 2.8. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: unmetered music question
On Wednesday 15 March 2006 10.53, Eddy-14 wrote:
Mats Bengtsson wrote:
If you don't want any time signature printed, you can do
\override Staff.TimeSignature #'print-function = ##f
What if I don't want a time signature in a part of a piece, and I want it
back in another part ? Setting it invisible is not a solution, since I
change it in almost every bar, and it produces spaces at the begining of
the bars.
The \time commands results in four property settings:
'timeSignatureFraction
'beatLength
'measureLength
'beatGrouping
If you set those manually instead, but leave 'timeSignatureFraction untouched,
then I think no time signature is created.
One way to figure out the values, could be to comment out the expression
starting with:
(define-extra-display-method ContextSpeccedMusic (expr)
in
scm/define-music-display-methods.scm
and then compile a file containing:
\displayLilyMusic { \time 3/4 c }
--
Erik
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Chord symbol placement
On Sunday 12 March 2006 19.53, Edward Ardzinski wrote: I am trying to write a lead sheet, and in a couple days feel like I've got good progress. However, I cannot get the chord symbols to be placed above the staff if I specify a key signature. I'm sure this is possible? It's definitely possible, you can try asking about for help on the lilypond-user list if you can't find answers in the manual. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to embed conditional non-music code
Citerar Alan Stern [EMAIL PROTECTED]: How can I make a non-music part of my .ly file conditional? For example, suppose I want to add something like between-system-padding = 0.3 \in did you try something like this? between-system-padding = #(if (eq? partNum 0) (* 0.3 inch-multiplier) '()) (where inch-multiplier is some magic number) Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to 'unset something
Citerar Jay Hamilton, Sound and Silence [EMAIL PROTECTED]: I'm sure this is easy but I can't even begin to figure out a way to search it in the manual I used \setEasyHeads for many of my students pieces but I would like to stop that function mid-way through the piece or even just a few measures into it. What is the command for that? Thank you. See the file ly/property-init.ly for hints (the command is defined there). Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How to 'unset something
On Sunday 05 March 2006 03.04, Jay Hamilton, Sound and Silence wrote: See the file ly/property-init.ly for hints (the command is defined there). First finding this file was nearly impossible the website docs are misleading. It's not on the web, it's in your local installation of lilypond (in some data dir). The exact location depends on your OS, but you'll probably find it if you scan your entire file system. -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: bug mailing list
Citerar Andrzej Kopec [EMAIL PROTECTED]: BTW, is there place where lilypond bugs are listed? I maintain a CVS archive of known bugs, here: http://savannah.gnu.org/cgi-bin/viewcvs/lilypond/lily-bugs/bugs/ Usually there's a more readable, but less up-to-date, listing here (it's generated from the CVS archive every now and then): http://lilypond.org/bugs/v2.7/ Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: stems in the treble clef
Citerar Annette [EMAIL PROTECTED]: I noticed that when I do the examples in the tutorial, the stems in the treble clef go up in your examples and yet when I do them, the stems go down. The only time I can make them go up is when I did that example of deciding where to draw the beam. Could you look into this? It even happened when I downloaded the examples from that long html page and Hi, Please use lilypond-user list for questions about lilypond usage. Also, it will be easier for us to help you if you can show us the exact contents of your input file. Thanks, Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
