Beam thickness

Mats Bengtsson wrote on 01 February 2008 16:07
(to -user)
>
> Trevor Daniels wrote:
> >
> > By default the beam thickness is set to 0.48 of a
> > staff-space (Note the IR is wrong is this respect;
> > it says in units of line-thickness, which is normally
> > right, but not for beams).  So to move a beam with
> > its top edge aligned to a position with its centre
> > aligned you'll need to move it an extra 0.24.
> >
> >
> Right! This is a property name that's used on
> many different layout objects
> and is included in several different interfaces.
> The problem with the
> documentation is the old usual one that there's
> only one documentation
> string per property name, no matter how many
> different uses there are
> for the same property name. Strangely enough,
> there's also a property
> called beam-thickness, that's only used for
> StemTremolo objects.
> I cannot see why the property name "thickness"
> could not be used in that
> application as well. On the other hand, it may be
> less obvious what

Re: Beam thickness

2008/2/1, Trevor Daniels <t.daniels <at> treda.co.uk>:

> If we are to propose a change it might be better to change
> the property name for the thickness of all beams to be
> "beam-thickness", which has the descriptive string, "Beam
> thickness, measured in staff-space units", and a default
> value of 0.48.  It would seem ideal! However, it is a
> property of the stem-tremolo-interface, not the
> beam-interface, so the change is not likely to be easy.  Or
> is it?

This is a good idea.

The interfaces merely serve to group and limit the properties, so you
don't get all properties listed on all grobs; it should not be a
problem.

--

-- 
Han-Wen Nienhuys - hanwen <at> xs4all.nl - http://www.xs4all.nl/~hanwen

[patch] first-clef property

Hi,

When typesetting ancient music, one may want to produce two editions:
eventually one with original clefs, as found in the manuscripts, and an
other one with new fashioned clefs. It is also custom in the later case
to print first the ancient clef (which bears some extra meaning, for
instance which particular instrument should play that part), then the
modern one, at the beginning of a piece.

I use a customized version of the \clef command, which allows specifying
two clefs, eg. \clef "soprano/treble". If some option is set, it behaves
like \clef "soprano", otherwise it behaves like \clef "treble", except
at the beginning of the first line, where a little soprano clef is
printed before the treble clef. The first-clef property makes it
possible to detect when it is the beginning of the piece.

The attached patch adds this first-clef grob property. May I apply it?
I understand that it may not be preferable to add code that presumably
would be useful to a single person... but this patch is very tiny 
And I've seen some posts showing interest for this kind of feature.

Nicolas

_______________________________________________

Re: [patch] first-clef property

Hmmh, maybe I do not understand correctly, but wouldn't it be possible to 
get equivalent behavior with tagged music?  I mean, put both \clef 
commands ('\clef "soprano"' and '\clef "treble"') into the code, put 
different tags on each of them, and then "turn" them "on/off" or switch 
between the two editions by filtering the music for the proper tags.

Anyway, wouldn't it be nicer to have some kind of scheme macro that 
expands to code that prints an incipit?  Your "first clef" could then be 
just part of the incipit that the macro creates.  And maybe the clef's 
name either could passed as argument to the scheme macro.  Or, 
alternatively, you set an, say, "original-clef" property that the macro 
recognizes and accordingly acts upon.

Greetings,
Juergen

On Fri, 1 Feb 2008, Nicolas Sceaux wrote:

> Hi,
>
> When typesetting ancient music, one may want to produce two editions:
> eventually one with original clefs, as found in the manuscripts, and an
> other one with new fashioned clefs. It is also custom in the later case
> to print first the ancient clef (which bears some extra meaning, for
> instance which particular instrument should play that part), then the
> modern one, at the beginning of a piece.
>
> I use a customized version of the \clef command, which allows specifying
> two clefs, eg. \clef "soprano/treble". If some option is set, it behaves
> like \clef "soprano", otherwise it behaves like \clef "treble", except

Re: [patch] first-clef property

Le 2 févr. 08 à 01:48, Juergen Reuter a écrit :

> Hmmh, maybe I do not understand correctly, but wouldn't it be  
> possible to get equivalent behavior with tagged music?  I mean, put  
> both \clef commands ('\clef "soprano"' and '\clef "treble"') into  
> the code, put different tags on each of them, and then "turn" them  
> "on/off" or switch between the two editions by filtering the music  
> for the proper tags.

\tag does not solve the first-clef detection problem, but the two  
editions
problem, about which the proposed patch is not about. I know about \tag,
and also that in the end one have to use \removeFromTag or \keepWithTag.
After years experimenting with that, I don't find it very practical when
applied to clef, because of its verbosity. Less LilyPond instructions
==> more maintainable. And I have many thousands of LilyPond loc to
maintain.

> Anyway, wouldn't it be nicer to have some kind of scheme macro that  
> expands to code that prints an incipit?  Your "first clef" could  
> then be just part of the incipit that the macro creates.  And maybe  
> the clef's name either could passed as argument to the scheme  
> macro.  Or, alternatively, you set an, say, "original-clef" property  
> that the macro recognizes and accordingly acts upon.

As I understand it, incipits are hackingly achieved using the
instrument name. I want instrument names to be defined separately
from incipit (they are not the same thing, there is no serious
reason to bind them, beside purely technical ones):

RE: GDP: NR 1.1 Piano Templates

> David Fedoruk wrote 02 February 2008 05:30
 (to -user)

> The "Piano Centered Dynamics" template in 
> particular is overwhelming.
> Perhaps separating the pedal performer out from 
> the rest would make
> this template less overwhelming.
> 

Piano-centered dynamics are very commonly required
when writing piano music.  This would be much simpler
to achieve if the two Dynamics contexts created in 
the template were available by default.  All that 
is required to achieve this is to add the two 
Dynamics contexts to engraver-init.ly and 
performer-init.ly respectively.  The template then
becomes very simple, and almost self-explanatory.
This seems a trivial but very worth-while change.

Trevor D 

Re: [patch] first-clef property

Nicolas Sceaux:
...
> \tag does not solve the first-clef detection problem, but the two  
> editions problem, about which the proposed patch is not about.
> I know about \tag,
...

I also find \tag messy and there is no "else" part either.

> > Anyway, wouldn't it be nicer to have some kind of scheme macro that  
> > expands to code that prints an incipit?  Your "first clef" could  
> > then be just part of the incipit that the macro creates.  And maybe  
> > the clef's name either could passed as argument to the scheme  
> > macro.  Or, alternatively, you set an, say, "original-clef" property  
> > that the macro recognizes and accordingly acts upon.
> 
> As I understand it, incipits are hackingly achieved using the
> instrument name. I want instrument names to be defined separately
> from incipit (they are not the same thing, there is no serious
> reason to bind them, beside purely technical ones):
> 
> \new Staff <<
>    \global
>    \set Staff . instrumentName = \markup { The instrument name }
>    \clef "xyz" %% automagically set the incipit clef
>    { ... the notes ... }
>  >>
> 
> How could you make the mix of the two?
> 

Re: [patch] first-clef property

Am Freitag, 1. Februar 2008 schrieb Nicolas Sceaux:
> When typesetting ancient music, one may want to produce two editions:
> eventually one with original clefs, as found in the manuscripts, and an
> other one with new fashioned clefs. It is also custom in the later case
> to print first the ancient clef (which bears some extra meaning, for
> instance which particular instrument should play that part), then the
> modern one, at the beginning of a piece.
>
> The attached patch adds this first-clef grob property. May I apply it?
> I understand that it may not be preferable to add code that presumably
> would be useful to a single person... 

Actually, we're already two  
I'm transcribing some old pieces by Schubert, who wrote the vocal voices using 
soprano/alto/tenor clef, while modern typesetting practice uses only the 
treble clef for these voices. Now, I want to make two editions, one with the 
original clefs, the other with modern clefs (but the original clefs as 
incipits). So, you see, I'm having exactly the same problem.

I thought about using tags, but that's really messy and prone to breaking 
(since there is no "else" part in the tag, so you can either remove one part 
or not remove it, but not have something else instead).

Cheers,
Reinhold

--

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria

Re: [patch] first-clef property

On Sat, 2 Feb 2008, Nicolas Sceaux wrote:

> ...
>> Anyway, wouldn't it be nicer to have some kind of scheme macro that expands 
>> to code that prints an incipit?  Your "first clef" could then be just part 
>> of the incipit that the macro creates.  And maybe the clef's name either 
>> could passed as argument to the scheme macro.  Or, alternatively, you set 
>> an, say, "original-clef" property that the macro recognizes and accordingly 
>> acts upon.
>
> As I understand it, incipits are hackingly achieved using the
> instrument name.

This is just one possible approach.  Template A.5.1 demonstrates a 
different approach.  Apparently, both approaches have limitations/flaws.

> I want instrument names to be defined separately
> from incipit (they are not the same thing, there is no serious
> reason to bind them, beside purely technical ones):
>
> \new Staff <<
> \global
> \set Staff . instrumentName = \markup { The instrument name }
> \clef "xyz" %% automagically set the incipit clef
> { ... the notes ... }
>>> 
>
> How could you make the mix of the two?
>

Re: [patch] first-clef property

Le 2 févr. 08 à 20:31, Juergen Reuter a écrit :

>> Maybe creating an incipit engraver, reading new context properties,
>> like incipitKeySignature, incipitTimeSignature, etc, and creating a
>> grob of the same nature as the instrument name.
>>
>
> Yes, this idea definitely sounds very reasonable!  Still,  
> implementing such an engraver may turn out challenging...

I have worked today on a draft, simple incipit engraver, with clef,
key signature and time signature. Might someone comment on it? I have
no experience with that part of the code. If something can be made
more eleguant, please speak 

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel