Re: GDP: NR Specification

[Graham Percival]

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.


Let do this in a slightly different manner.  Here's what the policy
current says:

* Notation Reference: a (hopefully complete) description of
  LilyPond input notation.  Some material from here may be
  duplicated in the Learning Manual (for teaching).  The material is
  presented in an approximate order of increasing difficulty, but
  the goal is _not_ to provide a step-by-step learning environment.
  For example, all material under "Pitches" should remain in that
  section, even though microtonal accidentals may seem more advanced
  than info about clefs or time signatures -- "Pitches" should be a
  one-stop reference about the pitch portion of notes.  This section
  is written in formal technical writing style.

Users are not expected to read this manual from start to finish.
However, they should be familiar with the material in the Learning
Manual (particularly ``Fundamental Concepts''), so do not repeat
that material in this book.  Also, you should assume that users
know what the notation means; explaining musical concepts happens
in the Music Glossary.



Based on the recent discussions, what should change in the written policy?

Cheers,
- Graham



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

Re: piano staff dynamics

[Kieren MacMillan]

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 it's included in both Staff contexts in the MIDI/PERFORMANCE  
BLOCK (i.e., the \score block *with* a \midi block).


As I said, there may be a better way of doing the same thing... this  
was all off the top of my head.  =)


Hope this helps!
Kieren.
___

\version "2.11.33"

pianoMusicRH = \relative
{
\clef treble
c' d e f |
e d c2 |
}
pianoMusicLH = \relative
{
\clef bass
c2 f, |
g2 c, |
}

dynamicsRH =
{
s2 s4^\p s4^\pp |
s1 |
}
dynamicsBH =
{
s1 |
s1_\sfz |
}
dynamicsLH =
{
\dynamicDown
s4\f s2. |
s2 s2\ppp |
}

%%  ENGRAVING BLOCK
\score
{
\context PianoStaff
<<
\context Staff = "upper" << \pianoMusicRH \dynamicsRH \dynamicsBH 
>>
\context Staff = "lower" << \pianoMusicLH \dynamicsLH >>
>>
}

%% MIDI/PERFORMANCE BLOCK
\score
{
\context PianoStaff
<<
\context Staff = "upper" << \pianoMusicRH \dynamicsRH \dynamicsBH 
>>
\context Staff = "lower" << \pianoMusicLH \dynamicsLH \dynamicsBH 
>>
>>
\midi {}
}


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

piano staff dynamics

[Michael Listrom]

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 \dynamicsBH
in the right-hand Staff context, and the \dynamicsLH in the left-hand Staff
context; and,
 2. In the \midi (PERFORMANCE) block, include the \dynamicsRH and
\dynamicsBH in the right-hand Staff context, and the \dynamicsLH and
\dynamicsBH in the left-hand Staff context.

 There might be a better way -- this is just off the top of my head...


 Hope this helps!
Kieren.

I am a little confused on how to implement.
Do I apply the dynamicsRH = {} with the dynamic markings inside the
brackets, and does that information go in the lilypond file itself? Where is
my music notation in all of this? And what does dynamicsBH stand for?
Regards,
Michael
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Simple? Stretch a couple of measures.

[Wilbert Berendsen]

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.wilbertberendsen.nl/
"You must be the change you wish to see in the world."
-- Mahatma Gandi


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

Re: GDP predefined commands

[Graham Percival]

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 project.


I'm not optimistic -- there's a bunch of much easier items on the 
technical-todo list.  But I've added this anyway; maybe in a few years, 
somebody will pick it up.


Cheers,
- Graham


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

Re: GDP predefined commands

[Mats Bengtsson]

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 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 project.

  /Mats


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

Re: minimum after-BarLine space in 2.11

[Kieren MacMillan]

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.


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

Re: minimum after-BarLine space in 2.11

[Monk Panteleimon]

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.
> 

When I added the "Score." context-indicator (?) to Kieren's
original suggestion, it had the intended result. I think that Kieren
had probably assumed I would put it in \layout{} but I wasn't doing
that, so I added "Score." and it worked. 
Here's the tweak in full for inside \score{{}} :

\override Score.Barline #'space-alist #'next-note = 
#'(semi-fixed-space . 1.2)


I suppose that it would work with just BarLine if it were
placed inside the \layout block after \context { \Score ...

Right?
-- 
Monk Panteleimon
Hermitage of the Holy Cross
Wayne, WV, USA
[EMAIL PROTECTED]

+
 IC + XC
+ + + + +
 NI + KA
+


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

Re: GDP predefined commands

[Graham Percival]

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 between NR and IR is obvious for you and me,
who know that the IR is the autogenerated stuff.


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 to tackle.  If anybody 
wants to attempt it, great!  But the IR is officially out of bounds of GDP.


Cheers,
- Graham


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

Re: GDP predefined commands

[Mats Bengtsson]

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're going to compact that chapter in the NR, and expand 
the relevant chapter in the LM.


By analogy, consider the man pages in unix.  If you've never used a 
command before -- say, git :)  -- then the man pages are useless.  You 
can't learn how to use git just from reading the man pages.  You need 
to read a tutorial, web pages, etc.


OTOH, if you're already familiar with the basic concepts, and just 
can't remember if you want

git-diff -M --cached
or
git-diff -B HEAD
then the man pages are great.

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 between
NR and IR is obvious for you and me, who know that the IR is the 
autogenerated
stuff. However, there's some information, in particular hidden in some 
interface

descriptions, that could just as well have been in the NR.
Again, I don't argue againts the current division, I'm just pointing out 
the fact that

this three level division is fairly uncommon compared to many other programs
and may not seem that obvious to new users.

   /Mats


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

RE: GDP predefined commands (was: text first draft)

[Trevor Daniels]

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.  That's why I think this
> > predefined variable should be in the main text.
> 
> No, absolutely not.  That would be the *worst* 
> possible thing to do.
> (below)
>
I think we have misunderstood each other.  I said: 
> > 
> > I agree entirely. A ref to the explanation is 
> > all that is required.
> 
In other words say what \fattext _does_ in the main
text but do not mention how it does it.  Most people
don't care _how_ it works, but most people will
certainly need to _use_ it at some time.  Perhaps
I misunderstood you, but I took your earlier note
to mean the command should be relegated to @commonprop.
I'm saying it should be in the main text, but without
any explanation of the underlying mechanism anywhere
in the NR - just a ref to the source code.  That needs
less effort, not more.

> Cheers,
> - Graham
> 



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

Re: GDP predefined commands

[Graham Percival]

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 the complete
piece of markup to be printed before that note."   (or whatever -- that
description was badly worded and possibly incorrect; I can't remember
what it does)

- Somewhere in the NR, it should be described how an advanced user 
can find the exact implementation of these predefined commands, in

case he/she wants to do something similar but on another object, for
example.

>

- On the other hand, the exact definition should not be
copied verbatim into the NR (perhaps with the exception of one single
example in the description mentioned in the previous item), since as
Graham points out, the information may easily get outdated.


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're going to compact that chapter in the NR, and expand 
the relevant chapter in the LM.


By analogy, consider the man pages in unix.  If you've never used a 
command before -- say, git :)  -- then the man pages are useless.  You 
can't learn how to use git just from reading the man pages.  You need to 
read a tutorial, web pages, etc.


OTOH, if you're already familiar with the basic concepts, and just can't 
remember if you want

git-diff -M --cached
or
git-diff -B HEAD
then the man pages are great.

NR is a reference to look stuff up; LM is for learning the material in 
the first place.


Cheers,
- Graham


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

Re: minimum after-BarLine space in 2.11

[Mats Bengtsson]

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.BarLine #'space-alist #'next-note #'semi-fixed-space = 1.2
 does not work and results in an error message. The reason, I think, is 
that
 this setting just adds a new entry to the alist and LilyPond gets 
confused when

 it finds two different settings for next-note in the space-alist.

  /Mats

Carl Sorensen wrote:

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 not equivalent to Kieren's answer, but it's much better, since it 
keeps all the

other settings of the space-alist for BarLine objects.




According to my (somewhat limited) understanding, I believe that both constructs
keep the rest of the space-alist settings.  The first construct would set the
next note property to '(semi-fixed-space . 1.2) and eliminate any other elements
in the next-note property, if they exist.  The second construct would update
only the semi-fixed-space element of the next-note property, retaining any other
values that might exist.

Is my understanding incorrect?

My mental model is that 


\override ItemHavingProperties #'foo #'bar #'baz #'frob = value

will set the frob property in the baz subchain of the bar subchain of the foo
alist-chain.

It would also be possible to  set

\override ItemHavingProperties #'foo #'bar #'baz = #'(frob . value)

but this will set the baz subchain value to (frob . value) and eliminate any
other items in the baz subchain.

If I'm wrong, please help me understand things.

Thanks,

Carl



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


--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
   Fax:   (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=



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

Re: GDP: renaming Program {usage, reference}

[Mats Bengtsson]

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 how to construct tweaks in a compact manner, the LM will 
describe how to construct tweaks in a legible manner, but finding out 
what the Voice #'padding property does (and what the default value 
is!) is only done in the IR.


(in this case, #'padding is used as examples in the LM and NR, so of 
course people will know about it -- but the actual place to find this 
info is the IR)


I agree completely on what you write here!
Funny, up to version 1.6 or so, it used to be called "LilyPond 
Internals", then it

changed to "Program Reference". Now we are almost back again.
I'm not convinced that "Internals Reference" is the best title, but 
let's not
spend too much effort on that discussion now and work on the contents 
instead.


  /Mats


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

Re: GDP predefined commands

[Mats Bengtsson]

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 exact implementation of these predefined commands, in case
 he/she wants to do something similar but on another object, for example.
- On the other hand, the exact definition should not be copied verbatim into
 the NR (perhaps with the exception of one single example in the 
description
 mentioned in the previous item), since as Graham points out, the 
information

 may easily get outdated.

  /Mats

Graham Percival wrote:



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, absolutely not.  That would be the *worst* possible thing to do.
(below)


Look in ly/propert-init.ly :

fatText = { \override TextScript  #'extra-spacing-width = #'(0 . 0)
 \override TextScript  #'infinite-spacing-height = ##t }

There was a proposal to explain this in every single @commonprop 
section, but I think it's better to include one GOOD explanation of 
this kind of thing in the LM.


I agree entirely. A ref to the explanation is all that is required.


Summary: "documentation is a process" and "we don't have the resources".

The exact definition of commands like \fatText changes.  I would be 
willing to bet money that \fatText will change at least once over the 
next five years.


If we discuss \fatText in the main docs (or in the @commonprop), then 
what happens when the definition changes?  either

1) the docs don't match the program.  (very bad!)  or
2) the docs need to be updated.

We don't have the resources to update the .tely files every time 
something changes.  We don't have the programmer resources to get them 
to do it, we don't have the documenter resources to find all these 
changes and update the appropriate places.  Would it be nice if we 
were overflowing with offers of help and could do this stuff?  Yes, 
totally.  But the lilypond community -- with a few notable exceptions, 
yourself included -- has not been willing to get involved in the 
development.


(I _will_ say that it's been getting better in the past year or so... 
but still nowhere enough help to make this feasible)



So how should users figure out what \fatText does exactly?  They read 
LM 4.2.1 and find ly/property-init.ly  on their own computer.  This 
file is *guaranteed* to be correct for their exact version of lilypond.


Documentation is a process, not a product.

(let's put this specific question to rest for a few days; I promise 
we will return to it)If you want to continue talking about this 
without any examplesN


Sorry, couldn't resist replying :)


At this point I'd like to state that LSR tags have been implemented 
and that we're 2 or 3 days away from having some useful examples to 
discuss, and it will be much easier to understand once you see an 
example.


Cheers,
- Graham


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


--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
   Fax:   (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=



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

Re: minimum after-BarLine space in 2.11

[Carl Sorensen]

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 not equivalent to Kieren's answer, but it's much better, since it 
> keeps all the
> other settings of the space-alist for BarLine objects.


According to my (somewhat limited) understanding, I believe that both constructs
keep the rest of the space-alist settings.  The first construct would set the
next note property to '(semi-fixed-space . 1.2) and eliminate any other elements
in the next-note property, if they exist.  The second construct would update
only the semi-fixed-space element of the next-note property, retaining any other
values that might exist.

Is my understanding incorrect?

My mental model is that 

\override ItemHavingProperties #'foo #'bar #'baz #'frob = value

will set the frob property in the baz subchain of the bar subchain of the foo
alist-chain.

It would also be possible to  set

\override ItemHavingProperties #'foo #'bar #'baz = #'(frob . value)

but this will set the baz subchain value to (frob . value) and eliminate any
other items in the baz subchain.

If I'm wrong, please help me understand things.

Thanks,

Carl



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

GDP predefined commands (was: text first draft)

[Graham Percival]

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, absolutely not.  That would be the *worst* possible thing to do.
(below)


Look in ly/propert-init.ly :

fatText = { \override TextScript  
#'extra-spacing-width = #'(0 . 0)
 \override TextScript  
#'infinite-spacing-height = ##t }


There was a proposal to explain this in every 
single @commonprop 
section, but I think it's better to include one 
GOOD explanation of this 
kind of thing in the LM.


I agree entirely. A ref to the explanation is 
all that is required.


Summary: "documentation is a process" and "we don't have the resources".

The exact definition of commands like \fatText changes.  I would be 
willing to bet money that \fatText will change at least once over the 
next five years.


If we discuss \fatText in the main docs (or in the @commonprop), then 
what happens when the definition changes?  either

1) the docs don't match the program.  (very bad!)  or
2) the docs need to be updated.

We don't have the resources to update the .tely files every time 
something changes.  We don't have the programmer resources to get them 
to do it, we don't have the documenter resources to find all these 
changes and update the appropriate places.  Would it be nice if we were 
overflowing with offers of help and could do this stuff?  Yes, totally. 
 But the lilypond community -- with a few notable exceptions, yourself 
included -- has not been willing to get involved in the development.


(I _will_ say that it's been getting better in the past year or so... 
but still nowhere enough help to make this feasible)



So how should users figure out what \fatText does exactly?  They read LM 
4.2.1 and find ly/property-init.ly  on their own computer.  This file is 
*guaranteed* to be correct for their exact version of lilypond.


Documentation is a process, not a product.

(let's put this specific question to rest for a 
few days; I promise we 
will return to it)If you want to continue talking about this without any examplesN


Sorry, couldn't resist replying :)


At this point I'd like to state that LSR tags have been implemented and 
that we're 2 or 3 days away from having some useful examples to discuss, 
and it will be much easier to understand once you see an example.


Cheers,
- Graham


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

Re: Importing ly files into a master file

[Carl Sorensen]

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 parts and printing out multiple
versions of the score on Mutopia. I noticed this one:




Carl Sorensen



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

Re: GDP: renaming Program {usage, reference}

[Graham Percival]

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 should 
have said "the lilypond input format".  Or even better,


How to write the text files that lilypond interprets.  Does not include 
complete details about properties, contexts, etc.



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 how to construct tweaks in a compact manner, the LM will 
describe how to construct tweaks in a legible manner, but finding out 
what the Voice #'padding property does (and what the default value is!) 
is only done in the IR.


(in this case, #'padding is used as examples in the LM and NR, so of 
course people will know about it -- but the actual place to find this 
info is the IR)


Cheers,
- Graham


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

Re: problem with neo-mensural style

[Mats Bengtsson]

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 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 I get the selected noteheads.

Who wants to look at my source to see what is wrong with it?

Fulko


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


--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
   Fax:   (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=



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

RE: educational first draft

[Trevor Daniels]

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.
>

Much, much better!
 
> Cheers,
> - Graham
> 
Trevor D
> 



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

GDP: LM Specification (was RE: GDP: renaming Program {usage, reference})

[Trevor Daniels]

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 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.

"The Notation Reference aims to provides accurate and
complete information (in several presentational formats) to
enable users to reproduce anything in a score found on their
bookshelves.  It assumes the user has mastered the concepts
introduced in the Learning Manual, particularly the way in
which a LilyPond score is structured, but does not rely on
the Learning Manual for any informational content.  The
primary purpose is to enable users to understand and modify
the statements in the templates to meet their needs, or to
construct their own scores from scratch.  As a reference
manual, the material is grouped logically into thematical
sections; unlike the Learning Manual it is not intended to
be read sequentially.  The purpose of every LilyPond command
is explained and demonstrated in a brief example to show its
syntax and effect.  Cross-references are provided to more
substantial examples which show the use of the commands in a
more realistic context, and to the technical descriptions of
the various cammands in the Internals Reference.  The manual
is indexed with both LilyPond and musical terms."

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




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

problem with neo-mensural style

[vwf]

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 I get the selected noteheads.

Who wants to look at my source to see what is wrong with it?

Fulko


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

Re: Importing ly files into a master file

[Mats Bengtsson]

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 
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.


Charles



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


--
=
Mats Bengtsson
Signal Processing
Signals, Sensors and Systems
Royal Institute of Technology
SE-100 44  STOCKHOLM
Sweden
Phone: (+46) 8 790 8463 
   Fax:   (+46) 8 790 7260
Email: [EMAIL PROTECTED]
WWW: http://www.s3.kth.se/~mabe
=



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

Re: minimum after-BarLine space in 2.11

[Mats Bengtsson]

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-fixed-space = 1.2
  
It's not equivalent to Kieren's answer, but it's much better, since it 
keeps all the
other settings of the space-alist for BarLine objects. On the other 
hand, it's an

undocumented feature that you can use this syntax in this situation.

 /Mats


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

Re: GDP: renaming Program {usage, reference}

[Mats Bengtsson]

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 versions), including the syntax in other 
programs, etc.


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.

Note: I'm not saying that I disagree on the currently proposed division 
into

separate manuals, just about your description of them.

  /Mats


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