Re: Proposed new available and recommended behavior of \relative

[David Kastrup]

Robert Schmaus  writes:

> Hi everyone,
>
> I haven't read all posts on this subject, so sorry should I write
> something that's already been written.
> Why not keep the \relative  {  } syntax as one supported
> way and simply change the \relative {  } syntax to what David
> proposed?

Uh, that was the plan anyway.  The question was rather whether we should
convert to using the second form preferably in documentation and
examples.

> I myself have always only used the first version (I didn't even know
> the other existed, to be honest), and I liked the idea of having a
> lever outside the music that shifted the music ocave-wise.

\transpose c c'' is such a lever.

> Or, as an alternative, the \relative {  } syntax could rely on
> music that was written *before* the relative block.

That one is not an actual alternative.

xxx = \relative { c d e f g }
yyy = \relative { c d e f g }

\new Voice { \yyy \xxx }

Now what is the music "written before the relative block"?  The whole
point of \relative is that it returns absolute music given relative
music.  You propose it should return relative music given relative
music.  But how would music then become absolute?

> That way, one would avoid the awkwardness of explaining that the first
> note in the \relative block is actually absolute. It just says that
> everything in the relative block is, well, relative to what was before
> (if anything) or a default (like c') otherwise. That also makes sense
> semantically.

The first pitch after \relative is an absolute pitch.  That makes sense
semantically.

> Thus, the proposed syntax of 
>
> \relative { r4 a'' a f c } 
>
> where a'' is absolute would become 
>
> r4 a'' \relative{ a f c }

See above.  Making this proposal work in a sensible and predictable
manner would be quite harder than it might appear.

-- 
David Kastrup

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

Re: midi micro tuning / Midi calibration

[David Kastrup]

Robert Schmaus  writes:

> Hi Arthur & Timothy,
>
>> You've brought up a good question.  Sounds like you may do "Early Music",
>> too.  
>
> Thanks! Although I have to admit, that my music only goes as early as
> the Swing Era - Big Bands usually are tuned to 442 as it fits the brass
> better. I'm merely looking for a way to avoid tuning my double bass if I
> want to use midi-practice-files.
>
>
>> Midi, itself, is tuned in 440 and equal.  However, there's a function
>> known as "pitch bend" in midi parlance,  that works on some, but not all,
>> midi instruments.  There are many midi editors out there (do a search), 
>> and I just installed a good one in Linux but haven't had a chance to test
>> it for pitch bend.  However, what you can get depends a lot  on what kind
>> of operating system you're using.
>
> I was sort of amazed - Midi being such a simple (so I imagined) format,
> I thought that the calibration to 440 should be a mere variable, easy to
> be adjusted. There's always more to it than it seems ...

Tuning is not really well standardized in Midi.  Midi is focused on
discrete notes, so the probability is quite high that the easiest way to
deal with 442Hz tuning is to look at your Midi playing facility.

-- 
David Kastrup


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

Re: Proposed new available and recommended behavior of \relative

[Robert Schmaus]

On Fri, Mar 8, 2013, at 09:06 AM, David Kastrup wrote:
> Robert Schmaus  writes:
> 
> > Hi everyone,
> >
> > I haven't read all posts on this subject, so sorry should I write
> > something that's already been written.
> > Why not keep the \relative  {  } syntax as one supported
> > way and simply change the \relative {  } syntax to what David
> > proposed?
> 
> Uh, that was the plan anyway.  The question was rather whether we should
> convert to using the second form preferably in documentation and
> examples.

Oh, sorry, I interpreted your remark from an earlier mail ("But when
upgrading, convert-ly will convert it to the form without explicit pitch
if it can.") in that way, that the \relative  {  } is
planned to disappear ultimately.


> > I myself have always only used the first version (I didn't even know
> > the other existed, to be honest), and I liked the idea of having a
> > lever outside the music that shifted the music ocave-wise.
> 
> \transpose c c'' is such a lever.

I have thought of that too - it's just that transposition for me is
something I'd apply to a complete score in concert pitch e.g. to produce
a music sheet for Bb instruments. Something that comes after the actual
music writing process - in my understanding anyway. Of course, one can
use any command in lilypond however one sees fit ...


> > Or, as an alternative, the \relative {  } syntax could rely on
> > music that was written *before* the relative block.
> 
> That one is not an actual alternative.
> 
> xxx = \relative { c d e f g }
> yyy = \relative { c d e f g }
> 
> \new Voice { \yyy \xxx }
> 
> Now what is the music "written before the relative block"?  The whole
> point of \relative is that it returns absolute music given relative
> music.  You propose it should return relative music given relative
> music.  But how would music then become absolute?

It would, if there's either a default (pitch) for \relative { ... } with
no music before it. Or if the compiler gives an error if a user were to
write something like your example. After all, it's always up to the
typesetter to write something that makes sense.


> Making this proposal work in a sensible and predictable
> manner would be quite harder than it might appear.

There are probably not many persons who would know this better than you
do ... and I don't think that any of what lilypond can produce is quite
as easy as it appears! Each time I use it, I am amazed by something new!

Best,
Robert

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

Re: midi micro tuning / Midi calibration

[Martin Tarenskeen]

On Fri, 8 Mar 2013, David Kastrup wrote:


Midi, itself, is tuned in 440 and equal.


Midi, itself, is not tuned at all.


However, there's a function
known as "pitch bend" in midi parlance,  that works on some, but not all,


That's one way to do it. Make sure to set this for each of the Midi 
channels that you need.



I was sort of amazed - Midi being such a simple (so I imagined) format,
I thought that the calibration to 440 should be a mere variable, easy to
be adjusted. There's always more to it than it seems ...




Tuning is not really well standardized in Midi.  Midi is focused on
discrete notes, so the probability is quite high that the easiest way to
deal with 442Hz tuning is to look at your Midi playing facility.


There are some "standards", but they will not always work.

Pitchbend probably has the largest support on hard- and software synths.
But it was not really meant to play a complete score in a different 
tuning. It was invented - like the name implies - to temporarily bend 
pitches, and then return to the normal tuning again. For synthplayers who 
always wanted to be a guitar hero but never learnt to play the guitar ;-)


But there is also this method:
http://www.midi.org/techspecs/ca25.pdf

and this:
http://www.midi.org/techspecs/midituning.php
http://www.microtonal-synthesis.com/MIDItuning.html

The specs are there, but they are not always supported.

The easiest way: play your MIDI file on a hardware synth or soundmodule 
and just push some buttons or turn a knob on the hardware to get the 
tuning right.


--

MT

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

Re: Proposed new available and recommended behavior of \relative

[Jan Nieuwenhuizen]

David Kastrup writes:

> Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
> an absolute one

+1

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

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

Re: Proposed new available and recommended behavior of \relative

[Marc Hohl]

Am 07.03.2013 20:21, schrieb Werner LEMBERG:

One rationale is to stop the "distribution" of the information for
the first pitch to potentially quite separate places, like being
able to write

\new Staff \relative {
   \key aes \major
   <<  % Voice one
 { c''2 aes4. bes8 }
 ...

instead of the previous

\new Staff \relative c'' {
   \key aes \major
   <<  % Voice one
 { c2 aes4. bes8 }
 ...

For me, everything which leads to a better structure is a good thing,
so I support this change.

+1

Marc



 Werner

___
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: Proposed new available and recommended behavior of \relative

[David Kastrup]

Robert Schmaus  writes:

> On Fri, Mar 8, 2013, at 09:06 AM, David Kastrup wrote:
>> Robert Schmaus  writes:
>> 
>> > Hi everyone,
>> >
>> > I haven't read all posts on this subject, so sorry should I write
>> > something that's already been written.
>> > Why not keep the \relative  {  } syntax as one supported
>> > way and simply change the \relative {  } syntax to what David
>> > proposed?
>> 
>> Uh, that was the plan anyway.  The question was rather whether we should
>> convert to using the second form preferably in documentation and
>> examples.
>
> Oh, sorry, I interpreted your remark from an earlier mail ("But when
> upgrading, convert-ly will convert it to the form without explicit pitch
> if it can.") in that way, that the \relative  {  } is
> planned to disappear ultimately.

No, so strictly speaking \relative x''' { x is always going to be
available as the kind of "lever" you are talking about.  It just becomes
less elegant.

>> > I myself have always only used the first version (I didn't even know
>> > the other existed, to be honest), and I liked the idea of having a
>> > lever outside the music that shifted the music ocave-wise.
>> 
>> \transpose c c'' is such a lever.
>
> I have thought of that too - it's just that transposition for me is
> something I'd apply to a complete score in concert pitch e.g. to
> produce a music sheet for Bb instruments.

\transposition is there for the purpose of setting the relation between
sounding and printing pitch.  \transpose is independent from that.
Granted, it only became independent very recently: before both were
weirdly intertwined.

>> > Or, as an alternative, the \relative {  } syntax could rely
>> > on music that was written *before* the relative block.
>> 
>> That one is not an actual alternative.
>> 
>> xxx = \relative { c d e f g }
>> yyy = \relative { c d e f g }
>> 
>> \new Voice { \yyy \xxx }
>> 
>> Now what is the music "written before the relative block"?  The whole
>> point of \relative is that it returns absolute music given relative
>> music.  You propose it should return relative music given relative
>> music.  But how would music then become absolute?
>
> It would, if there's either a default (pitch) for \relative { ... } with
> no music before it.

What is your definition of "before"?

> Or if the compiler gives an error if a user were to write something
> like your example. After all, it's always up to the typesetter to
> write something that makes sense.

But computers are not interested in making sense but rather in following
instructions.  So to give an error when something does not make sense,
you need well-defined rules for what makes sense and what not.  And I
don't see a reasonable cut-off point for that.

>> Making this proposal work in a sensible and predictable manner would
>> be quite harder than it might appear.
>
> There are probably not many persons who would know this better than
> you do ...

It's not as much a matter of _implementing_ this proposal but rather of
making a coherent definition of what this proposal should exactly be.

If there is no manner to convert the idea into a set of coherent rules
that a human could follow reliably, there won't be a set of coherent
rules for the computer either.

> and I don't think that any of what lilypond can produce is quite as
> easy as it appears! Each time I use it, I am amazed by something new!

"amazed", "caught on the wrong foot", and "unpleasantly surprised" are
different things.

"It did just what I thought it would, only better" is what we want to
arrive at.  Or at least "my mistake was obvious".  So "can we make it
guess better what I mean" is a trap: LilyPond should not need to guess
your meaning, nor should you need to guess its actions.  If guesswork is
involved, the human/computer interface is broken.

-- 
David Kastrup

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

Re:Proposed new available and recommended behaviour of \relative

[Kevin Barry]

Dear LilyPond users,

Am I right in saying that the proposed new \relative {}, where the first 
pitch is absolute, is equivalent to simply writing \relative f {} in 
current usage? That might make it easier to explain in documentation 
than trying to explain that the first note is treated differently to the 
rest, although f may initially seem like a strange choice of reference 
point to a new user.


As for the change itself I'm in favour of it, but I don't feel strongly 
about it.


Kevin

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

Re: Proposed new available and recommended behaviour of \relative

[David Kastrup]

Kevin Barry  writes:

> Dear LilyPond users,
>
> Am I right in saying that the proposed new \relative {}, where the
> first pitch is absolute, is equivalent to simply writing \relative f
> {} in current usage?

Yes in Western scales.

> That might make it easier to explain in documentation than trying to
> explain that the first note is treated differently to the rest,
> although f may initially seem like a strange choice of reference point
> to a new user.

What is the resulting pitch of

\relative c' { ces, } ?

Quick, without thinking?  What is the resulting pitch of

\relative f { fes, } ?

Quick, without thinking?  What is the proposed resulting pitch of

\relative { fes, } ?

Now there is not even an opportunity for thinking.  Yes, f is special,
but telling people to translate \relative { x } first into \relative f {
x } and then figuring out its meaning is putting the cart before the
horse.

The whole point of the choice \relative f is not that f is such a pretty
pitch, but rather the invariant we get, namely that the first pitch
after \relative (whether it is only a reference pitch or part of the
music) is absolute.

> As for the change itself I'm in favour of it, but I don't feel
> strongly about it.

It is conceivable we'll split it in two parts.  Part one would be
changing definition and existing uses of \relative without reference
pitch.  I don't think consider this change really controversial.

But its main point is making things simpler (and obviating an otherwise
arbitrary choice), and _if_ one considers this point met, this would
warrant changing it to the usage we promote by example.

With the current 2-week release schedule, the time frame we are talking
about is a month.  Even the part one change (a reduced version of the
convert-ly rules, the definition change of \relative, and accompanying
documentation not written yet) will not make it into this weekend's (?)
release.

I'd prefer not having to write two different batches of documentation:
to make phase two stick, one would need adaption of a _lot_ of
introductory material anyway.  But that does not mean that all
documentation work has to happen in the same development version as
either of the other steps.  It does have to happen timely, and
definitely before the next stable release.

-- 
David Kastrup


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

Re: Proposed new available and recommended behaviour of \relative

[David Kastrup]

David Kastrup  writes:

> What is the resulting pitch of
>
> \relative c' { ces, } ?
>
> Quick, without thinking?  What is the resulting pitch of
>
> \relative f { fes, } ?
>
> Quick, without thinking?  What is the proposed resulting pitch of
>
> \relative { fes, } ?
>
> Now there is not even an opportunity for thinking.  Yes, f is special,
> but telling people to translate \relative { x } first into \relative f
> { x } and then figuring out its meaning is putting the cart before the
> horse.
>
> The whole point of the choice \relative f is not that f is such a
> pretty pitch, but rather the invariant we get, namely that the first
> pitch after \relative (whether it is only a reference pitch or part of
> the music) is absolute.

By the way: that is the reason I don't propose (I actually did at one
time, though) using \relative f everywhere without changing \relative in
any manner.

f is a distraction.  Why wouldn't you want to write
\relative fis { cis ...
instead when in a\major ?  f is not even in the scale.  Yes, both are
the same, but I don't want to even think about it, and the easiest way
not to think about it is not writing it.

-- 
David Kastrup


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

Re: Proposed new available and recommended behavior of \relative

[Colin Hall]

David Kastrup writes:

> Martin Tarenskeen  writes:
>
 The idea is that \relative { ... } (namely \relative used without an
 explicit reference pitch) uses the first note inside as the reference
 pitch.  That is, if the first note happens to be written as fis'' it
 will sound as fis'' (absolute pitch).
>>
>> I wouldn't mind, if I can still use the the old syntax, which is what
>> I prefer, and if the documentation clearly explains these two ways of
>> usage. I think the old syntax is easier for me when I want to
>> copy/paste notes.
>
> The only thing that works reliably for copy/paste is absolute pitch.
> Relative pitch is always prone to octave errors.

In my early days with Lilypond I learned this to my cost. I've never
used \relative since then.

Cheers,
Colin.

-- 
Colin Hall

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

Re: Proposed new available and recommended behavior of \relative

[David Kastrup]

Colin Hall  writes:

> David Kastrup writes:
>
>> Martin Tarenskeen  writes:
>>
> The idea is that \relative { ... } (namely \relative used without an
> explicit reference pitch) uses the first note inside as the reference
> pitch.  That is, if the first note happens to be written as fis'' it
> will sound as fis'' (absolute pitch).
>>>
>>> I wouldn't mind, if I can still use the the old syntax, which is what
>>> I prefer, and if the documentation clearly explains these two ways of
>>> usage. I think the old syntax is easier for me when I want to
>>> copy/paste notes.
>>
>> The only thing that works reliably for copy/paste is absolute pitch.
>> Relative pitch is always prone to octave errors.
>
> In my early days with Lilypond I learned this to my cost. I've never
> used \relative since then.

Well, stuff can get rather wordy, and mixing \transpose c c''' in scores
together with \transposition was a recipe for audible surprises.  Quick:
what is the result of

\addQuote "trumpet" { \transpose c f' {
\transposition bes'
c' d' e' f' }
  c' d' e' f' }

\quoteDuring "trumpet" { R1*2 }

Now let us think logically: \transposition bes' means that c' will
instead sound like bes', a small seventh higher.  So measure two should
start with bes'.  In measure 1, we transpose upwards an octave and a
fourth, so instead we should start with es'''.

Checking with 2.17.12, we arrive at pitch bes' for measure one instead
of es''', and at pitch f for measure two.  So \transpose failed to
audibly affect the passage it was put on, but after the end of
\transpose, the following bes' moved in the opposite direction, an
octave and a fourth downwards.

With the current source, we get es''' and bes' for measure one and two.

As to be expected.  People _did_ find actual recipes for working with
\transposition and \transpose together.  Those recipes are not really
corresponding with what we have in our documentation.  And you better
not try understanding them or adapting them to other situations.

So there _is_ a point in using only \relative for the sake of reducing
octave marks.  Or at least there has been.

Now that \transpose has become more boring in its effects and not an
accident waiting to happen in connection with \transposition, it _might_
be considered for things like not entering a soprano flute passage in
true pitch but rather two octaves lower.

-- 
David Kastrup

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

Re: Proposed new available and recommended behavior of \relative

[Werner LEMBERG]

>> Well... if you just don't emit the warning if the first pitch in a
>> \relative {} block is incorrect, then it seems like you get exactly
>> the current proposal except that you have to spell \relative { c''
>> } as \relative { c='' } instead.
> 
> I like that idea!

Indeed, this has some benefits in that the distinction between
relative and absolute notes stay intact.


Werner

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

Re: Proposed new available and recommended behavior of \relative

[David Kastrup]

Werner LEMBERG  writes:

>>> Well... if you just don't emit the warning if the first pitch in a
>>> \relative {} block is incorrect, then it seems like you get exactly
>>> the current proposal except that you have to spell \relative { c''
>>> } as \relative { c='' } instead.
>> 
>> I like that idea!
>
> Indeed, this has some benefits in that the distinction between
> relative and absolute notes stay intact.

The problem I have with it is that it is contrived.  Converting the
whole documentation to this usage would seem artificial, and octave
checks are not intended to change the meaning of code but to catch
errors.

-- 
David Kastrup


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

Re: Proposed new available and recommended behavior of \relative

[Francisco Vila]

2013/3/8 Jan Nieuwenhuizen :
> David Kastrup writes:
>
>> Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
>> an absolute one
>
> +1

+1 , I was currently using \relative f { }  anyway, so this would
allow removing the f, leaving the {...} intact, which for me would
imply a smooth transition to the new behavior.

But given my well-known problem with \transposition, I am not really sure :-)
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: [ANNOUNCE] ly2video 0.4.1

[Knut Petersen]

--- ly2video.py.orig2013-03-07 09:40:54.675565398 +0100
+++ ly2video.py2013-03-07 09:52:19.787389048 +0100
@@ -1723,7 +1723,7 @@
 fSanitisedLyFile.write("\\header {\n   tagline = ##f composer = 
##f\n}\n")
 headerPart = True

-if re.search("title\\s*=", line):
+if re.search(" title\\s*=", line):
 titleText.name = line.split("=")[-1].strip()[1:-1]
 if re.search("composer\\s*=", line):
 titleText.author = line.split("=")[-1].strip()[1:-1]


As \b matches the empty string at the beginning of a word, a better solution is 
to use

 +if re.search("\\btitle\\s*=", line):

as \b matches the empty string at the beginning of a word.

Adam, that should fix issue 49.

cu,
 Knut

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

Re: Proposed new available and recommended behaviour of \relative

[Francisco Vila]

2013/3/8 David Kastrup :
> What is the resulting pitch of
>
> \relative c' { ces, } ?
>
> Quick, without thinking?

Without thinking: I don't know. Good example.

>  What is the resulting pitch of
>
> \relative f { fes, } ?
>
> Quick, without thinking?

Without thinking, I know this is an absolute « fes, » because I am
used to \relative f { }, this is good.
But if you are used to \relative c' {} then you get and octave lower
than expected.
Now the problem is, what does absolute « fes, » look like? At the end
of the day, you must think a bit.

>  What is the proposed resulting pitch of
>
> \relative { fes, } ?

> Now there is not even an opportunity for thinking.

This is very good. Thinking is always uncomfortable when you don't want to.

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

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

Re: Proposed new available and recommended behavior of \relative

[David Kastrup]

Francisco Vila  writes:

> 2013/3/8 Jan Nieuwenhuizen :
>> David Kastrup writes:
>>
>>> Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
>>> an absolute one
>>
>> +1
>
> +1 , I was currently using \relative f { }  anyway, so this would
> allow removing the f, leaving the {...} intact, which for me would
> imply a smooth transition to the new behavior.

Issue 3229 comes with convert-ly rules that should give everybody a
smooth transition.  Indeed, if you are not planning on updating your
version number manually (and thus keeping convert-ly from trying its
hand), you better _not_ make the transition yourself, or you'll get

\relative f { e }  % original by Francisco
\relative { e }% conversion by Francisco
\relative c' { e } % first conversion step by convert-ly
\relative { e' }   % second conversion step by convert-ly

> But given my well-known problem with \transposition, I am not really
> sure :-)

What was that again?

-- 
David Kastrup

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

Re: Bar lines

[Werner LEMBERG]

> To be absolutely clear: i want both an 'end-bar' property and the
> thing mentioned above.

OK.

> Is my explanation clear?

Yes, thanks.  However, I still don't see the usefulness.


Werner

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

Re: override stencil question

[David Nalesnik]

Hi Rama,

On Fri, Mar 8, 2013 at 12:05 AM, Rama Gottfried wrote:

> here is a working version of the bezier glissando (I just had too many
> coordinates in my curveto command).
>
> still trying to find some reference on the grob-interpret-markup function
> -- it seems there are a few of these grob- functions that are not in the
> documentation list of scheme functions.
>

There's a reference to it here:
http://www.lilypond.org/doc/v2.17/Documentation/extending/callback-functions

Also, you can find its definition in scm/output-lib.scm.  (BTW, it calls
ly:text-interface::interpret-markup which you'll find documented on the
list of Scheme functions.)

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

Re: Proposed new available and recommended behavior of \relative

[Klaus Föhl]

> Thomas Morley  writes:
>
>> 2013/3/7 David Kastrup :
>>>
 Please take a look at

 Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
 an absolute one
>>
>> To be absolutely clear, am I right that this patch will not affect the
>> use of \relative with a given pitch like.
>> \relative d' { ... }
>> ?
>
> Yes and no.  This usage will work just as before when written from
> scratch.  But when upgrading, convert-ly will convert it to the form
> without explicit pitch if it can.

I am somewhat unhappy with the concept behind the new default use
being \relative {...} without qualifier as it mixes absolute and relative
pitch writing within the bracket. At least as it is explained.

No change to new functionality but different explanation,
the new \relative {...} would be equivalent to \relative f {...}
(or do I overlook some subtle issue in case of nested use or transposition?)
hence all notes within { } could be interpreted as relative notation...

> That's a similar approach like we took for \override: the old syntax
> continues to work, but convert-ly tries promoting the "suggested" form.

I wonder if a such change would be welcome, as it is slightly surprising.

Cheers
Klaus


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

Re: Excellent paper on 'Copyfraud'

[Pierre Perol-Schneider]

Thanks for this intersting info Mike.
Pierre

2013/3/8 Mike Blackstock 

> This paper might be of interest to anyone typesetting public domain
> music from so-called copyrighted scores:
> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=787244
>
> Abstract:
> "Copyfraud is everywhere. False copyright notices appear on modern
> reprints of Shakespeare's plays, Beethoven's piano scores, greeting
> card versions of Monet's Water Lilies, and even the U.S. Constitution.
> Archives claim blanket copyright in everything in their collections.
> Vendors of microfilmed versions of historical newspapers assert
> copyright ownership. These false copyright claims, which are often
> accompanied by threatened litigation for reproducing a work without
> the owner's permission, result in users seeking licenses and paying
> fees to reproduce works that are free for everyone to use. "
>
> 75 pages, PDF - Jason Mazzone, University of Illinois College of Law
>
> ___
> 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: Excellent paper on 'Copyfraud'

[pls]

yes, thanks for sharing it!
Am 08.03.2013 um 14:22 schrieb Pierre Perol-Schneider 
:

> Thanks for this intersting info Mike.
> Pierre
> 
> 2013/3/8 Mike Blackstock 
> This paper might be of interest to anyone typesetting public domain
> music from so-called copyrighted scores:
> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=787244
> 
> Abstract:
> "Copyfraud is everywhere. False copyright notices appear on modern
> reprints of Shakespeare's plays, Beethoven's piano scores, greeting
> card versions of Monet's Water Lilies, and even the U.S. Constitution.
> Archives claim blanket copyright in everything in their collections.
> Vendors of microfilmed versions of historical newspapers assert
> copyright ownership. These false copyright claims, which are often
> accompanied by threatened litigation for reproducing a work without
> the owner's permission, result in users seeking licenses and paying
> fees to reproduce works that are free for everyone to use. "
> 
> 75 pages, PDF - Jason Mazzone, University of Illinois College of Law
> 
> ___
> 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

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

lecker lek-ker in "old" German lyrics

[Klaus Föhl]

Hello,

Some German lyrics from before the times of Neue Deutsche Rechtschreibung
feature ck between two syllables. Without Hyphen it is "lecker", with hyphen
it is "lek-ker". Using lec -- ker or lek -- ker ( on purpose not le -- cker)
the hyphen may or may not appear. Is there anything beyond trial and error
to avoid lec-ker or lekker?

Some time ago there was an idea of introducing "lek == ker" for forcing
a hyphen but otherwise no change to formatting compared to "lek -- ker".
Has there happened anything since (I did not find anything in the 2.16 doc)?

Cheers
Klaus


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

Re: lecker lek-ker in "old" German lyrics

[Janek Warchoł]

Hi,

On Fri, Mar 8, 2013 at 2:41 PM, Klaus Föhl  wrote:
> Hello,
>
> Some German lyrics from before the times of Neue Deutsche Rechtschreibung
> feature ck between two syllables. Without Hyphen it is "lecker", with hyphen
> it is "lek-ker". Using lec -- ker or lek -- ker ( on purpose not le -- cker)
> the hyphen may or may not appear. Is there anything beyond trial and error
> to avoid lec-ker or lekker?
>
> Some time ago there was an idea of introducing "lek == ker" for forcing
> a hyphen but otherwise no change to formatting compared to "lek -- ker".
> Has there happened anything since (I did not find anything in the 2.16 doc)?

I'm working on this, and i hope that this will be available in next weeks.

Janek

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

Re: Repeating stanza numbers

[Phil Holmes]

- Original Message - 
From: "Laura Conrad" 



If someone who understands this better than I do agrees with me that
this is a bug, I'll be happy to write up a real bug report, especially
if you tell me what feature of lilypond to report the bug against.  I've
put a lot of effort into writing up bugs recently (both here and on
emacs24) that got categorized as "not a bug" when the real category is
"too hard to fix".  I assume there's a reason why stz went away, and
maybe it's because what stanza does with stanza numbers is really hard
to do on the second system.  Although I don't see why it should be.



There is absolutely no way that a bug or enhancement request in LilyPond 
should be rejected as "too hard to do".  It should always be accepted.  It 
may not be implemented, but it will remain in the issues list.  An 
enhancement request for stanza numbers at line breaks seems perfectly 
reasonable.


--
Phil Holmes 



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

Re: missing bars

[Kieren MacMillan]

Hi Katie,

Use bar checks:


Hope this helps!
Kieren.

On 2013-Mar-8, at 09:51, Katie Ganem  wrote:

> For some reason when I compile the file I'm working on, bars of music are 
> being omitted from the page.  I tried changing the margins, but it didn't 
> seem to work.  I then tried inputting more music but it is not even showing 
> up.
> 
> Someone told me it was because I have wrong durations so I tried deleting 
> some of the code so I could start over, but now it won't even acknowledge 
> that I've made changes when I compile. even though it says it successfully 
> compiled and doesn't list any errors.  It simply shows me the same thing over 
> and over again.  I tried reopening lilypond to no avail.
> 
> Here is the code I am using.  Attached is a screen shot of what is showing up 
> when I compile it.
> 
> \paper {
>   left-margin = .75\in
>   right-margin = .75\in
>   }
> }
> \header{
>   title = "Happily Ever After"
> }
> melody = 
> \relative c' {
>   \clef treble
>   \key g \major
>   \time 12/8
> 
> b8 c8 d8 d8 e8 d8 e4 g8 ~g8 f8 d8
> b8 c8 d8 d8 e8 d8 bes4 a8~a8 gis8 a8
> b8 c8 d8 d8 e8 d8 g8 d8 f8 e8 c8 e8 
> d1.
> g8 g8 g8 g8 fis8 g8 bes4 a8 ~ a4 g8
> d8 d8 d8 d8 cis8 d8 g4 f8 ~ f8 g8 f8
> e4 e8 r4. r8 r8 f8 ~ f4 d8
> e4. r4. r4. r8 dis8 e8
> f8 g8 f8 f8 e8 f8 a4. ~a8 f8 e8
> d8 cis8 d8 g8 fis8 g8 g8 fis8 g8 bes8 g8 f8
> g2. r2.
> r2. r8 r8 bes8 a8 g8 f8
> \key c \major
> e8 c8 e8 f8 d8 f8 g8 e8 g8 f8 r8 dis8
> e4 c8 r4. r8 r8 a8 b8 c8 d8
> e8 c8 e8 f8 d8 f8 g8 e8 g8 f8 d8 f8
> a2. r4 a8 g8 a8 g8
> b8 g8 b8 g4 a8 r4. r8 r8 g8
> bes8 g8 bes8 g4 a8 r4. r4.
> r4 d,8 e8 g8 a8 r4 bes8 ~(bes8 a8) g8
> g1.
> r4. bes8. a8.~a2.
> r1
> }
> 
> 
> text = \lyricmode {
>   Win i fred maid of the My re has but 
> one sin gle hu man de si re Oh I 
> ask for no more than two shoes on the floor next to 
> mine
> Some one to fly and to float with To
>  swim in the marsh and the moat with As for 
> this one he'd be 
> fine And I'm 
> burn ing to bring it a bout If I
> don't I'll be stuck with good bye and good luck and get
> out
> I want to get
> in to some hap pi ly hap pi ly ev er
> af ter I want to walk
> hap pi ly out of the chap el e tern nal ly 
> tied and then I'll be
> hap pi ly hap py yes
> hap pi ly hap py
> and thour ough ly sat is
> fied 
> oh yeah!
> }
> 
> upper = 
> \relative c' {
>   \clef treble
>   \key g \major
>   \time 12/8
>   \time 12/8
>   \set Staff.timeSignatureFraction = 4/4
> \scaleDurations 3/2{
> 
> 
> 4 (8) r8 \grace dis'8 (8) (8) \times 2/3 {r8  bes>8 r8} 
> 4 (8) r8 8 (4.)
> 4 (4 4 4)
> \times 2/3 {r8  }
> %Voice 1  Voice 2
> << {\times 2/3 {d4 d8}} \\ {\times 2/3 {a16 bes16 a16 g8 e8}} >>
> 8 8 ~8 8
> 4 4 4 4
> 4 4 4 4
> 8 8 r4 r8 4 8
> 
> 
> 
> }
> }
> 
> lower = 
> \relative c {
>   \clef bass
>   \key g \major
>   \time 12/8
>   \set Staff.timeSignatureFraction = 4/4
> \scaleDurations 3/2{
> g1
> r1
> r1
> r1
> r1
> r1
> 
> }
> }
> 
> \score {
>   <<
> \new Voice = "mel" { \autoBeamOff \melody }
> \new Lyrics \lyricsto mel \text
> \new PianoStaff <<
>   \new Staff = "upper" \upper
> 
>   \new Staff = "lower" \lower
> >>
>   >>
>   \layout {
> \context { \Staff \RemoveEmptyStaves }
>   }
>   \midi { }
> }
> 
> 
> \version "2.16.2"  % necessary for upgrading to future LilyPond versions.
> 
> ___
> 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: missing bars

[Katie Ganem]

That does help.  Thank you.  But now I can't seem to get music to show up when 
I compile it.  I tried copying it into a new file, but it goes through the 
motions, says that it successfully compiled and then shows nothing.  Does 
anyone know what could cause this? 

On Mar 8, 2013, at 9:56 AM, Kieren MacMillan wrote:

> Hi Katie,
> 
> Use bar checks:
> 
> 
> Hope this helps!
> Kieren.
> 
> On 2013-Mar-8, at 09:51, Katie Ganem  wrote:
> 
>> For some reason when I compile the file I'm working on, bars of music are 
>> being omitted from the page.  I tried changing the margins, but it didn't 
>> seem to work.  I then tried inputting more music but it is not even showing 
>> up.
>> 
>> Someone told me it was because I have wrong durations so I tried deleting 
>> some of the code so I could start over, but now it won't even acknowledge 
>> that I've made changes when I compile. even though it says it successfully 
>> compiled and doesn't list any errors.  It simply shows me the same thing 
>> over and over again.  I tried reopening lilypond to no avail.
>> 
>> Here is the code I am using.  Attached is a screen shot of what is showing 
>> up when I compile it.
>> 
>> \paper {
>>  left-margin = .75\in
>>  right-margin = .75\in
>>  }
>> }
>> \header{
>>  title = "Happily Ever After"
>> }
>> melody = 
>> \relative c' {
>>  \clef treble
>>  \key g \major
>>  \time 12/8
>> 
>> b8 c8 d8 d8 e8 d8 e4 g8 ~g8 f8 d8
>> b8 c8 d8 d8 e8 d8 bes4 a8~a8 gis8 a8
>> b8 c8 d8 d8 e8 d8 g8 d8 f8 e8 c8 e8 
>> d1.
>> g8 g8 g8 g8 fis8 g8 bes4 a8 ~ a4 g8
>> d8 d8 d8 d8 cis8 d8 g4 f8 ~ f8 g8 f8
>> e4 e8 r4. r8 r8 f8 ~ f4 d8
>> e4. r4. r4. r8 dis8 e8
>> f8 g8 f8 f8 e8 f8 a4. ~a8 f8 e8
>> d8 cis8 d8 g8 fis8 g8 g8 fis8 g8 bes8 g8 f8
>> g2. r2.
>> r2. r8 r8 bes8 a8 g8 f8
>> \key c \major
>> e8 c8 e8 f8 d8 f8 g8 e8 g8 f8 r8 dis8
>> e4 c8 r4. r8 r8 a8 b8 c8 d8
>> e8 c8 e8 f8 d8 f8 g8 e8 g8 f8 d8 f8
>> a2. r4 a8 g8 a8 g8
>> b8 g8 b8 g4 a8 r4. r8 r8 g8
>> bes8 g8 bes8 g4 a8 r4. r4.
>> r4 d,8 e8 g8 a8 r4 bes8 ~(bes8 a8) g8
>> g1.
>> r4. bes8. a8.~a2.
>> r1
>> }
>> 
>> 
>> text = \lyricmode {
>>  Win i fred maid of the My re has but 
>> one sin gle hu man de si re Oh I 
>> ask for no more than two shoes on the floor next to 
>> mine
>> Some one to fly and to float with To
>> swim in the marsh and the moat with As for 
>> this one he'd be 
>> fine And I'm 
>> burn ing to bring it a bout If I
>> don't I'll be stuck with good bye and good luck and get
>> out
>> I want to get
>> in to some hap pi ly hap pi ly ev er
>> af ter I want to walk
>> hap pi ly out of the chap el e tern nal ly 
>> tied and then I'll be
>> hap pi ly hap py yes
>> hap pi ly hap py
>> and thour ough ly sat is
>> fied 
>> oh yeah!
>> }
>> 
>> upper = 
>> \relative c' {
>>  \clef treble
>>  \key g \major
>>  \time 12/8
>>  \time 12/8
>>  \set Staff.timeSignatureFraction = 4/4
>>\scaleDurations 3/2{
>> 
>> 
>> 4 (8) r8 \grace dis'8 (8) (8) \times 2/3 {r8 > bes>8 r8} 
>> 4 (8) r8 8 (4.)
>> 4 (4 4 4)
>> \times 2/3 {r8  }
>> %Voice 1 Voice 2
>> << {\times 2/3 {d4 d8}} \\ {\times 2/3 {a16 bes16 a16 g8 e8}} >>
>> 8 8 ~8 8
>> 4 4 4 4
>> 4 4 4 4
>> 8 8 r4 r8 4 8
>> 
>> 
>> 
>> }
>> }
>> 
>> lower = 
>> \relative c {
>>  \clef bass
>>  \key g \major
>>  \time 12/8
>>  \set Staff.timeSignatureFraction = 4/4
>>\scaleDurations 3/2{
>> g1
>> r1
>> r1
>> r1
>> r1
>> r1
>> 
>> }
>> }
>> 
>> \score {
>>  <<
>>\new Voice = "mel" { \autoBeamOff \melody }
>>\new Lyrics \lyricsto mel \text
>>\new PianoStaff <<
>>  \new Staff = "upper" \upper
>> 
>>  \new Staff = "lower" \lower
 
 
>>  \layout {
>>\context { \Staff \RemoveEmptyStaves }
>>  }
>>  \midi { }
>> }
>> 
>> 
>> \version "2.16.2"  % necessary for upgrading to future LilyPond versions.
>> 
>> ___
>> 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: lecker lek-ker in "old" German lyrics

[Mats Bengtsson]

On 03/08/2013 03:52 PM, lilypond-user-requ...@gnu.org wrote:

Hello,

Some German lyrics from before the times of Neue Deutsche Rechtschreibung
feature ck between two syllables. Without Hyphen it is "lecker", with hyphen
it is "lek-ker". Using lec -- ker or lek -- ker ( on purpose not le -- cker)
the hyphen may or may not appear. Is there anything beyond trial and error
to avoid lec-ker or lekker?

Some time ago there was an idea of introducing "lek == ker" for forcing
a hyphen but otherwise no change to formatting compared to "lek -- ker".
Has there happened anything since (I did not find anything in the 2.16 doc)?

The following should make it:

  \context {
\Lyrics
\override LyricHyphen #'minimum-distance = #1
  }


   /Mats

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

Re: missing bars

[Kieren MacMillan]

Hi Katie,

> That does help.  Thank you.  But now I can't seem to get music to show up 
> when I compile it.

Are you sure you used bar checks, as I suggested?
When I try it (see snippet, below), it clearly shows where your data entry 
errors are.

Kieren.

p.s. You should also be using full measure rests (R1) instead of whole note 
rests (r1).
___

\paper {
left-margin = .75\in
right-margin = .75\in
}
}
\header{
title = "Happily Ever After"
}

melody = \relative c' {
  \clef treble
  \key g \major
  \time 12/8
  b8 c8 d8 d8 e8 d8 e4 g8 ~ g8 f8 d8   |
  b8 c8 d8 d8 e8 d8 bes4 a8 ~ a8 gis8 a8   |
  b8 c8 d8 d8 e8 d8 g8 d8 f8 e8 c8 e8   |
  d1.   |
  g8 g8 g8 g8 fis8 g8 bes4 a8 ~ a4 g8   |
  d8 d8 d8 d8 cis8 d8 g4 f8 ~ f8 g8 f8  |
  e4 e8 r4. r8 r8 f8 ~ f4 d8   |
  e4. r4. r4. r8 dis8 e8   |
  f8 g8 f8 f8 e8 f8 a4. ~ a8 f8 e8   |
  d8 cis8 d8 g8 fis8 g8 g8 fis8 g8 bes8 g8 f8   |
  g2. r2.   |
  r2. r8 r8 bes8 a8 g8 f8   |
  \key c \major
  e8 c8 e8 f8 d8 f8 g8 e8 g8 f8 r8 dis8   |
  e4 c8 r4. r8 r8 a8 b8 c8 d8   |
  e8 c8 e8 f8 d8 f8 g8 e8 g8 f8 d8 f8   |
  a2. r4 a8 g8 a8 g8   |
  b8 g8 b8 g4 a8 r4. r8 r8 g8   |
  bes8 g8 bes8 g4 a8 r4. r4.   |
  r4 d,8 e8 g8 a8 r4 bes8( ~ bes8 a8) g8   |
  g1.   |
  r4. bes8. a8. ~ a2.
  r1
}


text = \lyricmode {
Win i fred maid of the My re has but 
one sin gle hu man de si re Oh I 
ask for no more than two shoes on the floor next to 
mine
Some one to fly and to float with To
swim in the marsh and the moat with As for 
this one he'd be 
fine And I'm 
burn ing to bring it a bout If I
don't I'll be stuck with good bye and good luck and get
out
I want to get
in to some hap pi ly hap pi ly ev er
af ter I want to walk
hap pi ly out of the chap el e tern nal ly 
tied and then I'll be
hap pi ly hap py yes
hap pi ly hap py
and thour ough ly sat is
fied 
oh yeah!
}

upper = \relative c' {
  \clef treble
  \key g \major
  \time 12/8
  \set Staff.timeSignatureFraction = 4/4
  \scaleDurations 3/2 {
4 (8) r8 \grace dis'8 (8) (8) \times 2/3 {r8 8 r8}   |
4 (8) r8 8 (4.)   |
4 (4 4 4)   |
\times 2/3 {r8  }   |
<< { \times 2/3 { d4 d8 } } \\ { \times 2/3 { a16 bes16 a16 g8 e8 } } >>   |
8 8 ~8 8   |
4 4 4 4   |
4 4 4 4   |
8 8 r4 r8 4 8   |
  }
}

lower = \relative c {
  \clef bass
  \key g \major
  \time 12/8
  \set Staff.timeSignatureFraction = 4/4
  \scaleDurations 3/2 {
g1   |
R1   |
R1   |
R1   |
R1   |
R1   |
  }
}

\score {
<<
  \new Voice = "mel" { \autoBeamOff \melody }
  \new Lyrics \lyricsto mel \text
  \new PianoStaff <<
\new Staff = "upper" \upper

\new Staff = "lower" \lower
>> >>

\layout {
  \context { \Staff \RemoveEmptyStaves }
}
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: missing bars

[Janek Warchoł]

On Fri, Mar 8, 2013 at 4:19 PM, Katie Ganem  wrote:
> I tried copying it into a new file, but it goes through the motions,
> says that it successfully compiled and then shows nothing.
> Does anyone know what could cause this?

This may happen if you define your music variables but don't actually
use them, for example if a file contains a definition

melody = { c d e f }

but you don't actually call it using \melody.

hth,
Jaenk

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

Re: override stencil question

[Rama Gottfried]

Hi David,

thanks for pointing out the scm folder, I hadn't looked in there yet -- this is 
really helpful.

the list of Scheme functions in the documentation gave me the idea that this it 
was a glossary -- but the scm folder seems like more the place to look for 
getting information.  will start digging in there, thanks!

Rama



On Mar 8, 2013, at 4:46 AM, David Nalesnik wrote:

> Hi Rama,
> 
> On Fri, Mar 8, 2013 at 12:05 AM, Rama Gottfried  
> wrote:
> here is a working version of the bezier glissando (I just had too many 
> coordinates in my curveto command).
> 
> still trying to find some reference on the grob-interpret-markup function -- 
> it seems there are a few of these grob- functions that are not in the 
> documentation list of scheme functions.
> 
> There's a reference to it here:  
> http://www.lilypond.org/doc/v2.17/Documentation/extending/callback-functions
> 
> Also, you can find its definition in scm/output-lib.scm.  (BTW, it calls 
> ly:text-interface::interpret-markup which you'll find documented on the list 
> of Scheme functions.)
> 
> HTH,
> David

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

Re: lecker lek-ker in "old" German lyrics

[Alexander Kobel]

On 03/08/2013 10:19 AM, Mats Bengtsson wrote:


On 03/08/2013 03:52 PM, lilypond-user-requ...@gnu.org wrote:

Hello,

Some German lyrics from before the times of Neue Deutsche Rechtschreibung
feature ck between two syllables. Without Hyphen it is "lecker", with
hyphen
it is "lek-ker". Using lec -- ker or lek -- ker ( on purpose not le --
cker)
the hyphen may or may not appear. Is there anything beyond trial and
error
to avoid lec-ker or lekker?

Some time ago there was an idea of introducing "lek == ker" for forcing
a hyphen but otherwise no change to formatting compared to "lek -- ker".
Has there happened anything since (I did not find anything in the 2.16
doc)?

The following should make it:

\context {
\Lyrics
\override LyricHyphen #'minimum-distance = #1
}


I think Klaus did not ask for forcing the hyphen to be visible, or 
forcing it to be hidden, but instead choose the letters depending on 
whether the hyphen appears or not in that place (with automatic 
deduction how cramped the space is).



Best,
Alexander

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

Re: Excellent paper on 'Copyfraud'

[Tim Slattery]

Mike Blackstock  wrote:

>This paper might be of interest to anyone typesetting public domain
>music from so-called copyrighted scores:
>http://papers.ssrn.com/sol3/papers.cfm?abstract_id=787244

Excellent article, even if it is 7 years old.

I'm in a singing group. We sing madrigals and some baroque pieces, all
several hundred years old. I see books all the time with copyright
notices all over the place on songs that were written 300 to 500 years
ago. I wonder just what is under copyright? Words and music certainly
are not. Any foreword, biographical material, commentary certainly is.

If the editor went to an old source, transcribed the piece into more
modern notation, added measures, key signature, time signature, does
that make the product copyrightable? If I make a copy with Lilypond,
is that infringement? Since I've produced sheet music for a public
domain work, I don't think so.

-- 
Tim Slattery
slatter...@bls.gov


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

Re: Excellent paper on 'Copyfraud'

[Tim McNamara]

On Mar 8, 2013, at 11:33 AM, Tim Slattery wrote:
> Mike Blackstock  wrote:
> 
>> This paper might be of interest to anyone typesetting public domain
>> music from so-called copyrighted scores:
>> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=787244
> 
> Excellent article, even if it is 7 years old.
> 
> I'm in a singing group. We sing madrigals and some baroque pieces, all
> several hundred years old. I see books all the time with copyright
> notices all over the place on songs that were written 300 to 500 years
> ago. I wonder just what is under copyright? Words and music certainly
> are not. Any foreword, biographical material, commentary certainly is.
> 
> If the editor went to an old source, transcribed the piece into more
> modern notation, added measures, key signature, time signature, does
> that make the product copyrightable? If I make a copy with Lilypond,
> is that infringement? Since I've produced sheet music for a public
> domain work, I don't think so.

Copyright varies by country rather than being internationally uniform, 
something of a problem now that the Internet has obliterated national 
boundaries for the sharing of information, copyrighted or otherwise.  In the 
US, at least, the novel arrangement of public domain works can be copyrighted.  
I can't copyright a Brahms piece, but I can copyright my arrangement of it.  I 
am not sure what constitutes an arrangement in the legal sense.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Proposed new available and recommended behavior of \relative

[Francisco Vila]

2013/3/8 Klaus Föhl :
> I am somewhat unhappy with the concept behind the new default use
> being \relative {...} without qualifier as it mixes absolute and relative
> pitch writing within the bracket. At least as it is explained.

I am not sure it mixes absolute and relative. The first note is
relative to nothing because there is no previous note.

To say "it mixes absolute and relative" you need more than one
absolute note, I think.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: Proposed new available and recommended behavior of \relative

[Olivier Biot]

On Fri, Mar 8, 2013 at 11:43 AM, David Kastrup  wrote:

> Werner LEMBERG  writes:
>
> >>> Well... if you just don't emit the warning if the first pitch in a
> >>> \relative {} block is incorrect, then it seems like you get exactly
> >>> the current proposal except that you have to spell \relative { c''
> >>> } as \relative { c='' } instead.
> >>
> >> I like that idea!
> >
> > Indeed, this has some benefits in that the distinction between
> > relative and absolute notes stay intact.
>
> The problem I have with it is that it is contrived.  Converting the
> whole documentation to this usage would seem artificial, and octave
> checks are not intended to change the meaning of code but to catch
> errors.
>

I have mixed feelings regarding the proposed syntax update of \relative.

Treating the first pitch of \music in \relative \music differently is not
intuitive and will likely result in octave errors.

Personally I think that

  c'' \relative { ... }

is more intuitive than

  \relative c'' { ... }

and could be made to work even when no starting pitch has been specified,
where the default LilyPond pitch would apply (IIRC c' as starting point).

The main question however, is to check how users make use of \relative
nowadays in their sheet music. Maybe that will shed some more light on the
problem and on a feasible change.

Best regards,

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

Re: override stencil question

[Thomas Morley]

2013/3/8 Rama Gottfried :
> Hi David,
>
> thanks for pointing out the scm folder, I hadn't looked in there yet -- this
> is really helpful.
>
> the list of Scheme functions in the documentation gave me the idea that this
> it was a glossary -- but the scm folder seems like more the place to look
> for getting information.  will start digging in there, thanks!
>
> Rama
>
>
>
> On Mar 8, 2013, at 4:46 AM, David Nalesnik wrote:
>
> Hi Rama,
>
> On Fri, Mar 8, 2013 at 12:05 AM, Rama Gottfried 
> wrote:
>>
>> here is a working version of the bezier glissando (I just had too many
>> coordinates in my curveto command).
>>
>> still trying to find some reference on the grob-interpret-markup function
>> -- it seems there are a few of these grob- functions that are not in the
>> documentation list of scheme functions.
>
>
> There's a reference to it here:
> http://www.lilypond.org/doc/v2.17/Documentation/extending/callback-functions
>
> Also, you can find its definition in scm/output-lib.scm.  (BTW, it calls
> ly:text-interface::interpret-markup which you'll find documented on the list
> of Scheme functions.)
>
> HTH,
> David
>
>
>
> ___
> lilypond-user mailing list
> lilypond-user@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-user
>

Several examples how it is used in
Snippets-Manual
http://lilypond.org/doc/v2.17/Documentation/snippets-big-page.html#index

and "The LilyPond Snippet Repository" (LSR)
http://lsr.dsi.unimi.it/LSR/

-Harm

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

Re: A plea for a documentation change ... Just a tiny one

[Colin Hall]

Guy Stalnaker writes:

> I've just spent an entire evening trying to figure out how to add some 
> lyric text to one voice of a three-measure two-voice section of a score. 

Thanks for contacting us about this, Guy, and for the thorough-going
report. Your suggestion for a change to the docs seems sound.

It can be very frustrating, trying to find your way around the lilypond
docs. You might find the following visual index useful, a recent piece
of work by Joram:

http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00916.html

Urs Liska replied to your post (thanks, Urs) to point out that we take
bug reports against the documentation on the bug-lilypond mailing list
in a concise format known as "Documentation Suggestions". See:

http://lilypond.org/doc/v2.17/Documentation/contributor/documentation-suggestions

The idea is that you, the reporter, are the person who has the best
understanding of the problem right now, so we ask you to tell us what to
add to the docs. Otherwise, a doc author has to figure it out, sometime
in the future, and we want the authors to focus on updating docs, not
figuring out problems.

Nick Payne recently made a very nice job of one of these doc suggestion
things:

http://lists.gnu.org/archive/html/bug-lilypond/2013-03/msg00033.html

And here is another good example:

http://lists.gnu.org/archive/html/bug-lilypond/2013-02/msg00046.html

If you adapt the text of your original post into that format, we'll
create a tracker and get it onto the work list. Send it to bug-lilypond
or just reply to this and one of us will forward it to bug-lilypond for
you.

Cheers,
Colin.


-- 
Colin Hall

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

span bar not working any more?

[Kieren MacMillan]

Hello all,

SpanBar isn't currently working as expected/documented: 


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

Re: Orchestral group

[Kieren MacMillan]

Hi Mario,

> Well! As I have already said I think that this solution is really nice but I 
> can not fix what I have underlined in red: that the staff bar connection. And 
> I can not add staff "Harpsichord" without  StaffGroup and only PianoStaff :-(

I can fix all the other things, but the SpanBar is a bug — hopefully that will 
be fixed soon.

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

Re: span bar not working any more?

[Kieren MacMillan]

Hi,

Just saw .

Sorry for the noise.
Kieren.


On 2013-Mar-8, at 20:58, Kieren MacMillan  wrote:

> Hello all,
> 
> SpanBar isn't currently working as expected/documented: 
> 
> 
> All the 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: Proposed new available and recommended behavior of \relative

[Keith OHara]

> Colin Hall  gmail.com> writes:
> 
> > In my early days with Lilypond I learned this to my cost. I've never
> > used \relative since then.

I stopped using \relative about a year ago, because absolute note entry is
vastly easier.

When writing, I do not generally remember the previous note (more likely the
previous chord, or the first note in the previous phrase).  Even when I do,
for some reason determining whether I am moving more than a nominal fourth
takes some mental effort. LilyPond punishes a single mistake in this mental
effort by placing every following note in the wrong octave.

I do, however, have in mind the range of the instrument, and can \transpose
so that written c d e f g a b falls in the center of that range.  In
borderline cases I prefer putting the home octave a bit higher, because ,
is one keystroke for me while ' requires two.  Transposed absolute entry
puts me in control.

\relative c' {} might work better if applied to short passages, but I can
never remember to close the }.  Just after typing a note, I am not thinking
that I might soon forget what I just typed.  When I do forget, looking back
to remember is easier than going back to close the }.

When I did use \relative c' {} it was a burden to think ahead "the first note
I want will probably be an f'', so the nearest C is c'' ".  The new proposal
for \relative {...} removes that burden.

David Kastrup  gnu.org> writes:

> Well, stuff can get rather wordy, and mixing \transpose c c''' in scores
> together with \transposition was a recipe for audible surprises.  Quick:

The combination  \transpose c c, { \transposition bes \clef bass c' d' }  
means "Typed c' represents concert bes " in version 2.16.  In version 2.18
it will mean "Printed c' represents concert bes "  (the new way being more
consistent with the case where there is no \transposition setting at all).
Neither way is terribly confusing.  Both are details that I tend not to
remember, so I take a guess and adjust once after I see if the cue notes
come out right.

  Transposed absolute note entry rocks.   Relative note entry sucks.


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

Re: Proposed new available and recommended behavior of \relative

[Shane Brandes]

It's funny. I think i have used \absolute maybe three times. It is too
much extra typing.

Shane

On Fri, Mar 8, 2013 at 11:45 PM, Keith OHara  wrote:
>> Colin Hall  gmail.com> writes:
>>
>> > In my early days with Lilypond I learned this to my cost. I've never
>> > used \relative since then.
>
> I stopped using \relative about a year ago, because absolute note entry is
> vastly easier.
>
> When writing, I do not generally remember the previous note (more likely the
> previous chord, or the first note in the previous phrase).  Even when I do,
> for some reason determining whether I am moving more than a nominal fourth
> takes some mental effort. LilyPond punishes a single mistake in this mental
> effort by placing every following note in the wrong octave.
>
> I do, however, have in mind the range of the instrument, and can \transpose
> so that written c d e f g a b falls in the center of that range.  In
> borderline cases I prefer putting the home octave a bit higher, because ,
> is one keystroke for me while ' requires two.  Transposed absolute entry
> puts me in control.
>
> \relative c' {} might work better if applied to short passages, but I can
> never remember to close the }.  Just after typing a note, I am not thinking
> that I might soon forget what I just typed.  When I do forget, looking back
> to remember is easier than going back to close the }.
>
> When I did use \relative c' {} it was a burden to think ahead "the first note
> I want will probably be an f'', so the nearest C is c'' ".  The new proposal
> for \relative {...} removes that burden.
>
> David Kastrup  gnu.org> writes:
>
>> Well, stuff can get rather wordy, and mixing \transpose c c''' in scores
>> together with \transposition was a recipe for audible surprises.  Quick:
>
> The combination  \transpose c c, { \transposition bes \clef bass c' d' }
> means "Typed c' represents concert bes " in version 2.16.  In version 2.18
> it will mean "Printed c' represents concert bes "  (the new way being more
> consistent with the case where there is no \transposition setting at all).
> Neither way is terribly confusing.  Both are details that I tend not to
> remember, so I take a guess and adjust once after I see if the cue notes
> come out right.
>
>   Transposed absolute note entry rocks.   Relative note entry sucks.
>
>
> ___
> 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

Proposed new available and recommended behavior of \relative

[Hwaen Ch'uqi]

Greetings All,
 In truth, I am quite satisfied with the current state of
\relative, whether with or without an absolute pitch indicated before
the braces. And yes, I do understand that, though users are at present
discouraged from using the latter, both

\relative c' { MUSIC } and \relative { MUSIC }

yield the same result. But why, after all, is the latter meant to be
deprecated? Do not the docs, in explaining the placement of pitch `c',
use middle C as a point of reference - as in, an octave below middle
C? And so, if the proposed change is implemented, my mental process of
assigning or interpreting

\relative fis'' { MUSIC } or \relative { fis'' MORE MUSIC }

invariably remains the same - that is, calculate the placement of said
pitch located two octaves and a raised fourth above the C which is one
octave below middle C. (This is why the deprecated syntax is so
useful; it is more direct, eliminating a step in the calculation.)
 I also share and echo reservations about mixing the purpose of
commas and apostrophes within the \relative braces themselves. This
may be a subtle distinction, but I cannot agree that, in the case of

\relative { fis'' MORE MUSIC }

that `fis''' is an absolute pitch. Yes, its placement is firmly
established, but only as it is *relative* to `c'. In which case, why
not leave the \relative situation as currently is, where the one true
absolute pitch of `c' (which, incidentally, is as arbitrary as any
other pitch) is invoked as a function of calling \relative in the
first place and is then used immediately - that is, before the braces
- in establishing a different reference point as desired by the user?
Hwaen Ch'uqi

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

Turn placed between notes

[Nick Payne]

See attached graphic. Quite a number of these in the score (Brahms 
Sextet Op 18). At the moment I'm creating them like so:


\version "2.17.13"

\relative f'' {
  f4.^\markup { \halign #-3.5 { \musicglyph #"scripts.turn" } } g16 a |
}

but with the value of halign hard coded, with differing note values and 
bar spacing, I have to fiddle with the value of halign each time to get 
the turn centred between the notes. Is there a more automated way of 
positioning the turn? Lilypond seems to assume that turns should be 
placed directly above a note, but that is often not the case.


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

Re: Proposed new available and recommended behavior of \relative

[Matthew Collett]

On 9/03/2013, at 12:22 am, Francisco Vila  wrote:

> 2013/3/8 Jan Nieuwenhuizen :
>> David Kastrup writes:
>> 
>>> Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
>>> an absolute one
>> 
>> +1
> 
> +1 , I was currently using \relative f { }  anyway, so this would
> allow removing the f, leaving the {...} intact, which for me would
> imply a smooth transition to the new behavior.

+1
I have always used \relative for pitch entry, and now usually use \relative f 
{}.  

With absolute pitch entry, not only is there extra typing but also a non-zero 
chance of an odd note or two being entered in the wrong octave undetected; with 
relative entry any octave error is immediately noticeable, since it propagates 
through the rest of the piece.

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

Re: Orchestral group

[Mario Moles]

In data venerdì 8 marzo 2013 22:37:02, Kieren MacMillan ha scritto:
> Hope this helps!
Oh yess!
This is great!
You are great!
(H)
Thank you so match!
;-)(Y)
 -- 
oiram/bin/selom
Da ognuno secondo le proprie capacità ad ognuno secondo i propri bisogni.
MIB-kernellinux-tester
Linux 
MIB Lilypond Frescobaldi Rosegarden ___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Turn placed between notes

[Keith OHara]

Nick Payne  internode.on.net> writes:

>  have to fiddle with the value of halign each time to get 
> the turn centred between the notes. Is there a more automated way of 
> positioning the turn? 

Parallel music.  Then I can think in terms of the timing of the turn, rather
than the spacing.  Usually I need a hidden note in the parallel part to put
the turn at the right height.

\new Voice \relative c'' {
  << f4. {s4 \once\hideNotes f8\turn\noBeam } >> g16-. a-. 



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