Re: Is there a way to get a "round" to play in the MIDI without making several staggered identical voices?

[H. S. Teoh]

On Wed, Sep 20, 2023 at 09:37:27AM -0400, Kevin Cole wrote:
>I'm not quite sure how to ask the question. 
>Is there a way to play the same melody as different voices with different
>time offsets -- i.e. without duplicating it and adding rests at the
>beginnings of the duplicates? (I only want it in the MIDI part, as the
>printed part would only need to display the basic melody once.)

Assign the music to a variable, and reuse it multiple times:

myMusic = {
... % music notes here
}

% Printed score
\score {
\new Staff {
\myMusic
}
\layout {}
}

% MIDI
\score {
<<
\new Staff {
\myMusic
}
\new Staff {
R1  % whatever time offset you want here
\myMusic
}
\new Staff {
R1*2% deeper time offset
\myMusic
}
>>
\midi {}
}


T

-- 
"The whole problem with the world is that fools and fanatics are always so 
certain of themselves, but wiser people so full of doubts." -- Bertrand 
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous

Re: Newbie questions

[H. S. Teoh]

On Fri, Sep 01, 2023 at 07:27:13PM +0200, Mats-Olof Liljegren wrote:
>Hello!
> 
>I'm a beginner with Lilypond but have decent programming knowledge.
>Something I haven't managed to figure out is how to best organize
>my projects. It becomes a very long file if everything is in the
>same one, so I've tried splitting it into separate `.ly` files for
>lyrics, soprano, alto, tenor, bass, and so on. It works, but I'm
>guessing there are smarter ways to organize scores and lyrics. 
[...]

It really depends on your workflow.  In my smaller projects (piano
pieces) I just keep everything in one file, with LH/RH parts as separate
variables outside the \score block.  Or, in more complex works, separate
voices in separate variables outside the \score block.

For small orchestral works, I keep the structural stuff (\score blocks,
\StaffGroup's, \Staff's, \midi blocks) in separate files, but the notes
themselves in a single file, one variable per instrument. Yes, the file
for notes does get very long, but it's manageable using a decent editor
with good navigational tools (one-key bookmarks, quick search function,
find-matching-braces) and helpful practices such as consistent naming of
variables (fluteIPart, fluteIIPart, violinIPart, violinIIPart, etc.),
and dividing input paragraphs of 4 or 8 bars each, with searchable
comment markers (e.g., `% Intro`, `% Exposition`, `% Development`,
`% Episode 1`, inserted before the corresponding paragraphs in each
instrument's part -- that way I can just search for "hornIIPart" then
"Development" to find the corresponding place to, say, the celloPart in
the same passage).

The reason I keep the \score blocks separate is because generating the
conductor's score vs. individual parts is very different, but once set
up you almost never need to change it. Putting it in different files
reduces the clutter in the notes file that I spend most of the time on.


T

-- 
"How are you doing?" "Doing what?"

Re: Sections or movements in a piece

[H. S. Teoh]

On Wed, Feb 01, 2023 at 06:04:20PM +, John Whitmore wrote:
>Hello all,
>    I'm on Ubuntu and currently only have version 2.22.1 installed so I
>could upgrade a few versions by installing outside the package manager, if
>that was required.
>I'm not the music notation, or music, expert and not sure what is the
>exact term for what it is I'm trying to do. I was search for "section" or
>"movement" thinking that might be the classical tern for it. I'm trying to
>put two distinct parts of music into a single score. So for example if you
>were putting two nursery rhymes into a single page of sheet music and the
>first is section A and second is Section B.
>I hope that makes some sense to people, but I'm sure I'm probably using
>the wrong terminology, and confusing the thing.

Wouldn't they be completely separate pieces?  Or are they "movements" as
in they are two parts of a single piece?

In any case, the way to typeset that in Lilypond is simply to use
multiple \score blocks:

\version "2.25.1"
\score {
% first nursery rhyme here
}
\score {
% second nursery rhyme here
}

They will be put on a single page if they fit, otherwise they will be
put on separate pages.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- 
Christopher

Re: Multiple instances of same articulation/bowing on one note

[H. S. Teoh]

On Wed, Feb 01, 2023 at 03:37:47AM +0100, Jean Abou Samra wrote:
> On 01/02/2023 03:34, kie...@kierenmacmillan.info wrote:
> > Hi Ahanu,
> > 
> >> g_\upbow ^\upbow g g % fails
> >  
> > I would personally consider that a bug!
> 
> script-engraver.cc:
> 
> void
> Script_engraver::listen_articulation (Stream_event *ev)
> {
>   /* Discard double articulations for part-combining.  */
>   for (vsize i = 0; i < scripts_.size (); i++)
> if (scm_is_eq (get_property (scripts_[i].event_, "articulation-type"),
>get_property (ev, "articulation-type")))
>   return;
[...]

Hmm. Shouldn't this be done only in the case of part combining? I.e.,
only when \partCombineXxx is being used.  But I'm not sure how practical
it is to implement this, though, if part combining is done very early in
the process and relies on later stages to de-duplicate articulations.

Maybe somehow attach an internal mark to notes that result from part
combining, so that the above code can be conditioned on this mark?


T

-- 
Ignorance is bliss... until you suffer the consequences!

Re: irrational meters

[H. S. Teoh]

On Wed, Jan 18, 2023 at 07:27:47PM -0500, David Zelinsky wrote:
> Silvain Dupertuis  writes:
> 
> > It is better not to confuse a /fraction/ (as an expression) and it's
> > /value/ (as a /number/) ­­— a number cannot have a numerator or a
> > denominator!
> 
> Well, a *rational* number does have a well-defined denominator:
> Because of unique factorization of the integers, there is a unique
> representation of a rational number as n/d where n and d are integers
> with no common factor and d is positive.

True, but time signatures do not have a 1-to-1 correspondence with
rational numbers: 6/8 and 3/4 are distinct as time signatures, even
though as fractions they signify the same rational number.


> Now if we wanted to think about time signatures N/D where N and D are
> elements of, say the integers with the square root of -5 adjoined,
> that's another matter.  Any takers, you composers out there?  :)
[...]

Adjoining square roots of some positive number may still be somewhat
imaginable, e.g., √5/4 means each measure consists of √5 (approximately
2.236...) quarter notes. Hard to perform precisely without computer
help, but still possible in theory.  But how is one to interpret √(-5)/4
??  How do you count up to an imaginary number of beats per bar, even in
theory?

//

Further thoughts about √5/4 as a time signature: due to the peculiarity
of standard musical notation, which only has symbols for note values
that are rational subdivisions of a whole note (and even that, not all
rational subdivisions are directly representable), any combination of
notes in a √5/4 bar will not fit exactly within the bar, √5 being
irrational. (This also applies to any other irrational fraction you may
choose for the top component of the time signature.) So that means the
last quarter note beat will be split across the bar line by some
irrational fraction, with the remaining duration overflowing into the
following bar.

Note that changing the notation may not help anything. Suppose we
introduce new notation for representing irrational note values. Then
either the new note values are commensurate with the (irrational) time
signature, or they're not.  If they are, then we've effectively reduced
the time signature to a traditional, rational signature: if we introduce
a note value of √5/6, for example, then 6 such notes would add up to 1
bar in a √5/4 signature, so we've effectively turned it into 6/4 and
it's no longer an irrational time signature. If the new note values are
not commensurate with the time signature, then we will still have notes
split across barlines even if we use the new note values, so nothing has
really changed.

Now if you have a long series of consecutive quarter notes, they will
span some number of bars, and every bar line will split a quarter note
in some unique, irrational fraction -- due to irrationality, no bar line
will fall exactly at the start/end of a quarter note, so excepting the
start of the first bar, everywhere else there will be notes split across
the barline. And each split note will be split in a unique, irrational
fraction.  If we individually move each barline so that it falls on the
closest start/end of a quarter note, then we end up with a series of
bars with regular (rational) time signatures, but with time signature
changes in an irregular pattern -- this is what I referred to in an
earlier post.  So, "rationalizing" an irrational time signature in this
way, we see the irrational number essentially serves as a source of
irregular bar lengths that never repeats.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

Re: irrational meters

[H. S. Teoh]

On Tue, Jan 17, 2023 at 07:08:41PM -0500, David Zelinsky wrote:
> Kieren MacMillan  writes:
> 
> > Hi Silvain,
> >
> >> I wonder about the term “irrational” meter. Should not we say
> >> “irregular” ??  as in mathematics, an irrational number is a number
> >> which cannot be represented as a fraction...
> >
> > As both a published composer *and* a published number theorist, I
> > wholeheartedly concur with your intuition — I’ve been pushing for
> > decades against “irrational” as a descriptor for time signatures
> > [except where it actually applies, of course, as in π/4].
> >
> > “Irregular” is better… but ultimately I prefer “non-dyadic” to
> > describe any time signature where the bottom number (a.k.a.
> > “denominator”, a label I also avoid) is not an integer power of 2.
[...]
> As another professional number theorist and musician (though not a
> composer), I also find this use of "irrational" to mean "non-dyadic"
> very grating.  But I once said as much on the Music Engraving Tips
> facebook group, and got summarily shot down as ignorant and elitist.
> The argument, such as it was, held that this is about *music*, not
> *mathematics*, so there's no reason to adopt mathematicians' quirky
> terminology.  This left me rather speechless, so I gave up.  However,
> if I ever have reason to discuss this type of meter, will always call
> it "non-dyadic".
[...]

This is off-topic, but it would be interesting if somebody composed a
piece with an actually irrational meter, like π/4 or 3/π.  Only thing
is, it would be impossible for human performers to play correctly, since
there isn't any way to count the beats correctly (counting beats implies
a rational fraction, since by definition it's impossible to count up to
an irrational ratio by counting finite parts).

But perhaps a more practicable approach is to use an irrational fraction
as an endless source of diverse beat divisions that has no long-term
patterns (because another property of an irrational number is that its
base-n expansion does not produce a repeating sequence).  For example,
one could take the digits of π (in whatever base one fancies) and use
that as the number of beats to divide each bar into. In base 10, the
first bar would be 3/4, the second bar 1/4, the third 4/4, then 1/4,
then 5/4, etc..  Or, if one wishes, use pairs of digits for time
signatures: 3/1, 4/1, 5/9, ... etc.. It doesn't have to be base 10, of
course. Base 12 would yield 3/1, 8/4, 8/0, and so on (not sure how to
interpret 8/0, but I'm sure someone could come up with something).


T

-- 
"The whole problem with the world is that fools and fanatics are always so 
certain of themselves, but wiser people so full of doubts." -- Bertrand 
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous

Re: LilyPond 2.24.0 released!

[H. S. Teoh]

On Sat, Dec 17, 2022 at 12:52:27AM +0100, Jean Abou Samra wrote:
> Le 16/12/2022 à 20:39, H. S. Teoh via LilyPond user discussion a écrit :
> > Hmm.  I'm running a local Linux build of 2.24.0 (commit
> > 916ae4111441a9426fbb9c11f7c42735eccf0cac).
> 
> 
> That is not 2.24.0, but current master. 2.24.0 is the tag v2.24.0,
> which the branch stable/2.24 also currently points to. The commit
> you identified is not part of 2.24.0 because we branched the stable
> release earlier than that.
> 
> At any rate, thanks for reporting. I've opened
> 
> https://gitlab.com/lilypond/lilypond/-/issues/6482
[...]

Thanks for the clarification!

I just realized that I had written the input wrong in the first case as
well, it should have been \repeat percent { \tuplet ... } rather than
\tuplet ... { \repeat percent }.  Maybe this is worth mentioning in the
docs for \tuplet?


T

-- 
Obviously, some things aren't very obvious.

Re: LilyPond 2.24.0 released!

[H. S. Teoh]

Hmm.  I'm running a local Linux build of 2.24.0 (commit
916ae4111441a9426fbb9c11f7c42735eccf0cac).  My configure command was
just running autogen.sh with --prefix.  Does that make a difference?


--T

On Fri, Dec 16, 2022 at 07:31:46PM +, Paul Hodges wrote:
>Your snippet compiles correctly (with the errors) on my Windows
>install of 2.24.0
>Paul
> 
>    From: H. S. Teoh via LilyPond user discussion 
>To: 
>Sent: 16/12/2022 18:33
>Subject: Re: LilyPond 2.24.0 released!
> 
>  On Thu, Dec 15, 2022 at 10:42:42PM +0100, Jonas Hahnfeld via LilyPond
>  user discussion wrote:
>  > We are proud to announce the release of GNU LilyPond 2.24.0.
>  [...]
> 
>  This latest release broke one of my scores.  I have reduced the problem
>  to the following snippet:
> 
>      \version "2.18.2"
>      \score {
>          \tuplet 3/2 4 { \repeat tremolo 6 { 8( } }
>      }
> 
>  Lilypond produces the following error:
> 
>      Processing `2.ly'
>      Parsing...
>      Interpreting music...
>      warning: omitting tuplet bracket with neither left nor right bound
>      2.ly:3:55: warning: unterminated slur
>          \tuplet 3/2 4 { \repeat tremolo 6 { 8
>                                          ( } }
>      Preprocessing graphical objects...
>      /usr/src/lilypond/share/lilypond/2.25.0/ly/init.ly:65:2: error:
>  Guile signaled an error for the expression beginning here
>      #
>       (let ((book-handler (if (defined? 'default-toplevel-book-handler)
>      In procedure ly:grob-array-ref: Wrong type argument in position 1
>  (expecting Grob_array): ()
> 
>  I have narrowed down the offending commit using git bisect to the
>  following:
> 
>      commit fd92bef058ee0fbbdaafdee0cc056316f6d4b9f9 (HEAD,
>  refs/bisect/bad)
>      Author: Jean Abou Samra 
>      Date:   Tue Oct 25 00:48:09 2022 +0200
> 
>          Move Tuplet_bracket::parallel_beam to objects callbacks
> 
>          Not only does this avoid redoing the same computation several
>  times, but it
>          makes what happens much clearer, because previously, different
>  calls to
>          Tuplet_bracket::parallel_beam would non-obviously return
>  different values
>          depending on the caller callback since some of the callers are
>  executed before
>          line breaking and some after.
> 
>  Prior to this commit, the original score compiled correctly, albeit with
>  the same warnings about omitting tuplet brackets.  The output is correct
>  (a slashed stem with the tuplet number written above the chord).  The
>  current release, however, does not produce any output because lilypond
>  aborts after displaying the above error message.
> 
>  How do I obtain the same output without triggering this error?
> 
>  --T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for 
Volkswagen.

Re: LilyPond 2.24.0 released!

[H. S. Teoh]

On Fri, Dec 16, 2022 at 10:33:58AM -0800, H. S. Teoh via LilyPond user 
discussion wrote:
[...]
> This latest release broke one of my scores.  I have reduced the
> problem to the following snippet:
> 
>   \version "2.18.2"
>   \score {
>   \tuplet 3/2 4 { \repeat tremolo 6 { 8( } }
>   }
[...]

Further investigation revealed that replacing `tremolo` with `percent`
triggers the same problem.

In addition, if the music inside the \tuplet does not add up to a
multiple of the tuplet duration, the same error is triggered. For
example:

\tuplet 7/4 8 {
a,=''32 cis e  a cis e a16
}

Arguably this is the user's fault for wrong input, but IMO lilypond
should inform the user of the actual problem rather than trigger an
internal Guile error.


--T

Re: LilyPond 2.24.0 released!

[H. S. Teoh]

On Thu, Dec 15, 2022 at 10:42:42PM +0100, Jonas Hahnfeld via LilyPond user 
discussion wrote:
> We are proud to announce the release of GNU LilyPond 2.24.0.
[...]

This latest release broke one of my scores.  I have reduced the problem
to the following snippet:

\version "2.18.2"
\score {
\tuplet 3/2 4 { \repeat tremolo 6 { 8( } }
}

Lilypond produces the following error:

Processing `2.ly'
Parsing...
Interpreting music...
warning: omitting tuplet bracket with neither left nor right bound
2.ly:3:55: warning: unterminated slur
\tuplet 3/2 4 { \repeat tremolo 6 { 8
  ( } }
Preprocessing graphical objects...
/usr/src/lilypond/share/lilypond/2.25.0/ly/init.ly:65:2: error: Guile 
signaled an error for the expression beginning here
#
 (let ((book-handler (if (defined? 'default-toplevel-book-handler)
In procedure ly:grob-array-ref: Wrong type argument in position 1 
(expecting Grob_array): ()

I have narrowed down the offending commit using git bisect to the
following:

commit fd92bef058ee0fbbdaafdee0cc056316f6d4b9f9 (HEAD, refs/bisect/bad)
Author: Jean Abou Samra 
Date:   Tue Oct 25 00:48:09 2022 +0200

Move Tuplet_bracket::parallel_beam to objects callbacks

Not only does this avoid redoing the same computation several 
times, but it
makes what happens much clearer, because previously, different 
calls to
Tuplet_bracket::parallel_beam would non-obviously return different 
values
depending on the caller callback since some of the callers are 
executed before
line breaking and some after.

Prior to this commit, the original score compiled correctly, albeit with
the same warnings about omitting tuplet brackets.  The output is correct
(a slashed stem with the tuplet number written above the chord).  The
current release, however, does not produce any output because lilypond
aborts after displaying the above error message.

How do I obtain the same output without triggering this error?


--T

Re: The problem of Lilypond changing instrument and the issue of .ly converting to MIDI with a custom setting

[H. S. Teoh]

On Wed, Aug 03, 2022 at 09:15:12PM +0800, 柊希里子 wrote:
>Hello, everyone on the mail list, I'm new to lilypond.
> 
>I have a list of questions below which I haven’t been able to solve
>despite my best effort searching on the internet. 
> 
>1. How do I convert the piano clef to violin and cello clef?

\clef treble
\clef bass


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

Re: Looking for the proper term to search for... like a... prelude? maybe?

[H. S. Teoh]

On Tue, Jul 05, 2022 at 09:38:31AM -0400, Kevin Cole wrote:
>With my very limited knowledge of music theory, I don't know what term(s)
>to search for. 
>I have a piece of music that starts with eight measures of piano, before
>the vocal part comes in. So, it only shows the treble and bass clef staves
>for eight measures, and then adds another staff when the vocals start.

Usually that's called an introduction?  "Prelude" literally would mean
the same thing, except that "prelude" is usually used to mean a
standalone extended movement meant to introduce a larger work -- 8 bars
would be a little short for that.


>I'm guessing that once I know what it's called I can read up on it
>in the documentation and / or find a good example of how to code
>that in LilyPond.
>(I thought perhaps I could "cheat" and use something like lots of
>"s1" followed by a "\break" and it might hide that portion of the
>vocals because nothing's happening, but it didn't work and I
>suspect that's not the right way to think about it anyway.)
>Thanks.

You could create a new vocal staff start 8 bars into the music; that
would have the intended effect, I think.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

Re: How do I add bass clef after the fact?

[H. S. Teoh]

On Wed, Apr 20, 2022 at 08:54:21PM +0300, Omer Katzir wrote:
> Unfortunately it doesn’t solved, because I want to add a complete new
> part and not move one voice.

Oh I see.  In that case, what you want is something like this:

\score {
<<
\new GrandStaff <<
\new Staff = "guitar traditional" <<
\clef "treble_8"
\context Voice = "upper" \upper
\context Voice = "lower" \lower
>>
\new TabStaff <<
... % what you had before
>>
>>
\new PianoStaff <<
\new Staff = "piano righthand" <<
\clef treble
... % piano notes here
>>
\new Staff = "piano lefthand" <<
\clef bass
... % piano notes here
>>
>>
>>
}


T

-- 
Gone Chopin. Bach in a minuet.

Re: How do I add bass clef after the fact?

[H. S. Teoh]

On Wed, Apr 20, 2022 at 07:41:54PM +0300, Omer Katzir wrote:
> I wrote my music, and decided I wanted to add bass, but I’m having
> problems adding a clef, keep getting errors and I’m still struggling
> with Lilypond. 
> 
> Here’s my sheet, it’s based on a template someone made for me, but
> it’s a guitar template and I want to add bass clef for Piano
> performance. 
[...]
> \score { 
>   <<
> \new GrandStaff <<
>   \new Staff = "guitar traditional" <<
> \clef "treble_8"
> \context Voice = "upper" \upper
> \context Voice = "lower" \lower
>   >>
[...]

You probably want a different staff for your lower voice, so do this
instead:

>   \new Staff = "guitar traditional" <<
> \clef "treble_8"
> \context Voice = "upper" \upper
>   >>
>   \new Staff = "piano" <<
> \clef bass
> \context Voice = "lower" \lower
>   >>


T

-- 
Long, long ago, the ancient Chinese invented a device that lets them see 
through walls. It was called the "window".

Re: partCombine misinterprets Solo

[H. S. Teoh]

On Wed, Mar 23, 2022 at 06:34:52AM -0400, David Santamauro wrote:
> I believe this is all related to the dynamics (more to the point, the
> termination: \!. If we forget the misplacement of “Solo” for a moment
> and observe the behavior of \partCombine with just the dynamics, it
> seems to have real difficulties with dynamics termination.

I use \partCombine quite extensively, and have observed that it's very
finicky when it comes to dynamics. Basically, before it can combine two
parts correctly, the dynamics must be identical in both parts. Identical
meaning that any dynamics like \f, \p must fall in exactly the same
beat, and any cresc/decresc must begin and end at the same place.  In
particular, if you have a cresc or decresc ending on a particular beat
in one part but not in the other (e.g., the other is silent or has an
unchanging dynamic like \f or \p), then it will *not* combine the parts
on that beat.

This applies not only to dynamics per se, but also to any additional
events in the two parts aside from notes, such as \set commands (like
\set Staff.midiExpression, and so on). The presence of any such commands
must be identical across the two parts, otherwise \partCombine will
refuse to combine it (and if forced to, is likely to produce incorrect
results).

Because of these issues, I have resorted to the hammer-fisted approach
of using \tag and \removeWithTag to "hide" certain things from
\partCombine or "inject" "fake" dynamics in certain places to make the
two parts match where they otherwise wouldn't. In the instrumental parts
the hacks would be suppressed so that the actual dynamics are printed
correctly.


T

-- 
Answer: Because it breaks the logical sequence of discussion. / Question: Why 
is top posting bad?

Re: Problem rendering all scores

[H. S. Teoh]

On Tue, Mar 22, 2022 at 08:36:45PM +, James.Correa wrote:
>Hi everybody,
>I start to have this problem with lilypond after an update to
>python 3.8 , I am on Manjaro KDE.
>Every time I try to engrave a score I got this message:
> 
>Starting lilypond 2.23.5 [Kintsugi-James-Correa.ly]...
> 
>/usr/local/lilypond/usr/bin/lilypond: error while loading shared
>libraries: libcrypt.so.1: cannot open shared object file: No such file or
>directory
> 
>Exited with return code 127.
> 
>I have no idea what is it or how to fix, can someone help?
[...]

This problem does not seem related to lilypond itself. This may help:


https://forum.manjaro.org/t/apg-error-while-loading-shared-libraries-libcrypt-so-1/104352/4

If that doesn't help, you may need to install a newer version of
lilypond from the Manjaro archives, that is built against a newer
version of libcrypt.so.1.

The underlying problem is that your Python upgrade also replaced/removed
a system library (libcrypt.so.1); so either you need to reinstall this
library, or you need a newer build of lilypond that doesn't depend on
this library (it presumably depends on the newer library).


T

-- 
Let's eat some disquits while we format the biskettes.

Re: Extracting a "score diff" from two [or more] Lilypond sources

[H. S. Teoh]

On Mon, Jan 24, 2022 at 05:02:14PM -0800, Flaming Hakama by Elaine wrote:
>On Mon, Jan 24, 2022 at 3:40 PM Kieren MacMillan
><[1]kie...@kierenmacmillan.info> wrote:
[...]
>  I think it's fair to state that the vast majority of people using
>  Lilypond don't use version control.
> 
>Sure, that may be the case.
>On the other hand, do most lilypond users have this issue?
>In any case, for anyone who does have this sort of a workflow task
>to accomplish, 
>I would suggest that it is in their interest to learn to use git.
>You might as well also ask, do the majority of lilypond users back
>up their files regularly?
>I'd guess most probably don't, or not regularly enough.  
>But if they decided to use git, they could get that for free.
>Want to collaborate on projects?  I mean the list goes on.

Sorry for barging in here, but I second this recommendation.  One can
certainly do useful work with lilypond using a careful, manual system of
backup files (and perhaps zip files if your project is large). But
because it's manual, it's also error-prone, liable to human error, and,
in a long-term project, time-consuming and hard to manage.

Using a real version control system (not necessarily git -- though I do
recommend it -- but whatever version control software you fancy)
alleviates most of the tedium of managing backups yourself, does so
reliably, stores copies of *all* versions of your project should you at
some point suddenly need to revisit an old version from several months
ago (that you may have discarded the backup of, in the manual system).
It makes it convenient for collaborative projects, remote off-site
backups are within a few keypresses, etc..

Better yet, in my own lilypond projects I've used git branches to make
experimental changes -- while composing, perhaps an idea strikes that
requires intrusive changes; no problem, start a new branch, sketch it
out, if it turned out to be a bad idea after all, just discard the
branch and go back to where I left off and keep going with the original
version. No fiddly manual backup system and confusing yourself over
exactly which backup was the last "good" one. If it turned out to be a
good idea, merge it back to the main branch and keep going.  Sometimes
multiple ideas strike; I try each of them in turn, each in their own
branch, then pick the best of the crop.

What is *not* to recommend?  I can see only advantages to using version
control software.  Yes it requires effort to learn, but it totally pays
off in the long run.  More than compensates for the initial learning
curve for the convenience, reliability, and power it gives you.  It
takes a huge load off your shoulders for managing an intricate, fragile
system of manual backups, and puts new power at your fingertips.  This
is true not just for lilypond projects; in fact I recommend version
control for *any* project that involves extensive editing of some
product over an extended period of time.

And you get diffing between any two versions of your project for free.
The one thing I can see here that could sweeten the deal even further,
is a tool that takes a version control diff and generates a lilypond
score with the changes highlighted somehow. Say in red and bold font,
for example, or as ossia staves. Now *that* I can see as a valuable
undertaking, if it can be pulled off.


T

-- 
Javascript is what you use to allow third party programs you don't know 
anything about and doing you know not what to run on your computer. -- Charles 
Hixson

Re: Lilypond's English Horn MIDI instrument is non-transposing?

[H. S. Teoh]

On Thu, Jan 13, 2022 at 04:40:17PM -0500, James B. Wilkinson wrote:
[...]
> If I make it with the English horn part correctly transposed, the MIDI
> sounds terrible. If I make it with the English horn part untransposed,
> it sounds fine. My conclusion is that the midiInstrument "english
> horn" reads its part in C rather than in F. Shouldn't it play the
> notes that a real English horn would?
[...]

Lilypond actually doesn't know what an "english horn" is. As far as it's
concerned, that's just an arbitrary name for a particular program number
in the General Midi standard.  It does not assign any meaning to the
name beyond mapping it to that program number.[*]

To get the right transposition, you need to use the \transposition
directive (see the documentation for details) to tell Lilypond how the
pitches are supposed to be interpreted.


[*] In fact, I've used Lilypond to make MIDI performances of orchestras
with instruments that don't exist in the General Midi standard -- by
remapping program numbers to custom assignments. Lilypond is completely
unaware of this, however, and still expects General Midi names for
instruments. So what Lilypond thinks is an "english horn" in my score
could be, for example, a bass clarinet or Wagner horn in the final
output.  The identifier "english horn" is just a stand-in for midi
program #70.  How that program is actually rendered is not controlled by
Lilypond, but by the midi player (and how you configured it) downstream.


T

-- 
Heads I win, tails you lose.

[j...@abou-samra.fr: Re: PNG/EPS output doesn't work anymore in 2.23.6?]

[H. S. Teoh]

On Mon, Dec 13, 2021 at 11:48:41PM +0100, Jean Abou Samra wrote:
[...]
> I don't understand what's going on at all. It all
> happens as if you were calling lilypond with wrong
> quoting as
> 
> lilypond -dbackend="eps myfile.ly"

Haha, in fact, you hit the nail right on the head (without realizing
it). :-)

It turns out to be entirely my fault after all: I have a wrapper shell
script that forwards to a local copy of lilypond (because I'm using a
local copy of guile-1.8 that I didn't want to conflict with the distro's
version), but I used the wrong forwarding for arguments:

export LD_LIBRARY_PATH=/usr/src/guile-1.8/lib
/usr/src/lilypond/bin/lilypond "$*"

where in the second line, I should have written "$@" instead.  This bug
went unnoticed because I usually only invoke lilypond with the single
.ly file as argument. But now when I need to pass additional arguments
to it, the "$*" smushes all the arguments into one where lilypond
expected multiple arguments, thus generating the observed mysterious
error message.

Changing it to "$@" fixed the problem.  Thanks a bunch, and sorry for
wasting everyone's time with something that isn't lilypond's fault at
all.


T

-- 
"I'm running Windows '98." "Yes." "My computer isn't working now." "Yes, you 
already said that." -- User-Friendly

Re: PNG/EPS output doesn't work anymore in 2.23.6?

[H. S. Teoh]

Here's the output:


GNU LilyPond 2.23.6 (running Guile 1.8)
command line options: "((backend . eps test.ly)
(gs-api . #f)
)": In procedure scm_i_lreadparen in expression (dynamic-wind 
swaports thunk ...):
: #:1:18: in pair: missing close paren



I'm using the latest git master (just updated this morning).  Running on
Linux (debian/testing), not compiling with Cairo.

Should I rollback git to the latest release to see if it makes a
difference?


--T

On Mon, Dec 13, 2021 at 10:37:17PM +0100, Jean Abou Samra wrote:
> Le 13/12/2021 à 20:54, Jean Abou Samra a écrit :
> >   #(display (ly:command-line-code))
> 
> 
> Silly me. It should print nothing at all since the error is
> occurring before LilyPond even starts parsing the file.
> Rather, try to change scm/lily.scm by applying the attached
> patch (`git apply show-command-line-code.patch`).
> 
> Thanks,
> Jean
> 
> 

> diff --git a/scm/lily.scm b/scm/lily.scm
> index c5c905b3ca..89563d9e2c 100644
> --- a/scm/lily.scm
> +++ b/scm/lily.scm
> @@ -436,6 +436,8 @@ messages into errors.")
>(ly:set-option 'debug-gc-object-lifetimes #f))
>   (else))
> 
> +(ly:message "command line options: ~s" (ly:command-line-options))
> +
>  (for-each (lambda (x)
>  (ly:set-option (car x) (cdr x)))
>(with-input-from-string (ly:command-line-options) read))
> @@ -846,6 +848,7 @@ PIDs or the number of the process."
> 
>  (define-public (lilypond-main files)
>"Entry point for LilyPond."
> +  (ly:message "command line code: ~s" (ly:command-line-code))
>(eval-string (ly:command-line-code))
>(if (ly:get-option 'help)
>(begin (ly:option-usage)


-- 
Freedom: (n.) Man's self-given right to be enslaved by his own depravity.

PNG/EPS output doesn't work anymore in 2.23.6?

[H. S. Teoh]

According to the usage manual, in order to get PNG output:

lilypond -dbackend=eps -dno-gs-load-fonts -dinclude-eps-fonts --png 
myfile.ly

But lilypond 2.23.6 aborts with this:

: In procedure scm_i_lreadparen in expression 
(dynamic-wind swaports thunk ...):
: #:1:18: in pair: missing close paren

What am I doing wrong?

P.S. I compiled lilypond with guile 1.8.8, don't know if that's related?


T

-- 
Food and laptops don't mix.

Re: Latest lilypond git master creating PDF 1.4 files instead of 1.7

[H. S. Teoh]

On Sat, Sep 11, 2021 at 09:35:00PM +0200, Valentin Petzel wrote:
> From what I see pdftops appears to be intelligent enough to rasterize
> the file only if it does actually contain transparency. If it does it
> uses a much less smooth rasterization that is probably not fit for
> printing, so be careful with this! See the attached picture for a
> comparisation, the left one is poppler (pdftops), the right one gs
> (pdf2ps).

I experimented with pstops, and it does seem to produce a non-rasterized
PS file, which can then be converted back to PDF without transparency,
thus sidestepping this issue.  I'll use that as a workaround for now.
:-D


[...]
> But anyway. Usually there should not be any reason to convert from pdf
> to ps, apart from printing or doing ps-style manipulations. But ps is
> only a subset of pdf, so the conversion in that direction cannot
> always be done in an acceptable manner.

I discovered that converting the pdf to ps and back again significantly
reduces the file size.  So it's kinda my poor-man's way of compressing
pdfs.  Of course, this only works if your pdf doesn't contain any
features incompatible with ps, which in my case is true.  And now that I
know that pdftops does a proper job with the conversion even when there
is transparency, it's a sufficiently-acceptable solution to this issue.


> Also I have tested gv on the pdf-files, but I’m not experiencing these
> delays. 
[...]

I wonder if it has to do with the amount of available RAM, as my PC is
10+ years old, so on a more modern machine the difference would be
unnoticeable.


T

-- 
If it tastes good, it's probably bad for you.

Re: Latest lilypond git master creating PDF 1.4 files instead of 1.7

[H. S. Teoh]

On Sat, Sep 11, 2021 at 12:04:11PM +0200, Valentin Petzel wrote:
> Okay. Basically the problem is that conversion from PDF to PS get’s
> really complicated at some point, and results in really large PS
> files.
> 
> I’ve tracked down the responsible commit to be
> cf2ae39e9d93c2dcdc50afd7d0389c314898273c, which implements
> transparency for PDF. Now this seems plausible, as transparency is NOT
> part of the Postscript specification, and Adobe and GS have just added
> (very volatile) methods to the PS specification for transparency in a
> created PDF file.
[...]

Is there an option for turning off transparency in Lilypond?  I don't
need transparency, so it would be nice to sidestep this issue in my
environment.


T

-- 
Obviously, some things aren't very obvious.

Re: Latest lilypond git master creating PDF 1.4 files instead of 1.7

[H. S. Teoh]

On Fri, Sep 10, 2021 at 09:52:09PM +0200, Jean Abou Samra wrote:
> Le 10/09/2021 à 19:09, H. S. Teoh a écrit :
> > OK, I attached a contrived .ly file that produces 2 pages of music
> > (the effect is most noticeable when there's more than 1 page), and
> > two .pdf's, one compiled by the official Debian lilypond package
> > (2.22.1), and one by my local lilypond build (latest git master).
> > 
> > The second file (test-bad.pdf) is noticeably slower to view on a PDF
> > viewer; this is especially noticeable when flipping between pages.
> > Whereas the first one (test-good.pdf) renders quickly and pages
> > quickly.
> 
> What is your PDF reader? With all of Evince,
> Okular and Firefox's built-in PDF reader on my
> Ubuntu system, both files render fast enough and
> I cannot see a noticeable difference.
[...]

I'm using GV, which shows noticeably slowdown.  I tested again with
Evince; the slowdown is still there but only in a more complex score.
With the contrived score I posted it's not really noticeable. Also,
Evince appears to cache generated pages at startup: with a more complex
score there's a noticeable delay during startup, but thereafter about
2-3 pages are cached, and the delay only happens when you scroll to an
uncached page.  With 2.22.1, there is no such slowdown.

Since PDF reader performance seems an unreliable measure of this issue,
here's another one: running pdf2ps and then ps2pdf on the 2.22.1 score
produces a compressed score (well, sometimes it doesn't compress well
but the resulting file size is comparable to the original).  But on git
master, both pdf2ps and ps2pdf take a very long time to run, and produce
a .ps and second .pdf about 10x the size of the original file.

Something about the .pdf produced by (my build of) git master causes
these tools to behave an in unusual way, and I want to find out why, and
whether it's something caused by lilypond itself, or by some build
misconfiguration on my part.


T

-- 
It is of the new things that men tire --- of fashions and proposals and 
improvements and change. It is the old things that startle and intoxicate. It 
is the old things that are young. -- G.K. Chesterton

Re: Latest lilypond git master creating PDF 1.4 files instead of 1.7

[H. S. Teoh]

On Fri, Sep 10, 2021 at 02:22:50PM +0200, Jonas Hahnfeld wrote:
> Am Freitag, dem 10.09.2021 um 10:46 +0200 schrieb Valentin Petzel:
[...]
> > This is nothing new and an arbitrary decision by Lilypond, simply
> > because XeTeX defaults to 1.5 and thus produces error when embedding
> > a 1.7 PDF.
> > 
> > But this means that whatever problem you have should not come frome
> > the PDF CompatibilityLevel, as this did never change (and anyway a
> > lower version should only limit the amount of functionality but not
> > create a need for conversion).
> 
> It did intermittently change during the last development cycle after I
> mistakenly removed "CompatibilityLevel 1.4" and recent Ghostscript
> versions defaulted to 1.7. The old behavior was restored soon after to
> avoid the warnings from XeTeX mentioned above. If there is an
> advantage in using a newer compatibility level, it would be great if
> you could open an issue on GitLab with more details.
[...]

Hmm, upon further investigation, CompatibilityLevel isn't really the
problem after all. Lilypond 2.22.1 also produces files with
compatibility level 1.4, but it does not exhibit the same slowness. What
else has changed since 2.22.1?  Or could it possibly be some other
environmental issue like fonts / PDF libraries?


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

Latest lilypond git master creating PDF 1.4 files instead of 1.7

[H. S. Teoh]

Hi all,

For a long time I have been using a local build of lilypond cloned from
git, IIRC around 2.21.0 or thereabouts.  Today, on a whim, I decided to
update lilypond to the latest git master.  After recompiling everything,
lilypond started producing version 1.4 PDF files instead of version 1.7
like it used to.  The resulting file is very slow to load or view with
my local PDF reader, which makes it very difficult to work with.

How do I coax lilypond to produce PDF 1.7 files again?  I'm not 100%
sure it's lilypond's fault; it could be something else in my environment
that changed, perhaps one of lilypond's dependencies?  But I'm at a
complete loss as to where to start looking.  Any pointers would be
greatly appreciated.

Thanks!


T

-- 
Right now I'm having amnesia and deja vu at the same time. I think I've 
forgotten this before.

How to make a macro of articulation marks?

[H. S. Teoh]

Hi,

In my Lilypond score I have a bunch of notes I want to highlight in MIDI
without changing the appearance of the printed score, so I have stuff
like:

a-.-\tag #'midi -\> b-.-\tag #'midi -\> c-.-\tag #'midi -\> d-.-\tag 
#'midi -\>

Stuff tagged #'midi is removed in the printed score with \removeWithTag,
but intact in the MIDI score.

Obviously, this is a pain to type; is there a simple way to factor the
repeated tags into a macro, so that I can e.g. type instead:

a-.\midiEmph b-.\midiEmph c-.\midiEmph d-.\midiEmph

?

I tried:

midiEmph = \tag #'midi -\>
a-.\midiEmph b-.\midiEmph c-.\midiEmph d-.\midiEmph

but the accent appears to just get dropped silently. What am I doing
wrong?


T

-- 
"No, John.  I want formats that are actually useful, rather than over-featured 
megaliths that address all questions by piling on ridiculous internal links in 
forms which are hideously over-complex." -- Simon St. Laurent on xml-dev

Re: why Kieren is a \relative evangelist [was “Re: Nested transposition"]

[H. S. Teoh]

On Fri, Mar 19, 2021 at 12:16:49PM -0400, Kieren MacMillan wrote:
[...]
> > Probably the biggest problem I encounter with \relative is when I
> > enter some music and then extract a section of it into a variable
> > for use somewhere else and having the original shift octaves
> > somewhere in the middle.  Then I have to search for the shift and
> > correct it.
> 
> That was the straw that broke my camel’s back so many years ago. I
> find it particularly bad if you try to compose or arrange directly in
> Lilypond (as opposed to simply transcribing or
> engraving-from-written-MS): write the first section, write the third
> section, then write the second section and the third section “becomes
> wrong”; fix that; try to cut-and-paste a chunk from Section 2 into
> Section 3, and both the new section *and* the rest of the piece
> “become wrong”; fix that; etc. When this plays out at higher
> resolution, I find it endlessly maddening (and flow-killing).
[...]

It's somewhat mitigated by inserting octave checks every so often (say,
at the start of every section), so that when it does go wrong, there's a
warning, and the problem only propagates up to the next octave check
rather than the rest of the piece.  That's what I do, anyway -- I also
compose directly in Lilypond. Octave checks are also the first warnings
that come up, so my usual practice is to interrupt Lilypond as soon as I
see an octave check failure, fix it, and repeat until no more warnings
come up.

Of course, I know your stance has been very clear all these years, so
I'm not going to try to convince you.  :-)  But just wanted to say that
there *are* ways to mitigate the problem, and that I find \relative
still extremely useful in tonal music.


T

-- 
Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG

Re: LilyPond v2.20.0 on Raspberry Pi OS (Debian buster)

[H. S. Teoh]

On Tue, Dec 15, 2020 at 05:08:10PM -0700, Anthony Fok wrote:
> Hi Feri and renyhp,
> 
> On Sun, Nov 22, 2020 at 2:40 AM  wrote:
> > renyhp  writes:
> > > If the path of installing debs is totally closed, is it possible
> > > to make my own build?
> > Ask the Debian package maintainer to provide an official backport.
> > It should be straightforward.
[...]

I'm using Debian, and have been building Lilypond myself.  Due to
problems with the latest version of Guile in Debian, I downloaded the
sources of guile-1.8 and built it separately, so that I can build
lilypond with guile-1.8.

My configure command for guile-1.8 is:

./configure --prefix=/usr/src/guile-1.8 
CFLAGS="-Wno-unused-but-set-variable -Wno-misleading-indentation 
-Wno-deprecated-declarations"

I use a custom prefix so that it doesn't interfere with anything else on
my system that might use Guile. The other flags are to suppress compiler
complaints about the older-style code in guile-1.8.

My lilypond configure command is:

[ ! -d build ] && mkdir build
cd build && PATH=/usr/src/guile-1.8/bin:$PATH 
PKG_CONFIG_PATH=/usr/src/guile-1.8/guile-1.8.8/ ../configure 
--prefix=/usr/src/lilypond/

The PKG_CONFIG_PATH hack is so that the configure script will find the
correct Guile installation instead of the system default one.  I also
configure a custom prefix for lilypond so that it doesn't interfere with
the official build of lilypond (though I haven't used the latter for a
long time now -- mainly because I find it excruciatingly slow due to
being built with a later version of Guile).

With this configuration, you need a special environment to build
lilypond, otherwise it may not find the right version of guile during
the build:

export PATH=/usr/src/guile-1.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/src/guile-1.8/lib
cd build && make -j2

The -j2 is optional, and possibly risky, since the last time I checked
lilypond's build isn't 100% concurrent-safe, so you might run into build
problems under some circumstances.  If you want to be sure, omit the -j2
and you just have to wait slightly longer for the build.

Running lilypond under this configuration also needs some care; the way
I do it is to install it somewhere outside of $PATH, then use the
following wrapper script that you put in $PATH, e.g., in
$HOME/bin/lilypond:

#!/bin/sh
export LD_LIBRARY_PATH=/usr/src/guile-1.8/lib
/usr/src/lilypond/bin/lilypond "$*"


T

-- 
He who laughs last thinks slowest.

Re: How should I convert an existing ".ly" file to a MIDI file containing audible arpeggios?

[H. S. Teoh]

On Sat, Dec 05, 2020 at 06:34:52AM +0100, Petr Pařízek wrote:
>On 5.12.2020 1:07, Knute Snortum wrote:
> 
>  > I'm confused.  Why doesn't the notation create arpeggios in MIDI?  
>
>  The \arpeggio command only prints the relevant symbols in the
>  notated score (i.e. in the PDF output) but does not have any
>  effect on the MIDI file.
>
>  The final part of the documentation on "Ties" contains a snippet
>  that explains that written-out arpeggios can be typed more
>  efficiently by applying the "tieWaitForNote" property and then
>  reseting it again:
>  
> [1]https://lilypond.org/doc/v2.20/Documentation/notation/writing-rhythms#ties
>  But I can't imagine rewriting it manually for every single
>  arpeggiated chord of my original file, considering how many they
>  are there. I'd love to find a way of automating this process but
>  I don't know how I would do that.
[...]

Some time ago I wrote a little .ly snippet to generate midi arpeggios
(see attached).  It takes a number N and a chord, and generates an
arpeggio where the start of each subsequent note of the chord (in the
order they are spelled in the input) is delayed from the previous note
by a duration equal to the length of the chord divided into N units.
For example:

\midiArpeggio 24 4

divides a quarter note into 24 units, and plays the first c on-beat, the
e 1/24th of a quarter note past the beat, g 2/24th of a quarter note
past the beat, and the last c 3/24th of a quarter note past the beat. By
varying the first argument you can control how fast the chord is rolled
(useful for adapting the generated midi to the current tempo of the
music so that it doesn't sound too fast or too slow).

Unfortunately, the output will look like a horrendous mess if you
typeset it; so I usually use it in a midi-only score tagged by #'midi,
with a layout-only score tagged by #'layout that uses lilypond's
built-in \arpeggio command, e.g., something like this:

\include "arpeggio.ly"
myMusic = {
...
\tag #'layout { \arpeggio }
\tag #'midi { \midiArpeggio 24  }
...
}

% This score is for printing only
\score {
\removeWithTag #'midi \myMusic
\layout {}
}

% This score is for generating midi
\score {
\removeWithTag #'layout \myMusic
\midi {}
}


T

-- 
My program has no bugs! Only unintentional features...
%
% A scheme function that unpacks a rolled chord into displaced notes with
% adjusted lengths such that it will render nicely in MIDI.
%
\version "2.20.1"

% Returns: A skip followed by the given note, with the skip scaled by n/d of
% the note's length, and the note scaled by (d-n)/d of its original length.
#(define shiftedNote (lambda (num denom note)
(if (= num 0)
; First note is unchanged
note

; Construct a skip + the note, both appropriately scaled
(let ((dLog (ly:duration-log (ly:music-property note 'duration)))
  (dDot (ly:duration-dot-count (ly:music-property note 'duration)))
  (dFac (ly:duration-factor (ly:music-property note 'duration)))
  (scaledNote (ly:music-deep-copy note)))
(set! (ly:music-property scaledNote 'duration)
  (ly:make-duration dLog dDot (*
(/ (car dFac) (cdr dFac))
(/ (- denom num) denom
(make-music 'SequentialMusic
'elements (list
(make-music 'SkipEvent
'duration (ly:make-duration dLog dDot
(* (/ (car dFac) (cdr dFac)) (/ num denom
scaledNote
)
)
)
)
))

% Generate a rolled chord from the given notes. Each subsequent note is shifted
% by num/denom.
#(define genArpeggio (lambda (num denom notes)
(if (pair? notes) ; Test for empty list
; Recursive case
(if (null? (ly:music-property (car notes) 'duration))
; Skip objects that have no duration
(genArpeggio (+ 1 num) denom (cdr notes))

; Shift notes
(cons
(shiftedNote num denom (car notes))
(genArpeggio (+ 1 num) denom (cdr notes))
)
)

; Base case
'()
)
))

% Params:
%   chord = The chord to arpeggiate.
%   denom = The fraction of the chord's length to use as a rest for each note
%   of the arpeggiated chord. This must not be less than the number of
%   notes in the chord. If it's greater than the number of chord notes, the
%   top note will be held longer.
midiArpeggio = #(define-music-function (denom chord) (number? ly:music?)
(let ((chordTones (ly:music-property chord 'elements)))
(make-music 'SimultaneousMusic
'elements (genArpeggio 0 denom chordTones)
 

Re: kind of OT: bach inventions

[H. S. Teoh]

On Fri, Aug 14, 2020 at 12:00:10PM -0700, Flaming Hakama by Elaine wrote:
>I was working with one of the Bach inventions and was trying to
>find public domain lilypond source, of either just the notes or an
>actual edition.
>All of mutopia's links seem to be down atm, was wondering if anyone
>happened to know of such a resource that is available.
[...]

Which invention are you interested in? I have lilypond source for
invention no.8, which I transcribed from a score I found on IMSLP.


T

-- 
An elephant: A mouse built to government specifications. -- Robert Heinlein

Re: Q: Irregular alternate repeats and MIDI

[H. S. Teoh]

On Tue, Aug 11, 2020 at 07:29:33AM -0700, Flaming Hakama by Elaine wrote:
>  -- Forwarded message --
>  From: Michael Gerdau <[1]m...@qata.de>
>  To: Lilypond User <[2]lilypond-user@gnu.org>
>  Date: Sat, 18 Jul 2020 07:57:23 +0200 (CEST)
>  Subject: Q: Irregular alternate repeats and MIDI
>  Hi List,
> 
>  I have a score with repeats and irregular alternate endings. I
>  can neatly engrave that but I don't seem to be able to produce
>  correct MIDI w/o manually arranging all segments.
[...]

I've struggled with this before, and eventually I just gave up and stuck
the segments in variables, and manually arrange them. Lilypond is
primarily a typesetting program, and even though we've made advances in
MIDI generation over the years it's still not quite there. Because of
this I usually use two scores, one just for layout, and one just for
midi, and the music content is stored in variables to be incorporated
into either score as necessary.


>Not exactly what you asked for, but one possible approach is to use
>tags.
> 
>Tags allow for conditional use of material.
> 
>In this case, you would add a tag that is specific to MIDI and put
>the repetitions in a similar way you did in the "manual" version.
> 
>Then, have two different scores, one for PDF and one for MIDI,
>which use different tags.

Definitely recommend this approach.  This is what I usually do:

global = {
\time 3/4
\tempo 4 = 100
s1*12
\tempo 4 = 120
s1*12
...
}

voiceA = {
... % music here
\tag #'layout {
% stuff here only for layout, not for MIDI
}
... % more music
}
voiceB = {
... % music here
\tag #'midi {
% stuff here only for MIDI, not for layout
}
... % more music
}
...

% This score is only for layout
\score {
\removeWithTag #'midi
<<
\new Staff {
% Repeats only present in layout score
\repeat volta {
\voiceA
}
...
}
\new Staff {
... % ditto
\voiceB
}
>>
\layout {}
}

% This score only for MIDI
\score {
\removeWithTag #'layout
<<
\new Staff {
% Manually sequence repeats if needed
\repeat unfold {
% Apply global events to every
% staff For more reliable MIDI
% generation
<< \global \voiceA >>
}
}
\new Staff <<
... % ditto
\global \voiceB
>>
>>
\midi {}
}


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater 
learning.

Re: What happened to INSTALL.txt?

[H. S. Teoh]

On Thu, Jul 30, 2020 at 10:05:27PM +0100, antlists wrote:
> On 30/07/2020 17:25, H. S. Teoh wrote:
> > On Mon, Jul 27, 2020 at 08:30:34AM -0700, Knute Snortum wrote:
> > > Well it looks like README.git should just contain this:
> > > Instructions for compiling LilyPond from source files can be
> > > found online at:
> > > 
> > > 
> > > [1]https://lilypond.org/doc/v2.21/Documentation/contributor/index_17#Compiling
> > 
> > Sounds like a good idea.
> > 
> Does it? You're assuming internet access ... :-(
> 
> Okay, most people will have it, but not all, and if all it needs is to
> run ./configure, then that's what should be in README.git.
[...]

Yeah, assuming internet access is not so nice.  README.git should at
least contain enough information to get INSTALL.txt generated without
needing online access, so that if you were to, hypothetically, get stuck
on a desert island without an internet connection (but somehow still
have your PC with you and a power source for it), you could in theory
compile a fresh checkout of lilypond.


T

-- 
Debugging is twice as hard as writing the code in the first place. Therefore, 
if you write the code as cleverly as possible, you are, by definition, not 
smart enough to debug it. -- Brian W. Kernighan

Re: What happened to INSTALL.txt?

[H. S. Teoh]

On Mon, Jul 27, 2020 at 08:30:34AM -0700, Knute Snortum wrote:
>Well it looks like README.git should just contain this:
>Instructions for compiling LilyPond from source files can be found
>online at:
> 
>   
>
> [1]https://lilypond.org/doc/v2.21/Documentation/contributor/index_17#Compiling

Sounds like a good idea.


T

-- 
There are two ways to write error-free programs; only the third one works.

Re: What happened to INSTALL.txt?

[H. S. Teoh]

On Sat, Jul 25, 2020 at 09:47:16AM +0200, Jonas Hahnfeld wrote:
> Hi,
> 
> Am Freitag, den 24.07.2020, 15:14 -0700 schrieb H. S. Teoh:
> > I pulled lilypond sources from git today, and while trying to figure
> > out a botched configure invocation, I did a git clean -x -f, and now
> > INSTALL.txt doesn't exist anymore...?  I did a fresh git clone from
> > git://git.sv.gnu.org/lilypond.git but same thing, INSTALL.txt seems
> > to have gone missing?
> 
> INSTALL.txt is not tracked in git, but generated from texinfo sources
> when running ./configure (or ./autogen.sh). For that reason, it was
> removed with git-clean.
[...]

Ah, thanks! That explains it.

Seems to me like kind of a chicken-and-egg problem, though. In order to
build lilypond I need to read INSTALL.txt, but in order to read
INSTALL.txt, I need to build lilypond first...  I ended up googling for
the file on the website and following the steps from there instead.


T

-- 
Тише едешь, дальше будешь.

What happened to INSTALL.txt?

[H. S. Teoh]

I pulled lilypond sources from git today, and while trying to figure out
a botched configure invocation, I did a git clean -x -f, and now
INSTALL.txt doesn't exist anymore...?  I did a fresh git clone from
git://git.sv.gnu.org/lilypond.git but same thing, INSTALL.txt seems to
have gone missing?

What am I doing wrong?


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.

Re: Guile for building lilypond on Ubuntu18.10

[H. S. Teoh]

On Sat, Mar 23, 2019 at 11:12:29AM +1100, Andrew Bernard wrote:
>Ubuntu now only supports guile 2 in its own repositories.
>How does on obtain the guile 1.8 needed to build lilypond for
>Ubuntu 18.10? Do we have to build from the source repository? If
>so, what exact release?
[...]

Others have already answered, but I'd like to provide another data point
in case some people find it helpful.  I use a Debian/sid system, so it
shares a lot of commonality with Ubuntu, but should apply to a wider
range of Debian-based distros.

I've also run into the problem that guile 1.8 is no longer in the
official Debian repos, so I had to download guile-1.8 from gnu.org
instead.  I discovered that it *is* possible to install guile-1.8
outside the usual places (/usr, /usr/local) where it might conflict with
newer versions of guile; I chose to install it under /usr/src/guile-1.8
where I can keep it self-contained to only stuff that actually needs 1.8
specifically. This is done by configuring guile-1.8 like this:

cd /path/to/guile-1.8/sources/
./configure --prefix=/usr/src/guile-1.8 
CFLAGS="-Wno-unused-but-set-variable -Wno-misleading-indentation 
-Wno-deprecated-declarations"

Guile configured this way would not be found by lilypond by default, so
lilypond needs to be compiled with an overridden $PATH.  I also found
that I needed python-2.7 (rather than python3), so that needs to be
configured specially as well.  So the lilypond configure command I use
is:

PATH=/usr/src/guile-1.8/bin:$PATH ./autogen.sh 
--with-python-include=/usr/include/python2.7/ CFLAGS="-Wno-sequence-point" 
LDFLAGS="-Wl,-rpath,/usr/src/guile-1.8/lib"

It's possible to install lilypond outside of /usr or /usr/local by using
the --prefix option, if desired.  This configuration won't build
directly, though, so you'd have to do this:

export PATH=/usr/src/guile-1.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/src/guile-1.8/lib
make

And unless you point your library paths to the right place, the lilypond
executable may not be able to find libguile*.so, so I use this wrapper
script instead (put it in /usr/bin or /usr/local/bin or /home/bin,
wherever $PATH can find it):

#!/bin/sh
export LD_LIBRARY_PATH=/usr/src/guile-1.8/lib
/path/to/installdir/lilypond "$*"

Using this method, I was able to compile and install an isolated version
of lilypond that could coexist alongside the official Debian
libguile/python/lilypond packages.


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: The composition process doesn't get disrupted using Lily Pond?

[H. S. Teoh]

On Wed, Jan 09, 2019 at 06:06:27PM -0800, Flaming Hakama by Elaine wrote:
[...]
>So, the tl;dr version is that, yes there can be blocks to the
>composition process when using lilypond.  But it is often possible
>to bucket that work, so you can get it done and get back to the
>composition process.  I think it can be worth it since there are a
>lot of good features in lilypond to help composition/arranging.
>
>My composition process sometimes includes lilypond.  Generally
>speaking, this is only at the point when I know the entire layout
>of the piece--at least in terms of the overall structure, the
>sections, and their durations.
[...]

Yes, my workflow when composing using lilypond is similar to this.


[...]
>The reason I like to start with the complete roadmap planned out is
>that it can be a pain to update the durations.  Especially if there
>are many instruments in the scores. 

My approach is to use unique section IDs as comments in \global, e.g.:

global = {
\tempo ... % blah blah

% Intro
s1*12

% Main theme
s1*24

% Episode 1
s1*18

% Main theme (2)
s1*20

% Episode 2
s1*22

% Conclusion
s1*9
}

and then repeat these comments verbatim in each instrument's part.
These comments become the milestones from which I can count measures
when adding/deleting measures, to make sure things line up (and add up).
I generally also group my measures into blocks, generally 4 measures per
block, to facilitate quick counting.  These marker comments also make it
easier to find the right line when I need to edit something.


>For example, if you then want to add a measure to one section of
>the song, you need to add this in the global definitions, as well
>as in each instrument/staff's music variable (and if you have chord
>symbols, it will need to be updated there, too.)   So, there
>becomes a little more overhead to modifying the duration of a
>section after the fact.  This type of thing can be done, but it
>does feel like a break in the composition process since you go from
>musical entry to lots of cutting & pasting in multiple files, with
>all of the debugging to ensure that you did it correctly.

My personal preference is to use a single file for all parts.  Yes, I
know that sounds crazy, but I find that it really helps in keeping
things in sync, rather than scattered across multiple files that are
even harder to keep track of.  Using a text editor with nice search /
bookmarking / split-window features makes this a lot more usable than it
sounds (if you ever have to reach for the scrollbar, you're doing it
wrong).

Using my landmark comments approach, it's a simple matter of searching
for the landmark string to locate the appropriate section.  And you
could also prefix / suffix each landmark with the instrument
abbreviation, say "Episode 2/Fl", "Episode 2/Vln1", then to you could
jump to the landmark for Episode 2 for the 1st violins with a single
search, to locate the measure that needs editing.  This, plus copious
use of bookmarks, let you jump between different instruments of the same
passage easily, which reduces a lot of the tedium in editing your score.


>On the other hand, you can certainly use lilypond to sketch out
>ideas, not worrying about, for example, how many bars will be in
>the intro while you work on the main theme, or how many instruments
>will be in the ensemble while you're trying to figure out the
>harmonic progression.  But at some point you will need to stop
>working on a sketch, and proceed with engraving.  At which point,
>you will have another break in the composition process while you
>prepare your lilypond code for note entry.

IME, I find that it works better if you do your lilypond sketching as
something completely separate from the actual, final score.  Use it to
explore ideas, get a feel for duration, section lengths, etc., in sketch
form (short score, piano reduction, or even just a single running staff
with tentative notes).

But once you're done with sketching, put it aside and begin a new
lilypond score from a clean slate, lay out your instruments, etc., then
copy-n-paste the music from the sketch into the various blanks.  I find
that this is far less messy than trying to hammer a rough sketch score
into something presentable.  It also liberates you in the sketching
phase from worrying about final score layout; you can sketch out new
ideas and experiment with throwaway ideas, hack the score without regard
to "proper" lilypond score practices, without fearing you'll ruin the
structure of your final score.


>So, generally, I would say that I tend to use lilypond after most
>of the composition has been done.  But you can use it earlier 

Re: Compiling LilyPond on Linux Mint 19.1

[H. S. Teoh]

On Fri, Dec 21, 2018 at 07:06:43PM +0100, Urs Liska wrote:
> 
> Am 21.12.18 um 09:06 schrieb Urs Liska:
> > Hi Lukas,
> > 
> > thanks for putting this together. Indeed since installing a distro
> > that doesn't Guile 1.8 anymore I hadn't been able to compile
> > LilyPond anymore. Once I managed to compile Guile 1.8 and do a build
> > but for some reason I lost this option. I think the point was that
> > after compiling Guile I had to actually change the way LilyPond's
> > make was handled - which of course isn't sustainable.

Some time ago I ran into the same problem with Guile 1.8 no longer being
the default version of Guile in my distro (and in fact, not even
installable anymore from the official repo), but Lilypond does not work
with newer versions of Guile.  Furthermore, Python 2.7 is also no longer
the default in my distro, which is an added level of pain, though
luckily I can still install Python 2.7, it's just not the default Python
that would get invoked.

Fortunately, I can compile my own version of Guile 1.8 as you did.  Once
that is done, I found that I actually don't need to change LilyPond's
makefile; all I needed was to set $PATH and re-run LilyPond's autogen.sh
with the appropriate customizations, like this:

PATH=/usr/src/guile-1.8/bin:$PATH ./autogen.sh \
--with-python-include=/usr/include/python2.7/ \
CFLAGS="-Wno-sequence-point" \
LDFLAGS="-Wl,-rpath,/usr/src/guile-1.8/lib"

Of course, replace /usr/src/guile-1.8 with the path to wherever you
compiled Guile 1.8 (you don't actually need to install Guile 1.8
anywhere on your system; autogen.sh appeared smart enough to pick up the
right files from Guile's source directory once that's built, and once
you hacked $PATH to pick up Guile 1.8 before anything else); and replace
/usr/include/python2.7 with wherever your distro installed Python 2.7's
include files.

After running this step, you should be able to just run make as usual,
and it should be able to build Lilypond successfully.

(I have put the above autogen.sh invocation in a script that I keep with
my lilypond git clone, so that I don't have to type all of that every
time!  Though, truth be told, you really only need to re-run autogen.sh
if you have a fresh git clone / source download, or you did a deep
cleaning of the source tree. I found that I could still just run make
after `git pull` without needing to run autogen.sh again.)

Hope this info helps.


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: How do I get MIDI dynamics from a \Dynamics staff?

[H. S. Teoh]

On Thu, Sep 20, 2018 at 05:06:48PM +0100, Peter Toye wrote:
>Guy,
> 
>Thanks. I've found the thread. It seems fairly complicated, and as
>I only use MIDI for proof-reading (proof-hearing?) I’ll ignore the
>dynamics altogether! Life's too short.

My usual approach, as always, is to use a separate score for midi:

%
% Just write your music this way:
%

upperPart = { ... }
dynPart = {
s1\ff   % ... etc.
}
lowerPart = { ... }

%
% The following can be pretty much copy-and-pasted to each
% piece:
%

% Score for layout
\score {
\new Staff { \upperPart }
\new Dynamics { \dynPart }
\new Staff { \lowerPart }
\layout {}
}

% Score for midi
\score {
% Explicitly merge dynPart into both parts so that
% dynamics will be applied correctly to both.
\new Staff << \upperPart \dynPart >>
\new Staff << \lowerPart \dynPart >>
\midi {}
}


T

-- 
Shin: (n.) A device for finding furniture in the dark.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Latest lilypond stable release?

[H. S. Teoh]

On Wed, Sep 19, 2018 at 01:53:38AM +0200, Simon Albrecht wrote:
> On 19.09.2018 01:46, H. S. Teoh wrote:
> > According to the website (lilypond.org), the latest stable release
> > is 2.18.2, and the unstable release is 2.19.82.
> > 
> > However, I've been using the latest version from git, and it claims
> > to be version 2.21.0.  So, what happened to 2.20.*?  Why does the
> > git version claim to be 2.21.0?
> > 
> > More pertinently, what version should I be using on the \version
> > line?
> 
> 2.19.82 is already a prerelease for 2.20.0, since we’re in the process
> leading up to this next stable release. IIUC, this is why the git
> version is called 2.21.0, because only some of the changes applied now
> will still make it into the stable release and most will be 2.21
> material.  It is customary for those who compile from current master
> to use a 2.21.0 version statement indeed.
[...]

Ah, that explains it.  Thanks!


T

-- 
MAS = Mana Ada Sistem?

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Latest lilypond stable release?

[H. S. Teoh]

According to the website (lilypond.org), the latest stable release is
2.18.2, and the unstable release is 2.19.82.

However, I've been using the latest version from git, and it claims to
be version 2.21.0.  So, what happened to 2.20.*?  Why does the git
version claim to be 2.21.0?

More pertinently, what version should I be using on the \version line?


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A Midi question

[H. S. Teoh]

On Thu, Sep 13, 2018 at 03:35:02AM +0200, Simon Albrecht wrote:
> On 13.09.2018 01:29, H. S. Teoh wrote:
> > The solution I've adopted is to always explicitly name all voices,
> > even temporary ones,
> 
> IIRC, they are named by default: "1", "2", etc. so you should just be
> able to use those names.
[...]

You're right!  I just tested the following, and it works correctly:

\version "2.19.2"
music = {
c4 d e f
<< {
c'4 c' c' c'
} \\ {
a4 a a a
} >>
}
dynPart = {
s1\ff
s4\pp s4\p s4\mp s4\ff
}
\score {
\new Staff <<
\context Voice="1" { \dynPart }
\context Voice="2" { \dynPart }
\music
>>
\midi {}
}

This will simplify my scores quite a bit.  Thanks for the tip!


T

-- 
It said to install Windows 2000 or better, so I installed Linux instead.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A Midi question

[H. S. Teoh]

On Thu, Sep 13, 2018 at 08:36:05AM -0700, foxfanfare wrote:
[...]
> Yes, very much! I tried all your proposals and now everything works
> great, thanks!

Glad to help.


> I just need to find how I can make rallentando and the midi output
> will be "acceptable" for my needs!
[...]

Usually I just use "fake" \tempo markings for things like this. For
example:

% global is my catch-all for various stuff that should be
% applied globally to every staff.
global = {
\tempo 4 = 100  % starting tempo

s1*12   % nothing interesting for next 12 bars

% Simulated rallentando
% These are tagged so that they don't show up in the
% printed score.
\tag #'midi \tempo 4 = 90
s8
\tag #'midi \tempo 4 = 85
s8
\tag #'midi \tempo 4 = 80
s8
\tag #'midi \tempo 4 = 75
s8
\tag #'midi \tempo 4 = 70
% ... etc., you can change s8 to any other duration
% depending on how fine-grained you want it to be, and
% repeat as often as desired to span the full length of
% the rall.
}

...

\score {
\removeWithTag #'layout
<<
\global
\music
>>
\midi {}
}

If you have a lot of rallentando's in your score, this quickly becomes
tedious, so you might want to consider writing a Scheme macro to
automatically do this for you. (If you need help with this, just ask and
one of the Scheme experts here will help. I'm only a beginner at Scheme
though I did manage to write a function that generates a bunch of midi
expression events to simulate crescendo/decresc on a single note, e.g.,
in a horn part. It's not perfect, but with a little push, Lilypond can
be coaxed to do quite a lot even with its limited midi support.)


T

-- 
I am not young enough to know everything. -- Oscar Wilde

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A Midi question

[H. S. Teoh]

On Wed, Sep 12, 2018 at 12:57:01PM -0700, foxfanfare wrote:
[...]
> Thanks Theo and Guy for your solution. I tried them and I think I'll
> make a mix of both. I didn't think of the Tags for specific midi
> indications, and especially, the idea of making two separate scores,
> one for the layout and one for the midi is very good.
> 
> I can now merge the dynamics variables and sustain pedals on each
> voices which need them. This sounds good to me, although I still have
> more test to attempt! But thanks anyway for the first clues :-)
[...]

Just to add to what someone has said, if you're writing piano scores
where temporary voices often appear, you may get unexpected midi output.
For example:

\new Staff = "rhs" {
1\p
<< { d1 }
\\ { b4 a b c } >>
}

If you look at the midi output, you'll discover that the \p only applies
to the `d1`, not the `b4 a b c`, because the << ... \\ ... >> construct
creates temporary anonymous Voices, and such Voices generally are
initialized with default settings (dynamic levels, etc.) instead of
inheriting from the current context.  The solution I've adopted is to
always explicitly name all voices, even temporary ones, and separate out
the dynamics and explicitly apply the dynamics to each voice in the midi
score.  E.g.:

dynPart = {
s1\p% etc...
}
rightPart = \new Voice = "rhsA" {
1\p

% NB: always name the voices, even if they're temporary
<< \context Voice="rhsA" { d1 }
\\ \context Voice="rhsB" { b4 a b c } >>
}
\score {
\removeWithTag #'layout
<<
\new Staff = "rhs" <<
% Actual notes get pulled in here
\rightPart

% Explicitly apply dynamics to every
% named Voice.
{ \context Voice="rhsA" \dynPart }
{ \context Voice="rhsB" \dynPart }
>>
... % etc.
>>
\midi {}
}

For the printed score, this would produce tons of redundant dynamic
markings, so I always use a separate score just for layout, and stick
\dynPart into a Dynamics context between the upper and lower parts of
the piano score for nicer layout.

Hope this helps.


T

-- 
If you're not part of the solution, you're part of the precipitate.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Cover page

[H. S. Teoh]

On Tue, Sep 11, 2018 at 03:09:57PM -0700, foxfanfare wrote:
> Simon Albrecht-2 wrote
> > Maybe. LaTeX becomes less of a good choice the more you actually
> > want to design the visuals. In a scientific paper, looks don’t
> > matter at all, it’s only about the content; that’s where LaTeX is
> > perfect, no doubt. If you’re going to design a poster, LaTeX is most
> > certainly not the tool of choice, because you want to have total
> > control over where everything is placed; visuals are essential.  A
> > cover page is somewhere inbetween, but further to the poster side,
> > I’d say.
> 
> Interesting. The total control of the layout is very important for me
> to achieve this task.  Especially for the cover which (I agree with
> you) I'd like to be more of a poster than a simple text...  Maybe it
> is worth a try using LP and the markups for this... Although I'm a
> little worried that no one seems to use it that way!
[...]

I've used LP and markups for title pages before.  It's *possible*,
though somewhat klunky.  It entailed a lot of looking up various markup
commands in the LP reference, tweaking things, and doing tedious work
like wrapping paragraphs manually, etc..


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A Midi question

[H. S. Teoh]

On Tue, Sep 11, 2018 at 03:15:48PM -0700, foxfanfare wrote:
[...]
> So I guess there is no solution for my first problem than re-write all
> the nuances and pedal markings with the notes input instead of
> variables if I want to improve the audio output?
[...]

Generally, the way I've been dealing with Lilypond and midi output is to
separate generate the layout score and the midi score.  Of course,
nobody wants to type in the same music twice just to be able to make the
midi not make your ears bleed without making the printed score a mess,
so I generate both from the same input.  Here's how I do it:

music = {
% Stuff that works for both printed score and midi:
a4 b c d e f g

% Stuff that requires extra midi markings, e.g. manual
% dynamics to control expression that you don't want to
% actually print in the score:
a-\tag #'midi \fff\> b-\tag #'midi \ff

% Stuff that basically requires completely different
% inputs to make the midi sound sane (e.g., spelling
% exactly how you want a trill played instead of
% fighting with Lilypond and/or articulate.ly):
\tag #'layout { a1\trill }
\tag #'midi { \tuplet 17/16 \repeat unfold 7 { a16 b } a gs a }

% More stuff in common
g8 a b c d e f
}

% This score is only for layout. Remove all midi-specific stuff.
\score {
\removeWithTag #'midi \music
\layout {}
}

% This score is only for midi. Remove all layout-only stuff.
\score {
\removeWithTag #'layout \music
\midi {}
}

Depending on your needs, you can do more than just \tag-ging midi vs.
layout stuff in your input.  For example, I compose polyphonic music
that I want to typeset in a 2-staff piano score, but for better midi
control I prefer to split the voices into separate staves in the midi
output. Generally, this is so that I can apply dynamics separately to
each voice (Lilypond has a tendency of messing up midi dynamics
otherwise) that in the printed score should only be printed once.

voiceA = ...
voiceB = ...
voiceC = ...
voiceD = ...
dynPart = {
s1\ff
s1\p
% ... etc.
}

% For printed score, use 2 staves shared between pairs of
% voices.
\score {
\removeWithTag #'midi
\new PianoStaff <<
\new Staff = "rhs" <<
\voiceA
\voiceB
>>
\new Dynamics \dynPart
\new Staff = "lhs" <<
\voiceA
\voiceB
>>
>>
\layout { }
}

% For midi output, output each voice in a separate Staff.
\include "articulate.ly"
\score {
\articulate
\removeWithTag #'layout
<<
\new Staff = "rhs" << \voiceA \dynPart >>
\new Staff << \voiceB \dynPart >>
\new Staff = "lhs" << \voiceC \dynPart >>
\new Staff << \voiceD \dynPart >>
>>
\midi { }
}

In extreme cases, esp. in orchestral music, sometimes I set it up so
that each voice / instrument is output as a separate midi, and played by
a software synth with different parameters (e.g., for individually
controlling reverb, panning, and other effects, and also as a workaround
for the 15-channel limit in midi when I have more than 15 parts), then
blended together with a post-processing tool.


T

-- 
Insanity is doing the same thing over and over again and expecting different 
results.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: avoiding collisions between staves

[H. S. Teoh]

On Fri, Aug 31, 2018 at 02:19:26PM -0400, Bret Whissel wrote:
> I'm having a collision problem between staves of a PianoStaff. A
> PhrasingSlur in the first voice (stems up) of the lower bass-clef
> staff slightly overlaps the eighth-note beams of the upper treble-clef
> 2nd voice (stems down).
> 
> Is there a way to adjust the staff-staff-spacing of just this one
> system? (I don't want to make any vertical spacing changes globally.)
> Or can I add more padding to the PhrasingSlur or Beam (or some other
> entity) to avoid the collision? (I'm compiling from git sources, so
> v2.19+.)
> 
> I haven't found a related snippet or discovered the correct recipe
> yet.
[...]

You could try to override the shape of the slur so that it no longer
collides.  Example:

| 2.
  \shape #'((0 . 0) (0 . -.75) (0 . -.75) (0 . 0)) Tie
  a~ | a4

Replace Tie with PhrasingSlur, or other such curved object in question.
Experiment with different values to the \shape command until you find
something that works for you.


T

-- 
May you live all the days of your life. -- Jonathan Swift

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Lilypond.org is down

[H. S. Teoh]

On Wed, May 23, 2018 at 04:50:34PM +0100, Sven Axelsson wrote:
>Getting 500-errors for all pages on the lilypond site. Anyone know
>what's going on?
[...]

No idea.  I'm getting 500 errors too. :-(


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: warning: compressing over-full page by 217.9 staff-spaces

[H. S. Teoh]

On Tue, Feb 20, 2018 at 09:51:48PM +0100, Urs Liska wrote:
> Sorry for the noise (pun intended), but I have to share this "incident" :-)
> 
> (result of joining three one-page pieces in one file and forgetting to
> update the \paper block ...)
[...]

LOL... reminds me of what happened to me once when I tried to squeeze
too much music into too few pages. It wasn't quite as bad as this, but
it did have lots of clashing systems. :-D


T

-- 
Who told you to swim in Crocodile Lake without life insurance??

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Hello / a 1st question

[H. S. Teoh]

On Thu, Aug 10, 2017 at 06:40:10PM +, Vlad Kudelin wrote:
>Hello dear Lilypond community! 
>I am a new user, and a pretty happy one! Just found out about THIS
>a week ago, and God! I am so grateful to the creators!!! 
>I am a guy who knows music and computers, but... hates mouse. In
>fact I've got Carpal using mouse to enter 100s of notes in some
>s/w But now I am free! can use emacs or whatever! –
>un–be–live-able!!!
>And also (perfectionists will understand the torture I've been
>through) : Lilypond just makes it natural to put everything under
>version control! 
>un–be–f- live-able!!! 
[...]

Welcome to Lilypond. :-)

I also hate the mouse, and I compose music with vim and lilypond. Which
means I can work on my music remotely via SSH over a low-bandwidth link.
No need for bandwidth (and memory) hogging VNC's. And yes, version
control.  I use git, which allows me to experiment with different
branches (different ways of scoring a passage) quickly and easily, and
without risk of losing previous versions should I decide to revert.

Not to mention the beautiful scores Lilypond produces.

You're in good company here. ;-)


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose 
Bierce

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Apple stealing "Lily"

[H. S. Teoh]

On Thu, May 04, 2017 at 09:52:25AM +0200, Sven Axelsson wrote:
> On 4 May 2017 at 00:37, Devin Ulibarri  wrote:
> > At any rate, just watch out, if Apple continually tries to advance
> > into imitating free/libre branding in an attempt to push it out of
> > the market completely, then that would be a problem for all of us.
> 
> Honestly, I don't understand what Apple has to do with this? The Lily
> app is developed by a small UK-based company called Pelican 7. It just
> happens to be available in the iTunes Store - as well as on Google
> Play and Amazon Appstore.
[...]

Honestly, I think the idea that Apple is trying to push free/libre
software out of the market is complete hooey.  There are major free
software projects contributed by Apple / Apple developers, like
LLVM/clang and others.  Just because they are a profit-making business
that has to be accountable to their shareholders doesn't automatically
make them bad or evil or whatever.  Yeah, sometimes their business model
may lead them to make decisions that are not necessarily aligned with
purist open source advocacy, but that doesn't mean that they are out to
"subvert" the open source community or "push it out of the market", or
any of the other malinformed conspiracy theories that, frankly, are
about as believable as UFO fanaticism.

And none of this is really relevant here on the Lilypond mailing list
anyway.  Since when did Lilypond hold exclusive trademarks over every
English word that may or may not have been derived from "lily", and what
does this even have to do with Apple, since the Lily app isn't even made
by Apple themselves in the first place?  Sounds like uninformed
alarmists' kneejerk reaction to me.


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a 
California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D. Wachs - 
Natural Intelligence, Inc.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: What does anyone want? (4)

[H. S. Teoh]

On Thu, Apr 20, 2017 at 03:24:23PM -0400, Jeffery Shivers wrote:
> Hi Miroslaw,
> 
> On Thu, Apr 20, 2017 at 2:42 PM, Mirosław Doroszewski
>  wrote:
> > [trimmed gobbledygook]
> 
> Please stop sending this series of rambling / off-topic / distracting
> messages to the lilypond-user list. Most people come here for help or
> to offer any kind of constructive conversation. You aren't doing
> either. People can block you (I certainly will), but your off-topic
> posts are still going to be wasting space in the archives that could
> otherwise go to meaningful threads.
[...]

Yes, please stop sending off-topic posts to this list.  You are actually
destroying your own cause by doing this, because your inappropriate
behaviour is turning people away rather than convince them to be
sympathetic to what you have to say.  There are forums where your posts
would be welcomed, but this mailing list is not it.  Bombarding mailing
lists intended for discussing topics unrelated to your cause is not the
way to convince anyone, and you'd do yourself a favor to stop doing
that.


T

-- 
I see that you JS got Bach.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: A "phylosophical" question

[H. S. Teoh]

On Sat, Mar 25, 2017 at 11:51:15AM -0700, Son_V wrote:
> Sorry for the subject, I wasn't able to choose a better one.
> I usually try to put in a beautiful way scores that came fro copy to
> copy.  So I try to be loyal to what I find; but I got a score, see
> below,
> 
>  
> 
> that Lilypond writes differently, see
> 
>  
> 
> Who is right?

That depends on the context and intent of the music.  Not enough
information to decide.


> And if them right one is the first,k how can I tell Lilypond to make
> what is in the first picture?
[...]

Manually beam the notes, e.g.:

g8[ ais] b[ cis] d2


T

-- 
People say I'm arrogant, and I'm proud of it.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: New LilyPond website

[H. S. Teoh]

On Thu, Feb 09, 2017 at 05:34:38PM -0500, John Roper wrote:
>Sadly the community does not want JavaScript to be used because
>most of the users don't like using it. I had that idea already but
>did not bring it up. I would love to though.
>
>On Feb 9, 2017 5:12 PM, "Bernardo Barros" <[1]bernardo.bar...@nyu.edu>
>wrote:
> 
>  [2]lilybin.com could be included into the official website as
>  part of its new design. Something like "Try it - Type Haskell
>  expressions in here" in Haskell website
>  [3]https://www.haskell.org/
[...]

I don't speak for anyone else, but I'm perfectly OK with using
Javascript -- as long as it's not *required* for the website to be
usable at all.  I think it totally makes sense for adding a "try it out
yourself" link to lilybin.com -- it's an optional extra that I think
adds a lot of value.


T

-- 
Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be 
algorithms.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Changing the staff of a note inside of a chord

[H. S. Teoh]

On Thu, Jan 19, 2017 at 10:02:00PM +0100, Amir Teymuri wrote:
> Hello,
> 
> how can i change the Staff of only one note of a chord? For example if
> i have the following line:
> 
> r2 8[ 8] r8 8
> 
> and want to change the staff of only the very last bes'' to be on the
> base clef (with the rest of the chord being remained at treble clef)?
[...]

Would this help?


http://lilypond.org/doc/v2.19/Documentation/notation/common-notation-for-keyboards#cross_002dstaff-stems


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from 
Calvin & Hobbes

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sat, Jan 07, 2017 at 09:42:51PM +0100, David Kastrup wrote:
> "H. S. Teoh" <hst...@quickfur.ath.cx> writes:
> 
> > Of course, the best scenario is that we figure out how to fix the
> > current guile2-related issues before LP 2.20 is released...
> 
> A lot of them require fixing Guile2.  Guile2 has a string API where it
> will not accept anything but Latin-1 strings in a native encoding.
> Everything else requires recoding: it cannot work with utf-8 strings
> even though its API offers only utf-8 as encoding to pass into Guile's
> native (but inaccessible) UCS-32 strings.  It does not allow string
> ports in any encoding but utf-8.  It cannot even pass its own native
> strings through string ports without reencoding.

Wow. That sounds like a totally disastrous API. :-(


> Its reencoding is not transparent for non-proper utf-8.  The Guile
> developers are in complete denial about the unsuitability for an
> extension language about Guile's call gates requiring reencoding for
> every string parameter.

That probably represents a significant overall performance hit. I wonder
if a significant chunk of lilypond's performance problems stem from
this.


> They are also in complete denial about the importance of interpreter
> speed for an _extension_ language: for them, compiler performance is
> everything.
> 
> They also consider it "somebody else's problem" to organize the
> compilation and storage of byte code for an application.
> 
> There is a lot in there where a solution simply cannot be achieved by
> LilyPond on its own, and a lot where a LilyPond-only solution makes
> very little sense in the overall Guile universe.

But surely we aren't the only ones facing these issues?  What about
other guile-dependent projects? Are they crying out too? I can't imagine
this state of things would continue to hold, if so. Sooner or later,
either the guile devs will capitulate and fix their API, or people will
just move away to other extension languages (or fork guile-1.8).


> > but that might need a lot more time. And we might want to keep LP
> > 2.18 in the distros in the meantime, which would mean bundling
> > guile1.8 with LP 2.18.
> 
> I think that the most promising way of attack is to make sure that
> Guile-2.0 and Guile-1.8 libraries can be installed in parallel, and
> with parallel architectures (most libraries can, Guile-1.8 was not
> multiarch-capable when it was removed).
> 
> When Debian can include Guile-1.8 without significant cost, why
> wouldn't they?  I think that there lies our most promising approach in
> the short term.
[...]

Debian does have quite a good number of libraries that can coexist with
different versions of themselves.  And in theory, I'd imagine that it
should be possible to tweak guile-1.8's build scripts so that it
installs into a version-specific path, so as not to have any conflicts
with guile-2.0.  So this should all be possible.  But I don't know how
much actual work it would take to make this all work, though.

In the short term, it will probably be easier to get a new version of
lilypond (containing a suitably-bundled guile-1.8 installation) into the
archive than it is to re-introduce guile-1.8. But I think it's worth a
shot.


T

-- 
ASCII stupid question, getty stupid ANSI.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sat, Jan 07, 2017 at 07:53:25PM -, Trevor Daniels wrote:
> 
> Urs Liska wrote Saturday, January 07, 2017 6:59 PM
> 
> > Am 07.01.2017 um 19:46 schrieb H. S. Teoh:
> >> I didn't realize there was so much going on with the transition (or
> >> lack thereof?) to guile 2.0.  What of the idea of packaging the
> >> last known-to-be-good version of guile 1.8 with the lilypond
> >> sources, and just going with that?
> > 
> > Well, Guile2 seems to offer things that we will probably *want* in
> > LilyPond, e.g. support for import/export to XML.
> 
> Without knowing much about Linux distros, I'm wondering if the best
> course of action would be to aim to bundle Guile 1.8 with the LP 2.20
> release.  Would that help in keeping LP in the distros?  Would it
> sidestep the issue of their having to maintain Guile 1.8 alongside
> Guile 2?  But if they insist on recompiling from source, is it even
> possible to "bundle" Guile 1.8 with LP in other than our own
> distributions?
[...]

I can't speak for other distros, but at least as far as Debian is
concerned, if the upstream (i.e., lilypond) source tarball contains a
copy of the guile-1.8 sources, and the build script is tweaked such that
it installs a copy of guile 1.8 in paths private to lilypond, e.g.,
/usr/lib/lilypond/guile-1.8 or some such path, rather than in
system-global paths like /usr/bin/guile, then it could probably be made
to work.

Such a practice might be frowned on by Debian devs, but at least this
way lilypond would have a chance to remain in the Debian-related
distros, which I consider to be pretty important. Otherwise, we risk
losing a significant chunk of our userbase.  Not everyone is willing (or
know how) to compile lilypond from the sources just to get it to run on
a guile2 system.

Of course, the best scenario is that we figure out how to fix the
current guile2-related issues before LP 2.20 is released... but that
might need a lot more time. And we might want to keep LP 2.18 in the
distros in the meantime, which would mean bundling guile1.8 with LP
2.18.


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely 
repeat each other.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sat, Jan 07, 2017 at 07:59:25PM +0100, Urs Liska wrote:
> 
> Am 07.01.2017 um 19:46 schrieb H. S. Teoh:
> > I didn't realize there was so much going on with the transition (or
> > lack thereof?) to guile 2.0.  What of the idea of packaging the last
> > known-to-be-good version of guile 1.8 with the lilypond sources, and
> > just going with that?
> 
> Well, Guile2 seems to offer things that we will probably *want* in
> LilyPond, e.g. support for import/export to XML.
[...]

True.  But perhaps shipping the guile-1.8 sources with lilypond could be
a temporary stop-gap measure until we figure out why guile 2.0 causes a
dramatic slowdown and problems with UTF characters?


T

-- 
Insanity is doing the same thing over and over again and expecting different 
results.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sat, Jan 07, 2017 at 09:59:22AM +0100, David Kastrup wrote:
> "H. S. Teoh" <hst...@quickfur.ath.cx> writes:
[...]
> > I've been able to get Lilypond 2.19 to work in Debian/testing by
> > compiling from source (lilypond git HEAD) with `./configure
> > --enable-guile2`.  There are some Scheme-related deprecation warning
> > messages that show up while lilypond is running, but otherwise it
> > seems to be working just fine.
> 
> If you never use a non-ASCII character and are satisfied with the
> speed of LilyPond dropping to less than a third and its memory
> requirements rising.
> 
> This is not a viable option for serious work.
[...]

Unfortunately, I think you're right. :-(  I've noticed that my newly
compiled lilypond now takes a very noticeable long pause just at startup
time, and seems more sluggish to work through complex scores in general.

I didn't realize there was so much going on with the transition (or lack
thereof?) to guile 2.0.  What of the idea of packaging the last
known-to-be-good version of guile 1.8 with the lilypond sources, and
just going with that?

After having witnessed several such problems with large software
projects (namely, depending on an external library that upstream no
longer maintains, and the new version is not backward compatible), and
having experienced the same thing myself in my own projects, I'm
starting more and more to question the wisdom of depending on external
libraries.  The most practical approach that I'm gradually adopting,
especially for open-source libraries, is to just ship the exact version
of the library that I develop on and test with along with my sources,
and not have to worry about dependency hell (including, by extension,
library upgrade hell) on the users' end.


T

-- 
Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be 
algorithms.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Thu, Jan 05, 2017 at 10:36:02AM +, Dr Nicholas Bailey wrote:
> Watch out for Debian. There isn't a Lilypond in Testing (Stretch)
> AFAIK. It's because they've removed the old scheme version. I develop
> in Testing in the hope that by the time I get around to releasing
> anything, it will be compatible with Stable :) Stable released rather
> infrequently, but I use it on our servers and it is very, well,
> *stable*.
> 
> It's easy to install the Stable lilypond debian package on a Testing
> Debian box, fortunately. Debian is my favourite distro: I've tried
> others but always returned. Shame about the scheme thing, but it will
> sort itself out sooner or later (if it hasn't already!). I guess the
> clue's in the distribution name: "Testing" ;)
[...]

I've been able to get Lilypond 2.19 to work in Debian/testing by
compiling from source (lilypond git HEAD) with `./configure
--enable-guile2`.  There are some Scheme-related deprecation warning
messages that show up while lilypond is running, but otherwise it seems
to be working just fine.

Hopefully whoever is maintaining the lilypond package will get things
working again in the official package!


T

-- 
Knowledge is that area of ignorance that we arrange and classify. -- Ambrose 
Bierce

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: how to get expression in midi

[H. S. Teoh]

On Wed, Jan 04, 2017 at 09:56:34PM +0100, Dario Marrini wrote:
[...]
>may you and anybody suggest me any MIDI editor avaluable for Linux?
>I don't use Windows anymore, since '99... 
[...]

Many years ago I used Rosegarden. I don't use it anymore these days,
since I work mostly in notation now, so Lilypond is enough for me. But
you may find it useful.


>I thought using lilypond might be better to manipulate some stuff
>like crescendo and diminuendo; simply putting two commands among
>notes; I have no idea how a midi editor could do that, but in case
>of a long crescendo (several bars) I think it's not a good idea
>using lilypond command, instead of changing singular notes'
>velocity; correct me if I am wrong
[...]

That depends on how far you wish to go with lilypond, and when it
becomes easier to just edit the midi afterwards instead of spending much
more time writing Scheme functions to do what you want in lilypond.
Personally, I actually prefer the latter, but I wouldn't recommend that
unless you're ready to spend more time writing code than writing music
(initially, anyway).  :-P

One of these days I plan to dig into the innards of midi generation in
lilypond and hopefully find ways to improve it, but time isn't on my
side. :-/


T

-- 
Doubt is a self-fulfilling prophecy.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: how to get expression in midi

[H. S. Teoh]

On Wed, Jan 04, 2017 at 07:59:17PM +0100, Dario Marrini wrote:
[...]
>  * violin part has many 1/8 notes, many are repeating itselves,
>listening the MIDI output it seems it's not very well, notes'
>sounds are too much closing, and repeating notes sound like a
>unique sound almost.  how may I fix this? I think it'd better
>writing each 1/8 note as 'staccato', but may the Midi output
>will be according on that?

You need a better midi soundfont or better midi synth.  This isn't
really something specific to Lilypond; it may be best to use a MIDI
editor to edit the notes yourself after generating it from lilypond.
Lilypond's midi capabilities are rather limited; what you're describing
is something that, while it is *possible* to fix using Lilypond, will
probably require much more work than it seems you're willing to spend on
it.

Resources you may find pertinent to your particular issue (note that
these are not specific to lilypond):

https://www.youtube.com/watch?v=VaSqSieQ4gQ
https://www.kvraudio.com/forum/viewtopic.php?t=365719

http://forum.cakewalk.com/TIP-Killing-the-quotmachinegunquot-effect-programming-MIDI-m1520197.aspx


>besides, it's very hard now to rewrite all the code, so, there
>is some tool to do that, a sort of 'mass modifier' about the
>text code? I dont' want to fight with my poor Perl
>knowledge

I'm not sure what Perl has to do with this, unless you're talking about
mass textual substitution.  You could possibly write a Scheme function
to turn notes into staccato, but I'm not sure that's necessarily a good
idea (it makes your music harder to edit later).


>  * is it possible to change the velocity (volume?) of a single
>long note?  example, brass ensemble start with a 'sf', then
>play crescendo the same note while 'crescendo' from a 'p' to a
>'f' again; I don't know if it is possible in a MIDI
>environment, and how to perform this using lilypond notation

It is definitely possible in MIDI.  How to do it in lilypond is another
story. :-P  Lilypond itself doesn't have a built-in way of performing
cresc / decresc on a single note; but it *is* possible to use `\set
Staff.midiExpression` to alter the volume of a note while it is
sounding.

Using this idea, I wrote a Scheme function that generates a series of
gradual changes to Staff.midiExpression to simulate a cresc / decresc.
In fact, it can do "ramps" of almost any numerical context setting,
though I most often use it for midiExpression.  Put the below snippet
into a file, say prop-ramp.ly, then write \include "prop-ramp.ly" at the
top of your input file, and you can use the \propRamp command to
generate these events.

(Scheme experts will probably laugh at the klunky way I wrote this,
since I'm a Scheme n00b, but so far I've used this in several of my
pieces and it works fairly well.  Also, it currently hardcodes settings
to the Staff context; while this works for midiExpression, it may not
work so well for other properties -- you may have to change the
`'context-type 'Staff'` line to something else in those cases.)


snip
%
% Scheme function for generating linear ramping of numerical Staff property
% values to allow for true crescendos/diminuendos.
%
% Usage:
%   \propRamp
%
% Example:
%   \new Staff {
%   << c'1  % a long note
%
%  % Ramp midi expression property for the above note
%  % from 1.0 to 0.0 over a duration of a dotted 1/2 note.
%  \propRamp #'midiExpression 1.0 0.0 2.
%   >>
%   }
%
\version "2.19.23"

#(define genPropertyRamp
(lambda (propertySym start end i n duration)
(if (>= i n)
'()

; start + (end - start)*i/n
(let ((curValue (+ start (/ (* i (- end start)) n

;(display "start = ")(display start)
;(display " end = ")(display end)
;(display " i = ")(display i)
;(display " curValue = ")(display curValue)
;(display "\n")

(cons
; \set Staff.midiExpression = #curValue
(make-music 'ContextSpeccedMusic
'context-type 'Staff
'element (make-music
'PropertySet
'symbol propertySym
'value curValue)
)
(cons
(make-music 'SkipEvent
'duration duration
)
(genPropertyRamp propertySym start end (+ i 1) n 
duration)
)
)
)
)
)
)

propRamp = #(define-music-function
(propertySym startValue endValue totalDur)
(symbol? number? 

Re: how to get expression in midi

[H. S. Teoh]

On Wed, Jan 04, 2017 at 05:07:30PM +0100, Dario Marrini wrote:
[...]
>    <<
>      \new Voice = "violino_I" { \violin_I }
>      \new Voice = "espress" { \expr_violin_I }
>    >>
[...]

In the latest 2.19.x, the MIDI dynamics performer has been moved from
Staff into Voice. So probably you should try this instead:

\new Voice = "violino_I" <<
\violin_I
\expr_violin_I
>>

That should do the trick, I believe.


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Hello everyone / Instrument-Name-Abbreviation on front of every system

[H. S. Teoh]

On Thu, Dec 29, 2016 at 01:12:21AM +0100, UCas wrote:
[...]
> For scores with more than 3 or 4 instruments I would find it useful,
> if I could put a short for the instrument-name in front of every line.
> The first system has the instruments in front, but I do not find a way
> to put an abbreviation of the names in front of every system across
> the score.
> 
> Is there a helpful snippet anywhere in the documentation? Any Idea?

Does this help?

\new Staff = "piccStaff" {
\set Staff.instrumentName = "Piccolo"
\set Staff.shortInstrumentName = "Picc"

% ... music goes here
}


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sat, Dec 31, 2016 at 01:15:08PM +1100, Andrew Bernard wrote:
[...]
>Debian example lags behind the leading edge to focus on stability.
[...]

To be fair, though, most home Debian users use the testing / unstable
releases (that are actually quite stable in spite of the names -- the
*really* unstable release is called 'experimental'), that are pretty
up-to-date, rather than the stable release, which does lag behind
noticeably.  Debian/stable is usually run on servers, where stability is
more important than having the latest and greatest.

More pertinently to the OP, though, Lilypond seems to run quite well on
pretty much all the major distributions, so the choice on which one to
use really isn't dependent on whether or not one can use Lilypond on it,
but rather on the OP's personal preferences on other factors offered by
each distribution.


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Which Linux distro for Lilypond

[H. S. Teoh]

On Sun, Dec 25, 2016 at 06:52:03AM +0100, Jacques Menu Muzhic wrote:
> I use LilyDev 4 (Debian 8 / Jessie, native GUI I guess) on a Mac with VMware 
> Fusion, on which Lilypond dev versions compile seamlessly.
[...]

I use Lilypond (but not Frescobaldi -- don't know if it works, I think
it probably does) on Debian/unstable.  Both the package from the
official Debian repository and building from source work well.

The official Debian version of lilypond is older (2.18.x), so I build
directly from git (2.19.x) instead.  I use both versions, usually 2.19
for more complex projects where I need 2.19 features, and 2.18 for
smaller experiments and such. So far, I haven't encountered any major
problems with either version.

Since Ubuntu & co. are Debian-based, the above probably applies to them
too.  I don't recommend vanilla Debian for first-time Linux users;
Ubuntu is probably more friendly and accessible, though both share the
same core.


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Is there a short way of forcing a particular octave?

[H. S. Teoh]

On Wed, Dec 21, 2016 at 09:30:08PM -0600, David Wright wrote:
> On Wed 21 Dec 2016 at 20:43:20 (-0500), Kieren MacMillan wrote:
[...]
> > Look: I’m glad you like \relative mode. But after a decade of using
> > \relative (and running into many frustrations) followed by nearly a
> > decade of using \absolute (with no such frustrations), you’ve got a
> > serious uphill battle convincing me that \relative is superior.  =)
> 
> I'm not trying to convince you of any such thing. I wrote "I can't see
> the point in *avoiding any methodology* that makes things easier and
> more reliable." I'm not trying to convince you to use it. I'm just
> worried about people's attempts to *dissuade others from* using it, as
> if there's something wrong or immature about it.
> 
> The examples you gave above were both about editing what's already
> written into LP source, and I know that you are composing directly
> into LP. Doing that would be much more difficult with \relative than
> \absolute.
[...]

FWIW, I also compose directly into LP, and I totally dig \relative mode.

I think it depends on the kind of music you're using it for. If you're
writing modern stuff that rarely sticks to traditional melody lines,
then \relative mode is probably not for you, because its determination
of octave appears to be designed around traditional melody lines.  But
if you're writing highly melodic stuff like I do, \relative mode is a
real keystroke saver (I'd get a wrist aneurysm if I had to type all
those 's and ,s hundreds of times every day).

I find \relative mode quite helpful in orchestral works because it lends
itself very well to copy-n-paste octave doublings. Trying to do that in
absolute mode and needing to edit tens of 's and ,s after you copy a
line that needs to be transposed by an octave is quite painful.

Now I realize that \relative has its disadvantages, and that you can use
\transpose and what-not to make editing ,s and 's less painful, but so
far, I haven't found a strong reason to switch to absolute mode. Whereas
when I start a new sketch without \relative, I quickly tire of all the
's and ,s and revert to \relative once again.

Of course, this is just based on the way I work and the kind of music I
work with.  Obviously your mileage may (and probably will) vary. But I
just wanted to chime in with another data point that \relative isn't
absolutely bad -- if you'll excuse the pun :-P -- and that there *are*
people who find it useful.


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Temporarily combine two Voices on the same Staff

[H. S. Teoh]

On Wed, Dec 21, 2016 at 11:52:02PM +0100, Thomas Morley wrote:
> 2016-12-21 19:08 GMT+01:00 H. S. Teoh <hst...@quickfur.ath.cx>:
[...]
> > So my question was, is it possible to tell Lilypond to merge the two
> > voices into chords just for beat 2? Or do I just have to "hack" it
> > by using spacers in voiceB and spelling out the chords in voiceA?
> 
> Probably (see inline comments):
[...]
> voiceB = \relative c'' {
> % m.7
> \voiceThree
> | cs=''8~ cs32 e d cs
> %% send this notes to Voice-"A"-context, to
> %% create simultaneous music
> \context Voice = "A" { d8. cs16 }
[...]
> \new PianoStaff <<
> \new Staff {
> \clef treble
> <<
> %% n.b.
> %% named Voices
> \new Voice = "A" \voiceA
> \new Voice = "B" \voiceB
> \new Voice \voiceC
> >>
> }
[...]

Wow.  That worked like a charm!!  Much thanks for the tip!


T

-- 
To provoke is to call someone stupid; to argue is to call each other stupid.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Temporarily combine two Voices on the same Staff

[H. S. Teoh]

On Tue, Dec 20, 2016 at 11:30:51PM +0100, Simon Albrecht wrote:
> On 20.12.2016 22:54, H. S. Teoh wrote:
> > I'm typesetting some complex polyphonic music, and have 3 Voices
> > sharing the same Staff. In the middle of the bar, the top two Voices
> > share the same rhythm, so I'd like to combine stems beams on them
> > just for 2 beats, and have them be treated independently again
> > afterwards. There is a 3rd Voice on the same Staff with downward
> > Beams, so without combining, the top two Voices would have
> > hard-to-read clashing beams.
> 
> Please give an example, else it’s hard to judge. But it would be very
> unusual in an otherwise strictly polyphonic work to use chords for
> just two beats.
[...]

Sorry, I didn't make it clear.  I was actually transcribing a Bach
piece, BWV 850 (fugue in D major in 4 voices, WTC book 1). I chose to
transcribe it using 4 Voices (there are several Staff crossings
throughout the piece, so this way I can use \change Staff="...", but
that's not pertinent here.) In measure 7, for example, I have:

\include "english.ly"
voiceA = \relative c'' {
% m.7
\voiceOne
| g'=''4  fs8. e16  d8. e16  c8. c16
}

voiceB = \relative c'' {
% m.7
\voiceThree
| cs=''8~ cs32 e d cs  d8. cs16  b4  e,4
}

voiceC = \relative c'' {
% m.7
\voiceFour
| a='4  a8. g16  fs8. g16  a4
}

voiceD = \relative c, {
% m.7
\oneVoice
| r4  d32 e fs g fs e fs d  b'8. b16  a8. g16
}

\new PianoStaff <<
\new Staff {
\clef treble
<<
\new Voice \voiceA
\new Voice \voiceB
\new Voice \voiceC
>>
}
\new Staff {
\clef bass
\new Voice \voiceD
}
>>

The edition I'm using as reference has, in this bar, the first 3 voices
on the upper staff, and the bass on the lower staff.  In beat 2 in the
Lilypond output, voiceA and voiceB have stems and beams that clash with
each other, because there simply isn't enough space to fit everything in
otherwise.  Whereas in the edition, in this beat voiceA and voiceB are
collapsed into 2-note chords so that they can share the same beam, thus
making it easier to read, even though they are still logically two
separate voices. In beats 3 and 4, because voiceA and voiceB are no
longer co-rhythmic, they are typeset the same way Lilypond does it.

So my question was, is it possible to tell Lilypond to merge the two
voices into chords just for beat 2? Or do I just have to "hack" it by
using spacers in voiceB and spelling out the chords in voiceA?


T

-- 
Mediocrity has been pushed to extremes.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Temporarily combine two Voices on the same Staff

[H. S. Teoh]

I'm typesetting some complex polyphonic music, and have 3 Voices sharing
the same Staff. In the middle of the bar, the top two Voices share the
same rhythm, so I'd like to combine stems beams on them just for 2
beats, and have them be treated independently again afterwards. There is
a 3rd Voice on the same Staff with downward Beams, so without combining,
the top two Voices would have hard-to-read clashing beams.

Is there a way to do this without using \partcombine?  I realize that
it's probably possible to rewrite this with \partcombine, but it seems
to be overkill for just 2 beats.  I could probably also spell out the
combined chords directly in one of the Voices, but if at all possible
I'd like to represent it as separate Voices.


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he 
said, "A double negative forms a positive. In some languages, though, such as 
Russian, a double negative is still a negative. However, there is no language 
wherein a double positive can form a negative." A voice from the back of the 
room piped up, "Yeah, yeah."

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: New LilyPond website

[H. S. Teoh]

Just took a look at the latest version of the new website, and liked it.
Thanks for taking the time to make it work with NoScript.


--T

On Tue, Nov 29, 2016 at 07:58:35PM -0500, John Roper wrote:
>[1]jmroper.com/lilypond
>On Tue, Nov 29, 2016 at 7:58 PM, John Roper <[2]johnroper...@gmail.com>
>wrote:
> 
>  Ok, I have updated the website. There is a little problem with the
>  sidebar pushing the other content down, but that is fine. My goal was to
>  recreate the current website using just html and css with a nicer look.
>  It does not require any js at all. This is just a sample so almost none
>  of the links actually work.
>  On Tue, Nov 29, 2016 at 7:49 PM, Chris Yate <[3]chrisy...@gmail.com>
>  wrote:
> 
>Having now looked at it, though only on my phone, I quite like it. But
>I did have to scroll scroll scroll to read what would be about one
>page of content.
> 
>What I saw was a very "sexy" marketing site for Lilypond, and I think
>it does it justice.
> 
>However, as someone already sold on the tool, all I want to read is
>the documents, or download binaries... I think I'm echoing the others
>in saying I'd like to see what you can do with responsive design to
>the documentation!
> 
>I'd suggest as models, the docs for things like AngularJS, Bootstrap,
>Ruby/Rails and Php. Although our documentation content is excellent,
>I'm sure there's structural changes that could improve the
>presentation, and certainly some responsive html/css... It's not my
>forte but I think it might be one of yours! :)
> 
>Chris
> 
>On 29 Nov 2016 22:54, "Karlin High" <[4]gne...@hotmail.com> wrote:
> 
>  On 11/29/2016 4:42 PM, John Roper wrote:
>  > I am trying to build the lilypond docs now.
> 
>  Very good! Chances of the new website project being accepted seem
>  much
>  higher if you can figure out how that works, and not greatly upset
>  the
>  existing workflow for maintaining documentation and translations.
>  --
>  Karlin High
>  Missouri, USA
> 
>  ___
>  lilypond-user mailing list
>  [5]lilypond-user@gnu.org
>  [6]https://lists.gnu.org/mailman/listinfo/lilypond-user
> 
>  --
>  John Roper
>  Freelance Developer and Simulation Artist
>  Boston, MA USA
>  [7]http://jmroper.com/
> 
>--
>John Roper
>Freelance Developer and Simulation Artist
>Boston, MA USA
>[8]http://jmroper.com/
> 
> References
> 
>Visible links
>1. http://jmroper.com/lilypond
>2. mailto:johnroper...@gmail.com
>3. mailto:chrisy...@gmail.com
>4. mailto:gne...@hotmail.com
>5. mailto:lilypond-user@gnu.org
>6. https://lists.gnu.org/mailman/listinfo/lilypond-user
>7. http://jmroper.com/
>8. http://jmroper.com/

> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


-- 
Don't throw out the baby with the bathwater. Use your hands...

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: New LilyPond website

[H. S. Teoh]

On Mon, Nov 28, 2016 at 08:33:25PM -0500, John Roper wrote:
>I have thought about the no scripts idea, and I belive that right now,
>there are not many websites that do not use javascript for some
>functionality. Wordpress it's self is almost entirely built upon
>javascript and php and it makes up >25% of all websites online
>
> ([1]https://martechtoday.com/wordpress-used-on-25-percent-of-all-websites-report-151115).
>Even the lilypond blog runs on wordpress.
[...]

Please don't misunderstand; I'm not opposed to using javascript at all.
I think the redesign you did is wonderful.  It's just that I prefer
scripting should be layered on top of non-scripted underlying content,
rather than require scripting to even load the content in the first
place.  There are various reasons. Others have pointed out
accessibility; I also have in mind mechanical processing. It's OK if the
website is harder to use without scripting; but it should still be
*usable*. I.e., the content should be static (or appear to be static
from the browser's POV -- it can be generated from server side, and
that's OK), rather than, for example, require AJAX requests to pull
content after the initial HTML is loaded.

As long as accessing the content and navigation is *possible* with no
scripting (i.e., the content and any links exist in HTML), that's good
enough for me. You can do whatever else you want with scripting (make it
fancier, dynamically style it, animate it, or whatever else), and it
would be OK by me.


T

-- 
Without geometry, life would be pointless. -- VS

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: New LilyPond website

[H. S. Teoh]

On Mon, Nov 28, 2016 at 06:25:24PM -0500, John Roper wrote:
>Hi, my name is John Roper and I am a freelance developer who does
>web design among other things. I use LilyPond occasionally and I
>felt that the website needed a little bit of a sprucing up. I
>decided to see what I could do and I have created a new, nicer
>looking, website based on wordpress which you can preview
>at http://jmroper.com/lilypond/. I have managed to get most of the
>content from the other website transferred over and I hope to have
>it all done soon. I was hoping that it would be able to move the
>LilyPond blog over to the main website as well. Please tell me what
>you think.
[...]

I don't speak for the community, but personally, I'd rather the website
be at least usable with scripting disabled. (Even though I am not
against making it nicer with scripting. But it shouldn't be a
requirement for the site to be usable.)


T

-- 
Guns don't kill people. Bullets do.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: general question for composers

[H. S. Teoh]

On Fri, Nov 18, 2016 at 01:18:53PM -0800, Tobin Chodos wrote:
>hi all,
> 
>this is a general question for composers using lilypond.  at what
>point in your process do you generally start engraving?  Like most
>composers coming from the consumer notation softwares, I'm
>accustomed to working in pencil first, but not to completely
>separating the engraving and composition tasks.  Curious about
>composer perspectives about this with lilypond.  are there
>strategies for working with a lilypond file while still composing?
[...]

I usually sketch on paper or in my head when I get an initial idea, but
I start inputting things into lilypond quite early on.  However, instead
of inputting the full score right from the get-go, what I do is to use
multiple \score{} blocks for working out various separate passages,
possible harmonizations, etc., just to be able to visually work out some
of the details, listen to the MIDI approximation, etc..

Once I am confident enough with these "lilypond sketches", I set aside
the input file(s) and begin the "real" score as a different (set of)
input file(s). The original worked out passages are either copy-n-pasted
or retyped into the new file(s); quite often I would get new ideas in
the process and may diverge from the initial lilypond sketches. But
having them still available as other input files allows easier
consultation with my original ideas and copy-n-pasting if/when I decide
to.  So I'd say I begin typing lilypond input quite early in the
composing process, which may or may not be a good idea, but at least I
find it helpful to be able to see the score early on and to take
advantage of the computer's editing functions (i.e., change notes
without needing to rewrite an entire staff or system or even page).

Of course, lilypond input being what it is, certain editing functions
are more troublesome than others; e.g., inserting/deleting bars from the
middle of the piece can involve a lot of grunt work.  I heard that
Frescobaldi(?) is supposed to ease a lot of this grunt work, but I still
prefer working directly with the plain text files.  To that end, I find
it very helpful to have a consistent, very rigid structure to my
lilypond files -- even though lilypond does allow very flexible input
syntax, in large complex pieces this quickly becomes unmanageable.

So I impose upon myself a certain format, such as having no more than 1
bar per input line, grouping bars into "stanzas" of 4 bars each,
delimited by a blank line, prepending passages with a unique comment
header such that it's easy to jump to a specific passage just by
searching for that unique string. I also use bar checks '|' both at the
beginning *and* end of every bar, which is redundant, of course, but
does serve the useful purpose of visually indicating the start and end
of a bar (esp. in complex pieces where a bar may span multiple lines) so
that I can easily identify a bar with just a glance. It makes counting
groups of bars much easier, and less confusing to find things in the
middle of a bar.

In multi-instrument works, I found it too troublesome to keep each
instrument part to a separate file -- I spend too much time switching
between files and trying to figure out where things are in each file,
and keeping a large number of files in sync.  Instead, I keep everything
in a single file with each instrument's part in a uniquely named
variable (e.g., violinIPart, violinIIPart, trumpetIPart, trumpetIIPart,
etc.), and navigate by using my editor's search function for that unique
part name, and then the section header string, which is duplicated
consistently across all parts (even if they consist of just rests /
spacers).  Some amount of effort is required to keep all these markers
in sync with each other, but in my experience I find that they save a
lot more time when navigating the input file, than it takes to maintain
them.

True, inserting a bar here or there would require updating every
instrument part manually, but in theory if I keep to a consistent,
strict layout then I could probably write an editor script for
performing such operations.  Originally, I thought of assigning each
passage to its own variable, so that I can add new bars to a passage
without disrupting subsequent passages, but in the end it was too
complex and messy to keep everything in sync (and to remember new names
for passages or invent a system for keeping them straight), so I stuck
with one variable per instrument part under a consistent naming scheme.

When I need to insert an extensive passage in the middle of a piece,
sometimes it's easier to do it in reduced score in a separate lilypond
input file until I work out exactly the right number of bars it would
need, before actually updating each instrument in the main input file
with the right number of spacers / filler bars that eventually will get
filled with the new notes. That way I know exactly how many rests to
insert in each instrument part. (I always 

Re: More trill questions

[H. S. Teoh]

On Fri, Nov 04, 2016 at 07:13:20PM -0400, Martin wrote:
> Hi again,
> I don't understand why the example below doesn't work.
> >From what I can see, starting with a trill in a polyphonic passage triggers 
> >a "syntax error, unexpected EVENT_IDENTIFIER".
> I got it to work is the trill is on the 2nd note...

The \trill command is supposed to *follow* the trilled note, so it
should be written c2\trill instead of \trill c2.


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Any thoughts on how to automatically avoid rest collisions in polyphonic music?

[H. S. Teoh]

On Wed, Oct 26, 2016 at 04:52:18PM -0700, David Bellows wrote:
> > Do you use the \voiceOne, \voiceTwo, \voiceThree commands in the
> > generated parts?  Sometimes those can help, by rendering rests for
> > each voice separately. Not sure if this is the solution you're
> > looking for, though.
> 
> I had been but keeping it all straight and making the process
> infinitely expandable became a headache so now I use << voice1 //
> voice2 // voice3 >> etc which is easy to just keep adding to. Would
> using \voiceOne (etc) make that much of a difference?

You can try it and see?  In my experience, it does help with placement
of notes especially when you have rests in multiple voices. Lilypond is
generally quite good at handling shifting notes/rests horizontally to
make them fit, but that depends on how complex the music is. Some cases
may be so complex it will always require manual intervention.

I'm not sure about using << ... // ... >> to make it "infinitely
expandable"... wouldn't the output become illegible past 4 voices?  If
you're mechanically generating these parts, I'd say keep it to 2 voices
per staff, which is least problematic. In theory, it should be easy for
the program to allocate a new Staff for every two voices, right?

You could have more, up to 4 per staff, if you use \voiceOne, \voiceTwo,
...  \voiceFour, but then there would be cases where collisions become
inevitable and lilypond may just give up trying to figure it out.  At
least, it would require manual intervention (recently I've been working
on a complex 4-voice piano score and lots of manual intervention were
needed to keep things straight and not turn into spaghetti on the page).


T

-- 
If Java had true garbage collection, most programs would delete themselves upon 
execution. -- Robert Sewell

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Any thoughts on how to automatically avoid rest collisions in polyphonic music?

[H. S. Teoh]

On Wed, Oct 26, 2016 at 02:10:49PM -0700, David Bellows wrote:
> I have a large computer music generating program that I'm creating.
> One of the things it does is generate sheet music for the generated
> music using Lilypond. It works really well.
> 
> When dealing with one or two voices everything's fine. But I just
> added a musical style that uses three voices and collisions with rests
> are occurring.

Do you use the \voiceOne, \voiceTwo, \voiceThree commands in the
generated parts?  Sometimes those can help, by rendering rests for each
voice separately. Not sure if this is the solution you're looking for,
though.


T

-- 
BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Write a custom backend?

[H. S. Teoh]

On Tue, Sep 13, 2016 at 02:04:04PM +0200, David Kastrup wrote:
> Mathieu Demange  writes:
> 
> > Hello all, 
> >
> > Could anybody help me to know if writing a custom output backend (in
> > scheme, of course) for Lilypond is something doable? I mean without
> > modifying any of Lilypond's internals.
[...]
> You'd have to make use of one of the existing translator groups (like
> Engraver_group or Performer_group) which might me more accurately
> called translator groupers: there is currently no way to define those
> in Scheme.
> 
> Personally, I'd consider it a great project to convert _all_ of Midi
> generation to Scheme.
[...]

I'm interested in this.  Any hints as to where to start looking? I.e.,
how does Perfomer_group work, how to use it, etc..

I was thinking of writing a better handler for midi dynamics, esp.
wrt single-note cresc/decresc.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- 
Christopher

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Trill with (automatic) accidentals

[H. S. Teoh]

On Thu, Sep 08, 2016 at 12:12:36PM +0200, Urs Liska wrote:
> Is it true that adding an accidental to a trill like in the attached
> image can only be realized through markups?

As far as I can tell from the docs, yes. But I don't know if there is
some hidden option somewhere that allows it?


> Is there an existing solution that can be used like \pitchedTrill but
> without explicitly printing the alternative note and instead printing
> an accidental (if necessary according the the accidental style in
> place)?
> 
> Using markup with hardcoded accidentals doesn't work properly with
> transpositions.
> 
> If not I think one would write a music function that is given an
> interval. From and the fundamental pitch it would determine the need
> for a specific accidental and from there construct the necessary
> markup.

That would be great!

And while you're at it, maybe also add similar functionality to the
various ornaments like \prall, \mordent, etc.?  Recently I was
transcribing a Haydn sonata, and had to resort to lots of ugly markup
just to get the accidentals to print properly.

And of course the midi didn't work properly (even with \articulate), and
I had to explicitly spell out the notes with \tag #'midi {...} and
\removeWithTag #'midi for the printed score.  Not sure how much you can
do on the midi front, but at least it would simplify things if the
ornament itself can take accidentals. It's at least halfway there. :-)


> I don't need a working solution right now, just some feedback on the
> issue.
> 
> I'm actually wondering why this doesn't seem to be possible
> out-of-the-box.
[...]

Yeah, I was also quite surprised to find out that there is apparently no
way to generate ornaments with accidentals without resorting to markup.
Given the classical roots of lilypond, I found this quite unexpected.


T

-- 
Always remember that you are unique. Just like everybody else. -- despair.com

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Midi dynamics behaviour changed in latest git HEAD

[H. S. Teoh]

On Sat, Aug 20, 2016 at 03:25:10PM +0300, Heikki Tauriainen wrote:
> Hi,
> 
> On Fri, 2016-08-19 at 10:16 -0700, H. S. Teoh wrote:
> > I've been using lilypond from git HEAD (mainly because lilypond in
> > my distro is too old, still stuck at 2.18, and I need features and
> > fixes in 2.19), and recently I noticed that midi dynamics in my
> > piano scores aren't being rendered correctly anymore.  Looking into
> > the commit log, I saw this:
> > 
> > Issue 4947: Link notes to dynamics in Dynamic_performer rather
> > than Staff_performer.  Dynamics in different voices are now
> > independent.
[...]
> Would instantiating the Voice contexts explicitly in the MIDI \score,
> 
> <<
>     \new Staff \new Voice << \rightHandPart \dynamicsPart >>
>     \new Staff \new Voice << \leftHandPart \dynamicsPart >>
> >>
> 
> help?  This is what I'd try first to ensure that \rightHandPart and
> \dynamicsPart will end up in the same Voice (and not in any separate
> implicit Voices which could get instantiated implicitly otherwise).
[...]

That did the trick.  Thanks a lot!!!


T

-- 
Famous last words: I wonder what will happen if I do *this*...

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Midi dynamics behaviour changed in latest git HEAD

[H. S. Teoh]

I've been using lilypond from git HEAD (mainly because lilypond in my
distro is too old, still stuck at 2.18, and I need features and fixes in
2.19), and recently I noticed that midi dynamics in my piano scores
aren't being rendered correctly anymore.  Looking into the commit log, I
saw this:

commit 980df8c5df6b784d573f1c3d16bb9c8f3ab8
Author: Dan Eble 
Date:   Wed Jun 15 18:54:53 2016 -0400

Issue 4947: Link notes to dynamics in Dynamic_performer rather than
Staff_performer.  Dynamics in different voices are now independent.


It seems that this is the probable cause of the problem, because in my
piano scores I use a separate Dynamics context to put all dynamics,
something like this:

rightHandPart = { c'1 ... }
dynamicsPart = { s1\mf ... }
leftHandPart = { c1 ... }

% Note: this is for layout only
\score {
\new PianoStaff <<
\new Staff { \rightHandPart }
\new Dynamics { \dynamicsPart }
\new Staff { \leftHandPart }
>>
\layout {}
}

% This is what midi is actually generated from
\score {
<<
\new Staff << \rightHandPart \dynamicsPart >>
\new Staff << \leftHandPart \dynamicsPart >>
>>
\midi {}
}

As you can see, \dynamicsPart is used for typesetting dynamics in the
layout score so that it will appear between the two staves, as is the
convention for piano notation. But for MIDI output I merge the dynamics
part with the parts for each hand. Prior to the above git commit, the
construct << \rightHandPart \dynamicsPart >> would cause dynamics to be
merged into \rightHandPart.  However, now it appears to be interpreted
as two separate voices with independent dynamics, so none of the
dynamics are applied to the actual notes anymore.

Is there some way to work around this?  How do I make lilypond merge the
dynamics from the Dynamics context into the LH/RH parts?

Thanks!


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: rehearsal marks: separate from content encoding and display above strings

[H. S. Teoh]

On Fri, Aug 12, 2016 at 10:58:08PM +0200, Johan Vromans wrote:
> On Fri, 12 Aug 2016 09:21:22 -0700
> "H. S. Teoh" <hst...@quickfur.ath.cx> wrote:
> 
> > global = {
> > \tempo "Allegro" 4 = 120
> > s1*16
> > \mark "A"
> > s1*16
> > \tempo "Largo" 4 = 45
> > s1*16
> > \mark "B"
> > s1*32
> > ... % etc.
> > }
> 
> Now if this would work with repeats and midi...
[...]

For midi, I generally recommend making a separate score dedicated for
midi, that's apart from the layout score. What I usually do is something
along these lines:

fluteIPart = { ... }
fluteIIPart = { ... }
oboeIPart = { ... }
oboeIIPart = { ... }
...

% Score for layout only
\score {
<<
\new ScoreMarks { \global }
\new StaffGroup <<
\new Staff {
\partcombine \fluteIPart \fluteIIPart
}
\new Staff {
\partcombine \oboeIPart \oboeIIPart
}
... % etc.
>>
...
>>
\layout {}
}

% Score for midi only
\score {
<<
\new Staff << \global \fluteIPart >>
\new Staff << \global \fluteIIPart >>
\new Staff << \global \oboeIPart >>
\new Staff << \global \oboeIIPart >>
... % etc.
>>
\midi {}
}


T

-- 
Try to keep an open mind, but not so open your brain falls out. -- theboz

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: rehearsal marks: separate from content encoding and display above strings

[H. S. Teoh]

On Fri, Aug 12, 2016 at 04:29:41PM +0100, Mark Knoop wrote:
[...]
> However I have just submitted a potential fix for this, see here
> https://codereview.appspot.com/308910043/ for its progress.
[...]

Thanks so much for doing this!! Looking forward to when I can have
ScoreMarks show up properly in frenched scores.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: rehearsal marks: separate from content encoding and display above strings

[H. S. Teoh]

On Fri, Aug 12, 2016 at 04:30:01PM +0200, Thomas Weber wrote:
> There are two things about rehearsal marks in orchestral scores I'd
> like to know about.
> 
> Firstly, how can I separate rehearsal marks (and other structural
> stuff like \break or \pageBreak) from the actual musical content?  Can
> I somehow add a virtual staff to carry the rehearsal mark information?
> I think I remember seeing something like that before, but I can't seem
> to find any documentation about it.
> 
> Secondly, how can I make rehearsal marks appear both on the very top
> staff and the top staff of the strings?  As far as I can see,
> rehearsal marks will always be put at the very top staff.
[...]

I use the attached file for this purpose, which is based on code that
Kieran MacMillan gave me. Here's an example usage:

\include "scoremarks.ly"

% Put your score markings here, rather than in the instrument
% parts.
global = {
\tempo "Allegro" 4 = 120
s1*16
\mark "A"
s1*16
\tempo "Largo" 4 = 45
s1*16
\mark "B"
s1*32
... % etc.
}

\score {
<<
% Basically, place ScoreMarks wherever you want
% the markings to appear in the score.
\new ScoreMarks { \global }
\new StaffGroup <<
% wind section music goes here
>>
\new StaffGroup <<
% brass section music goes here
>>
\new ScoreMarks { \global }
\new StaffGroup <<
% string section music goes here
>>
>>
\layout {}
}


T

-- 
A linguistics professor was lecturing to his class one day. "In English," he 
said, "A double negative forms a positive. In some languages, though, such as 
Russian, a double negative is still a negative. However, there is no language 
wherein a double positive can form a negative." A voice from the back of the 
room piped up, "Yeah, yeah."
\version "2.18.2"

% Make it possible to put tempo markings over multiple StaffGroups
% automatically. Credit: Kieran MacMillan.
\layout {
\context {
\type "Engraver_group"
\name ScoreMarks
\consists "Staff_collecting_engraver"
\consists "Axis_group_engraver"
\override VerticalAxisGroup.staff-affinity = #DOWN
\consists "Mark_engraver"
\consists "Time_signature_engraver"
\override TimeSignature.stencil = #point-stencil
\consists "Metronome_mark_engraver"

% Padding above ScoreMarks context
\override VerticalAxisGroup.nonstaff-unrelatedstaff-spacing.padding = #3

% Padding below ScoreMarks context
\override VerticalAxisGroup.nonstaff-relatedstaff-spacing.padding = #0.6
}
\context {
\Score
\numericTimeSignature 
\remove "Mark_engraver"
\remove "Metronome_mark_engraver"
\accepts ScoreMarks
}
}

% vim:ai ts=4 sw=4 et:
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Generating music expressions from within \applyContext?

[H. S. Teoh]

On Tue, Jul 26, 2016 at 11:38:48PM +0200, David Kastrup wrote:
[...]
> But semi-continuous controller changes in Midi don't make sense to
> require actual iteration by LilyPond.  Instead this should be made a
> feature of the Midi backend.
> 
> I don't see a feasible way to do that in the current state of LilyPond
> by mere Scheme programming.
[...]

Understood. I'm actually a C/C++ programmer by trade, and I don't mind
hacking the C++ code in LilyPond if need be. It's just that the midi
backend seems very scantily documented, and the few times I've tried I
couldn't figure out exactly how it works. Well, I suppose if I spent
enough time on it I'd get it, but it would be nice if somebody who
understands the organization of the code could provide some pointers on
where things are and a quick overview of how various pieces connect.

My dream is to enhance the midi backend to support single note
cresc/decresc just by setting a Staff property. (Would such a patch be
accepted into the official code base?) But right now that dream seems
still rather distant.


T

-- 
Не дорог подарок, дорога любовь.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Generating music expressions from within \applyContext?

[H. S. Teoh]

On Wed, Jul 27, 2016 at 09:47:53AM +0300, Heikki Tauriainen wrote:
[...]
> I also gave up on my attempts to try and understand how to make use of
> \applyContext back then, after I found the crude workaround of making
> use of additional global variables to access the dynamic equalizer
> function, and the maximum and minimum expression levels from within
> the music function.  (I think the inspiration for this came from the
> implementation of the \articulate function, which uses a number of
> such variables for controlling the behavior of the function - by
> changing the values of the variables between \articulate invocations,
> the function can be made to work differently between invocations
> without the need to specify extra function arguments.)

Wow.  Thanks so much for the code!  I'll definitely take a look at it
once I finish my current project (which is at too advanced of a stage to
introducing a whole new way of writing things at this point).  The idea
of using global variables ala articulate.ly did occur to me, but I never
thought to pursue the idea.


> At the risk making a fool out of myself by letting the Scheme experts
> tear this example code to shreds, I'll attach the workaround code
> (which I've tried to clean up a bit from my local stuff without much
> testing, it could contain bugs) here.
[...]

Haha, I'm pretty sure my own Scheme code is just as atrocious, if not
more, but the important thing is that it does what it's supposed to. :-)


T

-- 
If it tastes good, it's probably bad for you.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Generating music expressions from within \applyContext?

[H. S. Teoh]

On Tue, Jul 26, 2016 at 09:48:36AM +0200, David Kastrup wrote:
> "H. S. Teoh" <hst...@quickfur.ath.cx> writes:
[...]
> > The background of this is that I'm writing a Scheme function that
> > generates single-note crescendos by emitting a series of \set
> > Staff.midiExpression = ... events.
> 
> Oh, but that's perfectly manageable with \applyContext.  Don't
> generate any events, just call ly:context-set-property! directly.  If
> you don't want to find Staff yourself, you can just write
> 
> \context Staff \applyContext (lambda ...
> 
> and then the context passed to the applyContext function will already
> be a Staff context.

Sound good, but how do I set the property at evenly-spaced time
intervals from inside the lambda?

The main problem I'm having is that the number of intervals will differ
depending on the volume levels of the given dynamics. Since the MIDI
expression controller only has 127 discrete volume levels, if I'm going
from 0 to 127 then I'd need 127 property changes, but if I'm going from
64 to 96 I only need 32 property changes.  But I wouldn't know this
until the \applyContext lambda is called. How do I insert property
changes at regularly-spaced intervals from inside the lambda?


[...]
> So far it does not sound like you want anything returned rather than
> setting some properties.
[...]

True, so perhaps there is a way after all.  It's just that so far I've
only really worked with music expressions and grobs when it comes to
Scheme, and haven't quite figured out what happens to these objects
afterwards. :-P


T

-- 
If Java had true garbage collection, most programs would delete themselves upon 
execution. -- Robert Sewell

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Generating music expressions from within \applyContext?

[H. S. Teoh]

Hi,

I have a Scheme function that returns a music expression. Unfortunately,
the expression returned depends on the properties of the context it's
evaluated in. I.e., based on the current setting of
Staff.dynamicAbsoluteVolumeFunction it will return a different number of
events in the music expression.

Is this possible?

The background of this is that I'm writing a Scheme function that
generates single-note crescendos by emitting a series of \set
Staff.midiExpression = ... events. Currently I've written a Scheme
function that's able to generate these events; however, it requires me
to specify numerical starting / ending values for midiExpression. I'd
like to be able to specify dynamics instead of numerical values, and
have the Scheme function automatically look up the numerical values
based on the current volume function defined for the Staff.

However, so far I haven't been able to figure out how to read the Staff
properties except using \applyContext with a lambda, and AFAICT it's not
possible to return a music expression from this lambda?

Or is there another (hopefully simpler?) way to achieve what I want?


--T

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: \keepWithTag #'A {\keepWithTag #'B \music}

[H. S. Teoh]

On Sun, May 08, 2016 at 05:13:31PM -0500, David Wright wrote:
> On Sat 07 May 2016 at 10:42:43 (+0200), Gianmaria Lari wrote:
> > Dear David thank you for explaining the problem and pointing me out
> > the documentation where this is discussed.
> > 
> > Yes, I could organize my code differently but this would be less
> > clear. Try to have a look to the attached image capture.png.
> > The first line is the wanted screen output, the second line the wanted
> > midi output  (that is normally not intended to print).
> > Now let me discuss how I would like to obtain it.
> 
> AIUI there are three ways of achieving what you want:
> 1) reverse the logic, as you have done here,
> 2) use lists in keepWithTag so that you don't nest them,
> 3) use tag groups.

Use \removeWithTag to remove unwanted tags.


> If you want to structure your music as you wish, then you can't use
> (2).  So that leaves you option (3).
> 
> BTW what does markup do to the midi output that you don't like?
[...]

I'm not the OP, but in my own scores I often find myself fighting with
the default midi output if I try to use the same score for layout.  The
best approach that has worked for me so far is to put all actual musical
content in variables, e.g., fluteI = \relative c' { ...}, fluteII = ...,
clarinetI = ..., etc., then have two scores, one that creates all the
elaborate bracketing structures needed in an orchestral score, including
using \partcombine and so forth, and the other midi-only score that just
has one voice per (midi) staff.

Things like \trill are rarely interpreted to my liking in the midi
output, so I'd usually write \tag #'layout { c1\trill }, then spell out
the trill as a tuplet in a \tag #'midi {...} block.  This is just one of
many things I've encountered.

Another off the top of my head is writing tremolo passages, where my
soundfont has a dedicated tremolo "instrument" that takes whole notes
and plays them tremolo, whereas for layout I'd use \repeat tremolo with
the 32nd notes.

Dynamics also sometimes go missing in midi output, esp. in piano music
where there are lots of transitory voices which seem to just default to
the default dynamic instead of inheriting from the parent voice. These
are hacked using things like c1-\tag #'midi -\pp so that the voice gets
the right dynamic in midi, but the extraneous dynamic doesn't show up in
the score.

Using \partcombine is one big reason for separating layout score from
midi score, because it often does all sorts of strange things to the
midi output, plus it doesn't work very well when two different
instruments are sharing the same staff in a large orchestral score.
There *is* an option for making MIDI per-voice rather than per-staff,
but since midi needs so many hacks to be tolerable anyway, might as well
just separate the two.


T

-- 
Life would be easier if I had the source code. -- YHL

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: midi articulation

[H. S. Teoh]

On Wed, Mar 23, 2016 at 05:21:13PM +, Daniel Birns wrote:
> Hi all,
> 
> Okay, I see what articulate.ly does. However… has anyone tried to do
> this within the midi generator. I debugged the python_midi.c file, and
> I can see what it’s doing. Geez, it seems like at the point where the
> midi file is being generated, lilypond ought to know everything about
> what’s the score, and ought to be able to apply articulation easily
> and much more correctly at that point.
> 
> Has anyone tried doing this? My guess is it’s nowhere near as easy as
> I think it should be. But, honestly, the midi files suck. As a
> Sibelius user, this is a showstopper — Sibelius does a beautiful job
> at this, and it seems like it shouldn’t be difficult for lilypond to
> do the same.
> 
> I’m a software developer — not python, nor guile , but just about
> everything else, but especially C++. I could do guile and python if
> needed. Perhaps I should try this, but is there interest? Do I have
> time for this? And why haven’t the others who know a great deal more
> about this than I do, done this?
> 
> Thanks. No criticism at all intended: I think lilypond is amazing. 
[...]

As far as I understand it (and I could be wrong), lilypond's original
authors did not regard midi support as important, as lilypond's original
mission was to typeset music and do it well.  So the original midi
support was tacked on as an afterthought and was pretty rudimentary, and
as far as I can tell, hasn't changed very much since then.  This was
probably one of the main reasons articulate.ly was invented in the first
place.

Be that as it may, I for one thing would be glad if somebody would take
the time to improve midi generation so that it's not so atrocious.  My
ideal conception of it is to have some kind of mapping mechanism for
translating notation into midi that offers the same configurability and
expressive power as the notation syntax itself, such that the user would
be able to, for example, specify how phrases should be rendered, whether
a particular Staff should emit Expression events for crescendos or
merely increment the velocity of the notes (as is currently done,
piano-style), how to translate breathing marks, or any mark, for that
matter (e.g., trill mark on a timpani Staff should emit tremolos or
switch to a different program for rolls).  The defaults ought to produce
pretty decent midi, but should be overridable by the user.

In any case, midi itself is rather limited, as the built-in limit of 16
channels is too restrictive for rendering large orchestral scores. For
this purpose I have written an auxiliary helper program that renders
individual StaffGroup's into separate midi files, to be separately
rendered by a software midi synth and then mixed into a single file
afterwards.  The program also generates suitable MIDI program switching
macros for implementing different articulations. Such functionality is
probably beyond the scope of lilypond, though conceivably one could
implement the necessary infrastructure for the user to be able to do
such things within lilypond itself, as opposed to resorting to external
tools.


T

-- 
"How are you doing?" "Doing what?"

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Rhythm details

[H. S. Teoh]

On Wed, Mar 16, 2016 at 02:49:41PM +, Alberto Simões wrote:
> hi
> 
> I am trying to find how to typeset the rhythm in attach, but given I do not
> know what is its name (neither in Portuguese, English or Italian or any
> other language) it is getting difficult to find how to do it.
> 
> Can anybody please let me know how this is called and, if you know, where in
> the documentation I can find how to typeset it?
[...]

I believe that's called a tremolo, and you can find the documentation
for it here:


http://lilypond.org/doc/v2.18/Documentation/notation/short-repeats#tremolo-repeats

Hope that helps!


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It 
is the customer who pays the wages. -- Henry Ford

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: grace note duration

[H. S. Teoh]

On Tue, Feb 23, 2016 at 03:22:11PM +0100, Gianmaria Lari wrote:
> Hello,
> 
> I have the following source
> 
>   g8 \grace {e16 f16} e8 d8
> 
> In the resulting midi output (using articulate.ly) the grace notes are
> played too quick (1/64?) and they are almost not audible. Is there any
> way to increase their duration?
[...]

Try:

#(define ac:defaultGraceFactor 1/16)

(Change 1/2 to whatever other fraction, according to what you need.)

Note that this only works if you're using articulate.ly, which is
probably a good idea anyway if you're generating midi, since the default
midi output isn't very good.


T

-- 
Perhaps the most widespread illusion is that if we were in power we would 
behave very differently from those who now hold it---when, in truth, in order 
to get power we would have to become very much like them. -- Unknown

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Repeat 8va

[H. S. Teoh]

On Fri, Jan 08, 2016 at 04:16:15PM -0600, Christopher R. Maden wrote:
> On 01/08/2016 04:08 PM, John Gourlay wrote:
> >As an exercise in learning to use LilyPond I’m engraving “The
> >Entertainer” by Scott Joplin. In the old published version I’m
> >working from (1902), the score looks like this at measure 22:
> >
> >I’m concerned about the “Repeat 8va”, which I assume means that on
> >the second repetition of this section it should be played an octave
> >higher than the first time. Do you know how to make this happen in
> >LilyPond? I can easily make the LilyPond output simply say “Repeat
> >8va”, but I’d really like LilyPond to know about the octave change,
> >so the midi output of the second repetition is played in the correct
> >octave.
> 
> Generally, once you get into any kind of moderately complicated score,
> you have to concoct your score and MIDI separately, e.g.:
> 
> theTune = c c c c
> 
> theScore = \repeat volta 2 { \theTune }
> 
> theMidi = \theTune \transpose c c' \theTune
> 
> \score{ \theScore \layout{} }
> 
> \score{ \theMidi \midi{} }
> 
> I like to use \articulate in the MIDI block, too, for instance.
[...]

Agreed. Once you get past a certain level of complexity, trying to use
the same score for both layout & midi is an exercise in pain. Almost all
of my scores start out with just a single score block, and end up
needing a separate midi score just so I can do things with the midi that
I don't want represented in the printed score.


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal 
lovers in dire need of being reminded to profess their hypothetical love for 
their long-forgotten.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Repeat 8va

[H. S. Teoh]

On Sat, Jan 09, 2016 at 12:11:48AM -0600, msk...@ansuz.sooke.bc.ca wrote:
> On Fri, 8 Jan 2016, Christopher R. Maden wrote:
> > Generally, once you get into any kind of moderately complicated
> > score, you have to concoct your score and MIDI separately, e.g.:
> >
> > theTune = c c c c
> > theScore = \repeat volta 2 { \theTune }
> > theMidi = \theTune \transpose c c' \theTune
> > \score{ \theScore \layout{} }
> > \score{ \theMidi \midi{} }
> 
> This is pretty much exactly what I do for a similar instruction in an
> original ragtime piece.
> 
> It's a shame that LilyPond's requirement to completely evaluate music
> expressions immediately, and therefore once and for all, forces this
> kind of thing on us.  The natural thing to want to do would be to have
> an "if (MIDI) { }" kind of construction at the point in the music
> where there's a difference; but that's simply impossible the way
> LilyPond currently works.  And so anyone who wants both a printed
> score and MIDI is forced to write the whole thing twice over,
> attempting to keep the two versons updated relative to each other by
> hand, with the ability to share code only at the lowest levels of the
> hierarchy.
[...]

This is not really true. What I usually do is something like this:

music = <<
\new Staff {
a1 b c
\tag #'midi { a8 r b r c r }
\tag #'layout { a4-. b-. c-. }
}
>>

\score {
\removeWithTag #'midi \music
\layout {}
}
\score {
\removeWithTag #'layout \music
\midi {}
}

The \tag #'layout and \tag #'midi lines basically behave like an if
(MIDI) block. This lets you intersperse layout-specific and
midi-specific stuff in the same place, so that you don't forget to
update one after editing the other.


T

-- 
The richest man is not he who has the most, but he who needs the least.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Where to look up explanation of syntax

[H. S. Teoh]

On Fri, Jan 08, 2016 at 06:30:21PM -0500, Joseph N. Srednicki wrote:
[...]
> I searched, but I cannot locate the appropriate location the in the
> Lilypond documentation that explains the "*5/6" syntax.
> 
> Can someone point me to this documentation?

http://www.lilypond.org/doc/v2.19/Documentation/notation/writing-rhythms#scaling-durations


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Variable names

[H. S. Teoh]

On Thu, Jan 07, 2016 at 08:59:22PM +0100, Johan Vromans wrote:
> I assume there have been discussions on extending the syntax for LP
> identifiers to include dashes and underscores. My personal opinion is
> that a non-alpha separator is good to have, but two different
> separators may quickly become confusing. Is it 'set_variable' or
> 'set-variable'?
> 
> Given the relation between LP and Guile, I'd suggest to only allow the
> dash and disallow the underscore (by syntax rule, not just by
> convention).
[...]

I think extending identifiers to include '-' and '_' is a bad idea. They
introduce ambiguities in cases like:

c1\myCustomMarkup_"text"-\pp-\moreCustomMarkup-.


T

-- 
Customer support: the art of getting your clients to pay for your own 
incompetence.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: articulate.ly and trills

[H. S. Teoh]

On Fri, Nov 27, 2015 at 05:32:37PM -0700, Gilberto Agostinho wrote:
> Hello all,
> 
> I would like to ask if anyone knows how to control the speed of the trills
> in the MIDI output when using articulate.ly. Currently, the articulate.ly
> simply converts a note with a trill into a bunch of 32nd notes, regardless
> of the tempo of the piece. This works very well for slow tempi (< 60 bpm),
> but sounds terrible when the tempo gets faster. E.g.:

I would like to know as well. Currently, I use a workaround by
separating the layout and midi scores, and use \tag to explicitly spell
out trills:

music = {
\tag #'layout { g1\startTrillSpan g1\stopTrillSpan }
\tag #'midi {
\tuplet 21/16 {
\repeat unfold 10 { g16 a }
g16
}
g1
}
}
\score {
\music
\layout {}
}
\score {
\music
\midi {}
}

This is rather ugly, and prone to errors (e.g. you accidentally write
the wrong notes in the \tag #'midi section so what is played is not
what's printed in the score). But it does let you insert things in the
"midi score" that improves the midi rendering, without polluting the
printed score.


T

-- 
Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: LilyPond-aware text editors

[H. S. Teoh]

On Mon, Nov 09, 2015 at 04:12:54PM -0700, zzk wrote:
> Flaming Hakama by Elaine wrote
> > Interestingly (perhaps only to me), the only other place I feel like
> > I took a step backward in changing editors is that the (in-file)
> > find/replace mechanisms in sublime text are clunkier, especially
> > since you can't use them macros.
> > 
> > I rather prefer emacs' M-x query replace or M-x replace-string to
> > the sublime text approach of multiple selection.
> 
> I agree with your point that emacs' replace capabilities look more
> powerful.  However, at this stage, it would be an overkill for me, as
> I am not a heavy text editor user. 
> 
> I guess, it is great that we have so many options today (with a number
> of open source apps). 
[...]

I wasn't sure if this would constitute a meaningful data point, but I do
use Lilypond extensively and only ever use vim (without syntax
highlighting). For the most part, navigation is no problem for me as I
use a very specific formatting, with comment markers indicating
different sections of a piece, so even in a full orchestral score it's
still usable to keep all the parts in a single file. (Layout specific
details like \layout and \paper blocks, macro definitions, and other
necessary boilerplate, are kept in different files, though, to minimize
distraction from the actual music.)


T

-- 
Written on the window of a clothing store: No shirt, no shoes, no service.

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Cadenza... in the MIDI

[H. S. Teoh]

On Thu, Nov 05, 2015 at 09:00:26PM +, Alberto Simões wrote:
> Hello
> 
> Probably this is in the manual, but I did not find it.
> 
> Is it possible to change the tempo (playing speed) in a specific zone
> of the music?
[...]

Usually what I do is to insert "invisible" \tempo marks to control midi
playback speed. Or more precisely, \tag them so that they are removed
from the typeset score, but included in the midi score. Something like
this:

myMusic = {
\tempo 4 = 120 % initial tempo
...
\tag #'midi \tempo 4 = 130 % tweak midi tempo
...
\tag #'midi \tempo 4 = 120 % set it back to "normal"
...
}

% Score for layout only
\score {
\removeWithTag #'midi \myMusic
\layout {}
}

% Score for midi only
\score {
\myMusic
\midi {}
}


T

-- 
Those who don't understand D are condemned to reinvent it, poorly. -- Daniel N

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user