headers
Michael Welsh Duggan | 1 Feb 2005 03:19
Picon
Favicon

Re: Patch: tie-ing enharmonic variants

Paul Scott <pslist <at> ultrasw.com> writes:

> Kilian A. Foth wrote:
>
>>Paul Scott writes:
>> > Kilian A. Foth wrote:
>> > > >Greetings,
>> > >
>> > >a while back I asked lilypond-user how to engrave a tie between
>> > >enharmonic variants, such as g sharp in one bar and a flat in the next
>> > >after a key change. The reponse was that not only does lilypond not do
>> > >this, but you cannot even typeset the tie manually by \overriding
>> > >something. I was also told that there had been a discussion about the
>> > >question previously, but I cannot find it in the archives - therefore
>> > >allow me to make my proposition here.
>> > >
>> > >I feel that lilypond should not silently refuse to tie enharmonic
>> > >variants if the user explicitly requests it. Choral music is
>> > >frequently notated like this, to help singers through key changes that
>> > >involve shifting from sharp to flat or vice versa. In keyboard music,
>> > >there is no difference between enharmonic variants at all, since there
>> > >is only one key for both. I therefore propose the following patch:
>> > >  > >
>> > What's wrong with just using a slur which should look identical to
>> what > you want?
>> > 
>>
>>Using a slur fails if you want to tie a chord, because it generates
>> only one slur instead of four.  
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Nieuwenhuizen | 1 Feb 2005 09:21
Picon
Gravatar

Re: Dashed slur proposal

Bertalan Fodor writes:

> I've found that dashed slurs are quite ugly. That's because
> output-ps.scm sets the dash length to the property Slur.dashed, but
> the gap between dashes is set to 10*slur.thickness, that is not
> good. I've found that changing output.scm's

> So it is obvious there should be a property called gap length or
> gap-factor to be able to set either:

Yes.  What we'd need is a dash-fraction and dash-period property
instead, see text-spanner.

However, for dashed/dotted slurs to be really nice, the current
builtin postscript dashing is too simplistic.  The path length of the
slur (and text-spanner) should be taken into account to make sure that
begin and end are solid, ie, the slur (or line-) ending must never be
part of a gap.

> Now, the thing I do not know is how to set up an other property.

What is it exactly that you need to know.  What do you miss when
looking at the places where a property (say dashed) is used?

Jan.

--

-- 
Jan Nieuwenhuizen <janneke <at> gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org
(Continue reading)

Permalink | Reply | 10 comments |
headers
Han-Wen Nienhuys | 1 Feb 2005 09:13
Picon
Picon
Favicon

fink, 2.5.10, lilypond-book

gperlist <at> shaw.ca writes:
> fails with
> 
> ! Undefined control sequence.
> l.1 \includegraphics
>                      {lily-203923813-1.eps}%
> 
> I don't really know how lilypond-book and latex live together; here's
> my commands and output.
> 
> simple.lytex:

try including the package graphics.sty

--

-- 

 Han-Wen Nienhuys   |   hanwen <at> xs4all.nl   |   http://www.xs4all.nl/~hanwen
Permalink | Reply | 4 comments |
headers
Kilian A. Foth | 1 Feb 2005 09:34
Picon

Re: Patch: tie-ing enharmonic variants

Han-Wen Nienhuys writes:
 > foth <at> informatik.uni-hamburg.de writes:
 > [...]
 > > 
 > > This changes tie-ing behaviour so that not the exact pitch property
 > > of two candidate notes is compared, but the normalized chromatic
 > > pitch.  (The old behaviour can, of course, be produced by not using
 > > ~ in the first place.)
 > 
 > Does this actually work? IIRC, the Tie code is hard-wired to assume
 > that ties are always horizontal.
 > 

You're right, the tie is still horizontal, i.e. it will end half a
line too low or too high (I lack the expertise to change tie direction
as well). It still looks rather good to me - way better than the
alternative (tieing to an invisible note of the appropriate pitch)
because that would let the tie end much too soon.

--

-- 
Kilian Foth                                    Phone +49 40 42883-2518
AB NATS, FB Informatik                         Fax   +49 40 42883-2515
Universität Hamburg
Vogt-Kölln-Str. 30
22527 Hamburg
Permalink | Reply | 4 comments |
headers
Bertalan Fodor | 1 Feb 2005 10:15
Picon
Favicon

Re: Dashed slur proposal


>However, for dashed/dotted slurs to be really nice, the current
>builtin postscript dashing is too simplistic.  
>
Yes, you're right. But it is better to have a not perfect but tweakable 
feature, than to not have a perfect. :-)

>What is it exactly that you need to know.  What do you miss when
>looking at the places where a property (say dashed) is used?
>  
>
I have the following questions:
The ADD_INTERFACE macro is only for documentation?
Where are the properties of a grob defined?
What is the Lookup::dashed_slur function for?
Are dashed slurs are actually simple curves?
Do I have to modify slur.cc, define-grob-properties.scm, 
define-grobs.scm, lookup.cc, output-*.scm? (And property-init.ly, 
engraver-init.ly,  and examples.)

Bert
Permalink | Reply | 0 comments |
headers
Mats Bengtsson | 1 Feb 2005 10:50
Picon
Picon
Favicon

Re: Patch: tie-ing enharmonic variants

For tie directions, take a look at the list of predefined commands at
http://lilypond.org/doc/v2.4/Documentation/user/out-www/lilypond/Ties.html#Ties
I think you can guess from the name, which command to use to direct it
upwards or downwards, respectively.

    /Mats

Kilian A. Foth wrote:
> Han-Wen Nienhuys writes:
>  > foth <at> informatik.uni-hamburg.de writes:
>  > [...]
>  > > 
>  > > This changes tie-ing behaviour so that not the exact pitch property
>  > > of two candidate notes is compared, but the normalized chromatic
>  > > pitch.  (The old behaviour can, of course, be produced by not using
>  > > ~ in the first place.)
>  > 
>  > Does this actually work? IIRC, the Tie code is hard-wired to assume
>  > that ties are always horizontal.
>  > 
> 
> You're right, the tie is still horizontal, i.e. it will end half a
> line too low or too high (I lack the expertise to change tie direction
> as well). It still looks rather good to me - way better than the
> alternative (tieing to an invisible note of the appropriate pitch)
> because that would let the tie end much too soon.
> 
> 
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mats Bengtsson | 1 Feb 2005 10:46
Picon
Picon
Favicon

Re: fink, 2.5.10, lilypond-book

Which, of course, should be done automatically by lilypond-book.

    /Mats

Han-Wen Nienhuys wrote:
> gperlist <at> shaw.ca writes:
> 
>>fails with
>>
>>! Undefined control sequence.
>>l.1 \includegraphics
>>                     {lily-203923813-1.eps}%
>>
>>I don't really know how lilypond-book and latex live together; here's
>>my commands and output.
>>
>>simple.lytex:
> 
> 
> try including the package graphics.sty
> 
> 

--

-- 
=============================================
	Mats Bengtsson
	Signal Processing
	Signals, Sensors and Systems
	Royal Institute of Technology
	SE-100 44  STOCKHOLM
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sebastiano Vigna | 1 Feb 2005 16:47
Picon

Sorry guys...

...I forgot to set the Insert authorisation for the database... the
result was just "Authorisation denied". Now the DB is open.
--

-- 
Ciao,

                                        seba
Permalink | Reply | 2 comments |
headers
Yuval Harel | 1 Feb 2005 16:59

Re: Patch: tie-ing enharmonic variants

On Tue, 1 Feb 2005 09:34:55 +0100, Kilian A. Foth  
<foth <at> informatik.uni-hamburg.de> wrote:

> Han-Wen Nienhuys writes:
>  > foth <at> informatik.uni-hamburg.de writes:
>  > [...]
>  > >
>  > > This changes tie-ing behaviour so that not the exact pitch property
>  > > of two candidate notes is compared, but the normalized chromatic
>  > > pitch.  (The old behaviour can, of course, be produced by not using
>  > > ~ in the first place.)
>  >
>  > Does this actually work? IIRC, the Tie code is hard-wired to assume
>  > that ties are always horizontal.
>  >
>
> You're right, the tie is still horizontal, i.e. it will end half a
> line too low or too high (I lack the expertise to change tie direction
> as well). It still looks rather good to me - way better than the
> alternative (tieing to an invisible note of the appropriate pitch)
> because that would let the tie end much too soon.
>

Supporting non-horizontal ties could be good for other purposes too - e.g.  
a tie may be slanted
in {\stemUp g2. ~ g2} to avoid the augmentation dot, or in << {<e e'>2 ~  
<e e'>8} \\ {g2 a} >>
to avoid the stem. Even if these collisions are not resolved  
automatically, a manual way to slant the tie could be nice.
Also, ties can cross staves - but that's probably much less common than
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bret Whissel | 1 Feb 2005 22:12
Picon

\partcombine and \lyricsto patch

The attached patches alter part-combine-iterator.cc and
new-lyrics-combine-music-iterator.cc so that \partcombine and \lyricsto
may be used together.

Properties "activeVoicePartOne" and "activeVoicePartTwo" are set to
indicate to which output channel the original part has been directed
(one of "one", "two", "shared", "solo", "null").  The lyric-combiner is
altered to look for a staff name if a voice name lookup fails, and then
tracks the appropriate "activeVoicePartXXX" property if the staff name
lookup succeeds.

If one wishes to set lyrics to the "soprano" voice, input might look
like the following:
<<
  \context Staff = "treble" {
    \set Staff.printPartCombineTexts = ##f
    \partcombine \vcsoprano \vcalto
  }

  \lyricsto "treble.1" \new Lyrics \texta

  \context Staff = "lower" {
    \set Staff.printPartCombineTexts = ##f
    \partcombine \vctenor \vcbass
  }
>>

where \lyricsto "treble.1" indicates the first part-combined part on the
staff named "treble" ("treble.2" would set the voice to the alto part).
The associatedVoice property may be changed, as before, with the added
(Continue reading)

Permalink | Reply | 0 comments |

Gmane