Re: Does Forbid_line_break_engraver still work?

2008-08-14 Thread Han-Wen Nienhuys
On Thu, Aug 14, 2008 at 6:59 AM, Carl D. Sorensen <[EMAIL PROTECTED]> wrote:
> I'm trying to make a clear example for the GDP docs.
>
> According to my understanding, Forbid_line_break engraver should eliminate
> line breaks at measures where there is a tie generated by the
> Completion_heads_engraver.

It should not eliminate those, but it's easily imaginable that bugs
may have had this side effect in the past.



-- 
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen


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


Re: autobeams

2008-08-14 Thread Carl Sorensen
James E. Bailey  mac.com> writes:

> 
> I don't understand this. Why aren't the last two eighth notes beamed  
> together?
> \version "2.11.54"
> \relative { \clef bass << {e8 d d c d8 c } \\ {  4 g 4} >>  
>  } 
> 

I think the answer is found in a known issue in the beams section:

The same holds for polyphonic voices, entered with @code{<<
@dots{} \\ @dots{} >>}.  If a polyphonic voice ends while an
automatic beam is still accepting notes, it is not typeset.


I think that the automatic beam is still accepting notes, because it
would prefer to end at the end of the measure.  Then, the voice
ends, which causes the autobeam to be entirely dropped.

I was able to get the autobeam to happen by including a spacer rest
in the voice:

\relative { \clef bass << {e8 d d c d8 c s32 } \\ {  4 g 4} >>
 }

This had the effect of terminating the autobeam at 3/4, instead
of trying to continue on to 4/4.

Perhaps once the behavior has been identified it can be fixed.

Carl





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


Re: SLopUF: context name

2008-08-14 Thread Carl Sorensen
Robin Bannister  dataway.ch> writes:

> 
> Hallo again!
> 
> At the end of LM 3.3.2. there is the caution:
> > Note the distinction between the name of the context type, Staff, Voice, 
> > etc,
> > and the identifying name of a particular instance of that type ...
> 
> Well, I can manage that, I think. 
> Because when I'm looking at the snippets, 
> these names look quite different: one lot are in quotes. 
> 
> But when I start reading in the manuals about using these names 
> I get confused. 

Robin,

Thanks for your work on this.  You've done an excellent job of identifying 
an area of confusion in the documentation.

As you mention, right now we're in the middle of a section-by-section revision.
Some of us may be able to pay a bit of attention to this suggestion in our
individual rewrites.  But I think that once we get it settled down we
may be able to use your tables to clean up the explanations.

Thanks,

Carl








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


Re: autobeams

2008-08-14 Thread James E. Bailey


Am 14.08.2008 um 23:28 schrieb Kieren MacMillan:


Hi Daniel,


Under what circumstances would you want the upper part
to be a different voice from the one-voice part?


One case is when you want lyrics or dynamics (etc.) to be attached  
to the lower part.


Hope this helps,
Kieren.


Or if you want different lyrics to be attached to the upper part.

In fact, it took me a long time to understand explicitly instantiating  
voices. The documentation explains it, I just didn't understand it  
until I played around with it. I've attached a small sample that shows  
some examples of explicitly instatiating Voices. (it's basically when  
you actually tell lilypond to create a \new Voice) and what you can do  
with that.


voices.ly
Description: Binary data


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


Re: Harp Pedals?

2008-08-14 Thread Reinhold Kainhofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Donnerstag, 14. August 2008 schrieb Valentin Villenave:
> 2007/7/8 Dewdman42 <[EMAIL PROTECTED]>:
> > I can't seem to find anything in the Lilypond manual about creating harp
> > pedal symbols.  I would think this issue has been covered a lot by users
> > of Lilypond.  how do I do it, or something like it:
> >
> > http://www.nabble.com/file/p11492013/ScreenHunter_03%2BJul.%2B08%2B12.40.
> >jpg
>
> Greetings Carl, hi everybody,
>
> I've been trying to implement this harp diagrams feature for a while,
> but my implementation is quite dirty and not fully working. 

Here's my attempt, which defines a \harp-pedal #"^v-|^--v" markup command 
(plus a version, which takes a list of 1, 0, -1 and #\| - unfortunately that 
version has some caveats as detailled in the .ly file).

Should this be included in git?

Cheers,
Reinhold


- -- 
- --
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFIpKn0TqjEwhXvPN0RAn8fAJ4o8jqAtCE7moet33By5m5428ZONgCYlUnP
IUQpO/BYuljGEj7V5bi2Qw==
=bf8X
-END PGP SIGNATURE-
\version "2.11. 55"

\paper {
  ragged-right = ##f
}

% The following defines a new markup command 
%  \harp-pedal #"^-v|--v^" 
% for harp pedal diagrams. Possible values in the string are:
%   ^ ... pedal is up
%   - ... pedal is neutral
%   v ... pedal is down
%   | ... vertical divider line
% The function does not check if the string has the typical form of three
% pedals, then the divider and then the remaining four pedals. Instead it 
% simply prints each symbol in the order as given. This means you can place
% the divider (even multiple dividers) anywhere you want.
% 
% There is also a \harp-pedal-verbose version, which 
% takes a list of directions and a possible |. Unfortunately, it has some
% caveats:
%   1) the | cannot be given as a string "|", but as a character #\|
%   2) if one wants to use directions like UP, CENTER or DOWN, one cannot use
%  '(UP DOWN CENTER #\| ), because the contents of that list are 
%  never evaluated. Instead one has to explicitly create a list like
%  (list UP DOWN CENTER #\| )

#(define-markup-command (harp-pedal-verbose layout props pedal-list) (list?)
  "Make a harp pedal diagram containing the directions indicated in @var{pedal-list}.

  For example,

@example
\\markup \\pedal-diagram-verbose #'(1 0 -1 #\\| 0 0 1 1)
\\markup \\pedal-diagram-verbose #(list UP CENTER DOWN #\\| CENTER CENTER UP UP)
@end example
"
  (make-harp-pedal layout props pedal-list))


#(define-markup-command (harp-pedal layout props definition-string) (string?)
  "Make a harp pedal diagram.  For example, say

@example
\\markup \\harp-pedal #\"^-v|\"
@end example
"
  (make-harp-pedal layout props (harp-pedals-parse-string definition-string)))


#(define (harp-pedals-parse-string definition-string)
 "Parse a harp pedals diagram string and return a list containing 1, 0, -1 or #\\|"
  (map (lambda (c) 
(case c
  ((#\^) 1)
  ((#\v) -1)
  ((#\-) 0)
  ((#\|) #\|)
  (else c)))
(string->list definition-string)))


#(define (make-harp-pedal layout props pedal-list)
  "Make a harp pedals diagram markup"
   
  ; FIXME the size variable should be defined by a prop. lookup
  (define sz 1.2)
   
  ; TODO is it worth adding a thickness variable here?
  (let* ((x (* sz 4))
(y (* sz 2))
(box-width (* sz 0.4))
(box-height (* sz 1))
(space (* sz 0.5))
(box-x-dimensions (lambda (prev-x p) (cons (+ prev-x space) 
 (+ prev-x space box-width
(box-y-dimensions (lambda (prev-x p) (cons (+ (- y (/ box-height 2)) p) 
   (+ y (/ box-height 2) p
(divider-command (lambda (xpos) (list 'draw-line 0.2 xpos 0 xpos (* y 2
(result (let process-pedal  ((remaining pedal-list)
 (prev-x 0)
 (stencils '()))
  (if (null? remaining)
(cons prev-x stencils) 
  
(case (car remaining)
  ((1 0 -1) 
 (let* ((p (car remaining))
(stencil (make-filled-box-stencil
  (box-x-dimensions prev-x p) (box-y-dimensions prev-x p)))
  (new-prev-x (+ prev-x space box-width space)))
  (process-pedal (cdr remaining) new-prev-x (cons stencil stencils
((#\|)
(let* ((xpos (+ prev-x space))
   (stencil 

Re: Harp Pedals?

2008-08-14 Thread Reinhold Kainhofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Donnerstag, 14. August 2008 schrieb Carl D. Sorensen:
> >> 2 - The implementation I provide is very dirty, as I said. [...]
> >> and  inside the function I don't know how I can increment the values for
> >> the horizontal placement of the boxes in an elegant way.
> >
> > I think the easiest and most Scheme-like way would be to loop through the
> > seven entries of the pedal list using recursive calls of a named let
> > clause... In particular:
> >
> > (let process-pedal ((remaining-pedals initial-pedals)
> > (xpos 0))
> > ; print the box for the (car remaining-pedals)
> > ;
> > ; now call the process-pedal loop with the cdr (unless we are
> > finished) ;
> > (if (not (empty? (cdr remaining-pedals)))
> >   (process-pedal (cdr remaining-pedals) (+ xpos width-of-this-pedal))
> > )
> > )
>
> This is a nice Scheme-like way to do it.  However, the problem is that you
> can't just do a recursive call.  You have to do a stencil-add for each
> pedal.  And you can't have a null list as an argument to stencil-add.

Hehe, you are right of course, but that's easily resolved in a Scheme-like 
fashion: simply collect the list of stencils created so far as a third 
variable in the let clause. And the whole let clause returns (cons 
final-x-pos created-stencils), so that one can then draw the horizontal line 
and combine all stencils for the final markup.

> The key here is that you can't just return a stencil (which would be very
> easy to do recursively); you need to return an add-stencil function.

Or you can simply return a list of stencils, to which you add one stencil 
after the other. No set! required here, since I do the prepending right in 
the next call to the let clause.

> Another way to do it, while less Scheme-like, is more straightforward.
> You initialize the stencil with the first element, then do a set! for
> the rest of the elements.  Abelson and Sussman would have a heart attack
> about doing it, but this seems to be the LilyPond way of doing it.
> LilyPond is full of set! assignments.

I started off like this, but then I realized how I could do it with recursion 
and the code got significantly easier...

> However, I can see that you (Reinhold) are a better LilyPond programmer
> than me, so you may know how to do it better than I do.  

Looking at your fret diagrams, I sincerely doubt your statement. You are 
definitely more versed in scheme programming than I am.
I have hardly any Scheme experience (learned it only for lilypond), I simply 
saw some nice scheme constructs in a patch for the part-combiner that Kristof 
Bastiaensen sent to the list three years ago... That's my whole experience!


> If I were starting from scratch, I would have only the terse format for
> markups, and the list format for internal LilyPond grob calls.

That's what I intended to do, too. But since internally everything is 
implemented with the list-based definitions, it's trivial to provide a 
list-based command, too. Given that harp pedals are a lot simpler than fret 
diagrams, it doesn't add any complexity, it simply saves one loop over the 
characters of the string.

Cheers,
Reinhold

- -- 
- --
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIpKjnTqjEwhXvPN0RAuF1AJ9iMbfLG+pby+vSpOAThkNSo1eFowCcCX1S
rt3e7SpkMff3rU3/CMlyc1w=
=YtyN
-END PGP SIGNATURE-


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


Re: Harp Pedals?

2008-08-14 Thread Reinhold Kainhofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Donnerstag, 14. August 2008 schrieb Carl D. Sorensen:
> On 8/14/08 11:16 AM, "Valentin Villenave" <[EMAIL PROTECTED]> wrote:
> >> This requires you to use lambda expressions, which are kind of
> >> confusing.
> >
> > Are lambda expressions related to
> > http://en.wikipedia.org/wiki/Lambda_calculus?
> >
> > If so, I have to confess I kinda gave up every time I tried to read
> > the Wikipedia page... :(
>
> Well, they're probably related to lambda calculus, but I don't understand
> lambda calculus enough to do anything with it.
>
> In my opinion, calling it lambda(x) makes it way hard for users to
> understand.  In my mind, I substitute temporary_function for lambda, and
> then it makes sense to me

Exactly, that's what lambda calculus is all about. Basically, a bunch of code 
is understood as a function, but since it does not have a function name, you 
simply call it lambda(x,...). The whole lambda calculus is all about 
analyzind the results of applying lambda(x...) to some expressions.

So, I simply think of lambda functions as "unnamed functions".

Cheers,
Reinhold

- -- 
- --
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIpKjhTqjEwhXvPN0RAnS9AKCbcGy06Y05Rm4tuOhrMoDKHV1YPACfXFto
rq4QR3UzvHRIuxp2oNInmg8=
=fXpe
-END PGP SIGNATURE-


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


Re: autobeams

2008-08-14 Thread Kieren MacMillan

Hi Daniel,


Under what circumstances would you want the upper part
to be a different voice from the one-voice part?


One case is when you want lyrics or dynamics (etc.) to be attached to  
the lower part.


Hope this helps,
Kieren.


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


Re: autobeams

2008-08-14 Thread Daniel Hulme
On Thu, Aug 14, 2008 at 05:31:27PM +0200, Mats Bengtsson wrote:
> If you care about the number of key strokes, why not add a short-hand,  
> using a music
> function:
>
> \version "2.10.0"
> % Usage \split {upper music} { lower music }
> split = #(define-music-function (parser location upper lower )  
> (ly:music? ly:music? )
>  #{ << { \voiceOne $upper } \new Voice { \voiceTwo $lower } >> \oneVoice 
> #})

OOC, why doesn't << {...} \\ {...} >> do that anyway? Under what
circumstances would you want the upper part to be a different voice from
the one-voice part? And is it possible to override \\ to make it behave
like that if you wanted to change it for a whole piece all at once?
(Yes, I know you could use a music function instead and thus change it
everywhere by just changing the function definition.)

-- 
Sequential composition: it's just one thing after another.
http://surreal.istic.org/  No one heard that but me.


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


SLopUF: context name

2008-08-14 Thread Robin Bannister

Hallo again!

At the end of LM 3.3.2. there is the caution:

Note the distinction between the name of the context type, Staff, Voice, etc,
and the identifying name of a particular instance of that type ...


Well, I can manage that, I think. 
Because when I'm looking at the snippets, 
these names look quite different: one lot are in quotes. 



But when I start reading in the manuals about using these names I get confused. 


LM says, for example,
 > context name (like Staff or Voice)
But when NR says
 > when setting lyrics the melody is in a named context
it is talking about an identifying name. 

And quite often they mention 
 > context type 
which could make someone think that that was something different again, 
i.e. something else to learn about, 
but maybe 
it is because it would be inappropriate to say "name" at that point 
or maybe
"name" is being used nearby for something else. 



OK. I know this doesn't fit in with the docs schedule. 
And I shouldn't really be reading NR 5 yet. 
This feedback goes orthogonal to the section view, 
and so will be untimely in many different ways. 
Feel free to ignore it (for the time being). 




Two weak rules:
WR1  Avoid "name" as a verb. 
WR2. Keep "context" and "name" words well apart. 

WR1 is because the this verb is ambiguous: 
 A: to refer to by name   (like the  of \context)

 B: to give a name to (like the =  of \context)
i.e. this is important when used near "\context" 
where the author might mean A and the reader understands B. 
(This may only apply to English, but English is the language being translated.)


WR2 is like taking big strides when your shoelaces are undone. 
It doesn't apply if there is a qualifier which reduces the ambiguity sufficiently: 
 e.g. named voice context (already has a type name, so must mean id)   
The lilypond word "context" itself is ambiguous if alone, 
applying to either type or instance. 

(I'm not talking about normal discourse, which copes with ambiguity). 
Unambiguity is most important in the command syntax sections. 
It is less important elsewhere but only if there are watertight definitions 
the puzzled reader can refer to when needing clarification. 

To apply these rules you have to find suitable words/phrases to replace the 
forbidden ones. 



I thought I would try this out to see if it produced something clearer for me. 
On starting I ran into a different problem: 
 the placeholders used in the new/context/set/override syntax sections vary 
 a lot, making it difficult for the reader to see the similarities. 
I unified the placeholders for  and  (but left the others unchanged) 
and thought up some new verbs. 

The result is attached as TAB-separated csv with 3 columns: 
 - section numbering
 - phrases/sentences I considered relevant to to "context" and "name" 
 - my rewording of those phrases/sentences which violated WR1/2. 



Cheers, 
Robin


r2b

LM.csv
Description: Binary data


NR.csv
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: spacing problem

2008-08-14 Thread Werner LEMBERG

> Did you try setting \override Score.SpacingSpanner
> #'average-spacing-wishes = ##f

It gives exactly the same result with both ##f and ##t.  Such
formatting must never happen IMHO.


   Werner


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


Re: Harp Pedals?

2008-08-14 Thread Carl D. Sorensen



On 8/14/08 11:16 AM, "Valentin Villenave" <[EMAIL PROTECTED]> wrote:

>
> Well, had I known it would make your day, I'd have spent less time
> looking at your code and asked my question sooner :-)
>

But looking at the code and hacking something together is what made your
question very useful!

>> If you really want to do this (why would users want to have values
>> greater than 1 or less than -1?  I don't know harp music, so I can't say),
>
> You have a point. However, what Reinhold proposes is even sexier (see below).
>

I agree.

>> This requires you to use lambda expressions, which are kind of confusing.
>
> Are lambda expressions related to
> http://en.wikipedia.org/wiki/Lambda_calculus?
>
> If so, I have to confess I kinda gave up every time I tried to read
> the Wikipedia page... :(

Well, they're probably related to lambda calculus, but I don't understand
lambda calculus enough to do anything with it.

In my opinion, calling it lambda(x) makes it way hard for users to
understand.  In my mind, I substitute temporary_function for lambda, and
then it makes sense to me

(temporary_function(adjustable-arg) (my-procedure adjustable-arg fixed-arg1
fixed-arg2))  makes a bit more sense to me.  It's a way to call a procedure
with some fixed arguments and one (or more) variable arguments.

So if I say

 (map ((lambda (x) (my-procedure x arg2 arg3)) mylist)

I get a result that is
  (list
(my-procedure (list-ref mylist 1) arg2 arg3)
(my-procedure (list-ref mylist 2) arg2 arg3)
   ...
(my-procedure (list-ref mylist (length mylist)) arg2 arg3))

So lambda is really useful for doing something to every item in a list.
>> At the time I wrote fret-diagrams, constants like 4, 2, and 0.4
>> were frowned upon.  So I used variables connected to properties
>> every time I needed a constant like this, and there was concern about
>> polluting the property name space, so I created fret-diagram-details.
>
> Yes indeed.
>
>> Also, LilyPond coding standards call for using full words rather than
>> abbreviations for variable names.  x, y, a, b and so forth should only
>> be used as part of a lambda function definition.
>
> Actually, d c b and so on referred to the note of the pedals.

So you may want to use variables d-pedal, c-pedal, b-pedal, etc.  It's not
the note that the variable is referring to, but the desired "status" of the
pedal.
>
>> I think the easiest and most Scheme-like way would be to loop through the
>> seven entries of the pedal list using recursive calls of a named let
>> clause... In particular:
>
> The problem is that the pedal boxes are not evenly spaced (there are
> three on one side, four on the other).
>
This should not be a problem.  You just need to get the start position
(which I think you've already done) and then add an increment for each
pedal.

>> Actually, each entry in a harp diagram can only have three values, so I don't
>> like numeric representations too much (internally, lilypond uses integers for
>> directions, but that is hidden from the user as much as possible by #UP etc.
>> I don't think the users should be exposed to numbers as directions in harp
>> diagrams). What I was thinking of was a rough textual representation of the
>> states:
>> \harpPedals #"^--|v-^-" such a string with one letter per pedal is much
>> easier
>> to parse.
>
> This is just awesome! Can it be handled by pure Scheme though, or does
> this need to be dealt with on the C++ side?

Pure Scheme will do it -- no need to touch C++ as long as you only want to
use markups.

If you eventually want to get a context (like the FretBoards context),
you'll need to modify the parser and write some C++.  But I think the
FretBoards context can serve as a pattern ...


Thanks for stirring the pot.  I hope you have some harp pedals soon!

Carl



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


Re: spacing problem

2008-08-14 Thread Mats Bengtsson
Did you try setting \override Score.SpacingSpanner 
#'average-spacing-wishes = ##f


  /Mats

Quoting Werner LEMBERG <[EMAIL PROTECTED]>:



I've just found a wonderful example which demonstrates what I want to
fix.  Look at the fourth and fifth quarter: It's *really* ugly.

On the other hand I'm not sure whether this is a different spacing
bug.  Joe?


   Werner







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


Re: Harp Pedals?

2008-08-14 Thread Carl D. Sorensen



On 8/14/08 10:56 AM, "Reinhold Kainhofer" <[EMAIL PROTECTED]> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am Donnerstag, 14. August 2008 schrieb Valentin Villenave:
>> 2007/7/8 Dewdman42 <[EMAIL PROTECTED]>:
>>> I can't seem to find anything in the Lilypond manual about creating harp
>>> pedal symbols.  I would think this issue has been covered a lot by users
>>> of Lilypond.  how do I do it, or something like it:
>>>
>>> http://www.nabble.com/file/p11492013/ScreenHunter_03%2BJul.%2B08%2B12.40.
>>> jpg
>>
>> I've been trying to implement this harp diagrams feature for a while,
>> but my implementation is quite dirty and not fully working.
>
> Nice to see that I'm not the only one interested in implementing harp pedal
> diagrams
> (http://www.mail-archive.com/lilypond-devel%40gnu.org/msg15542.html).
>
>> Basically,
>> I tried to write a markup command that would take seven arguments, one
>> for each pedal. However, for some reason I cannot pass more than three
>> arguments to the markup command (see below).
>>
>> 1 - What I'd really like to achieve is to have one single argument
>> containing the whole set of pedals, like you do with your diagrams,
>> such as
>> \harp #"0;-1;0;1;0;0;1;"
>> instead of
>> \harp #0 #-1 #0 #1 #0 #0 #1
>>
>> However, I cannot parse the string to extract the values (I've tried
>> to figure it out from your code, but it's way over my skills).
>
> I'll try to come up with a proper parser.
>
>> 2 - The implementation I provide is very dirty, as I said. [...]
>> and  inside the function I don't know how I can increment the values for
>> the horizontal placement of the boxes in an elegant way.
>
> I think the easiest and most Scheme-like way would be to loop through the
> seven entries of the pedal list using recursive calls of a named let
> clause... In particular:
>
> (let process-pedal ((remaining-pedals initial-pedals)
> (xpos 0))
> ; print the box for the (car remaining-pedals)
> ;
> ; now call the process-pedal loop with the cdr (unless we are finished)
> ;
> (if (not (empty? (cdr remaining-pedals)))
>   (process-pedal (cdr remaining-pedals) (+ xpos width-of-this-pedal))
> )
> )

This is a nice Scheme-like way to do it.  However, the problem is that you
can't just do a recursive call.  You have to do a stencil-add for each
pedal.  And you can't have a null list as an argument to stencil-add.

So one way out of the problem is a look-ahead to see if
the _next_ element is
the last element; your recursive function then looks like:

  (if (next-element-is-last)
  (ly:add-stencil (make-stencil current-pedal)
  (make-stencil (cadr remaining-pedals)))
  (ly:add-stencil (make-stencil current-pedal)
 (process-pedal (cdr remaining-pedals)...))

The key here is that you can't just return a stencil (which would be very
easy to do recursively); you need to return an add-stencil function.

I used code like this in the fret-diagrams module.

Another way to do it, while less Scheme-like, is more straightforward.
You initialize the stencil with the first element, then do a set! for
the rest of the elements.  Abelson and Sussman would have a heart attack
about doing it, but this seems to be the LilyPond way of doing it.
LilyPond is full of set! assignments.


However, I can see that you (Reinhold) are a better LilyPond programmer
than me, so you may know how to do it better than I do.  Feel free to ignore
anything I say.


>
> Actually, each entry in a harp diagram can only have three values, so I don't
> like numeric representations too much (internally, lilypond uses integers for
> directions, but that is hidden from the user as much as possible by #UP etc.
> I don't think the users should be exposed to numbers as directions in harp
> diagrams). What I was thinking of was a rough textual representation of the
> states:
> \harpPedals #"^--|v-^-" such a string with one letter per pedal is much easier
> to parse. Of course, we can have two versions, a terse one with #"^--|v-^-"
> and a "normal" one with "1;0;0;-1;0;1;0". That's just a matter of two
> different string parsers before the same function is called, similar to the
> fret-parse-definition-string function and the subsequent call to the function
> that really generates the fret diagram.

If I were you, I'd avoid having multiple syntaxes.  I did it in fret
diagrams because I came up with the normal syntax and implemented it, then
Han-Wen wanted a list-based syntax to be compatible with the normal LilyPond
structure (everything is lists) so I came up with verbose, and users
proposed the terse format because it was easier to enter.

If I were starting from scratch, I would have only the terse format for
markups, and the list format for internal LilyPond grob calls.  I would not
have a list-based markup interface; it's not useful for users in my opinion.
I would not need the "normal" interface, because now I know how to set all
the d

Re: spacing problem

2008-08-14 Thread Werner LEMBERG

I've just found a wonderful example which demonstrates what I want to
fix.  Look at the fourth and fifth quarter: It's *really* ugly.

On the other hand I'm not sure whether this is a different spacing
bug.  Joe?


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


Re: \textLengthOn - choosing which note to lengthen

2008-08-14 Thread Carl D. Sorensen



On 8/14/08 12:42 PM, "Chris Snyder" <[EMAIL PROTECTED]> wrote:


>
> This seems pedantic to me - isn't the time that elapses before the next
> musical moment going to be equal to the length of the shortest
> note/skip/rest in the current moment?

The example I showed had a dotted half note and a markup in the current
moment.  The next moment came from ending the eighth note of the previous
moment, not from ending something in the current moment.  Not all voices
have to have an element in the current moment, at least as far as I
understand the architecture of LilyPond.

>
> That looks fine to me. I think I've understood it better than
> demonstrated in the example I provided; your version is easier to
> understand.
>
> Thanks for taking the time to work with me on this. Your attention to
> detail on even such a minor element is appreciated.

You're welcome.

Carl



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


Re: \textLengthOn - choosing which note to lengthen

2008-08-14 Thread Chris Snyder

Carl D. Sorensen wrote:

Your proposed text shows that you don't quite understand how
\textLengthOn works from a LilyPond point of view.  Your terminology
is not quite right, so we'll need to change the text a bit before
we put it in the manual.  I hope you'll not mind that.


Please feel free to modify it in whatever way you see fit.


\textLengthOn applies to a musical moment, not a note.  A musical
moment starts at an instant in time of the score, and includes all
events that occur at that instant.  A musical moment ends when
the next musical moment begins, or when the first event occurs
is not simultaneous with the current moment.


Your explanation is helpful - perhaps something like that should be in 
the doc as well? Looking at the docs some more, it seems that the idea 
of musical moments isn't explained anywhere (at least not as well as 
you've just explained it to me).



So, in the example, the first musical moment contains the c4 in
the treble cleff, the c1 in the bass clef, and the markup.  The
second musical moment contains the e in the treble clef.  The
effect of \textLengthOn is to make the first musical moment
take as much horizontal space as the markup.

While it appears that \textLengthOn adds space to the shortest
note, this is incorrect.  It is not the duration of the note in
the current moment that matters, but the timing of the first
note to follow the current moment.


This seems pedantic to me - isn't the time that elapses before the next 
musical moment going to be equal to the length of the shortest 
note/skip/rest in the current moment?



Perhaps this modified version of your example helps to
explain the concept.
\score...


That looks fine to me. I think I've understood it better than 
demonstrated in the example I provided; your version is easier to 
understand.


Thanks for taking the time to work with me on this. Your attention to 
detail on even such a minor element is appreciated.


-Chris


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


Re: Please forget LM MG NR IR SL AU

2008-08-14 Thread Jan Nieuwenhuizen
On di, 2008-08-12 at 20:08 +0200, James E. Bailey wrote:

> And am I the only one who thinks of cars seeing MG?

Nope, no cars here.

:-)

-- 
Jan Nieuwenhuizen <[EMAIL PROTECTED]> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien   | http://www.lilypond.org



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


Re: Score with large empty section at the top

2008-08-14 Thread Tim Reeves
> > I think it is standard behaviour.
> > I remember there was a command to let LilyPond display all the spaces
> > it uses and its names. But I don´t remember the command and couldn´t
> > find it by searching ...
> 
> Take a look at Notation Reference 4.6.1: "Displaying spacing."
> 
> -Chris


He actually did include annotate-spacing = ##t in his Paper block in his 
file, but he had it commented out. Putting it back in did give several 
clues for how to change the spacing to his liking.___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Harp Pedals?

2008-08-14 Thread Valentin Villenave
2008/8/14 Carl D. Sorensen <[EMAIL PROTECTED]>:

> Valentin, you made my day.  To have somebody asking _me_ questions
> about LilyPond programming is a first.  I've been the one asking
> everybody else questions.  Thanks!

Well, had I known it would make your day, I'd have spent less time
looking at your code and asked my question sooner :-)

> You really don't want to get in the string business for this case.

> It's much easier to just pass one argument to the function, a
> list of pedal values.

Oh yeah! Stupid, stupid me. I simply forgot about the list type.

> If you really want to do this (why would users want to have values
> greater than 1 or less than -1?  I don't know harp music, so I can't say),

You have a point. However, what Reinhold proposes is even sexier (see below).

> This requires you to use lambda expressions, which are kind of confusing.

Are lambda expressions related to http://en.wikipedia.org/wiki/Lambda_calculus?

If so, I have to confess I kinda gave up every time I tried to read
the Wikipedia page... :(

> If you're going to do scheme programming with lilypond, lambda functions
> are your friends, even though they can be confusing.

I'll try harder then...


> At the time I wrote fret-diagrams, constants like 4, 2, and 0.4
> were frowned upon.  So I used variables connected to properties
> every time I needed a constant like this, and there was concern about
> polluting the property name space, so I created fret-diagram-details.

Yes indeed.

> Also, LilyPond coding standards call for using full words rather than
> abbreviations for variable names.  x, y, a, b and so forth should only
> be used as part of a lambda function definition.

Actually, d c b and so on referred to the note of the pedals.

> With make-pedal-stencil defined you can now add a new variable to your let
> assignment list
[...]
> And before your code to add stencils you can do a for-each:
[...]
> Which should glue all of your pedal stencils together in one big
> stencil pedals-stencil.

Great! This definitely looks good.

> I think it's good for you to figure out how it works, so I've left the
> debugging to you.  If you have more questions, feel free to ask.

I guess I will, pretty soon :)

Many thanks anyway.

2008/8/14 Reinhold Kainhofer <[EMAIL PROTECTED]>:

> Nice to see that I'm not the only one interested in implementing harp pedal
> diagrams
> (http://www.mail-archive.com/lilypond-devel%40gnu.org/msg15542.html).

Oh yes, I remember now that you had asked for possible glyphs.

> I think the easiest and most Scheme-like way would be to loop through the
> seven entries of the pedal list using recursive calls of a named let
> clause... In particular:

The problem is that the pedal boxes are not evenly spaced (there are
three on one side, four on the other).

> Actually, each entry in a harp diagram can only have three values, so I don't
> like numeric representations too much (internally, lilypond uses integers for
> directions, but that is hidden from the user as much as possible by #UP etc.
> I don't think the users should be exposed to numbers as directions in harp
> diagrams). What I was thinking of was a rough textual representation of the
> states:
> \harpPedals #"^--|v-^-" such a string with one letter per pedal is much easier
> to parse.

This is just awesome! Can it be handled by pure Scheme though, or does
this need to be dealt with on the C++ side?

> Of course, we can have two versions, a terse one with #"^--|v-^-"
> and a "normal" one with "1;0;0;-1;0;1;0". That's just a matter of two
> different string parsers before the same function is called, similar to the
> fret-parse-definition-string function and the subsequent call to the function
> that really generates the fret diagram.

This looks really, really cool, though way beyond my knowledge. Nice
to have some "real" people on my side, anyway :-)

Cheers,
Valentin


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


Re: Harp Pedals?

2008-08-14 Thread Reinhold Kainhofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Am Donnerstag, 14. August 2008 schrieb Valentin Villenave:
> 2007/7/8 Dewdman42 <[EMAIL PROTECTED]>:
> > I can't seem to find anything in the Lilypond manual about creating harp
> > pedal symbols.  I would think this issue has been covered a lot by users
> > of Lilypond.  how do I do it, or something like it:
> >
> > http://www.nabble.com/file/p11492013/ScreenHunter_03%2BJul.%2B08%2B12.40.
> >jpg
>
> I've been trying to implement this harp diagrams feature for a while,
> but my implementation is quite dirty and not fully working. 

Nice to see that I'm not the only one interested in implementing harp pedal 
diagrams 
(http://www.mail-archive.com/lilypond-devel%40gnu.org/msg15542.html).

> Basically, 
> I tried to write a markup command that would take seven arguments, one
> for each pedal. However, for some reason I cannot pass more than three
> arguments to the markup command (see below).
>
> 1 - What I'd really like to achieve is to have one single argument
> containing the whole set of pedals, like you do with your diagrams,
> such as
> \harp #"0;-1;0;1;0;0;1;"
> instead of
> \harp #0 #-1 #0 #1 #0 #0 #1
>
> However, I cannot parse the string to extract the values (I've tried
> to figure it out from your code, but it's way over my skills).

I'll try to come up with a proper parser.

> 2 - The implementation I provide is very dirty, as I said. [...]
> and  inside the function I don't know how I can increment the values for
> the horizontal placement of the boxes in an elegant way.

I think the easiest and most Scheme-like way would be to loop through the 
seven entries of the pedal list using recursive calls of a named let 
clause... In particular:

(let process-pedal ((remaining-pedals initial-pedals)
(xpos 0))
; print the box for the (car remaining-pedals)
;
; now call the process-pedal loop with the cdr (unless we are finished)
;
(if (not (empty? (cdr remaining-pedals)))
  (process-pedal (cdr remaining-pedals) (+ xpos width-of-this-pedal))
)
)
   


> 3 - Ideally, we should add something like
> (if (> a 0) set! a 1
> (if (< a 0) set! a 1))
> so to allow users to use any values bigger values than 1 or lower than
> -1 without breaking their result.

Actually, each entry in a harp diagram can only have three values, so I don't 
like numeric representations too much (internally, lilypond uses integers for 
directions, but that is hidden from the user as much as possible by #UP etc. 
I don't think the users should be exposed to numbers as directions in harp 
diagrams). What I was thinking of was a rough textual representation of the 
states:
\harpPedals #"^--|v-^-" such a string with one letter per pedal is much easier 
to parse. Of course, we can have two versions, a terse one with #"^--|v-^-" 
and a "normal" one with "1;0;0;-1;0;1;0". That's just a matter of two 
different string parsers before the same function is called, similar to the 
fret-parse-definition-string function and the subsequent call to the function 
that really generates the fret diagram.

Cheers,
Reinhold

- -- 
- --
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [EMAIL PROTECTED], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFIpGO7TqjEwhXvPN0RAoivAKCReMSX7BloLs9HYyIchHGhC+qlawCcCBX6
XqI7A0C/G2yjePZqXD4OI4E=
=PGyG
-END PGP SIGNATURE-


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


Re: Harp Pedals?

2008-08-14 Thread Carl D. Sorensen



On 8/14/08 8:50 AM, "Valentin Villenave" <[EMAIL PROTECTED]> wrote:

> 2007/7/8 Dewdman42 <[EMAIL PROTECTED]>:
>>
>> I can't seem to find anything in the Lilypond manual about creating harp
>> pedal symbols.  I would think this issue has been covered a lot by users of
>> Lilypond.  how do I do it, or something like it:
>>
>> http://www.nabble.com/file/p11492013/ScreenHunter_03%2BJul.%2B08%2B12.40.jpg
>
> Greetings Carl, hi everybody,
>
> I've been trying to implement this harp diagrams feature for a while,
> but my implementation is quite dirty and not fully working. Basically,
> I tried to write a markup command that would take seven arguments, one
> for each pedal. However, for some reason I cannot pass more than three
> arguments to the markup command (see below).

Valentin, you made my day.  To have somebody asking _me_ questions
about LilyPond programming is a first.  I've been the one asking
everybody else questions.  Thanks!

>
> 1 - What I'd really like to achieve is to have one single argument
> containing the whole set of pedals, like you do with your diagrams,
> such as
> \harp #"0;-1;0;1;0;0;1;"
> instead of
> \harp #0 #-1 #0 #1 #0 #0 #1
>
> However, I cannot parse the string to extract the values (I've tried
> to figure it out from your code, but it's way over my skills).

You really don't want to get in the string business for this case.
If you do you'd  have to first split the string (using the Scheme
function string-split) and then convert the resulting codes from
strings to numbers (using the Scheme function string->number).

It's much easier to just pass one argument to the function, a
list of pedal values.

See below, where I've shown what the call would look like.

>
> 2 - The implementation I provide is very dirty, as I said. I don't
> know if it would be best to haave a separate stencil function, and
> inside the function I don't know how I can increment the values for
> the horizontal placement of the boxes in an elegant way.
>
> 3 - Ideally, we should add something like
> (if (> a 0) set! a 1
> (if (< a 0) set! a 1))
> so to allow users to use any values bigger values than 1 or lower than
> -1 without breaking their result.
>

If you really want to do this (why would users want to have values
greater than 1 or less than -1?  I don't know harp music, so I can't say),
then probably the best way to do it is something like

(let ((normalized-pedal-list (map (lambda(x) (if (> x 1) 1
 (if (< x -1) -1 x)))
  (user-pedal-list)))

The parentheses don't match in this example on purpose, because it's only
part of your let assignments.

This requires you to use lambda expressions, which are kind of confusing.
I think of lambda expressions as defining a temporary function of the
argument, without giving the function a name. So in this case we define
an unnamed function that will take an argument x and return 1 if x > 1,
-1 if x < -1 and x otherwise.  Then we map that unnamed function to
each element of user-pedal list, and return a list containing the results
of that function being applied to each element of the pedal list.

If you're going to do scheme programming with lilypond, lambda functions
are your friends, even though they can be confusing.

> Can you please have a quick look at the code below, when you have a minute?
>
>
> % I have to define some variables  separately or else
> % compiling fails miserably.
>
> % The following three are already
> % defined using the main function
>
> %#(define d 0)
> %#(define c 0)
> %#(define b 0)
> #(define e 0)
> #(define f 0)
> #(define g 0)
> #(define a 0)
>
> #(define-markup-command (harp layout props d c b) (integer? integer? integer?)
#(define-markup-command (harp layout props pedal-list)
(list?)

>  ; FIXME the size variable should be defined by a prop. lookup
props lookup is done with chain-assoc-get, which you can see in
scm/fret-diagrams.scm
>
>   (define sz 1.2)
>  ; TODO is it worth adding a thickness variable here
At the time I wrote fret-diagrams, constants like 4, 2, and 0.4
were frowned upon.  So I used variables connected to properties
every time I needed a constant like this, and there was concern about
polluting the property name space, so I created fret-diagram-details.

I'd recommend that for right now you define variables like
(let* ((width 4)
   (height 2)
   (stencil-width (* size width))
   (stencil-height (* size height))
and so forth.

That way, you are declaring (by the variable name) what the constant is
before you use it.  But you're not putting it in the property list
unless you think it's something users may need to vary.  It took me a
while to figure this approach out, so I thought I'd help you out
from the beginning.

Also, LilyPond coding standards call for using full words rather than
abbreviations for variable names.  x, y, a, b and so forth should only
be used as part of a lambda function definition.

I'd try 

Re: Conditional breaks

2008-08-14 Thread David Pounder
If each score is very short, you could try forbidding page breaks within each 
score:

\new Score \with {
\override NonMusicalPaperColumn #'page-break-permission = ##f
} { 
etc.

May depend on the version you are using.

David.

--- Original Message ---
From: "Mark Austin" <[EMAIL PROTECTED]>
To: lilypond-user@gnu.org
Sent: 14.8.08, 15:38:37
Subject: Conditional breaks

-snip
What I'd like to be able to do
is mark a tune so as to add a page break before it if the piece does
not fit on the current page.

Mark Austin.

 --
 For Whigs admit no force but argument
 --


___
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


Re: autobeams

2008-08-14 Thread James E. Bailey


Am 14.08.2008 um 17:31 schrieb Mats Bengtsson:




James E. Bailey wrote:


Am 14.08.2008 um 13:58 schrieb Jonathan Kulp:

Perhaps even better: don't use the \\ but explicitly

instantiate one of the voices
(related to a recent email discussion).


When I removed the \\, I got errors about clashing columns.  I'll  
check into the explicit voice instantiation thing.  For now I like  
the \oneVoice solution for this example.


The \oneVoice solution did not work for the example from GDP I'm  
working on, though.  The autobeaming still doesn't appear.  Here's  
the original code and then the fix I made for it.  In James'  
example, the \oneVoice fixed stem direction and autobeaming.  In  
this example, there was no problem with stem direction to begin  
with, just with autobeaming.  If you see a more elegant way please  
share :)


explicitly instantiating the voice would be
cadenza = \relative c' {
c4 d8 << { \voiceOne e f g } \new Voice { \voiceTwo d4. } >>
\oneVoice g4 f2 g4 g
}

\new GrandStaff <<
\new Staff { \cadenza c'4 }
\new Staff {
  #(ly:export (mmrest-of-length cadenza))
  c'4
}
>>

I'm not a big fan, especially for something so short, because it's  
so much more typing.
If you care about the number of key strokes, why not add a short- 
hand, using a music

function:

\version "2.10.0"
% Usage \split {upper music} { lower music }
split = #(define-music-function (parser location upper lower )  
(ly:music? ly:music? )
#{ << { \voiceOne $upper } \new Voice { \voiceTwo $lower } >>  
\oneVoice #})


% Example using it:
\relative c'{  c8 d \split { e f g f } {c4 b } e8 d }

 /Mats


Thanks, I really don't understand that music function, but I'll keep  
this email around for when I have to do a lot of these.




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


Re: autobeams

2008-08-14 Thread Mats Bengtsson



James E. Bailey wrote:


Am 14.08.2008 um 13:58 schrieb Jonathan Kulp:

Perhaps even better: don't use the \\ but explicitly

instantiate one of the voices
(related to a recent email discussion).


When I removed the \\, I got errors about clashing columns.  I'll 
check into the explicit voice instantiation thing.  For now I like 
the \oneVoice solution for this example.


The \oneVoice solution did not work for the example from GDP I'm 
working on, though.  The autobeaming still doesn't appear.  Here's 
the original code and then the fix I made for it.  In James' example, 
the \oneVoice fixed stem direction and autobeaming.  In this example, 
there was no problem with stem direction to begin with, just with 
autobeaming.  If you see a more elegant way please share :)


explicitly instantiating the voice would be
cadenza = \relative c' {
 c4 d8 << { \voiceOne e f g } \new Voice { \voiceTwo d4. } >>
 \oneVoice g4 f2 g4 g
}

\new GrandStaff <<
 \new Staff { \cadenza c'4 }
 \new Staff {
   #(ly:export (mmrest-of-length cadenza))
   c'4
 }
>>

I'm not a big fan, especially for something so short, because it's so 
much more typing.
If you care about the number of key strokes, why not add a short-hand, 
using a music

function:

\version "2.10.0"
% Usage \split {upper music} { lower music }
split = #(define-music-function (parser location upper lower ) 
(ly:music? ly:music? )
 #{ << { \voiceOne $upper } \new Voice { \voiceTwo $lower } >> 
\oneVoice #})


% Example using it:
\relative c'{  c8 d \split { e f g f } {c4 b } e8 d }

  /Mats


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


Re: strange tempo 2

2008-08-14 Thread Mats Bengtsson



David Bobroff wrote:


This was all well and good until I found that I had two metronome 
markings occurring at the same time.  Lily doesn't like that any more 
than two rehearsal mark appearing at the same time.  The odd score I'm 
working on has two time signatures going on at the same time.  One is 
in 1/4 and the other is in 5/8.  I need to print both


4 = 53 and 4 ~ 4. = 53

...on separate staves.  I'm thinking I'm back to my polyphonic 
solution above.

Can't you move the corresponding engraver(s) to the Staff context?


(Is the snippet repository off-line?  I can't get in now.)

Yes, it seems so, and that they know about it.

   /Mats


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


Re: strange tempo 2

2008-08-14 Thread Kieren MacMillan

Hi David,


I need to print both
4 = 53 and 4 ~ 4. = 53
...on separate staves.  I'm thinking I'm back to my polyphonic  
solution above.


One possibility would be to move the mark engraver to the Staff  
context, and use \tag for the different elements — it's a lot more  
work, but would definitely solve the problem you have.


Hope this helps!
Kieren.

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


Re: strange tempo 2

2008-08-14 Thread David Bobroff

A few days ago I posted this:


Following Mats' suggestion I went to:

http://lsr.dsi.unimi.it/LSR/Item?id=204

..to find a solution for an odd tempo marking.  I succeeded in displaying the desired 
result but ran into a snag.  The tempo I want to display occurs at a rehearsal mark.  The 
tempo marking also uses a modified rehearsal mark.  Lily doesn't like that.  
"Previous mark here" is what I get.

Then I tried voicifying to get the two "marks" to print.  I offset the tempo 
marking by attaching it to a skip.  Then I changed the #'X-offset (down near the bottom 
of the score block) to adjust the position of the tempo marking.

Is this a good way to go about this or is there something more informed?

-David


%
\version "2.11.55"

rhythmMarkStaffReduce = #-4
rhythmMarkLabelFontSize = #-3

rhythmMark = #(define-music-function (parser location musicI label) (ly:music? 
string? )

   #{
  \mark \markup {
\line \vcenter {
  \score { % 1st column in line
\new Staff \with {
  fontSize = #rhythmMarkStaffReduce
  \override StaffSymbol #'staff-space = #(magstep 
rhythmMarkStaffReduce)
  \override StaffSymbol #'line-count = #0
  \override VerticalAxisGroup #'Y-extent = #'(0 . 0)  % td
  \override VerticalAxisGroup #'minimum-Y-extent = #'(0 . 0) %RV
}

\relative { \stemUp $musicI }

\layout {
  ragged-right= ##t
  indent = 0
  \context {
\Staff
\remove "Clef_engraver"
\remove "Time_signature_engraver" }
} % layout

  } % 1st Score end
  \hspace #-0.5% 2nd column in line

   % 3rd column in line

  \italic \fontsize #rhythmMarkStaffReduce "="
   
  \combine % 4th column in line

\italic \fontsize #rhythmMarkLabelFontSize $label
\transparent \italic \fontsize #rhythmMarkLabelFontSize f
% This fakes a uniform baseline (ie. create common anchor for 
vcenter)
%% END 5
} % line end
  } % markup end
   #})


rhyMarkFiveEight = {
  % \override Score.SpacingSpanner #'common-shortest-duration = 
#(ly:make-moment 1 4) % tight
  \override Score.SpacingSpanner #'common-shortest-duration = #(ly:make-moment 
3 16) % even
  % \override Score.SpacingSpanner #'common-shortest-duration = 
#(ly:make-moment 1 8) % loose
  { b'4 ~ b4. }
}



\score {
\relative c' {
\time 4/4
c1
\time 5/8
\mark \default
<<
{
s8
\override Score.RehearsalMark #'self-alignment-X = #LEFT
\override Score.BarNumber #'break-visibility = #all-invisible
%\override Score.RehearsalMark #'padding = #-2
\once \override Score.RehearsalMark #'X-offset = #-2  % td
\rhythmMark \rhyMarkFiveEight #"53"
s2
}
\\
{
\stemNeutral
d4 e4.
}
>>
}
}
%


I got some responses which led up to this from Neil Puttock:


2008/8/7 David Bobroff <[EMAIL PROTECTED]>:

> Does Rheinhold's work allow for the kind of thing I want; a quarter tied to
> a dotted quarter = ?


Yes, since tempoText can take any \markup commands.

So in your snippet, all you need to do is change your rhythmMark
function so that the \score markup is set to tempoText; setting it
automatically creates a metronome mark:

\set Score.tempoText = \markup { ... }

Then you can junk the polyphonic section with the skips and the
metronome mark will be aligned with the first note in the bar.

Regards,
Neil



This was all well and good until I found that I had two metronome 
markings occurring at the same time.  Lily doesn't like that any more 
than two rehearsal mark appearing at the same time.  The odd score I'm 
working on has two time signatures going on at the same time.  One is in 
1/4 and the other is in 5/8.  I need to print both


4 = 53 and 4 ~ 4. = 53

...on separate staves.  I'm thinking I'm back to my polyphonic solution 
above.


(Is the snippet repository off-line?  I can't get in now.)

-David


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


Re: it's all up to you users

2008-08-14 Thread Valentin Villenave
2008/8/14 Patrick Horgan <[EMAIL PROTECTED]>:

> I think that's almost it, but it should be Fozzy Force after Fozzy Bear.

Fuzzy Force makes a nice sequel to Grumpy Graham... next time we'll
have to find something that begins with an E :-)

Cheers,
Valentin


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


Re: Harp Pedals?

2008-08-14 Thread Valentin Villenave
2007/7/8 Dewdman42 <[EMAIL PROTECTED]>:
>
> I can't seem to find anything in the Lilypond manual about creating harp
> pedal symbols.  I would think this issue has been covered a lot by users of
> Lilypond.  how do I do it, or something like it:
>
> http://www.nabble.com/file/p11492013/ScreenHunter_03%2BJul.%2B08%2B12.40.jpg

Greetings Carl, hi everybody,

I've been trying to implement this harp diagrams feature for a while,
but my implementation is quite dirty and not fully working. Basically,
I tried to write a markup command that would take seven arguments, one
for each pedal. However, for some reason I cannot pass more than three
arguments to the markup command (see below).

1 - What I'd really like to achieve is to have one single argument
containing the whole set of pedals, like you do with your diagrams,
such as
\harp #"0;-1;0;1;0;0;1;"
instead of
\harp #0 #-1 #0 #1 #0 #0 #1

However, I cannot parse the string to extract the values (I've tried
to figure it out from your code, but it's way over my skills).

2 - The implementation I provide is very dirty, as I said. I don't
know if it would be best to haave a separate stencil function, and
inside the function I don't know how I can increment the values for
the horizontal placement of the boxes in an elegant way.

3 - Ideally, we should add something like
(if (> a 0) set! a 1
(if (< a 0) set! a 1))
so to allow users to use any values bigger values than 1 or lower than
-1 without breaking their result.

Can you please have a quick look at the code below, when you have a minute?


% I have to define some variables  separately or else
% compiling fails miserably.

% The following three are already
% defined using the main function

%#(define d 0)
%#(define c 0)
%#(define b 0)
#(define e 0)
#(define f 0)
#(define g 0)
#(define a 0)

#(define-markup-command (harp layout props d c b) (integer? integer? integer?)
 ; FIXME the size variable should be defined by a prop. lookup

  (define sz 1.2)
 ; TODO is it worth adding a thickness variable here?

  (let ((x (* sz 4))
(y (* sz 2))
(box-width (* sz 0.4))
(box-height (* sz 1))
(space (* sz 0.5)))
(ly:stencil-add
  (ly:make-stencil
   `(draw-line 0.2 ; horizontal line
   ,(- 0 x) ,y ,x ,y))
  (ly:make-stencil
   `(draw-line 0.2 0 0 0 ,(* y 2))) ; vertical line (shorter)

 ;; FIXME: the boxes should be drawn using a separate function

  (make-filled-box-stencil   ;;  pedal D
(cons (- space x) (+ (- space x) box-width))
(cons (+ (- y (/ box-height 2)) d) (+ (+ y (/ box-height 2)) d)))

  (make-filled-box-stencil  ;; pedal C
(cons (+ (- (* space 2) x) box-width) (- (* (+ space box-width) 2) x))
(cons (+ (- y (/ box-height 2)) c) (+ (+ y (/ box-height 2)) c)))

  (make-filled-box-stencil  ;; pedal B
(cons (+ (- (* space 3) x) (* box-width 2)) (- (* (+ space
box-width) 3) x))
(cons (+ (- y (/ box-height 2)) b) (+ (+ y (/ box-height 2)) b)))

  (make-filled-box-stencil  ;; pedal E
(cons space (+ space box-width))
(cons (+ (- y (/ box-height 2)) e) (+ (+ y (/ box-height 2)) e)))

  (make-filled-box-stencil  ;; pedal F
(cons (+ (* space 2) box-width) (* (+ space box-width) 2))
(cons (+ (- y (/ box-height 2)) f) (+ (+ y (/ box-height 2)) f)))

  (make-filled-box-stencil  ;; pedal G
(cons (+ (* space 3) (* box-width 2)) (* (+ space box-width) 3))
(cons (+ (- y (/ box-height 2)) g) (+ (+ y (/ box-height 2)) g)))

  (make-filled-box-stencil  ;; pedal A
(cons (+ (* space 4) (* box-width 3)) (* (+ space box-width) 4))
(cons (+ (- y (/ box-height 2)) a) (+ (+ y (/ box-height 2)) a))


\new Staff {
c1-\markup {

 % This function should take 7 arguments, or
 % the seven pedal indications in one single arg.
  \harp #1 #-1 #0
  }
}




Thanks,
Valentin


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


Re: Does Forbid_line_break_engraver still work?

2008-08-14 Thread Carl D. Sorensen



On 8/14/08 5:01 AM, "Trevor Daniels" <[EMAIL PROTECTED]> wrote:

> Carl
>
> I don't believe tied notes over a bar line inhibit
> line breaks, whether they are inserted manually or
> by the Completion_heads_engraver, even when the
> Forbid-line-break-engraver is present (as it is by
> default.)

The docs say that if Forbid_line_break_engraver is present,
it will inhibit line breaking if music is playing,
as it is with a tied note created by Completion_heads_engraver.

I haven't been able to document that, but I think Dmytro did.

Carl



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


Re: Does Forbid_line_break_engraver still work?

2008-08-14 Thread Mats Bengtsson



Carl D. Sorensen wrote:

Thanks, Mats.  That's the confirmation I was hoping to get, coming from
one who can speak definitively!
  
Not at all! Then you need to figure out what change in the code that 
made the difference.

I just looked at the output from a single example.

  /Mats


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


Conditional breaks

2008-08-14 Thread Mark Austin
Is there any way of including a conditional page break?

What I want it for is in collections of Folk Music. These are short
pieces, typically 32 bars, and generally 2-4 lines of music. What I
don't want is to split a piece of music over two pages; and it's
getting tedious compiling Lilypond; checking the pdf, adding a break
as appropriate and repeatng ad nauseum. What I'd like to be able to do
is mark a tune so as to add a page break before it if the piece does
not fit on the current page.

Mark Austin.

 --
 For Whigs admit no force but argument
 --


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


Re: Does Forbid_line_break_engraver still work?

2008-08-14 Thread Carl D. Sorensen
Thanks, Mats.  That's the confirmation I was hoping to get, coming from
one who can speak definitively!

Carl


On 8/14/08 5:11 AM, "Mats Bengtsson" <[EMAIL PROTECTED]> wrote:

> It seems that things have changed in the 2.11.x releases. It used to be
> that the
> line breaking was determined "before" the note splitting, or at least
> that the line breaking
> algorithm didn't consider the split note as two separate notes. So, if
> you try your example
> with version 2.10.33, you will see what you expected to see. However,
> when I try the
> latest version from the GIT repository, then you will indeed get a line
> break even if the
> Forbid_line_break_engraver is active (which it is by default). You can
> easily verify that
> the Forbid_line_break_engraver still works by commenting out the two lines
> \remove "Note_heads_engraver"
> \consists "Completion_heads_engraver"
>
> This means that you can remove the corresponding passage from the docs.
>
>/Mats
>
>
> Carl D. Sorensen wrote:
>> I'm trying to make a clear example for the GDP docs.
>>
>> According to my understanding, Forbid_line_break engraver should eliminate
>> line breaks at measures where there is a tie generated by the
>> Completion_heads_engraver.
>>
>> In the code below, I can't change where the line break is by including or
>> removing the Forbid_line_break_engraver.  I've tried changing the line-width
>> and the presence or absence of the Forbid_line_break_engraver.  As far as I
>> can see, there is no special requirement to avoid breaking on the tied
>> measure; it's just a standard bar line.
>>
>> Any suggestions as to what I'm doing wrong?  Or is this just a bug?
>>
>> Thanks,
>>
>> Carl
>>
>>
>>
>>
>> \paper{
>>   ragged-right=##f
>>   line-width=10\cm
>>   indent=0\cm
>> }
>>
>> \new Voice \with {
>> \remove "Note_heads_engraver"
>> \consists "Completion_heads_engraver"
>> \consists "Forbid_line_break_engraver"
>> %\remove "Forbid_line_break_engraver"
>> }
>> \relative c'
>> %  { c2. c8 d4 e f g8 a4 b c8 c2 b4 a g16 f4 e d c8. c2 d8}
>> { c4 c c c
>> d d d d
>> e e e e2
>> f4 f f
>> g g g g
>> a a a a2
>> b4 b b
>> }
>>
>>
>>
>> ___
>> lilypond-user mailing list
>> lilypond-user@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-user
>>
>
> --
> =
> Mats Bengtsson
> Signal Processing
> School of Electrical Engineering
> Royal Institute of Technology (KTH)
> 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: \textLengthOn - choosing which note to lengthen

2008-08-14 Thread Carl D. Sorensen



On 8/14/08 7:25 AM, "Chris Snyder" <[EMAIL PROTECTED]> wrote:

>
> Here ya go. This is for section 1.8.1.1. I'd recommend that it be placed
> between the current \textLengthOn example and the Predefined commands
> header.

Chris, thanks for the specific location recommendation.  This makes it
easy for the doc team to assess your contribution and change the docs.
>
> -- begin documentation snippet --
>
> Note that \textLengthOn does not necessarily increase the spacing of
> the note that the text is attached to. Rather, the shortest moment in
> time when the text occurs will get the added space (even if it is
> in another voice).
>
Your proposed text shows that you don't quite understand how
\textLengthOn works from a LilyPond point of view.  Your terminology
is not quite right, so we'll need to change the text a bit before
we put it in the manual.  I hope you'll not mind that.

\textLengthOn applies to a musical moment, not a note.  A musical
moment starts at an instant in time of the score, and includes all
events that occur at that instant.  A musical moment ends when
the next musical moment begins, or when the first event occurs
is not simultaneous with the current moment.

So, in the example, the first musical moment contains the c4 in
the treble cleff, the c1 in the bass clef, and the markup.  The
second musical moment contains the e in the treble clef.  The
effect of \textLengthOn is to make the first musical moment
take as much horizontal space as the markup.

While it appears that \textLengthOn adds space to the shortest
note, this is incorrect.  It is not the duration of the note in
the current moment that matters, but the timing of the first
note to follow the current moment.

> \score {
>\new ChoirStaff <<
>  \new Staff \relative c' {
>\clef treble
>c4 e g e
>  }
>  \new Staff \relative c {
>\clef bass
>\textLengthOn
>c1_\markup \column {
>  "The space is inserted between the first"
>  "and second beat, even though this text"
>  "is attached to the whole-note."
>}
>  }
> }
>
Thanks for the small example -- it's very helpful.  Again, we'll
need to change it a bit some to better show the LilyPond
behavior.

Perhaps this modified version of your example helps to
explain the concept.

\score {
   \new ChoirStaff <<
 \new Staff \relative c' {
   \clef treble
   c4 e g e
 }
 \new Staff \relative c {
   \clef bass
   \textLengthOn
   c8 e2._\markup \column {
 "The musical moment extends from the"
 "e in the bass clef to the e in the"
 "treble clef, so the e in the treble"
 "clef is pushed right to fit this text."
   }
  g8
 }
   >>
}


Please let me know if this explanation has helped you
understand \textLengthOn.  If not, I'll need to better
understand the source of your confusion.

Thanks for your contributions to the documentation process!

Carl



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


[no subject]

2008-08-14 Thread Kieren MacMillan

Hey Graham (et al.):

I'm back out of my rabbit hole for a while...  =)

What can I do to help the docs project? At one point, we were talking  
about me doing some "large scale", "real world" examples — putting  
together a real tutorial on chord name changes, revamping the  
examples on stylesheets, trying to develop comprehensive transposing- 
part guidelines, etc. — and that's still fine by me, if that's the  
best use of my skills and time.


Best wishes,
Kieren.

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


Re: Score with large empty section at the top

2008-08-14 Thread Gilles Sadowski
Hello.

For automatic adjustment of vertical spacing, you could also try what
is explained here:
  
http://lilypond.org/doc/v2.10/Documentation/user/lilypond/Two_002dpass-vertical-spacing#Two_002dpass-vertical-spacing


Best,
Gilles


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


Re: autobeams

2008-08-14 Thread James E. Bailey


Am 14.08.2008 um 13:58 schrieb Jonathan Kulp:

Perhaps even better: don't use the \\ but explicitly

instantiate one of the voices
(related to a recent email discussion).


When I removed the \\, I got errors about clashing columns.  I'll  
check into the explicit voice instantiation thing.  For now I like  
the \oneVoice solution for this example.


The \oneVoice solution did not work for the example from GDP I'm  
working on, though.  The autobeaming still doesn't appear.  Here's  
the original code and then the fix I made for it.  In James'  
example, the \oneVoice fixed stem direction and autobeaming.  In  
this example, there was no problem with stem direction to begin  
with, just with autobeaming.  If you see a more elegant way please  
share :)


explicitly instantiating the voice would be
cadenza = \relative c' {
 c4 d8 << { \voiceOne e f g } \new Voice { \voiceTwo d4. } >>
 \oneVoice g4 f2 g4 g
}

\new GrandStaff <<
 \new Staff { \cadenza c'4 }
 \new Staff {
   #(ly:export (mmrest-of-length cadenza))
   c'4
 }
>>

I'm not a big fan, especially for something so short, because it's so  
much more typing.




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


Re: Score with large empty section at the top

2008-08-14 Thread Chris Snyder

Dominic Neumann wrote:

I think it is standard behaviour.
I remember there was a command to let LilyPond display all the spaces
it uses and its names. But I don´t remember the command and couldn´t
find it by searching ...


Take a look at Notation Reference 4.6.1: "Displaying spacing."

-Chris


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


Re: Score with large empty section at the top

2008-08-14 Thread Dominic Neumann
If you don´t want the wide gap, add
   ragged-bottom = ##t
to your paper section.

Dominic

2008/8/14 Dominic Neumann <[EMAIL PROTECTED]>:
> Hi Maarten,
>
> I think it is standard behaviour.
> I remember there was a command to let LilyPond display all the spaces
> it uses and its names. But I don´t remember the command and couldn´t
> find it by searching ...
>
> Dominic
>
> 2008/8/13 SPAM <[EMAIL PROTECTED]>:
>> I'm transcribing a piece for six brass players in Lilypond and making a
>> complete conductor's score with it. It fits 18 lines on one page (3x6
>> instruments). Because of the title on the first page, it only fits 2x6 on
>> the first page, but the score is aligned at the bottom on the first page
>> leaving a wide gap between the title of the piece and the notes.
>> Is that standard behaviour or is it a bug? And can it be tweaked that the
>> notes start immediately below the title?
>> Output is on , source files
>> are attached and or all separate on 
>>
>> Comments on style are also appreciated.
>>
>> Maarten
>>
>>
>>
>> ___
>> 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


Re: Score with large empty section at the top

2008-08-14 Thread Dominic Neumann
Hi Maarten,

I think it is standard behaviour.
I remember there was a command to let LilyPond display all the spaces
it uses and its names. But I don´t remember the command and couldn´t
find it by searching ...

Dominic

2008/8/13 SPAM <[EMAIL PROTECTED]>:
> I'm transcribing a piece for six brass players in Lilypond and making a
> complete conductor's score with it. It fits 18 lines on one page (3x6
> instruments). Because of the title on the first page, it only fits 2x6 on
> the first page, but the score is aligned at the bottom on the first page
> leaving a wide gap between the title of the piece and the notes.
> Is that standard behaviour or is it a bug? And can it be tweaked that the
> notes start immediately below the title?
> Output is on , source files
> are attached and or all separate on 
>
> Comments on style are also appreciated.
>
> Maarten
>
>
>
> ___
> 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


Re: \textLengthOn - choosing which note to lengthen

2008-08-14 Thread Chris Snyder

Carl Sorensen wrote:
> If you'd like to propose additions to the docs, we'd appreciate it if
> you'd tell us where the addition should go.
>
> Also, in a case like this, a simple example that shows the behavior
> being described can help understand possibly-confusing wording.
> If you could work up a simple example (one bar long) that
> demonstrates the point you're trying to make, I'll add it to the
> documentation.

Here ya go. This is for section 1.8.1.1. I'd recommend that it be placed 
between the current \textLengthOn example and the Predefined commands 
header.


-- begin documentation snippet --

Note that \textLengthOn does not necessarily increase the spacing of
the note that the text is attached to. Rather, the shortest moment in
time when the text occurs will get the added space (even if it is
in another voice).

\score {
  \new ChoirStaff <<
\new Staff \relative c' {
  \clef treble
  c4 e g e
}
\new Staff \relative c {
  \clef bass
  \textLengthOn
  c1_\markup \column {
"The space is inserted between the first"
"and second beat, even though this text"
"is attached to the whole-note."
  }
}
  >>
}


-- end documentation snippet --

Thanks!

-Chris


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


Re: it's all up to you users

2008-08-14 Thread Patrick Horgan

Graham Percival wrote:

[1] Personally, I'd go for the "Fuzziness Force", devoted to
making confused people feel warm and fuzzy.  But I suspect that
other people aren't as fond of fuzzy things as I am... and
besides, people would start calling you "the FF" or "FFers", and
this whole thing started with a rant against abbreviations.  :)
  

I think that's almost it, but it should be Fozzy Force after Fozzy Bear.

Cheers,
- Graham
  

Best Regards

Patrick



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


Re: Stuck, and don't know why.

2008-08-14 Thread Bertalan Fodor (LilyPondTool)
If you really need to insert dozens of musical examples, then I would 
suggest the following:

1. as LilyPond is already downloaded and installed, the first step is right
2. if you don't have Java installed, install it from http://www.java.com
3. install jEdit: 
http://prdownloads.sourceforge.net/jedit/jedit4.3pre15install.exe
4. Start jEdit, go to Plugins menu, Plugin Manager and on the Install 
tab, check the LilyPondTool plugin.
5. If you installed LilyPond to an other place than c:\program 
files\lilypond, go to Plugins > Plugin Options and set the path to 
LilyPond appropriately.
6. Follow http://lilypondtool.organum.hu/129.html for the first score 
with LilyPond.


If you have other questions, ask it on the lilypond-user@gnu.org list.



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


Re: textlentgh on forever

2008-08-14 Thread Mats Bengtsson
Since the predefined macro \textLengthOn uses \override and not \once 
\override,

the setting will apply for all following notes in the same Voice context.

   /Mats

Stefan Thomas wrote:

Dear Lilypondusers,
how can I switch on textLentgthOn for more than one word?


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


--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
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: autobeams

2008-08-14 Thread Jonathan Kulp

Mats Bengtsson wrote:

Why not a \oneVoice, which gives the same result but lets LilyPond 
automatically determine
the stem direction. 


This works perfectly. Thanks!

Perhaps even better: don't use the \\ but explicitly

instantiate one of the voices
(related to a recent email discussion).


When I removed the \\, I got errors about clashing columns.  I'll check 
into the explicit voice instantiation thing.  For now I like the 
\oneVoice solution for this example.


The \oneVoice solution did not work for the example from GDP I'm working 
on, though.  The autobeaming still doesn't appear.  Here's the original 
code and then the fix I made for it.  In James' example, the \oneVoice 
fixed stem direction and autobeaming.  In this example, there was no 
problem with stem direction to begin with, just with autobeaming.  If 
you see a more elegant way please share :)


Jon

p.s. As I mentioned before, this example in the docs is not specifically 
aimed at multiple voices, so another solution would be to remove the 
second voice altogether.  It just bugs me when stuff doesn't work :)

--

% Example from Notation Reference 1.2.6.2

cadenza = \relative c' {
  c4 d8 << { e f g } \\ { d4. } >>
  \oneVoice g4 f2 g4 g
}

\new GrandStaff <<
  \new Staff { \cadenza c'4 }
  \new Staff {
#(ly:export (mmrest-of-length cadenza))
c'4
  }
>>


% My adjustment to make autobeaming work

\version "2.11.55"

cadenza = \relative c' {
  << { c4 d8 e f g g4 f2 g4 g } \\ { s4. d4. s4 } >>
%   g4 f2 g4 g
}

\new GrandStaff <<
  \new Staff { \cadenza c'4 }
  \new Staff {
#(ly:export (mmrest-of-length cadenza))
c'4
  }
>>



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


textlentgh on forever

2008-08-14 Thread Stefan Thomas
Dear Lilypondusers,
how can I switch on textLentgthOn for more than one word?
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: percussion beaters

2008-08-14 Thread Graham Percival
Stefan,

This is a complete non-issue.  The example will be added to the
docs after you send me your next update, and this example has
*been* ready for a week.  You're not supposed to discuss examples
like this in the .itely file anyway.

Work on the issues I told you to work on, and send me the updated
.itely and .ly file.

Cheers,
- Graham


On Thu, 14 Aug 2008 13:14:14 +0200
Mats Bengtsson <[EMAIL PROTECTED]> wrote:

> www.lilypond.org -> Documentation for 2.11 -> Snippet List ->
> Percussion -> Percussion Beaters
> (or SL Percussion according to Graham naming).
> 
>/Mats
> 
> Stefan Thomas wrote:
> > Dear Valentin,
> > but how can I open this file? Where do I find it?
> > I don't have the source-code of the documentation and I don't know
> > how to compile it.
> >
> > 2008/8/14 Valentin Villenave <[EMAIL PROTECTED] 
> > >
> >
> > 2008/8/11 Stefan Thomas <[EMAIL PROTECTED]
> > >:
> >
> > > unfortunately I can't reach the link anymore! I would like to
> > add the
> > > example to the documentation of percussion instruments!
> >
> > Yes, we're experiencing major problems with the LSR. However,
> > this snippet should be available using
> >
> > @lilypondfile[verbatim,lilyquote,texidoc,doctitle]
> > {percussion-beaters.ly }
> >
> > in the source code of the documentation.
> >
> > Cheers,
> > Valentin
> >
> >
> > 
> >
> > ___
> > lilypond-user mailing list
> > lilypond-user@gnu.org
> > http://lists.gnu.org/mailman/listinfo/lilypond-user
> >   
> 
> -- 
> =
>   Mats Bengtsson
>   Signal Processing
>   School of Electrical Engineering
>   Royal Institute of Technology (KTH)
>   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


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


Re: percussion beaters

2008-08-14 Thread Valentin Villenave
2008/8/14 Stefan Thomas <[EMAIL PROTECTED]>:

> but how can I open this file? Where do I find it?
> I don't have the source-code of the documentation and I don't know how to
> compile it.

Oh, I forgot you weren't using the source code... As Mats said, the
snippet is already in the percu-related snippet list on
http://kainhofer.com/~lilypond/input/lsr/lilypond-snippets/Percussion.html

However, if you do want to include it in one of the documentation
pages, please tell me which section it is and I'll see if I can add it
for you (not verbatim though, since it's quite a bunch of postscript
lines).

Cheers,
Valentin


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


Re: percussion beaters

2008-08-14 Thread Mats Bengtsson
www.lilypond.org -> Documentation for 2.11 -> Snippet List -> Percussion 
-> Percussion Beaters

(or SL Percussion according to Graham naming).

  /Mats

Stefan Thomas wrote:

Dear Valentin,
but how can I open this file? Where do I find it?
I don't have the source-code of the documentation and I don't know how 
to compile it.


2008/8/14 Valentin Villenave <[EMAIL PROTECTED] 
>


2008/8/11 Stefan Thomas <[EMAIL PROTECTED]
>:

> unfortunately I can't reach the link anymore! I would like to
add the
> example to the documentation of percussion instruments!

Yes, we're experiencing major problems with the LSR. However, this
snippet should be available using

@lilypondfile[verbatim,lilyquote,texidoc,doctitle]
{percussion-beaters.ly }

in the source code of the documentation.

Cheers,
Valentin




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


--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
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: Does Forbid_line_break_engraver still work?

2008-08-14 Thread Mats Bengtsson
It seems that things have changed in the 2.11.x releases. It used to be 
that the
line breaking was determined "before" the note splitting, or at least 
that the line breaking
algorithm didn't consider the split note as two separate notes. So, if 
you try your example
with version 2.10.33, you will see what you expected to see. However, 
when I try the
latest version from the GIT repository, then you will indeed get a line 
break even if the
Forbid_line_break_engraver is active (which it is by default). You can 
easily verify that

the Forbid_line_break_engraver still works by commenting out the two lines
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"

This means that you can remove the corresponding passage from the docs.

  /Mats


Carl D. Sorensen wrote:

I'm trying to make a clear example for the GDP docs.

According to my understanding, Forbid_line_break engraver should eliminate
line breaks at measures where there is a tie generated by the
Completion_heads_engraver.

In the code below, I can't change where the line break is by including or
removing the Forbid_line_break_engraver.  I've tried changing the line-width
and the presence or absence of the Forbid_line_break_engraver.  As far as I
can see, there is no special requirement to avoid breaking on the tied
measure; it's just a standard bar line.

Any suggestions as to what I'm doing wrong?  Or is this just a bug?

Thanks,

Carl




\paper{
  ragged-right=##f
  line-width=10\cm
  indent=0\cm
}

\new Voice \with {
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
\consists "Forbid_line_break_engraver"
%\remove "Forbid_line_break_engraver"
}
\relative c'
%  { c2. c8 d4 e f g8 a4 b c8 c2 b4 a g16 f4 e d c8. c2 d8}
{ c4 c c c
d d d d
e e e e2
f4 f f
g g g g
a a a a2
b4 b b
}



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


--
=
Mats Bengtsson
Signal Processing
School of Electrical Engineering
Royal Institute of Technology (KTH)
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: percussion beaters

2008-08-14 Thread Stefan Thomas
Dear Valentin,
but how can I open this file? Where do I find it?
I don't have the source-code of the documentation and I don't know how to
compile it.

2008/8/14 Valentin Villenave <[EMAIL PROTECTED]>

> 2008/8/11 Stefan Thomas <[EMAIL PROTECTED]>:
>
> > unfortunately I can't reach the link anymore! I would like to add the
> > example to the documentation of percussion instruments!
>
> Yes, we're experiencing major problems with the LSR. However, this
> snippet should be available using
>
> @lilypondfile[verbatim,lilyquote,texidoc,doctitle]
> {percussion-beaters.ly}
>
> in the source code of the documentation.
>
> Cheers,
> Valentin
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user


Re: Does Forbid_line_break_engraver still work?

2008-08-14 Thread Trevor Daniels

Carl

I don't believe tied notes over a bar line inhibit
line breaks, whether they are inserted manually or
by the Completion_heads_engraver, even when the
Forbid-line-break-engraver is present (as it is by
default.)

Trevor

- Original Message - 
From: "Carl D. Sorensen" <[EMAIL PROTECTED]>

To: "Lilypond-User List" 
Sent: Thursday, August 14, 2008 10:59 AM
Subject: Does Forbid_line_break_engraver still work?


I'm trying to make a clear example for the GDP docs.

According to my understanding, Forbid_line_break engraver should eliminate
line breaks at measures where there is a tie generated by the
Completion_heads_engraver.

In the code below, I can't change where the line break is by including or
removing the Forbid_line_break_engraver.  I've tried changing the line-width
and the presence or absence of the Forbid_line_break_engraver.  As far as I
can see, there is no special requirement to avoid breaking on the tied
measure; it's just a standard bar line.

Any suggestions as to what I'm doing wrong?  Or is this just a bug?

Thanks,

Carl




\paper{
 ragged-right=##f
 line-width=10\cm
 indent=0\cm
}

\new Voice \with {
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
\consists "Forbid_line_break_engraver"
%\remove "Forbid_line_break_engraver"
}
\relative c'
%  { c2. c8 d4 e f g8 a4 b c8 c2 b4 a g16 f4 e d c8. c2 d8}
{ c4 c c c
d d d d
e e e e2
f4 f f
g g g g
a a a a2
b4 b b
}



___
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


Does Forbid_line_break_engraver still work?

2008-08-14 Thread Carl D. Sorensen
I'm trying to make a clear example for the GDP docs.

According to my understanding, Forbid_line_break engraver should eliminate
line breaks at measures where there is a tie generated by the
Completion_heads_engraver.

In the code below, I can't change where the line break is by including or
removing the Forbid_line_break_engraver.  I've tried changing the line-width
and the presence or absence of the Forbid_line_break_engraver.  As far as I
can see, there is no special requirement to avoid breaking on the tied
measure; it's just a standard bar line.

Any suggestions as to what I'm doing wrong?  Or is this just a bug?

Thanks,

Carl




\paper{
  ragged-right=##f
  line-width=10\cm
  indent=0\cm
}

\new Voice \with {
\remove "Note_heads_engraver"
\consists "Completion_heads_engraver"
\consists "Forbid_line_break_engraver"
%\remove "Forbid_line_break_engraver"
}
\relative c'
%  { c2. c8 d4 e f g8 a4 b c8 c2 b4 a g16 f4 e d c8. c2 d8}
{ c4 c c c
d d d d
e e e e2
f4 f f
g g g g
a a a a2
b4 b b
}



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


Re: Proposed syntax change: renaming of \center-align markup command

2008-08-14 Thread Valentin Villenave
2008/8/14 Mats Bengtsson <[EMAIL PROTECTED]>:

> Also, for the people that have (mis-)used \center-align for a single markup,
> they
> won't even notice the change, since it produces the same output in that
> case, even
> though they will have an unnecessary pair of curly braces in their code
> after the change.

Oh, that's right. Let's go for Neil's #1 option then :)

Cheers,
Valentin


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


Re: percussion beaters

2008-08-14 Thread Valentin Villenave
2008/8/11 Stefan Thomas <[EMAIL PROTECTED]>:

> unfortunately I can't reach the link anymore! I would like to add the
> example to the documentation of percussion instruments!

Yes, we're experiencing major problems with the LSR. However, this
snippet should be available using

@lilypondfile[verbatim,lilyquote,texidoc,doctitle]
{percussion-beaters.ly}

in the source code of the documentation.

Cheers,
Valentin


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


Re: Proposed syntax change: renaming of \center-align markup command

2008-08-14 Thread Mats Bengtsson



Graham Percival wrote:


convert-ly would translate \old-command to \new-command.  Or at
least print a warning about "\old-command now means foo".  And
we'll dump a warning about this in NEWS.
  
Also, for the people that have (mis-)used \center-align for a single 
markup, they
won't even notice the change, since it produces the same output in that 
case, even
though they will have an unnecessary pair of curly braces in their code 
after the change.
(See for example the last example of 
http://lilypond.org/doc/v2.10/Documentation/user/lilypond/New-dynamic-marks#New-dynamic-marks

for such an example. This has already been corrected in GDP).

   /Mats


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


Re: Large white space on score

2008-08-14 Thread Peter Johnson


Maarten Deen wrote:
> 
> But lilypond puts the title at the top and the 12 lines of music at the
> bottom 
> of the page, leaving a large open space inbetween, see attached picture.
> 
> Why is this? Is there a way of alining the music to the top?
> 
> 

Maarten,

Try adding "ragged-bottom = ##t" to your main \paper block and then set
between-system-space and between-system-padding to something that works for
you.  There is also a page-spacing-weight factor which adjusts the relative
importance of horizontal and vertical spacing and other settings for the
distance from your titles to the music.  More in Notation Reference 4.1.2.

Peter
-- 
View this message in context: 
http://www.nabble.com/Large-white-space-on-score-tp18970713p18978047.html
Sent from the Gnu - Lilypond - User mailing list archive at Nabble.com.



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


Re: Comments on Learning Manual 3 -- Fundamental concepts

2008-08-14 Thread Mats Bengtsson



Robin Bannister wrote:

Robin Bannister wrote

A:   21 hits for "\context Staff"
B:   14 hits for "\context { \Staff"


I think I get it now. It must be that "\context" is overloaded, does 
two quite different things. Upon meeting a "\context" you must 
categorise it as A or B.
The uninitiated attach no particular significance to the decisive "{" 
or, in my case, the word "block". Especially when they're still 
chewing over \context vs.\new.
The main difference isn't even shown in the list above, namely that A: 
happens within a music expression (i.e. at places where you also can 
have ordinary note names), whereas B: only happens within a \layout{...} 
block.


/Mats


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


Re: autobeams

2008-08-14 Thread Trevor Daniels


There you go - it still happens - another red face!

Thanks, Mats ;)

- Original Message - 
From: "Mats Bengtsson" <[EMAIL PROTECTED]>

To: "Trevor Daniels" <[EMAIL PROTECTED]>
Cc: "Jonathan Kulp" <[EMAIL PROTECTED]>; "James E. Bailey" 
<[EMAIL PROTECTED]>; "Mailinglist lilypond-user" 

Sent: Thursday, August 14, 2008 9:17 AM
Subject: Re: autobeams





Trevor Daniels wrote:


I would use your first solution, Jonathan, and simply
insert a \stemDown:
Why not a \oneVoice, which gives the same result but lets LilyPond 
automatically determine
the stem direction. Perhaps even better: don't use the \\ but explicitly 
instantiate one of the voices

(related to a recent email discussion).


\relative c' {
 \clef bass  <<
   { e8 d d c d8 c \stemDown 4 }
 \\
   { 4 g 4 }
 >>
}

  /Mats






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


Re: it's all up to you users

2008-08-14 Thread Trevor Daniels


Graham Percival wrote Thursday, August 14, 2008 12:28 AM



We now have a good documentation team for lilypond, and a good
number of them are gradually moving into bugfixing and
programming.  The thing we lack -- one of the last "unhealthy"
portions of the lilypond project -- is an "email support" team.
We need more people answering these simple questions, so that
advanced programmers don't do it.

If we could get a dozen people signing up for such duties, it
would be great.  Assuming they're spread across the world and/or
check their emails at random times (ok, that's not realistic, but
bear with me), then simple questions would receive an answer
within two hours.  And since this "User Support Team" wouldn't be
overworked doing documentation, they'd be really polite and
friendly and fuzzy feelings would abound.

Frankly, the answer doesn't even need to be correct.  I mean, if
you /think/ you have the right answer, but aren't completely
certain... answer anyway!  In the worst case, you'll make a
mistake, and advanced user will send a correction in a few hours.
You'll learn from that.  And the questioner will still get a warm
and fuzzy feeling from seeing both your attempted answer and the
correction.  It'll emphasize that you're just another user who is
trying to help out.


OK, doing this might make your face red occasionally,
but believe me, *it is worth it*!  Many's the time I
thought I knew the answer and responded, only to be
gently corrected by Mats, but, boy!, is this the way to
learn?!  You don't forget those lessons!  The key thing
is to express some doubt in your response, if you're
not absolutely sure of your answer - but let's have
more answers flowing from more of you! 


Cheers,
- Graham


Trevor




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


Re: Absolute vs. relative pitches

2008-08-14 Thread Trevor Daniels


Graham Percival wrote Thursday, August 14, 2008 12:42 AM



On Wed, 13 Aug 2008 18:31:16 +0100
"Trevor Daniels" <[EMAIL PROTECTED]> wrote:


John, you wrote Wednesday, August 13, 2008 5:53 PM

> IMNSHO we *must* discuss absolute vs. relative pitches with usage
> cases in the Learning Manual.

I agree with this.  IIRC I wanted to do so but Graham vetoed it, but
maybe he opposed it just in the early sections of the manual.


I still disagree.  One of the big changes in GDP was standardizing
on \relative c'' {} for the example.  Now you want to go back? :(


Not at all.  No one is suggesting changing any of the
examples.  I agree standarising these on relative is right.
The suggestion is simply to discuss the merits and demerits 
of relative and absolute properly, later in the manual.



Some new users found it really confusing when examples were
randomly switching between relative and absolute -- sometimes even
on the same doc page!


I wouldn't mind adding a section to LM 3 about absolute mode, with
usage cases and whatnot.  But I still really think that everything
else in the docs should be \relative.


Great!  We are agreed, then :)


Cheers,
- Graham




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


Re: autobeams

2008-08-14 Thread Mats Bengtsson



Trevor Daniels wrote:


I would use your first solution, Jonathan, and simply
insert a \stemDown:
Why not a \oneVoice, which gives the same result but lets LilyPond 
automatically determine
the stem direction. Perhaps even better: don't use the \\ but explicitly 
instantiate one of the voices

(related to a recent email discussion).


\relative c' {
 \clef bass  <<
   { e8 d d c d8 c \stemDown 4 }
 \\
   { 4 g 4 }
 >>
}

  /Mats



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


Re: autobeams

2008-08-14 Thread Trevor Daniels


Jonathan Kulp wrote Thursday, August 14, 2008 5:50 AM

I had a similar problem with an example I was working on for GDP 
Rhythms, in Notation Reference 1.2.6.2.  If you look at that example, 
you can see that there's a whole series of 8ths that ought to be 
autobeamed but are not.  I couldn't even make them beam properly 
manually.  I ended up sidestepping the issue and removing the extra 
voice, since that example is only meant to show how to make another part 
in a different staff begin at the right place after a cadenza.   I don't 
know why the author of it introduced the complexity of multiple voices 
in that context.


Regarding your example, there were two ways I could get it to beam those 
last two 8ths automatically. One was to move the C in the final chord of 
the bar to the upper voice and allow the multiple-voice passage to last 
for the entire bar, rather than for only the first three beats.  Here:


\version "2.11.55"
\relative { \clef bass << {e8 d d c d8 c c4 } \\ {  4 g 4 a> } >>  }


This makes the beaming work, and all the notes are the same, but it does 
not preserve the original intent of having the final chord  all 
in the lower voice.   I'm sure you found that you could manually beam 
the "d8[ c]" but it doesn't seem like you should have to.


The other way was to leave the  chord intact in the lower voice, 
but put it inside the multi-voice << >> and add a quarter-note skip to 
the upper voice:


\version "2.11.55"
\relative { \clef bass << {e8 d d c d8 c s4 } \\ {  4 g 4 c> } >>  }


This does seem like a workaround, though, as it looks like something 
that ought to work exactly the way you had it the first time.  Anyone 
else see what the problem could be?


I think the problem is this.  The autobeaming rules define
where beams should start and end, but mainly where they
should end.  The rules are defined in scm/auto-beam.scm
and are applied in a Voice context.  In common time, eighth 
note beams end only on half-note boundaries.  Autobeaming 
only kicks in when one of the defined end-points is reached, 
and in these examples the voice is terminated before the 
next half-note boundary is reached.  The common feature in

the 'workarounds' is to add notes or spacers so that one
of the defined beam end-points is reached before the voice
terminates.

This seems to be a drawback of inserting short parallel
voices which probably merits a mention in the docs (that's 
why I'm answering, Graham :)


I would use your first solution, Jonathan, and simply
insert a \stemDown:

\relative c' {
 \clef bass 
 <<

   { e8 d d c d8 c \stemDown 4 }
 \\
   { 4 g 4 }
 >>
}

Trevor



Best,

Jonathan

James E. Bailey wrote:
I don't understand this. Why aren't the last two eighth notes beamed 
together?

\version "2.11.54"
\relative { \clef bass << {e8 d d c d8 c } \\ {  4 g 4} >> a c> } 



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



--
Jonathan Kulp
http://www.jonathankulp.com


___
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


Re: GDP Single-staff polyphony

2008-08-14 Thread Francisco Vila
2008/8/11 Graham Percival <[EMAIL PROTECTED]>:
> Thanks, I applied all your suggestions.

Thank you, Graham, I've been very disconnected and missed this.
-- 
Francisco Vila. Badajoz (Spain)
http://www.paconet.org


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