Trevor Daniels wrote:
I do too. I wonder if it might be useful to discuss
and find a consensus on what the purpose of the NR is
in rather more detail? Here's a strawman specification
to knock about if people think a specification might
be useful to guide documentation writers in the future.
Hi, Michael:
I am a little confused on how to implement.
See example, below.
The important thing to observe is that the dynamics that should be
"in" both Staff contexts is only included in the upper Staff in the
ENGRAVING BLOCK (i.e., the \score block *without* a \midi block),
whereas i
Here is a reply from Kieren. I have some more questions
If you want dynamics that apply to both, then you could use three
identifiers:
dynamicsRH = { ... }
dynamicsBH = { ... }
dynamicsLH = { ... }
Then, in the .ly file,
1. In the \score (ENGRAVING) block, include the \dynamicsRH and \dynam
Op donderdag 8 november 2007, schreef Jeff Elliott:
> ragged-last-bottom = ##t
>
> Would that make a difference?
I think so, because Lilypond will then probably create more systems and
therefore make another arrangement of measures.
Met vriendelijke groet,
Wilbert Berendsen
--
http://www.wilbe
Mats Bengtsson wrote:
Graham Percival wrote:
However, that's one thing that I'm never going to tackle. If anybody
wants to attempt it, great! But the IR is officially out of bounds of
GDP.
Perhaps you can just send out a wish list, hoping that some Scheme hacker
finds it an interesting pr
Graham Percival wrote:
True. This problem is exacerbated by the fact that I have no clue how
the IR is constructed -- if I _did_ understand it, we could probably
make a few changes that would make the whole thing considerably easier
to read.
However, that's one thing that I'm never going t
Hi,
I think that Kieren had probably assumed I would put it in \layout{}
Yes -- your last few posts implied that you put most tweaks there...
I suppose that it would work with just BarLine if it were
placed inside the \layout block after \context { \Score ...
Correct!
Best regards,
Kieren
Mats Bengtsson wrote:
> Sorry, I was just confused when I wrote my previous answer.
> Also, I hadn't actually tried any example in LilyPond. If you do,
> you will soon realize that:
>
> - None of the commands given below do anything useful, since you have to
> replace BarLine by Score.BarLine.
Mats Bengtsson wrote:
Graham Percival wrote:
NR is a reference to look stuff up; LM is for learning the material
in the first place.
Agreed! However, what's special with LilyPond is that it's three
levels, not two. Often for me, the IR is the real reference to look
stuff up. The division betw
Graham Percival wrote:
Yes, with one quirk: the LM/NR division.
The current "changing defaults" doesn't make anybody happy. It's too
verbose for programmers (or people who are already familiar with it,
but can't remember certain details), but much too short for first-time
readers. So we'r
Graham Percival wrote on 08 November 2007 12:26
>
> Trevor Daniels wrote:
> >> Actually, \fatText _is_ simply an arcane override
> >> > -- but one which the
> >> > developers thought was so common that they
> >> > included a predefined
> >> > variable.
> >
> > The difference exactly. Tha
Mats Bengtsson wrote:
Isn't the main points of this discussion that: - Predefined commands
like \fatText should be described in the NR. Even if the
implementation of it might change over the years, the semantics will
remain the same.
Yes. "\fatText: pushes the next note to the right to allow
Sorry, I was just confused when I wrote my previous answer.
Also, I hadn't actually tried any example in LilyPond. If you do,
you will soon realize that:
- None of the commands given below do anything useful, since you have to
replace BarLine by Score.BarLine.
- The construct
\override Score.Ba
Graham Percival wrote:
Internals Reference: defines the "under the hood" lilypond stuff.
Which doesn't really make sense, since you have to look under the hood
every time you want to make a property setting.
Err, remember that the Program Reference is now the IR. The NR will
describe ho
Isn't the main points of this discussion that:
- Predefined commands like \fatText should be described in the NR.
Even if the implementation of it might change over the years, the
semantics
will remain the same.
- Somewhere in the NR, it should be described how an advanced user
can find the e
Mats Bengtsson ee.kth.se> writes:
> Wilbert Berendsen wrote:
> > Op woensdag 7 november 2007, schreef Kieren MacMillan:
> >
> >> \override BarLine #'space-alist #'next-note = #'(semi-fixed-space . 1.2)
> >
> > \override BarLine #'space-alist #'next-note #'semi-fixed-space = 1.2
> >
> It's n
Trevor Daniels wrote:
Actually, \fatText _is_ simply an arcane override
> -- but one which the
> developers thought was so common that they
> included a predefined
> variable.
The difference exactly. That's why I think this
predefined variable should be in the main text.
No, absolutel
Charles Gran campdeadly.com> writes:
> What I am hoping to do is divide a chorale
> piece into four files one for each part, so that when I am working on
> a part I can run that part only. I'm just trying to speed up the run
> process.
>
You can find an excellent example of separating part
Mats Bengtsson wrote:
Graham Percival wrote:
The strong editorial decision from a few months ago is this:
Notation Reference: defines the lilypond input syntax.
>
I think it describes a lot more than just the syntax.
Sorry, I was misusing a word again -- I didn't mean "syntax". I shoul
I would recommend you to first try yourself to reduce it to a
small example that illustrates the same problem. You might
even find the solution yourself during that process.
/Mats
vwf wrote:
Hello,
I have a problem with a kind of meo-mensural style. The source used to
work with an old versi
Graham Percival wrote 07 November 2007 16:29
>
> Ok, I was convinced that some reorg was better.
>
> Educational -> Editorial annotations
> Note heads -> 1.1 Pitches
> 1.3.3 Analysis brackets -> Editorial
>
> Take a look at it and let me know what you think.
> Docs in the usual GDP
> place.
>
Mats Bengtsson wrote
>
> Graham Percival wrote:
> >
> > The strong editorial decision from a few months
> ago is this:
> >
> > Notation Reference: defines the lilypond input syntax.
> I think it describes a lot more than just the syntax.
>
>/Mats
>
I do too. I wonder if it might be useful to
Hello,
I have a problem with a kind of meo-mensural style. The source used to
work with an old version of lilypond. I'm in the process of converting
it for LilyPond 2.10.25, but I cannot get it right:
the first two notes of the melody appear with modern noteheads, and from
the third one onwards
Goto www.lilypond.org -> Documentation -> Doc for your version of
LilyPond ->
User manual -> LilyPond index
and look for "include".
/Mats
Charles Gran wrote:
I'm pretty sure that I read somewhere that you can include lily files
in other lily files. What I am hoping to do is divide a chorale
Wilbert Berendsen wrote:
Op woensdag 7 november 2007, schreef Kieren MacMillan:
\override BarLine #'space-alist #'next-note = #'(semi-fixed-space . 1.2)
Just a question to improve my Lily understanding: Can this also be written as:
\override BarLine #'space-alist #'next-note #'semi-
Graham Percival wrote:
The strong editorial decision from a few months ago is this:
Notation Reference: defines the lilypond input syntax.
I think it describes a lot more than just the syntax.
Application Usage: how to compile the syntax, how to convert to/from
the syntax (including old v
26 matches
Mail list logo