Re: Doc: Reorganize music functions material. (issue1031044)

[Mark Polesky]

patch set 4 is up: http://codereview.appspot.com/1031044


  


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

Re: Doc: LM: Reformat ly code. (issue1056041)

[Mark Polesky]

patch set 4 is up: http://codereview.appspot.com/1056041


  


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

Re: translation problems in website

[Francisco Vila]

2010/5/6 Jean-Charles Malahieude :

> There still remains a /big/ problem:
> I can get back and forth in the split-html versions.
> But, with the big-page versions, as soon as a link contains any accented
> character (e.g "Communauté" for me or "Código fuente" for Paco), it does not
> reach it.
> Sorry not being capable to diagnose why.

We are talking about issue #1036,
http://code.google.com/p/lilypond/issues/detail?id=1036

http://lists.gnu.org/archive/html/lilypond-devel/2010-03/msg00219.html

-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


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

Re: Doc: Reorganize music functions material. (issue1031044)

[percival . music . ca]

The patch looks ok, but I'm getting some weird build errors... quite
possibly the same thing Werner noticed (wherein lilypond-book borks if
it has two identical snippets).

My main goal today was to check Patrick's build system changes, so I'll
have to leave it with this vague warning.  If you can't reproduce it
from a clean build, give me a ping and I'll do a full rebuild and keep a
log tomorrow.

http://codereview.appspot.com/1031044/show


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

Re: translation problems in website

[Francisco Vila]

2010/5/6 Jean-Charles Malahieude :
> There still remains a /big/ problem:
> I can get back and forth in the split-html versions.
> But, with the big-page versions, as soon as a link contains any accented
> character (e.g "Communauté" for me or "Código fuente" for Paco), it does not
> reach it.
> Sorry not being capable to diagnose why.

besides that, can you link to

  out-www/offline-root/Documentation/notation/index.fr.html

from

  out-www/offline-root/Documentation/web/manuals.fr.html

? The link to 'notation' points to accueil.fr.html instead. Same for
every manual in all other languages, I think.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


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

Re: Doc: LM: Reformat ly code. (issue1056041)

[percival . music . ca]

Looks (mostly) good to me, other than the below 2 items.


http://codereview.appspot.com/1056041/diff/33001/27003
File Documentation/learning/fundamental.itely (right):

http://codereview.appspot.com/1056041/diff/33001/27003#newcode1339
Documentation/learning/fundamental.itely:1339: @c TODO: This extended
example (from here to the end of this node)
I don't want any commits to add TODOs to "finished" code; please move
this to your own personal todo list, or add an issue on the tracker for
it.

http://codereview.appspot.com/1056041/diff/33001/27003#newcode2481
Documentation/learning/fundamental.itely:2481: <<
There is *still* an indentation mistake here.  This is the third time
I've pointed it out -- do we disagree on the "two-space indents" rule?

http://codereview.appspot.com/1056041/show


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

Following voices in chords?

[David Kastrup]

Hi, how would I do something like the following _properly_:

{ \clef bass  <<
 { \glissando s4 4 }
 \new Voice { \hideNotes \glissando s4 4  }
 \new Voice { \hideNotes \glissando s4 4 }
  >>
}

Note that this has several deficiencies: We get clashing notecolumn
warnings, and the s4 that is required for proper length glissando lines
takes musical time.  The obvious solution, writing s4*0 instead, does
not change the spacing at all!

Note that this is already better than the snippet version for double
glissandi which attaches a glissando bar to a differently shaped
invisible voice (consequently shifting it), and which does not cater for
chords that need to rearrange noteheads in order to properly fit one
stem.  Rotating the chord notes (rather than picking just the bottom
notes for the hidden voice) and not using \\ caters for the hidden notes
being in the same place as the original ones -- hence the clashing
notecolumns!

I do not actually need this for glissandi, but for following voices from
chord to chord (and I doubt that the midi performance would be all too
hot in case \glissando is translated into midi).

-- 
David Kastrup


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

Translation errors in German documentation

[Marc Hohl]

I found some typos and translation errors in the German documentation
of the current development version.

Should I create a patch to correct them, or should I inform the
current translator about my observations - or both?

Marc


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

Re: translation problems in website

[Graham Percival]

On Fri, May 7, 2010 at 8:45 AM, Francisco Vila  wrote:
> 2010/5/6 Jean-Charles Malahieude :
>
>> There still remains a /big/ problem:
>
> We are talking about issue #1036,
> http://code.google.com/p/lilypond/issues/detail?id=1036
>
> http://lists.gnu.org/archive/html/lilypond-devel/2010-03/msg00219.html

Thanks for identifying it, Francisco.  Jean-Charles: we're not
planning on working on that issue in the near future, sorry.


In addition to that one, there's still a few issues with the fr website:

** Node following `Publications' in menu `Archives' and in sectionning
`Archives des annonces' differ
** `Archives des annonces' doesn't appear in menus
** `Communauté' is up for `Archives des annonces', but has no menu
entry for this node
*** Unknown node in menu entry `Archives' (in
/main/src/lilypond/Documentation/fr/web/community.itexi l. 56 in
@divEnd)


Sorry,
- Graham


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

Aligning single systems?

[David Kastrup]

Hi, for theoretical work it often is necessary to write several short
systems in one line, interspersed with text.

I don't manage to have
a) new systems continue aligned to the previous system in a line, like
when doing
\line { \score { ... \layout {} } some text \score { ... \layout {} } }

It might be possible to fudge stuff with \stopStaff and \startStaff, but
I still can't get the text interspersed.

b) to have interspersed text appear at useful height with relation to
the surrounding score.


An additional problem is when using lilypond-book: there is no baseline
info for the included images, leading to additional nuisances when
images are to be placed in-line.

Would it be possible to have some Staff property, say, baseline-height
that specifies a Staff line to be aligned with the baseline of
surrounding constructs?  If it were #f, we'd get the old behavior, and
of course only one Staff's baseline-height could be heeded within a
StaffGroup.  This might not be easy to make work in lilypond-book, but
at least for interspersed text and staffs all within Lilypond, it might
help.

-- 
David Kastrup



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

Re: Following voices in chords?

[David Kastrup]

Kieren MacMillan  writes:

> Hi David,
>
>> this is already better than the snippet version for double glissandi
>
> Does Carl's recent "multi-gliss" snippet/macro not suffice to do what
> you need?

That keyword does not ring a bell with either Google search or the
Lilypond source tree, nor my memory.  So I could not really tell.

You obviously know better what to feed to what search engine or grep.
Could you lend me a hand?

-- 
David Kastrup


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

Re: Following voices in chords?

[Kieren MacMillan]

Hi David,

> this is already better than the snippet version for double glissandi

Does Carl's recent "multi-gliss" snippet/macro not suffice to do what you need?

Cheers,
Kieren.

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

Re: Following voices in chords?

[Carl Sorensen]

On 5/7/10 7:21 AM, "David Kastrup"  wrote:
> 
> Hi, how would I do something like the following _properly_:
> 
> { \clef bass  <<
>  { \glissando s4 4 }
>  \new Voice { \hideNotes \glissando s4 4  }
>  \new Voice { \hideNotes \glissando s4 4 }
>>> 
> }
> 
> Note that this has several deficiencies: We get clashing notecolumn
> warnings, and the s4 that is required for proper length glissando lines
> takes musical time.  The obvious solution, writing s4*0 instead, does
> not change the spacing at all!

Have you looked at 


I recognize that it takes a different tack than you want, because it only
goes note for note instead of chord for chord.  But it shows the way to get
the spacing you want and to avoid the clashing note columns.

\once \override Glissando #'minimum-length = #5
\once \override Glissando #'springs-and-rods =
   #ly:spanner::set-spacing-rods

is the way to get the spacing.  To avoid the clashing note columns, you
could do

\override NoteColumn #'ignore-collision = ##t

before your function, and

\revert NoteColumn #'ignore-collision

after the function.

It would be pretty simple for you to adjust the inner workings of
chord-glissando.ly to make it work by rotating the chord, rather than by
carving out individual notes.

HTH,

Carl



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

Re: Translation errors in German documentation

[Carl Sorensen]

On 5/7/10 12:36 AM, "Marc Hohl"  wrote:

> I found some typos and translation errors in the German documentation
> of the current development version.
> 
> Should I create a patch to correct them, or should I inform the
> current translator about my observations - or both?

It seems to me that creating a patch is the appropriate thing to do, and
make sure the translator is copied on the emails about the patch.

Thanks,

Carl



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

Re: Following voices in chords?

[David Kastrup]

Carl Sorensen  writes:

> On 5/7/10 7:21 AM, "David Kastrup"  wrote:
>> 
>> Hi, how would I do something like the following _properly_:
>> 
>> { \clef bass  <<
>>  { \glissando s4 4 }
>>  \new Voice { \hideNotes \glissando s4 4  }
>>  \new Voice { \hideNotes \glissando s4 4 }
 
>> }
>> 
>> Note that this has several deficiencies: We get clashing notecolumn
>> warnings, and the s4 that is required for proper length glissando lines
>> takes musical time.  The obvious solution, writing s4*0 instead, does
>> not change the spacing at all!
>
> Have you looked at 
> 

Just right now, after a pointer from Kieren.

> I recognize that it takes a different tack than you want, because it only
> goes note for note instead of chord for chord.  But it shows the way to get
> the spacing you want and to avoid the clashing note columns.
>
> \once \override Glissando #'minimum-length = #5
> \once \override Glissando #'springs-and-rods =
>#ly:spanner::set-spacing-rods
>
> is the way to get the spacing.

Ok, that helps.  Not sure I understand this, though.

> To avoid the clashing note columns, you could do
>
> \override NoteColumn #'ignore-collision = ##t
>
> before your function, and
>
> \revert NoteColumn #'ignore-collision
>
> after the function.

This does not change the composition of the chord?

> It would be pretty simple for you to adjust the inner workings of
> chord-glissando.ly to make it work by rotating the chord, rather than
> by carving out individual notes.

Well, looks like a fair piece of work.  And if one invests all this
work... I guess it would be nicer if one could write   and notes got matched one by one.  And
possibly let \glissando be the same as that spelled-out first
chord.

Putting aside the obvious "patches will be thoughtfully considered" to a
later point of time, anybody with a hunch why this would be a bad idea
and/or terribly complicated to implement and/or leading to a lot of
unpredictable behavior?

Thanks,

-- 
David Kastrup


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

Re: Following voices in chords?

[Carl Sorensen]

On 5/7/10 8:29 AM, "David Kastrup"  wrote:

> Carl Sorensen  writes:
> 
>> I recognize that it takes a different tack than you want, because it only
>> goes note for note instead of chord for chord.  But it shows the way to get
>> the spacing you want and to avoid the clashing note columns.
>> 
>> \once \override Glissando #'minimum-length = #5
>> \once \override Glissando #'springs-and-rods =
>>#ly:spanner::set-spacing-rods
>> 
>> is the way to get the spacing.
> 
> Ok, that helps.  Not sure I understand this, though.
> 
>> To avoid the clashing note columns, you could do
>> 
>> \override NoteColumn #'ignore-collision = ##t
>> 
>> before your function, and
>> 
>> \revert NoteColumn #'ignore-collision
>> 
>> after the function.
> 
> This does not change the composition of the chord?

No -- it just ignores the collision.

> 
>> It would be pretty simple for you to adjust the inner workings of
>> chord-glissando.ly to make it work by rotating the chord, rather than
>> by carving out individual notes.
> 
> Well, looks like a fair piece of work.  And if one invests all this
> work... I guess it would be nicer if one could write  e\glissando g\glissando>  and notes got matched one by one.  And
> possibly let \glissando be the same as that spelled-out first
> chord.
> 
> Putting aside the obvious "patches will be thoughtfully considered" to a
> later point of time, anybody with a hunch why this would be a bad idea
> and/or terribly complicated to implement and/or leading to a lot of
> unpredictable behavior?

I don't have any ideas why it would be a bad idea.  I'd be happy to have the
behavior you describe.

The reason it doesn't work now is that \glissando inside a chord construct
creates an articulation, while \glissando outside a chord construct creates
a separate event.  For me, it was much easier to create a music function
than to dive in and do the repairs necessary to get to the state you
describe.  So I did it.

I appreciate your consistent questioning as to how we might be able to get
LilyPond to behave in a way that seems consistent with our expectations.  I
wish I had the time to understand the internals of parsing better so I could
contribute more in this area.  But I don't, so I do the best I can with the
time I have.

Thanks,

Carl



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

Re: Following voices in chords?

[David Kastrup]

Carl Sorensen  writes:

> On 5/7/10 8:29 AM, "David Kastrup"  wrote:

>> Well, looks like a fair piece of work.  And if one invests all this
>> work... I guess it would be nicer if one could write > e\glissando g\glissando>  and notes got matched one by one.
>> And possibly let \glissando be the same as that spelled-out
>> first chord.
>> 
>> Putting aside the obvious "patches will be thoughtfully considered"
>> to a later point of time, anybody with a hunch why this would be a
>> bad idea and/or terribly complicated to implement and/or leading to a
>> lot of unpredictable behavior?
>
> I don't have any ideas why it would be a bad idea.  I'd be happy to
> have the behavior you describe.
>
> The reason it doesn't work now is that \glissando inside a chord construct
> creates an articulation, while \glissando outside a chord construct creates
> a separate event.  For me, it was much easier to create a music function
> than to dive in and do the repairs necessary to get to the state you
> describe.  So I did it.

In this case, a music function basically is casting a snippet's essence
into something one can use.

> I appreciate your consistent questioning as to how we might be able to
> get LilyPond to behave in a way that seems consistent with our
> expectations.  I wish I had the time to understand the internals of
> parsing better so I could contribute more in this area.  But I don't,
> so I do the best I can with the time I have.

And it's appreciated.  In an ideal world, the snippet corpus would be
without things one would label "hack".

I don't know when I'll have time to look at that one, but it seems
tempting.

-- 
David Kastrup


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

Re: Following voices in chords?

[Graham Percival]

On Fri, May 07, 2010 at 04:29:42PM +0200, David Kastrup wrote:
> Well, looks like a fair piece of work.  And if one invests all this
> work... I guess it would be nicer if one could write  e\glissando g\glissando>  and notes got matched one by one.  And
> possibly let \glissando be the same as that spelled-out first
> chord.
> 
> anybody with a hunch why this would be a bad idea
> and/or terribly complicated to implement and/or leading to a lot of
> unpredictable behavior?

How would this work for chords with a different number of notes?
Like:
   
wanting to match up c-d and g-f ?  I admit that I don't know
off-hand if anybody would ever want to do this, nor what the
musical interpretation would be... I could imagine it possibly
happening with divisi string music, but that would be better
written as separate voices anyway.

Then again, contemporary music tends to do lots of weird stuff, so
I wouldn't want to bet that nobody would ever want to indicate
such a connection between two chords.  Or, at the very least,
something like:
   
but wanting to match up c-e and g-f  (i.e. the "d" is the
non-gliss note, instead of the "e")

Cheers,
- Graham


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

Re: Following voices in chords?

[Carl Sorensen]

On 5/7/10 8:55 AM, "Graham Percival"  wrote:

> On Fri, May 07, 2010 at 04:29:42PM +0200, David Kastrup wrote:
>> Well, looks like a fair piece of work.  And if one invests all this
>> work... I guess it would be nicer if one could write > e\glissando g\glissando>  and notes got matched one by one.  And
>> possibly let \glissando be the same as that spelled-out first
>> chord.
>> 
>> anybody with a hunch why this would be a bad idea
>> and/or terribly complicated to implement and/or leading to a lot of
>> unpredictable behavior?
> 
> How would this work for chords with a different number of notes?
> Like:
>
> wanting to match up c-d and g-f ?  I admit that I don't know
> off-hand if anybody would ever want to do this, nor what the
> musical interpretation would be... I could imagine it possibly
> happening with divisi string music, but that would be better
> written as separate voices anyway.
> 
> Then again, contemporary music tends to do lots of weird stuff, so
> I wouldn't want to bet that nobody would ever want to indicate
> such a connection between two chords.  Or, at the very least,
> something like:
>
> but wanting to match up c-e and g-f  (i.e. the "d" is the
> non-gliss note, instead of the "e")

One is always free to reorder the notes in the chord.  Nothing says that the
notes have to be written in ascending order.

Thanks,

Carl



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

Re: Following voices in chords?

[Carl Sorensen]

On 5/7/10 8:54 AM, "David Kastrup"  wrote:

> Carl Sorensen  writes:
> 
> 
>> I appreciate your consistent questioning as to how we might be able to
>> get LilyPond to behave in a way that seems consistent with our
>> expectations.  I wish I had the time to understand the internals of
>> parsing better so I could contribute more in this area.  But I don't,
>> so I do the best I can with the time I have.
> 
> And it's appreciated.  In an ideal world, the snippet corpus would be
> without things one would label "hack".

Well, I'll work on fixing the hack so it rotates the chords.  I don't think
it's too big a shift.

Hopefully that will get the job done for you, until somebody can get it
fixed right.

Thanks,

Carl



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

Re: Following voices in chords?

[David Kastrup]

Graham Percival  writes:

> On Fri, May 07, 2010 at 04:29:42PM +0200, David Kastrup wrote:
>> Well, looks like a fair piece of work.  And if one invests all this
>> work... I guess it would be nicer if one could write > e\glissando g\glissando>  and notes got matched one by one.  And
>> possibly let \glissando be the same as that spelled-out first
>> chord.
>> 
>> anybody with a hunch why this would be a bad idea
>> and/or terribly complicated to implement and/or leading to a lot of
>> unpredictable behavior?
>
> How would this work for chords with a different number of notes?
> Like:
>
> wanting to match up c-d and g-f ?

Write \glissando 

> I admit that I don't know off-hand if anybody would ever want to do
> this, nor what the musical interpretation would be... I could imagine
> it possibly happening with divisi string music, but that would be
> better written as separate voices anyway.
>
> Then again, contemporary music tends to do lots of weird stuff, so
> I wouldn't want to bet that nobody would ever want to indicate
> such a connection between two chords.  Or, at the very least,
> something like:
>
> but wanting to match up c-e and g-f  (i.e. the "d" is the
> non-gliss note, instead of the "e")

Then write  as the second chord...  I would also expect ties to
try working in specified order rather than doing their own sorting.

A different approach would be if

<< { c e }
   { g f }
   { s d } >>

managed to assemble chords properly (but then putting \glissando in the
individual sequences does not keep the \glissando attached to the
respective notes: the glissando basically remembers only its point of
time within the voice, not its note of attachment).

-- 
David Kastrup



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

Re: Aligning single systems?

[Boris Shingarov]

Hi David,


for theoretical work it often is necessary to write several short

 > systems in one line, interspersed with text.
 
This is exactly what we are doing.

 > I don't manage to have
 > a) new systems continue aligned to the previous system in a line, like
 > when doing
 > \line { \score { ... \layout {} } some text \score { ... \layout {} } }
 
I am not sure I understand what the problem is.
Do you mean having several embedded scores on one line?  Like this:
\markuplines {
  \justified-lines {
    some text
    \score { ... \layout {} }
    more text
    \score { ... \layout {} }
  }
}
What is the functionality missing from this?
 

b) to have interspersed text appear at useful height with relation to

 > the surrounding score.
 
We were able to obtain nice looking results via a combination of
adjustments to baseline-skip, minimum-Y-extent, staff-space, and other
similar standard settings, I can't remember off the top of my head what
they were, but the idea is, achieving it did not require any custom
programming work, nor even Scheme scripting.  What I am struggling
with right now, is the crappy vertical spacing of lines that results. 
Because the "padding" / "spacing" specifications are only specific to
text lines, and embedded scores *are* text lines to the page layout
algorithm, my text-only lines are spaced visually much more tightly
than lines containing embedded scores.  I think the G clef is (at
least partly) to blame.

 > Would it be possible to have some Staff property, say, baseline-height
 > that specifies a Staff line to be aligned with the baseline of
 > surrounding constructs?

Hmm... so it would be relative to what, the bottom of the bounding
rectangle?  Or I think more usefully, to the middle staff line?  so
one could say: "the middle lines of all embedded staves are always 1mm
above the baseline of the text".  That would be way cool, and I don't
see why it would be too hard to implement.
 
Boris
 
 
 
 
 
 
 



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

Re: Aligning single systems?

[Karl Hammar]

David:
> Hi, for theoretical work it often is necessary to write several short
> systems in one line, interspersed with text.
> 
> I don't manage to have
> a) new systems continue aligned to the previous system in a line, like
> when doing
...
> b) to have interspersed text appear at useful height with relation to
> the surrounding score.
>
> An additional problem is when using lilypond-book: there is no baseline
> info for the included images, leading to additional nuisances when
> images are to be placed in-line.

With latex, I've done (see [1], for my tries):

\newcommand{\INL}[1]{\raisebox{-0.8ex}{\includegraphics[height=3ex]{#1}}}
...
The limit of the \emph{Medium} register in all female voices varies
from \INL{op31_fig4.eps}; as a general rule, however,
\INL{op31_fig5.eps} should be looked as the highest note.
...

But I have to hand-tune the \raisebox and the height.

> Would it be possible to have some Staff property, say, baseline-height
> that specifies a Staff line to be aligned with the baseline of
> surrounding constructs?  If it were #f, we'd get the old behavior, and
> of course only one Staff's baseline-height could be heeded within a
> StaffGroup.  This might not be easy to make work in lilypond-book, but
> at least for interspersed text and staffs all within Lilypond, it might
> help.

Good idéa!

What I would need is the total height, and the amount of space
below the staff,

The values are available in some form, since the notation manual
(for v2.13), sec. "4.6.1 Displaying spacing" demonstrates
 \paper { annotate-spacing = ##t }, where one can find numbers for
bottom-of-extent and extent-estimate.

As a workaround one could, if possible, set thoose two heights (with
margins) to fixed values, then you'd only have to hand-tune it once.

Regards,
/Karl Hammar

[1] git://turkos.aspodata.se/musik.git




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

Re: Following voices in chords?

[David Kastrup]

Carl Sorensen  writes:

> On 5/7/10 8:54 AM, "David Kastrup"  wrote:
>
>> Carl Sorensen  writes:
>> 
>> 
>>> I appreciate your consistent questioning as to how we might be able to
>>> get LilyPond to behave in a way that seems consistent with our
>>> expectations.  I wish I had the time to understand the internals of
>>> parsing better so I could contribute more in this area.  But I don't,
>>> so I do the best I can with the time I have.
>> 
>> And it's appreciated.  In an ideal world, the snippet corpus would be
>> without things one would label "hack".
>
> Well, I'll work on fixing the hack so it rotates the chords.  I don't
> think it's too big a shift.

Probably not.

> Hopefully that will get the job done for you, until somebody can get
> it fixed right.

Well, I got "the job done" manually already for this particular job.  It
would probably be a good idea to make your function more visible to the
would-be user as long as no proper fix is in.

With the rotation trick and with the clashing notecolumn warning
removed, there are enough non-trivial components for trickery there to
make this code an interesting template for other tasks even when a
"proper fix" might be available eventually.

-- 
David Kastrup



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

Re: Doc: LM: Reformat ly code. (issue1056041)

[Mark Polesky]

Graham Percival wrote:
> http://codereview.appspot.com/1056041/diff/33001/27003#newcode2481
> Documentation/learning/fundamental.itely:2481: <<
> There is *still* an indentation mistake here.  This is the
> third time I've pointed it out -- do we disagree on the
> "two-space indents" rule?

Graham,

have you not been getting my comment replies?

I've explained this twice now:
http://codereview.appspot.com/1056041/diff/1/3#newcode2537
http://codereview.appspot.com/1056041/diff/24001/25002#newcode2481

Now I will explain it a third time.

The indentation is intentionally wrong.  It represents an
intermediate stage of the input code as new elements are
added, and before they are formatted.  The text is clear
about this and walks the user through the step of fixing the
indentation.

To see this yourself, go to LM 3.4.1 "Soprano and cello":
http://kainhofer.com/~lilypond/Documentation/learning/soprano-and-cello.html

Scroll down past the third example to the paragraph that
starts with "This is looking promising".  Read the next
couple of paragraphs in context:

* * * * * * * * * *

This is looking promising, but the cello part won’t appear
in the score – we haven’t used it in the \score section. If
we want the cello part to appear under the soprano part, we
need to add

  \new Staff \celloMusic

underneath the soprano stuff. We also need to add << and >>
around the music – that tells LilyPond that there’s more
than one thing (in this case, two Staves) happening at once.
The \score looks like this now:

  [ the example with bad indentation ]

This looks a bit messy; the indentation is messed up now.
That is easily fixed. Here’s the complete soprano and cello
template.

  [ the example with good indentation ]

* * * * * * * * * *

- Mark





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

Re: Doc: Reorganize music functions material. (issue1031044)

[n . puttock]

On 2010/05/07 12:20:50, Graham Percival wrote:

The patch looks ok, but I'm getting some weird build errors... quite

possibly

the same thing Werner noticed (wherein lilypond-book borks if it has

two

identical snippets).


No problems here following a clean build.

Cheers,
Neil

http://codereview.appspot.com/1031044/show


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

Re: Doc: LM: Reformat ly code. (issue1056041)

[Graham Percival]

On Fri, May 07, 2010 at 01:31:35PM -0700, Mark Polesky wrote:
> Graham Percival wrote:
> > http://codereview.appspot.com/1056041/diff/33001/27003#newcode2481
> > Documentation/learning/fundamental.itely:2481: <<
> > There is *still* an indentation mistake here.  This is the
> > third time I've pointed it out -- do we disagree on the
> > "two-space indents" rule?
> 
> Graham,
> 
> have you not been getting my comment replies?

Apparently not!

> I've explained this twice now:
> http://codereview.appspot.com/1056041/diff/1/3#newcode2537
> http://codereview.appspot.com/1056041/diff/24001/25002#newcode2481

Huh.  Yes, that makes perfect sense...


... oh, I see the problem now.  I can't (or at least, a year ago I
couldn't) use my google apps account for codereview, so I made a
throwaway gmail account for that, but never set up forwarding.  I
see your replies on that account.

Sorry about this.
- Graham


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

Re: LSR texidocs missing -es suffix

[Neil Puttock]

On 4 May 2010 23:49, Francisco Vila  wrote:

> Yes, putting the suffix had only sense when the same file (located in
> input/texidocs) mixed various translations, now they are kept away in
> our lang/ directories.

Ah yes, I'd completely forgotten they used to be lumped together.

> If your patch looks for texidoc= alone and not for texidoc[lang]= etc
> any more, we should change all texidoc[lang]= string names in all
> [lang]/texidocs snippets, for every [lang].

It only touches .texidoc files which are missing the language
extension, so a blanket change wouldn't be necessary.

Cheers,
Neil


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

Re: Aligning single systems?

[David Kastrup]

"Boris Shingarov"  writes:

> Hi David,
>
>> for theoretical work it often is necessary to write several short
>  > systems in one line, interspersed with text.  
> This is exactly what we are doing. 
>
>  > I don't manage to have
>  > a) new systems continue aligned to the previous system in a line, like
>  > when doing
>  > \line { \score { ... \layout {} } some text \score { ... \layout {} } }
>  
> I am not sure I understand what the problem is. Do you mean having
> several embedded scores on one line?  Like this:
> \markuplines {
>   \justified-lines {
>     some text
>     \score { ... \layout {} }
>     more text
>     \score { ... \layout {} }
>   }
> }
> What is the functionality missing from this?

Make it concrete:

\markuplines {
  \justified-lines {
some text
\score { e''' \layout {} }
more text
\score { c \layout {} }
  }
}

Nothing lines up.  Text is in the sky, music systems are skewed.

>> b) to have interspersed text appear at useful height with relation to
>  > the surrounding score.  
> We were able to obtain nice looking results via a combination of
> adjustments to baseline-skip, minimum-Y-extent, staff-space, and other
> similar standard settings, I can't remember off the top of my head
> what they were, but the idea is, achieving it did not require any
> custom programming work, nor even Scheme scripting.

Sounds not quite easy.  Something like that should be easy, or scores in
markup become hard to use.

>   What I am struggling with right now, is the crappy vertical spacing
> of lines that results. 


>  > Would it be possible to have some Staff property, say,
>  > baseline-height that specifies a Staff line to be aligned with the
>  > baseline of surrounding constructs?
>
> Hmm... so it would be relative to what, the bottom of the bounding
> rectangle?  Or I think more usefully, to the middle staff line?

A specified staff line at specified height might be nice, like bottom
staff line at baseline, or middle staff line at x-height.  But since
staff lines have a fixed distance, maybe just one spec (likely middle
staff line) would be useful enough.

> so one could say: "the middle lines of all embedded staves are always
> 1mm above the baseline of the text".  That would be way cool, and I
> don't see why it would be too hard to implement.

If we had something like that, one would not need to meddle with
paddings and the resulting spurious spacings.

-- 
David Kastrup



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

Re: Doc: Reorganize music functions material. (issue1031044)

[n . puttock]

LGTM.

http://codereview.appspot.com/1031044/show


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

Re: Issue 684: break-align-symbol support

[Neil Puttock]

On 5 May 2010 14:40, Kieren MacMillan  wrote:

> Has there been any progress/thinking towards
>    
> ??

Not from me, I'm afraid, though I might return to it once I've cleared
up all my other half-finished patches. :)

Cheers,
Neil


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

Re: MetronomeMark alignment (once again)!

[Neil Puttock]

On 6 May 2010 20:16, Xavier Scheuer  wrote:

> I'm not a developer but does this mean that:
>
>  1. the "break-align" support is ready for MetronomeMark,
>  2. but that the PATCH has not been applied because MetronomeMark
>     used to align on note columns (this means the notes, right?)
>  3. and you can't make "break-align" work with alignment on notes?

The patch doesn't work properly with full-bar rests and prevents
alignment with note columns.

I posted a similar patch elsewhere which allowed a crude switch
between aligning on notes and prefatory material, but this should be
done automatically depending on where the tempo mark is placed.

> Or is it stated somewhere that tempo indications should align on
> *notes*?  Does Ted Ross' book say something about this?

I only have Gardner Read to hand, and he says the following:

"The initial letter of the term (usually a capital) customarily is
aligned over the meter signature, or—if none is present—over the first
notational element of the measure, such as noteheads, accidentals,
repeat signs, and so on."

Cheers,
Neil


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

Re: Following voices in chords?

[Carl Sorensen]

On 5/7/10 9:37 AM, "David Kastrup"  wrote:

> Carl Sorensen  writes:
> 
>> On 5/7/10 8:54 AM, "David Kastrup"  wrote:
>> 
>>> Carl Sorensen  writes:
>>> 
>>> 
 I appreciate your consistent questioning as to how we might be able to
 get LilyPond to behave in a way that seems consistent with our
 expectations.  I wish I had the time to understand the internals of
 parsing better so I could contribute more in this area.  But I don't,
 so I do the best I can with the time I have.
>>> 
>>> And it's appreciated.  In an ideal world, the snippet corpus would be
>>> without things one would label "hack".
>> 
>> Well, I'll work on fixing the hack so it rotates the chords.  I don't
>> think it's too big a shift.
> 
> Probably not.
> 
>> Hopefully that will get the job done for you, until somebody can get
>> it fixed right.
> 
> With the rotation trick and with the clashing notecolumn warning
> removed, there are enough non-trivial components for trickery there to
> make this code an interesting template for other tasks even when a
> "proper fix" might be available eventually.

Unfortunately, the rotation trick messes up the note values when the chord
is in relative mode.  I haven't been able to figure out a better hack to do
it, so I guess we're stuck with the existing chord-glissando for now.

Thanks,

Carl



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

Re: MetronomeMark alignment (once again)!

[Carl Sorensen]

On 5/7/10 3:35 PM, "Neil Puttock"  wrote:
> 
> I only have Gardner Read to hand, and he says the following:
> 
> "The initial letter of the term (usually a capital) customarily is
> aligned over the meter signature, or notational element of the measure, such as noteheads, accidentals,
> repeat signs, and so on."

Ross says

" The tempo marking is put slightly above the top staff. The left side of
the first letter in the marking is vertically aligned with the left side of
the time signature."


Stone says:
"[Tempo indications] are placed above the music."

Stone does give some specific rules about showing equivalent durations when
time signature changes (and Read uses a practice that doesn't follow Stone).

I'd guess that there aren't well-defined standards here.

Thanks,

Carl



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

fixing the LM "verse and refrain" example

[Mark Polesky]

*** This refers to LM 3.2.3 "Voices and vocals" ***

Trevor Daniels wrote:
> I put this in after several questions on -user about how
> this should be done, but I wasn't very happy with it.  If
> you can come up with a better way of coding a solo verse
> going into a two-part refain let's change it.

Well, the proper way of doing it requires (I think) this
rather advanced \layout block:

  \layout {
ragged-right = ##t
\context {
  \RemoveEmptyStaffContext
  \override VerticalAxisGroup #'remove-first = ##t
}
  }

I'd be surprised if anyone was okay with having that in the
LM, but in either case, what's there now needs to be removed
or replaced.  Of the two solutions presented, the nested
contexts in the first are too convoluted, and the method of
using two \score blocks (given in the second solution) is
semantically incorrect.

I've attached a solution here.  Have a look at it and let me
know what you think.

- Mark


  \version "2.13.20"

global = {
  \key g \major
  \time 3/4
  s2.*2
  \break
  \time 2/4
  s2*2
  \bar "|."
}

SoloNotes = {
  \clef "treble"
  \relative g' {
g4 g g |
b4 b b |
  }
  R2*2 |
}
SoloLyrics = \lyricmode {
  One two three |
  four five six |
}

SopranoNotes = {
  \clef "treble"
  R2.*2 |
  \relative c'' {
c4 c |
g4 g |
  }
}
SopranoLyrics = \lyricmode {
  la la |
  la la |
}

BassNotes = {
  \clef "bass"
  R2.*2 |
  \relative c {
c4 e |
d4 d |
  }
}
BassLyrics = \lyricmode {
  dum dum |
  dum dum |
}

\score {
  <<
\new Voice = "SoloVoice" << \global \SoloNotes >>
\new Lyrics \lyricsto "SoloVoice" \SoloLyrics

\new ChoirStaff <<
  \new Voice = "SopranoVoice" << \global \SopranoNotes >>
  \new Lyrics \lyricsto "SopranoVoice" \SopranoLyrics

  \new Voice = "BassVoice" << \global \BassNotes >>
  \new Lyrics \lyricsto "BassVoice" \BassLyrics
>>
  >>
  \layout {
ragged-right = ##t
\context {
  \RemoveEmptyStaffContext
  \override VerticalAxisGroup #'remove-first = ##t
}
  }
}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Some engraver brainstorming (was: Following voices in chords?)

[David Kastrup]

Had a rather sleepless night after starting coding yesterday evening.
And came up with some ideas.

Idea#1 (that which I started coding on) is rather straightforward:
replace all the data structures in the glissando_engraver by deques and
work with them in the obvious manner.

Now what if I want two glissando lines from a 3-note chord to another
one.  Think think think.  So maybe make the engraver just responsible
for one glissando.  Then I write

\glissando \glissando

and have two lines connecting c-d and g-g.  How to do that?  Well,
simplest is by using two engravers.  One accepts notes until it is full
and leaves the rest for the next engraver, and the same thing for the
connecting notes.  Nice thing is that you can tweak both glissandi
separately.

However, two engravers is an ugly interface, and one might to need more.
So the next idea is that the engraver derives from a base class
"cloneable_engraver" and the additional engraver instances are handled
mostly automatically.

The engraver can just check if it has resources free and if it doesn't,
it says something like:

  if (line) // we already started a line
clone.delegate(event);

delegate checks whether there is a clone already, and if so delegates
the event to it.  If not, it creates a clone.

And if we are at the end note time, we have something like
  if (!end_line) // we already ended the line
clone.finish(...)

This is all rather half-baked and fuzzy, but the idea is to just keep
most of the existing code around and just deal with cloning when
necessary.

Now here comes the interesting thing: basically, all stuff that works
with \new Voice { \hideNotes repeat-what-we-already-did-elsewhere } is
an incredibly ugly crutch.

And hard to do, to boot.  So why not obliterate it completely?  For most
tweakable constructs, there is some motivation to use them in a separate
instance without moving everything around.

So how about the ultimate tweak: using a separate engraver?  We can't
have overlapping slurs with a single engraver, for example.  But if we
write something like

 

and use @1 with the scope of a tweak, and let it use the engraver of
subvoice 1 (a subvoice having its own engraver copies that get to handle
basic events just from its own subvoice), then it becomes possible to
use parallel slurs in one voice.

That way, the individual engravers need just to cater for a single
entity at one time, as they do now.  More generality, code as simple as
previously.

It might even be conceivable to move events to a subvoice of a different
Voice/Staff and do cross-staff beams/voices in that way.  However, that
would be a non-local operation and likely quite harder to get right
reliably.

Of course, all this tastes of "goto" in that it would be a nightmare to
translate into MusicXML and its ilk.  But the \hideNotes in separate
Voice construct works just by chance (as long as the hidden constructs
are similar enough to have exactly the same spacing) and also is not
nice to put into MusicXML.  And a pain to document in snippets.

And make no mistake: something like this is _needed_ all the time.

So much for the nightly brainstorm.  Have to go to a rehearsal now.

-- 
David Kastrup



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