date:20130729

Hi Urs (et al.),

> But I think fingerings would be good to have for this kind of benchmark.
> So Kieren, you wrote that this is 'the' Beethoven sonata you actually played, 
> so do you have some fingerings around to insert?

I have a huge number of "editorial markings", mostly entered by my teacher at 
the time.
I would be happy to have these in a separate file to include as necessary, but 
they don't (IMO) belong in the "stylesheet" proper.

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

Re: stylesheets, defaults, and other in-Pond-erables

Hi Urs (et al.),

> a)
> Do you want LilyPond to achieve the results of the benchmark tests by 
> 'automatic engraving', i.e. only with general overrides and settings? Or will 
> you accept local tweaks too?

I envision an ongoing iteration of two stylesheet sets and a tweaks file:

1. Lilypond "House Style". This set of stylesheets will get us as close as 
possible to our benchmark(s) with no local tweaks. In a perfect world, these 
are distributed with the application source/binary. These would be the 
stylesheets against which revisions would be tested, features suggested and 
introduced, etc.

2. Henle (or Barenreiter or Peters or…) "House Style". This will change global 
settings (like fonts, spacing, etc.) to make our default output "virtually 
identical" to the original model(s), without resorting to "composition-specific 
tweaks".

3. Specific "edition file". This would be a file accompanying the "_notes.ily" 
file for a particular piece (e.g., Beethoven Op 10 No 3), with appropriate 
editorial markings, manual/local tweaks, etc., that would take #2's "virtually 
identical" and turn it into "indistinguishable".

I intend to spend at least 75% of my time on #1, at least 24% of my time on #2, 
and only if I happen to get to #3 will I put remaining ergs into it.

> b)
> When comparing to the benchmark scores do you want the LilyPond scores look 
> exactly like their models or 'as good as' their models?

#1 should make it look "as good as".
#2 should make it look "almost exactly like".
#3 would make it look "exactly like".

Does that make sense?

> In addition to these questions I have a suggestion: If you are going to have 
> a set of multiple style sheets and example scores I'd highly recommend to put 
> it into a Git repository which allows others to contribute through pull 
> requests.
> I repeat my offer to do this in the context of openlilylib.org where it would 
> be a good fit. We could host everything there which doesn't directly go into 
> LilyPond proper.
> This could also a good place to present the results.

I'm happy to keep working on these stylesheets in that way, as long as someone 
else administers this (including hand-holding me through the process of setting 
up Git).

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

Re: Henle piano template

No, these don't, but I think that fingerings in itself _do_ belong in there, 
and if the original ones from Henle are copyrighted ...



Kieren MacMillan  schrieb:

>Hi Urs (et al.),
>
>> But I think fingerings would be good to have for this kind of
>benchmark.
>> So Kieren, you wrote that this is 'the' Beethoven sonata you actually
>played, so do you have some fingerings around to insert?
>
>I have a huge number of "editorial markings", mostly entered by my
>teacher at the time.
>I would be happy to have these in a separate file to include as
>necessary, but they don't (IMO) belong in the "stylesheet" proper.
>
>Cheers,
>Kieren.
>___
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Henle piano template

Hi Urs,

Amazing — thanks for this.
Once I've recompressed from my (incredible) week in the wilderness, I'll give 
these some serious consideration and adapt/enhance the stylesheet appropriately.

Thanks!
Kieren.

On 2013-Jul-23, at 04:59, Urs Liska  wrote:

> Am 16.07.2013 20:23, schrieb Kieren MacMillan:
>> Hello all,
>> 
>> I'm getting close with my Henle piano stylesheet(s) — see attached.
>> Once this is ready, I'm going to document it and put it up on the Lilyblog.
>> 
>> I think the last thing I need is an "oval BarNumber enclosure" (see photo).
>> Can anyone help with that?
>> 
>> Thanks,
>> Kieren.
>> 
>> 
>> 
>> 
>> ___
>> lilypond-user mailing list
>> 
>> lilypond-user@gnu.org
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
> Hi Kieren,
> 
> now I've finally laid hand on my copy of Henle's Beethoven Sonatas 
> (Just to be sure: it's a two volume edition, number 32, (c) 1952/80, the 
> preface is signed with 'Winter 1975/76')
> 
> If I'm now going through it and do some nitpicking this of course doesn't 
> mean I'm less impressed by it than before ...
> I compare to a laser printout of a file compiled with LilyPond 2.17.22.
> 
> Interestingly, all issues I saw myself are actually differences from the 
> original model:
>   • The "Presto" is somewhat too tight at the staff, and possibly 
> slightly too wide.
> Correction: This has improved between 2.17.18 and 2.17.22 (although the font 
> is still wider)
>   • M. 4 (both hands) Fermata and prolongation dot are too tight.
>   • The inter-staff space in the third system is too small.
> This doesn't only look strange by itself, but the cross-staff octaves in m. 
> 16/17 are really problematic
>   • The staccato dots in m. 25 and 29 should be placed inside the staff
> There are a few more things I now notice in direct comparison:
>   • The fonts of Dynamics and Text Scripts are astonishingly similar
> (which may be one of the reasons why the overall impression is so convincing)
>   • (not suprisingly) there are many little differences in the way slurs 
> are attached to notes.
> In particular I think that Henle tends to start stem-side slurs much closer 
> to the notehead
> see for example
> - the initial upbeat
> - upbeat to m. 5
> - l.h. m. 31-32
> This tends to result in a tighter impression.
>   • Longer phrasing slurs may be slightly irregular, e.g. the ones over 
> m. 5-6
> This allows to 'enclose' the notes tighter through a curve that couldn't be 
> expressed by a simple bezier expression.
>   • The 'cresc.' in m. 18 isn't whited out (can you say that?) in Henle
> -> There I definitely prefer your LilyPond version.
> Differences to the musical text (of my copy?):
>   • m. 22: the topmost f sharp should be parenthesized
>   • The chord at the end of m. 15 shouldn't have a staccato
>   • In m. 31 a 'sf' is missing on the second crotchet
> And finally: Shouldn't you consider to include the fingerings too?
> Keep up the good work!
> Best
> Urs
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user


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

Re: Henle piano template

Hi Urs,

> No, these don't, but I think that fingerings in itself _do_ belong in there, 
> and if the original ones from Henle are copyrighted ...

This is my vision.

1. Each of the following hierarchically inherits from (i.e., includes) the one 
above:

Lilypond.ily
Score.ily
PianoStaff.ily
Lilypond_piano_solo.ily
Lilypond_piano_solo_letter.ily, Lilypond_piano_solo_A4.ily, 
Lilypond_piano_solo_letter_landscape.ily, …

This would be the point at which the default Lilypond user would \include a 
"house style" (e.g., Lilypond_piano_solo_letter.ily) to engrave their basic 
piano solo parts.

Then we'd have

Henle_piano_concert.ily

or some such name. This would be in place of Lilypond_piano_solo_letter.ily 
(etc.), and would be included if you wanted that "Henle Beethoven urtext" look. 
Finally, we have

Beethoven_Op10No3_manuscript.ily
Henle_Beethoven_Op10No3_Winter19751976_editorials.ily

and you'd have a file

Henle_Beethoven_Op10No3_Winter19751976.ly
\include Henle_piano_concert.ily
\include Beethoven_Op10No3_manuscript.ily
\include Henle_Beethoven_Op10No3_Winter19751976_editorials.ily

Yes?

So fingerings (which are NOT in the manuscript, as far as I know) would be 
included in Henle_Beethoven_Op10No3_Winter19751976_editorials.ily only, not the 
main stylesheet (Henle_piano_concert.ily).

Of course, in order to make the main stylesheet as good as possible, we need to 
have fingerings in there (via the \include structure I've outlined above), so 
that we can tweak everything accordingly. To avoid the copyright problem, I 
would do this (which, ultimately, is a superior structure anyway):

Henle_Beethoven_Op10No3_Winter19751976.ly
\include Henle_piano_concert.ily
\include Beethoven_Op10No3_manuscript.ily
\include Henle_Beethoven_Op10No3_Kieren_editorials.ily

Right?

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

optional transposition triggered by an external file?

2013-07-29 Thread Marc Hohl


Hello list,

for my current project I have some scores located in
individual files:

A.ly
B.ly
C.ly

which can be compiled independently, and a latex file
containing calls like this

\lilypondfile{A.ly}

[... some text ...]

\lilypondfile{B.ly}

[... even more text ...]

\lilypondfile{C.ly}

This works fine.

Now I want to include an appendix for transposing instruments
(Saxophone in e flat etc.) where all the files are transposed
accordingly.

Now my (probably way too complicated and crude) idea sounds like this:

I need a way to define an optional variable that controls (if defined)
the transposition so I can say, for example:

\begin{appendix}
\chapter{For Bb instruments}
\begin{lilypond}
#(define transposeTo d)
\include{A.ly}
\end{lilypond}

\begin{lilypond}
#(define transposeTo d)
\include{B.ly}
\end{lilypond}

...
\end{appendix}

As an alternative, the #(define ...) stuff could be hidden in a file
transposeToBes.ily and the above calls change to

\begin{appendix}
\chapter{For Bb instruments}
\begin{lilypond}
\include{transposeToBes.ily}
\include{A.ly}
\end{lilypond}

\begin{lilypond}
\include{transposeToBes.ily}
\include{B.ly}
\end{lilypond}

...
\end{appendix}

Is this feasible, or am I overlooking the obvious?
I like the idea of having compilable standaloe files for each
piece of music, so this is what I want to achieve.

Regards,

Marc

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

Re: aleatoric / frame engraver revisited

On Sun, Jul 21, 2013 at 3:29 PM, David Nalesnik wrote:

> Hi,
>
> I recently replied to an old thread with an updated version of an engraver
> for frames.  Only, the message doesn't show up in the archived thread here:
> http://www.mail-archive.com/lilypond-user@gnu.org/msg70166.html  I'm not
> sure why this has happened.
>
> The message along with .png can be viewed here, but the .ly file appears
> as binary data.
>
> http://lists.gnu.org/archive/html/lilypond-user/2013-07/msg00373.html
>
> I will attach the .ly file here so it will be accessible in the archives.
>
> Sorry for any inconvenience!
>
> --David
>

Here's the latest version.  Note that it's written to work with the current
development version (2.17.22).  There are some comments in the file
indicating how to convert it to work with earlier versions (including
2.17.21).  Adapting it to 2.16 might be trickier.

The problem with vertical spacing I noted in the message linked to above is
resolved.  (Turns out it actually was an issue of needing a function for
pure height.)

There is still the issue with the frame being sized to contain dynamics but
then pushing them aside.  This happens because the frame is an inside-staff
object, while dynamics are outside-staff objects.  I'm guessing that
LilyPond doesn't allow for resolution of this predicament.  (Hopefully, I'm
wrong.)  One workaround is shown in the example.

There is now better horizontal spacing, so this is usable with barlines.

The arrow on the extender line can be removed, and the bracket can be drawn
beneath the staff.  Don't know why you'd want to, but there it is.

If you'd like text above the extender line, just add it to a spacer.

Once again, the example shows some of the modifications you can make.

Please let me know if you run into problems with this, or have suggestions.
 Please note that this is an attempt to create serviceable garden-variety
frame notation, not to support every idiosyncratic notation you might see.

Hope this is helpful!

--David

frameEngraver25.ly
Description: Binary data
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: aleatoric / frame engraver revisited

One more thing--


On Mon, Jul 29, 2013 at 9:36 AM, David Nalesnik wrote:

>
> [...]
>
The arrow on the extender line can be removed, and the bracket can be drawn
> beneath the staff.  Don't know why you'd want to, but there it is.
> [...]
>

The bracket also can be removed.

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

Re: feature request: abs-fontsize available for all text grobs

Hi Jan-Peter and David,

>From what I can tell, this is a complete and wonderfully elegant solution to 
>my request — thank you.
I will be sending funds to both of you soon.

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

Re: stylesheets, defaults, and other in-Pond-erables

Am 29.07.2013 15:50, schrieb Kieren MacMillan:

Hi Urs (et al.),

a)
Do you want LilyPond to achieve the results of the benchmark tests by
'automatic engraving', i.e. only with general overrides and settings? Or will
you accept local tweaks too?

I envision an ongoing iteration of two stylesheet sets and a tweaks file:

1. Lilypond "House Style". This set of stylesheets will get us as close as
possible to our benchmark(s) with no local tweaks. In a perfect world, these are
distributed with the application source/binary. These would be the stylesheets against
which revisions would be tested, features suggested and introduced, etc.

2. Henle (or Barenreiter or Peters or…) "House Style". This will change global settings (like
fonts, spacing, etc.) to make our default output "virtually identical" to the original model(s),
without resorting to "composition-specific tweaks".

3. Specific "edition file". This would be a file accompanying the "_notes.ily" file for a
particular piece (e.g., Beethoven Op 10 No 3), with appropriate editorial markings, manual/local tweaks, etc., that
would take #2's "virtually identical" and turn it into "indistinguishable".

I intend to spend at least 75% of my time on #1, at least 24% of my time on #2,
and only if I happen to get to #3 will I put remaining ergs into it.

b)
When comparing to the benchmark scores do you want the LilyPond scores look
exactly like their models or 'as good as' their models?

#1 should make it look "as good as".
#2 should make it look "almost exactly like".
#3 would make it look "exactly like".

Does that make sense?

LGTM.

In addition to these questions I have a suggestion: If you are going to have a
set of multiple style sheets and example scores I'd highly recommend to put it
into a Git repository which allows others to contribute through pull requests.
I repeat my offer to do this in the context of openlilylib.org where it would
be a good fit. We could host everything there which doesn't directly go into
LilyPond proper.
This could also a good place to present the results.

I'm happy to keep working on these stylesheets in that way, as long as someone
else administers this (including hand-holding me through the process of setting
up Git).

I'll gladly do this.
More privately.

Urs

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

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

Re: feature request: abs-fontsize available for all text grobs

2013-07-29 Thread David Kastrup

Kieren MacMillan  writes:

> Hi Jan-Peter and David,
>
> From what I can tell, this is a complete and wonderfully elegant
> solution to my request — thank you.
> I will be sending funds to both of you soon.

Before you do any such step, you'd better check that you are not sending
funds the wrong way.  While I have proposed a solution I consider more
elegant as a response to Jan-Peter posting actually working code, I have
only very roughly sketched that solution without bothering to turn it
into working code.

Without the ocular proof in the form of running code, "I think I can do
better" does not really seem to warrant a prize.

All the best

-- 
David Kastrup

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

shiftDuration and partial

2013-07-29 Thread Stjepan Horvat

hi guys..di you realize that shiftDuration doesn't convert the partial
part..?!
is this a bug?

for example:

\shiftDuration #1 #0 { c4 d e f } -> c8 d e f
but \shiftDuration #1 #0 { \partial 4 c4 d e f } -> c8 d | f g

-- 
*Nesmotren govori kao da mačem probada, a jezik je mudrih iscjeljenje.
Izreke 12:18*
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: shiftDuration and partial


Am 29.07.2013 17:26, schrieb Stjepan Horvat:

hi guys..di you realize that shiftDuration doesn't convert the partial
part..?!
is this a bug?

for example:

\shiftDuration #1 #0 { c4 d e f } -> c8 d e f
but \shiftDuration #1 #0 { \partial 4 c4 d e f } -> c8 d | f g

I'm not sure, but I think that \partial 4 isn't technically a duration 
such as c4 or r4.

If that's right it wouldn't be a but but a limitation.

HTH
Urs

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

Re: shiftDuration and partial

2013-07-29 Thread David Kastrup

Urs Liska  writes:

> Am 29.07.2013 17:26, schrieb Stjepan Horvat:
>> hi guys..di you realize that shiftDuration doesn't convert the partial
>> part..?!
>> is this a bug?
>>
>> for example:
>>
>> \shiftDuration #1 #0 { c4 d e f } -> c8 d e f
>> but \shiftDuration #1 #0 { \partial 4 c4 d e f } -> c8 d | f g
>>
> I'm not sure, but I think that \partial 4 isn't technically a duration
> such as c4 or r4.
> If that's right it wouldn't be a but but a limitation.

It is technically a duration, but it is stored in a "partial-duration"
music property instead of a "duration" property and thus is not affected
by scaling.

Which seems somewhat weird.  But it's been this way always since the
PartialSet event has been created in

commit 743267e6df7253daa9eded70c6c2736902111511
Author: Neil Puttock 
Date:   Sun Sep 26 00:43:29 2010 +0100

Fix #372.

Thanks to Carl for providing the inspiration for this patch.

* input/regression/auto-beam-partial-grace.ly:

  new regtest

* input/regression/display-lily-tests.ly:

  remove TODO for scaled duration \partial test

* lily/partial-iterator.cc (new file):

  use a simple music iterator to calculate the correct measurePosition
  setting, and warn for \partial used after the start of a score

* scm/define-music-display-methods.scm:

  simplify display method for partial: since the new music object `PartialSe
  carries the original duration from the parser, extra code for converting
  moments to durations is no longer required

* scm/define-music-properties.scm (all-music-properties):

  add property for \partial, partial-duration

* scm/define-music-types.scm (music-descriptions):

  add PartialSet

* scm/ly-syntax-constructors.scm (partial):

  change constructor to allow 'origin to be set directly (used by iterator
  to signal warning message)

  use PartialSet


I think it could reasonably safe be replaced with just "duration" (and
thus would transform under shiftDurations), but the usefulness is likely
somewhat limited since \partial may only be used at the beginning of a
piece for some reason.

-- 
David Kastrup


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

letterspacing control

Hello all,

Is there a letterspacing parameter I can adjust?
A search of the archives turned up only questions (and old ones at that).

In my Beethoven template, for example, I'm hacking it like this:

title = \markup \override #'(word-space . 1) \line { S O N A T E }

But I'd much rather have direct control of the letterspacing.

Thanks,
Kieren.

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

Re: aleatoric box / frameEngraver

Hi Karol,

On Sat, Jul 20, 2013 at 6:57 AM, Karol Majewski  wrote:

>
> OK, so have repeat signs in \markup \Score. Now I need the extender. How
> can I modify David's function to start the extender without frame? For
> example:
>
>
>
> c'4 \extenderStart s4*2 \extenderStop
>
Again, I think the best course of action here is not to omit the frame;
rather, you would replace the frame with repeat-bar stencils.

The problem that I'm facing is that I can't find a convenient function in
the barline interface to produce a barline stencil.  It's possible to quote
massive portions of scm\bar-line.scm in the .ly file and then make some
adaptations to the print function for Frame and the width function for
FrameStub (see the latest version of the file at
http://www.mail-archive.com/lilypond-user@gnu.org/msg83197/frameEngraver25.ly).
That works, but it's just too awful.

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

Re: letterspacing control

Hi Kieren,


On Mon, Jul 29, 2013 at 12:39 PM, Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hello all,
>
> Is there a letterspacing parameter I can adjust?
> A search of the archives turned up only questions (and old ones at that).
>
> In my Beethoven template, for example, I'm hacking it like this:
>
> title = \markup \override #'(word-space . 1) \line { S O N A T E }
>
> But I'd much rather have direct control of the letterspacing.
>
>
I believe you'll find something int the following thread which could help
you do this:
http://www.mail-archive.com/lilypond-devel@gnu.org/msg47691.html

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

Re: Henle piano template

2013-07-29 Thread PMA


Urs Liska wrote:

No, these don't, but I think that fingerings in itself _do_ belong in there, 
and if the original ones from Henle are copyrighted ...

It seems to me that the only fingerings
properly belonging in an Urtext edition
are those of the composer.  If he / she
supplied none, then _none_.

PA

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

Re: Henle piano template

Hi Peter,

> It seems to me that the only fingerings properly belonging in an Urtext 
> edition
> are those of the composer.  If he / she supplied none, then _none_.

Agreed.
The Henle Preface states that Beethoven's fingering is indicated in italics — I 
can (and will) include those in the Beethoven_Op10No3_notes.ily file, and other 
fingerings in their appropriate "edition tweaks" file(s).

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

Re: Henle piano template



Hi  Kieren,

unfortunately I don't understand everything completely:

Am 29.07.2013 16:07, schrieb Kieren MacMillan:

Hi Urs,


No, these don't, but I think that fingerings in itself _do_ belong in there, 
and if the original ones from Henle are copyrighted ...

This is my vision.

1. Each of the following hierarchically inherits from (i.e., includes) the one 
above:

 Lilypond.ily
 Score.ily
 PianoStaff.ily
 Lilypond_piano_solo.ily
 Lilypond_piano_solo_letter.ily, Lilypond_piano_solo_A4.ily, 
Lilypond_piano_solo_letter_landscape.ily, …

This would be the point at which the default Lilypond user would \include a "house 
style" (e.g., Lilypond_piano_solo_letter.ily) to engrave their basic piano solo 
parts.


LGTM.

Then we'd have

 Henle_piano_concert.ily


OK. Had to remind myself that 'concert' is a paper format...

or some such name. This would be in place of Lilypond_piano_solo_letter.ily (etc.), and 
would be included if you wanted that "Henle Beethoven urtext" look. Finally, we 
have

 Beethoven_Op10No3_manuscript.ily
 Henle_Beethoven_Op10No3_Winter19751976_editorials.ily


What exactly do you mean by 'manuscript' and 'editorials'?
Manuscript in the sense of 'bare musical text' or literally Beethoven's
manuscript? Or style tweaks relevant to that concrete score?
And editorials: editorial markings or styles for that score?

and you'd have a file

 Henle_Beethoven_Op10No3_Winter19751976.ly
 \include Henle_piano_concert.ily
 \include Beethoven_Op10No3_manuscript.ily
 \include Henle_Beethoven_Op10No3_Winter19751976_editorials.ily

Yes?

So fingerings (which are NOT in the manuscript, as far as I know) would be 
included in Henle_Beethoven_Op10No3_Winter19751976_editorials.ily only, not the 
main stylesheet (Henle_piano_concert.ily).


Maybe I'm completely wrong, but _if_ I see it right, I'd strongly oppose.
If you imagine a workflow where you separate information from the
manuscript from later (editorial) additions that will be appropriate in
many cases. But I'm strongly against mixing engraving and editing in
your project.
What you are proposing is a set of style sheets affecting the engraving,
and this should in no way impose any way to organize the editing process.
But maybe I'm seeing this completely wrong.
Could you please say something more specific about how you intend these
files? Maybe some sample entries?

Of course, in order to make the main stylesheet as good as possible, we need to 
have fingerings in there (via the \include structure I've outlined above), so 
that we can tweak everything accordingly. To avoid the copyright problem, I 
would do this (which, ultimately, is a superior structure anyway):

 Henle_Beethoven_Op10No3_Winter19751976.ly
 \include Henle_piano_concert.ily
 \include Beethoven_Op10No3_manuscript.ily
 \include Henle_Beethoven_Op10No3_Kieren_editorials.ily

Right?


Well, depends on your answers to my previous questions ;-)

Best
Urs


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





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

Re: Henle piano template

Hi Urs,

> What exactly do you mean by 'manuscript' and 'editorials'?

'Manuscript' is what Beethoven himself wrote, or (by huge consensus of multiple 
editors across multiple engraving houses) is generally understood to have meant.
'Editorials' is what some specific editor (e.g., the Henle editor) added for a 
specific edition: fingerings, courtesy accidentals, etc.

> Or style tweaks relevant to that concrete score?
> And editorials: editorial markings or styles for that score?

Editorial markings (e.g., fingering not added by Beethoven) and the like could 
be put into a file like

Beethoven_Op10No3_Henle_Winter19751976_editorials.ily

Plate adjustments (e.g., the specific whiteout-ing and placement of the ff in 
m.22), etc. — what you call "style tweaks relevant to that concrete score" — 
could be put directly into the main output file:

Beethoven_Op10No3_Henle_Winter19751976.ly
\include Beethoven_Op10No3_Henle_Winter19751976_editorials.ily

or included separately still:

Beethoven_Op10No3_Henle_Winter19751976.ly
\include Beethoven_Op10No3_Henle_Winter19751976_tweaks.ily
\include Beethoven_Op10No3_Henle_Winter19751976_editorials.ily

> I'm strongly against mixing engraving and editing in your project.

+1
I'm trying to "completely" separate content from presentation (although I find 
it extremely difficult to do well, given Lilypond's current toolkit — I know 
you're working on improving that!).

> What you are proposing is a set of style sheets affecting the engraving,
> and this should in no way impose any way to organize the editing process.

Correct: the editing should happen only on the last step, after the "basic 
Henle piano music house style" has been achieved through stylesheets.

> Could you please say something more specific about how you intend these 
> files? Maybe some sample entries?

It will no doubt become clearer as I finalize the file set — expect that 
sometime later this week.

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

Re: Henle piano template


Am 29.07.2013 20:04, schrieb PMA:

Urs Liska wrote:
No, these don't, but I think that fingerings in itself _do_ belong in 
there, and if the original ones from Henle are copyrighted ...

It seems to me that the only fingerings
properly belonging in an Urtext edition
are those of the composer.  If he / she
supplied none, then _none_.
But I think what we are aiming at here is a reproduction of a given 
score/edition, in the current case Henle's Edition of Beethoven op. 10/3.
Whether an Urtext edition should or should not contain editorial 
fingerings - or whatever editorial decisions you might to name - isn't 
the question at hand. This is a complex issue which would probably have 
been answered quite differently if you ask it 1950, 1980 or today. I 
really vote for working towards the 'style', at least at the moment.
And for that the fingering style of Henle's edition should be part of 
the challenge, especially as good engraving of fingerings isn't trivial.


Urs


PA

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



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

Re: Henle piano template

2013-07-29 Thread PMA


Urs Liska wrote:

Am 29.07.2013 20:04, schrieb PMA:

Urs Liska wrote:

No, these don't, but I think that fingerings in itself _do_ belong in
there, and if the original ones from Henle are copyrighted ...

It seems to me that the only fingerings
properly belonging in an Urtext ed
are those of the composer. If he / she
supplied none, then _none_.

But I think what we are aiming at here is a reproduction of a given
score/edition, in the current case Henle's Edition of Beethoven op. 10/3.
Whether an Urtext edition should or should not contain editorial
fingerings - or whatever editorial decisions you might to name - isn't
the question at hand. This is a complex issue which would probably have
been answered quite differently if you ask it 1950, 1980 or today. I
really vote for working towards the 'style', at least at the moment.
And for that the fingering style of Henle's edition should be part of
the challenge, especially as good engraving of fingerings isn't trivial.

Urs


True, the question at hand had not invited my remark.
It had, tho, stirred up my old impression that Henle's
use of "fingerings by..." reduces their "Urtext" claim to
falsehood.  Perhaps I'd have interpreted the term less
strictly, had I not as a pianist counted on blank space
to scribble in _my_ fingerings.

PA


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

Re: Slurs end point need to be different when going up & down

2013-07-29 Thread Eluze

MarcM wrote
> If we compare slurs in original scores. We can see that when the second
> note included in the slur is going up, the end point of the slur ends on a
> south west point. 

 
> 
> When the interval goes down, the end point of the slur ends on a south
> east point of the note.

 
> 
> Slurs in lilypond are pretty close when the internal is going up. However
> when the interval is going down, the end point is such that the slur
> appears to miss the note:
 
>  
> 
> I was initially going to tweak the slur but we should not have to do that
> for every slur going down.

I think there are lots of styles to attach slurs to noteheads or stems and I
don't know of valid rules.

where is your example from? I know other scores where slurs look quite
different.

if you like you can specify or propose a new style as a feature request.

Eluze



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Slurs-end-point-need-to-be-different-when-going-up-down-tp148490p148534.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Henle piano template


Am 29.07.2013 22:20, schrieb PMA:

Urs Liska wrote:

Am 29.07.2013 20:04, schrieb PMA:

Urs Liska wrote:

No, these don't, but I think that fingerings in itself _do_ belong in
there, and if the original ones from Henle are copyrighted ...

It seems to me that the only fingerings
properly belonging in an Urtext ed
are those of the composer. If he / she
supplied none, then _none_.

But I think what we are aiming at here is a reproduction of a given
score/edition, in the current case Henle's Edition of Beethoven op. 
10/3.

Whether an Urtext edition should or should not contain editorial
fingerings - or whatever editorial decisions you might to name - isn't
the question at hand. This is a complex issue which would probably have
been answered quite differently if you ask it 1950, 1980 or today. I
really vote for working towards the 'style', at least at the moment.
And for that the fingering style of Henle's edition should be part of
the challenge, especially as good engraving of fingerings isn't trivial.

Urs


True, the question at hand had not invited my remark.
It had, tho, stirred up my old impression that Henle's
use of "fingerings by..." reduces their "Urtext" claim to
falsehood. 
"Urtext" is a fiction anyway in 95% of the cases. What would you 
consider "Urtext" when you have a manuscript, a fair copy, an original 
edition controlled by the composer, a personal copy of the OE with 
corrections, and another, later manuscript with other readings than the 
OE or the corrected copy?
Or (as is often the case with Chopin for example) if you have an 
original edition and several copies of that edition with different 
additions by the composer (for example embellishments for different pupils)?


I think there can't be such a thing like a perfect edition. But an 
edition should strive as hard as possible to account for how the printed 
score relates to the (different) sources. "Critical edition" is probably 
a much more honest term to what one can achieve.
And in such a context fingerings don't compromise the claim at all - if 
it is clear which fingerings are authentic and which aren't.



Perhaps I'd have interpreted the term less
strictly, had I not as a pianist counted on blank space
to scribble in _my_ fingerings.
That's true. I have more and more got used to not write any fingerings 
at all (I usually find them simply distracting). And the less fingerings 
the editors printed the less black spots I have to 'mute' mentally. When 
I pick a copy from the time with my first piano teacher I'm usually 
shocked: He let me copy his fingerings, and that means that in 
complicated passages I have fingerings attached to nearly all notes! I 
really can't play from these scores anymore. I was quite surprised when 
I had a Bach score at the piano that I found it quite difficult, but 
after erasing all the pencil fingerings I could practically play it from 
sight again.


PA




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

Re: Henle piano template


Am 29.07.2013 20:53, schrieb Kieren MacMillan:

Hi Urs,


What exactly do you mean by 'manuscript' and 'editorials'?

'Manuscript' is what Beethoven himself wrote, or (by huge consensus of multiple 
editors across multiple engraving houses) is generally understood to have meant.
'Editorials' is what some specific editor (e.g., the Henle editor) added for a 
specific edition: fingerings, courtesy accidentals, etc.


Or style tweaks relevant to that concrete score?
And editorials: editorial markings or styles for that score?

Editorial markings (e.g., fingering not added by Beethoven) and the like could 
be put into a file like

 Beethoven_Op10No3_Henle_Winter19751976_editorials.ily

Plate adjustments (e.g., the specific whiteout-ing and placement of the ff in m.22), etc. 
— what you call "style tweaks relevant to that concrete score" — could be put 
directly into the main output file:

 Beethoven_Op10No3_Henle_Winter19751976.ly
 \include Beethoven_Op10No3_Henle_Winter19751976_editorials.ily

or included separately still:

 Beethoven_Op10No3_Henle_Winter19751976.ly
 \include Beethoven_Op10No3_Henle_Winter19751976_tweaks.ily
 \include Beethoven_Op10No3_Henle_Winter19751976_editorials.ily


I'm strongly against mixing engraving and editing in your project.

+1
I'm trying to "completely" separate content from presentation (although I find 
it extremely difficult to do well, given Lilypond's current toolkit — I know you're 
working on improving that!).


What you are proposing is a set of style sheets affecting the engraving,
and this should in no way impose any way to organize the editing process.

Correct: the editing should happen only on the last step, after the "basic Henle 
piano music house style" has been achieved through stylesheets.


Could you please say something more specific about how you intend these files? 
Maybe some sample entries?

It will no doubt become clearer as I finalize the file set — expect that 
sometime later this week.
I think I'll wait for that to show up. As I'm still not really sure what 
you mean I might criticize the wrong things ...
If you find a way to elegantly input different editorial layers 
separately, I'd be the first to be happy.
'Manuscript' might not be the best wording though. I think what you are 
referring to is something like the 'main source'.
That's for example what a renowned Schoenberg editor told me. When I 
asked him how to select which source to use as the main source he argued 
that one sometimes has to be quite pragmatic: just use the source as the 
main one that requires the smallest number of documented readings and 
deviations.

I think this is what you are referring to here.
And in our special case this main source would be the Henle edition in 
its entirety.
If you want to separate this into manuscript and editorial additions you 
would actually have to redo the whole editorial process - which actually 
isn't necessary for what we're actually after.


Best
Urs


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



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

Re: Henle piano template

2013-07-29 Thread PMA


Urs Liska wrote:

"Urtext" is a fiction anyway in 95% of the cases. What would you
consider "Urtext" when you have a manuscript, a fair copy, an original
edition controlled by the composer, a personal copy of the OE with
corrections, and another, later manuscript with other readings than the
OE or the corrected copy?
Or (as is often the case with Chopin for example) if you have an
original edition and several copies of that edition with different
additions by the composer (for example embellishments for different
pupils)?

Fair enough, except that with fingerings by somebody centuries
after a composer's death, the term "Urtext" just hits like a slap --
as though the term "original" meant, oh, anything.  "Perfect" is
beside the point.

I think there can't be such a thing like a perfect edition. ...



Perhaps I'd have interpreted the term less
strictly, had I not as a pianist counted on blank space
to scribble in _my_ fingerings.

That's true. I have more and more got used to not write any fingerings
at all (I usually find them simply distracting). And the less fingerings
the editors printed the less black spots I have to 'mute' mentally. When
I pick a copy from the time with my first piano teacher I'm usually
shocked: He let me copy his fingerings, and that means that in
complicated passages I have fingerings attached to nearly all notes! I
really can't play from these scores anymore. I was quite surprised when
I had a Bach score at the piano that I found it quite difficult, but
after erasing all the pencil fingerings I could practically play it from
sight again.

A hefty argument for printing _no_ fingerings -- except to report the
composer's suggestions, for whatever insight these might convey
(hand-differences in this regard notwithstanding).

PA

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

A spacing issue

2013-07-29 Thread Rachael Thomas Carlson

Hello:

I am having an issue with spacing.  I sent an email out a couple days
ago without any responses (except my own responses).  I thought that I
had solved my \markup spacing issue but I was wrong.  I am days away
from finishing this score and I am at a bottleneck with this spacing
issue.  At the root of the problem is my inability to get \markup
TextScript to not require space.  I would really like it if I could
input markup and have it not worry about colliding with other objects.
I have attached a lilypond file (the example was a little too big to put
it in the email as is) and a png showing this issue.  I am at a loss.
If someone could put me in the right direction that would be fantastic.

You will notice in the png that the line forces the space between the
bass clef staff and the tab staff to increase.  I do not want this line
to take up any extra space.

Thank you,
Rachael
<>\version "2.16.2"
\layout {
  indent=0\mm
  ragged-right = ##t
}
<<
  \new GrandStaff <<
  \new Staff <<
\clef "treble"
{a1 \break
a1}
  >>
  \new Staff <<
\clef "bass"
{a,1
a,1}
  >>
>>
  \new TabStaff
  <<
\tabFullNotation
{1^\markup { \draw-line #'(0 . 9) }
1 }
  >>
>>

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

Re: Slurs end point need to be different when going up & down

2013-07-29 Thread MarcM


My example comes from the transcription for Violin of the piece "La plus que
lente" from Debussy
http://javanese.imslp.info/files/imglnks/usimg/3/3a/IMSLP212816-SIBLEY1802.20456.9d77-39087017285851violin.pdf



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Slurs-end-point-need-to-be-different-when-going-up-down-tp148490p148539.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Slurs end point need to be different when going up & down

2013-07-29 Thread Eluze


My example comes from the transcription for Violin of the piece "La plus que
lente" from Debussy
http://javanese.imslp.info/files/imglnks/usimg/3/3a/IMSLP212816-SIBLEY1802.20456.9d77-39087017285851violin.pdf

take a look at the attached exerpts from your file below - is this
consistent behavior? 

my personal opinion isn't important, but I wouldn't follow this style.

Eluze
 
 



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Slurs-end-point-need-to-be-different-when-going-up-down-tp148490p148540.html
Sent from the User mailing list archive at Nabble.com.

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

Re: Slurs end point need to be different when going up & down

2013-07-29 Thread MarcM


Yes there are some cases where the anchor is not consistent. There is an
effort though to connect the notes together.
With lilypond the slur seems to miss the notes when going down. 
  



--
View this message in context: 
http://lilypond.1069038.n5.nabble.com/Slurs-end-point-need-to-be-different-when-going-up-down-tp148490p148541.html
Sent from the User mailing list archive at Nabble.com.

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

Re: A spacing issue

2013-07-29 Thread Nick Payne

On 30/07/13 07:44, Rachael Thomas Carlson wrote:

Hello:

I am having an issue with spacing.  I sent an email out a couple days
ago without any responses (except my own responses).  I thought that I
had solved my \markup spacing issue but I was wrong.  I am days away
from finishing this score and I am at a bottleneck with this spacing
issue.  At the root of the problem is my inability to get \markup
TextScript to not require space.  I would really like it if I could
input markup and have it not worry about colliding with other objects.
I have attached a lilypond file (the example was a little too big to put
it in the email as is) and a png showing this issue.  I am at a loss.
If someone could put me in the right direction that would be fantastic.

You will notice in the png that the line forces the space between the
bass clef staff and the tab staff to increase.  I do not want this line
to take up any extra space.

This works with 2.17.23. I think the syntax is ok for 2.16.2.

\version "2.16.2"
\layout {
  indent=0\mm
  ragged-right = ##t
  \context {
\Score
  \override StaffGrouper #'staffgroup-staff-spacing =
  #'((basic-distance . 11)
 (padding . -10)
 (stretchability . 0))
  }
}
<<
  \new GrandStaff
  <<
\new Staff <<
  \clef "treble"
  {a1 \break
  a1}
>>
\new Staff <<
  \clef "bass"
  {a,1
  a,1}
>>
  >>
  \new TabStaff
  <<
\tabFullNotation
{1^\markup { \draw-line #'(0 . 9) }
1 }
  >>
>>
<>___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: optional transposition triggered by an external file?

2013-07-29 Thread David Rogers

Marc Hohl  writes:

> Hello list,
>
> for my current project I have some scores located in
> individual files:
>
> A.ly
> B.ly
> C.ly
>
> which can be compiled independently, and a latex file
> containing calls like this
>
> \lilypondfile{A.ly}
>
> [... some text ...]
>
> \lilypondfile{B.ly}
>
> [... even more text ...]
>
> \lilypondfile{C.ly}
>
> This works fine.
>
> Now I want to include an appendix for transposing instruments
> (Saxophone in e flat etc.) where all the files are transposed
> accordingly.
>
> Now my (probably way too complicated and crude) idea sounds like this:
>
> I need a way to define an optional variable that controls (if defined)
> the transposition so I can say, for example:
>
> \begin{appendix}
> \chapter{For Bb instruments}
> \begin{lilypond}
> #(define transposeTo d)
> \include{A.ly}
> \end{lilypond}
>
> \begin{lilypond}
> #(define transposeTo d)
> \include{B.ly}
> \end{lilypond}
>
> ...
> \end{appendix}


I've never tried this. Is it even possible to define things in the latex
file that are then parsed by Lilypond? If it is possible, perhaps adding
a special line inside each of A.ly, B.ly, and C.ly, which contains
\transpose C \transposeTo . That looks to me [if it was going to work at
all] as if your .ly files would then refuse to work if you ever forgot
to define \transposeTo in your latex file - but maybe it's worth it.

-- 
David R

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

Re: Henle piano template