Urs Liska writes:
> Am 15.02.2013 12:39, schrieb David Kastrup:
>> Urs Liska writes:
>>
>>> Am 15.02.2013 12:18, schrieb Jan-Peter Voigt:
>>>
>>> Am 15.02.2013 11:40, schrieb Urs Liska:
>>> You can create an adhoc-book in scheme with
. Don't write it if you don't mean
it.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
list, or a new function call.
So (#{ ... #}) only makes sense when #{ ... #} actually returns a
_function_, and you want to call that function. But in this case, it
does not return anything.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu
up{
> \override #'(baseline-skip . 1.5)
> \abs-fontsize #10
> \column{
> \halign #-1.3 "D.C."
> \concat{ "sin'al " \raise #0.8 \musicglyph #"scripts.ufermata" }
> }
> }
> s1
> }
> \new staff { c''1 s1}
>>>
> %%%%
the fingering from chorded
> notes, or from all notes, but not just from unchorded notes.
Remove the Fingering_engraver, _and_ add a dummy engraver listening to
fingering events and ignoring them. Then New_fingering_engraver will
not feel compelled taking over.
--
David Kastrup
_
ts.rcomma"
> \raise #1
> \musicglyph #"scripts.ufermata"
> }
> \breathe
> }
Doesn't \single\override (aka \tweak) work here? A \tweak has the
advantage of not messing with anything else happening at the same time.
--
David Kastrup
__
"sin'al " \raise #0.8 \musicglyph #"scripts.ufermata" }
>>> }
>>> }
>>> s1
>>> }
>>> \new staff { c''1 s1}
>>>>>
>>> %%% END LILY CODE SNIPPET
>>
>> Please test your examples be
Noeck writes:
> Am 17.02.2013 04:09, schrieb David Kastrup:
>> Remove the Fingering_engraver, _and_ add a dummy engraver listening to
>> fingering events and ignoring them. Then New_fingering_engraver will
>> not feel compelled taking over.
>>
>
> Ok, th
be
somewhat surprised if the --prefix option worked reliably: I don't think
people test it much.
> 7. make install
First make, then make install.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
27;d expect the
> slur to be above.
>
> \version "2.16.1"
> \relative c'' { \slurUp d4. \slashedGrace e16 ( d8 b4 d4 ) }
\version "2.16.1"
\relative c'' { d4. \slashedGrace e16^( d8 b4 d4 ) }
works fine here.
--
David Kastrup
___
Sávio Ramos writes:
> Hello,
>
> The command \cadenzaOn \cadenzaOff don't remove stem.
Is there a reason they should?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
They shouldn't. They only affect timing, not the appearance of notes.
>>
>> To hide stems, use
>>
>> \override Stem #'stencil = ##f
>
> /beams/ are removed
Hardly. Autobeaming is switched off, so you get only beams for manual
beaming. But that
Thomas Morley writes:
> I wrote too early.
> Now Firefox saves the file and _then_ opens it with gedit.
>
> Not what I wanted.
I have a hard time imagining how to open the text editor on a file that
has not been saved.
--
D
t people call
"great notation program" likely concerns note entry, and that's not
something where the LilyPond toolchain really shines.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
cribes exactly how the finished score will appear,
what will happen with the spacing when transposing? Presumably it is
ingrained into the file, so how will everything get retrofitted?
However, LilyPond indeed has a weakness in as far as it does not really
have a "file format&q
Hilary Snaden writes:
> On 2013-02-21 23:10, David Kastrup wrote:
>
>> However, LilyPond indeed has a weakness in as far as it does not
>> really have a "file format". It is an evolving input language.
>
> If that's a "weakness", it's one I&
\voiceTwo \tromA }
> \new Voice { \voiceTwo \tromB }
> >>
Both with \voiceTwo?
Of course this will clash.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Jim Long writes:
> On Fri, Feb 22, 2013 at 09:41:01AM +0100, David Kastrup wrote:
>> Jim Long writes:
>>
>> > I will say that the merging of noteheads onto stems is probably
>> > the weak spot in my knowledge.
>>
>> [...]
>>
>> > T
akes it clearer.
> If you want to achieve that result but want (obviously) to have
> separate voices
I don't see anything here that would warrant separate voices. Just use
\new Voice << \tromboneOne \tromboneTwo >>
in order to put both into the sa
one by non-specialists.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
73391.ly"
>> Child returned 1
>>
>>
>> What could I be doing wrong or am I missing something?
>
> Does the simple example above compile:
>
> \begin{lilypond}
> \relative c' {
> c2 e2 \times 2/3 { f8 a b } a2 e4
> }
> \end{lilypond}
Without li
and now everything, including lilypond-book works as
> expected.
>
>
> I am glad this works, but does anyone know how to fix this properly ?
It's apparently a consequence of Fedora's directory structure and/or
PATH not matched to how they install LilyPond.
--
David Kast
nge for money.
Of course, if you fund a set of six non-LilyPond specific programmers to
stay in the same office for a month on issue 34, it will with some
probability make progress, but that's not to be had for a "reasonable
amount".
--
David Kastrup
slur outside the brackets didn't work either,
> obviously. Does anyone have any thoughts on how to render this
> properly? Thanks.
Try removing \\ here. I does not appear that the chosen constructs
really need separate voices.
--
David Kastrup
u'd likely get better error messages from 2.16.2. There is a missing
closing brace or similar.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
David Kastrup writes:
> "Peter Gentry" writes:
>
>> I tried this solution but got the following result. What went wrong?
>>
>> Starting lilypond-windows.exe 2.16.0 [Untitled]...
>> Processing `c:/windows/temp/frescobaldi-pkr1ne/tmp52xhgd/document.ly
' {
> c8[] c
> }
As expected, a one-note beam.
Maybe look at
http://lilypond.org/doc/v2.16/Documentation/notation/beams#manual-beams>
to see how this is done for single notes.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
lar point of
processing. I doubt that you would notice a significant difference if
you had 100 bar checks every bar.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
SCM - it
> is good practice to first look for an error in the user.ly
> file. Digging for it using judicious %s to comment out lines until you
> find the offending article.
>
> I will erect a large notice to remind me:)
You could just update to a version
concisely as
tboff = \omit TupletBracket
tbon = \undo \tboff
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
matic.
> Are there ideas which are still worked on?
Don't know of any falling under the "still worked on" umbrella. Work
happens all the time, and sometimes it makes old wishlist items come
into accessible range and/or a new light.
--
David Kastrup
__
operating systems fostering this cooperation.
If you find you enjoy working with LilyPond and its community, chances
are that working with the Free Systems where it is at home will become
rewarding to you.
Ok, too long.
--
David Kastrup
___
lilypond
awareness about it when saying how
> fantastic the experience is of using a certain piece of
> freedom-denying software.
Well, it _is_ good cake. But they would be welcome to the whole bakery.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
solutely fantastic, but some people's aversion to anything which
> looks at all technical seems unsurmountable to me (although I'd love
> to be proven wrong; after all, I still see "non-technical" airport
> staff happily typing cryptic commands into old-school terminals in
&
rk better
> on Linux, that's perfectly fine, but it is completely unreasonable for
> you to expect me to censor myself because it happens to work great on
> Windows.
If people gather that switching to Windows will make themselves get a
great working Python, you are not necessarily d
oolean and Y is one or more context or property
> changes.
>
> How generic could you make an engraver, which allowed users with
> little or no Scheme experience to set up their own "switches"?
Isn't that what
\applyContext
is for,
OS.
Those who don't care will not actively help Free Software including
LilyPond, so it is in LilyPond's best interest to make them care. Which
is not necessarily the same as annoying them. But it is also not the
same as hiding under a rock.
--
David Kastrup
__
ought LilyPond
to them in the first place.
Without the GNU project, there would be no LilyPond. We would not have
a build platform, we would not have GUILE, we would not have the
enthusiasm of its founders. Without Free Software, it is not even
conceivable h
e music" formula within a lyricmode block I get an
> "unexpected LYRICS_STRING" error. Can someone clarify?
Do you have a minimal example?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Daniel Rosen writes:
>> -Original Message-
>> From: David Kastrup [mailto:d...@gnu.org]
>> Sent: Tuesday, February 26, 2013 7:24 PM
>> To: lilypond-user@gnu.org
>> Subject: Re: Footnotes to lyrics
>>
>> Daniel Rosen writes:
>>
g b \applyContext #(lambda (context) (if cond
> (ly:context-mod-apply! context mod))) c a f d c1
>
> }
>
>
> I think, for your idea of automatically changing properties in a
> context, you will need an engraver.
\applyContext is not run "in the music stream" but during ite
ed nor
tolerant, and when this imbalance and intolerance is tilted against the
GNU project and its goals and guidelines, it is not even serving a
discernible purpose.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
from yours.
And if one is really, really loath to doing that, then erring on the
calmer side of recollection might be safer.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Daniel Rosen writes:
>> -Original Message-
>> From: David Kastrup [mailto:d...@gnu.org]
>> Sent: Wednesday, February 27, 2013 5:24 AM
>> To: lilypond-user@gnu.org
>> Subject: Re: Footnotes to lyrics
>>
>> Conversion to 2.17.13 (what I ha
yours.
>
> Done. And it didn't change my opinion that some people in this thread
> have crossed the line into inflammatory advocacy.
Now that is a summary that I can agree with.
--
David Kastrup
___
lilypond-user mailing list
lilyp
Daniel Rosen writes:
>> -Original Message-
>> From: David Kastrup [mailto:d...@gnu.org]
>> Sent: Wednesday, February 27, 2013 9:03 AM
>> To: Daniel Rosen
>> Cc: lilypond-user@gnu.org
>> Subject: Re: Footnotes to lyrics
>>
>> Phooey. I as
ing it.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Adam Spiers writes:
> On Tue, Feb 26, 2013 at 5:22 PM, David Kastrup wrote:
>> Adam Spiers writes:
>>> I just blogged about this:
>>>
>>> http://blog.adamspiers.org/2013/02/25/music-industry-learns-nothing-from-the-avid-sibelius-saga/
>>
>>
ression by closing 3203 (in order to
preserve the history of it, by merging into the old issue 3192) and
reopening the old issue. That should make people less afraid to delay
the patch in its current form by further review as it clearly is _not_
f
> Can anyone recommend a workaround in the meantime?
The following actually works fine for me in 2.17.12:
\score {
{ c'4 c' c' c' }
\addlyrics
{ \footnote #'(-2 . -2) \markup "text"
\markup Mu- sic is nice }
}
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
bout GUILE/Scheme
outside of LilyPond might extend your horizons and make you realize how
you might want to see things done differently or Scheme-accessible in
LilyPond.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Daniel Rosen writes:
> I'm typesetting a piece of vocal music, and I want to have a melisma
> without a slur being drawn.
http://lilypond.org/doc/v2.16/Documentation/notation/common-notation-for-vocal-music#index-melismata>
--
Adam Spiers writes:
> On Thu, Feb 28, 2013 at 6:51 AM, David Kastrup wrote:
>> Adam Spiers writes:
>>> On Tue, Feb 26, 2013 at 5:22 PM, David Kastrup wrote:
>>>> Adam Spiers writes:
>>>>> I just blogged about this:
>>>>>
>&
Zenaan Harkness writes:
> On 2/27/13, David Kastrup wrote:
>> Kieren MacMillan writes:
>>
>>> David,
>>>
>>>> Then it would seem that many of us have forgotten
>>>> what brought LilyPond to them in the first place.
>>&
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
>> Starting scene of Macbeth. But at any rate, I perceive a shift in
>> educational systems to award degrees that have at best a weak
>> correlation with being competent in the certified field of expertise.
>> T
erful stories, are all sad. It's just that
> Hollywood will find a way to pervert most beautiful sad stories into a
> happy end before we get to see them ;-)
An optimist believes that we are living in the best of all conceivable
worlds. A pessimist _knows_ it.
--
David Kastrup
___
, sorry for that.
> Evidently the - immediately following the first syllable is necessary
> but the reason for it is not obvious.
It can only be a symbol if it consists of just letters, possibly
separated by single - or _. A - at the end makes sure that it is
lyrics, and not a specifica
.
You don't need an explicit ! everywhere if you want every accidental
anyway. Look up \accidentalStyle in the manual: you'll likely find a
style that matches your requirements.
--
David Kastrup
___
lilypond-user mailing list
is _not_ how LilyPond works. Instead you
write the pitch you want to hear. LilyPond will decide by its own rules
when it needs a sharp, a flat, or a natural.
What you write as a is _always_ played on a white key, what you write as
fis is _always_ played on a black key.
--
Davi
you are
staying in the same voice, things will come together just fine.
Note that
<< \x \y >>
is parallel music while
<< \x \\ \y >>
is a shorthand equivalent to
<< \context Voice = "1" \with { \voiceOne } \x
ive { f } -> f'
\relative { g } -> g
That makes only sense in relation to c', so why not write it explicitly?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
kely that nobody answers than
you consider it likely that more than one person would try helping.
Now let's just consider the case that a single person would be willing
to help you. Why should he invest more effort than you?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
oneVoice)))
Uh, any reason this is not just
split =
#(define-music-function (parser location music1 music2)
(ly:music? ly:music?)
#{ << { \voiceOne $music1 \oneVoice }
\context Voice = "2" { \voiceTwo $music2 } >>
#})
Why make things more complex than necessary?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
n right now pretty much literally from
the Scheme expression back to using an embedded LilyPond expression, so
it is quite unlikely that it does something different.
Have you even tried it?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.or
l that helpful to her.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
ctly the same music
expression after this change, just written in a different manner.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_would_ have triggered issue 2263 in case you were using _chord_
_repetition_ in connection with \relative.
http://code.google.com/p/lilypond/issues/detail?id=2263>,
previously
http://code.google.com/p/lilypond/issues/detail?id=1110>.
Oh, that one had bounties. Don't even r
g \relative
on it would have been sufficient. So writing the function without any
copying (as the Scheme version did) would only have prevented one way of
blowing up on the old repeat chord implementation.
Given the amount of friendly words that I lost over the repeatchord
feature and its origin
Now how to get to line 27 of your file depends on the editor you are
using.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
regard since it is pretty much our
_only_ development platform. Even for people otherwise at home on other
operating systems. So it is doubly important that we don't have
stumbling blocks requiring experienced users of GNU/Linux there.
Now it is true that I likely don't have a good c
\consists "Ottava_spanner_engraver" }
$music
#})
\relative c {
\clef bass
<<
{
1~
4
}
\\
{ r2. \voiceOttava #-1 { \voiceTwo 4 4 } }
>>
}
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
list the
same advice, again and again?
While it is quite more efficient to condense it in the manual and point
to that, pointing every single user to this manual section is going to
get old as well.
After telling enough people "the problem is actually simple, it is just
you who are incompetent", maybe we should think twice about what we have
to gain by making LilyPond users feel incompetent.
I don't see a compelling technical reason not to cater to this
particular naive expectation.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Marc Hohl writes:
> Am 06.03.2013 09:38, schrieb David Kastrup:
>> Marc Hohl writes:
>>
>>> kudos for this detailed explanation! I wonder if the documentation about
>>> bar lines should be enhanced in this way, or is there a place where this
>>> inform
Thomas Morley writes:
> 2013/3/6 David Kastrup :
>
>> It is orthogonal to us making \bar "|:" and \bar ":|" well-defined by
>> letting : automatically imply a thick bar since nothing else makes
>> sense.
>>
>> We don't want t
visual variant.
I think that if we depart from the notion that the bar name for \bar
should always correspond to the WYSIWYG definition of the in-line
rendition, and thus separate the logical user interface from the purely
visual definition of the resulting look, we will keep the aesthetics of
both users and programmers reasonably unoffended.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
l have to add
>
> \layout {
> \context {
> \Voice
> \remove "Slur_performer"
> }
> }
That would not do anything in the \layout block since the \layout block
does not have a Slur_performer in Voice anyway. It belongs in the \midi
block.
lily would offer a better way to _structurize_ music, this
> discussion would be rather academic.
We'd still need a way to configure the visual appearance.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
alias, whereas for Marc the alias would be \bar "|:" and
for me it would be the main interface...
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Janek Warchoł writes:
> On Wed, Mar 6, 2013 at 9:24 PM, David Kastrup wrote:
>> Marc Hohl writes:
>>> As I mentioned elsewhere, I seldom use the repeat sign explicitely, I
>>> try to get along with \repeat volta. Moreover, I find it very annoying
>>> to e
David Kastrup writes:
> Kieren MacMillan writes:
>
>> I definitely use a lot of chord repetition, and I always (= 99% of the
>> time) use \relative. In fact, until only recently, most of my code had
>> \relative {} instead of the now-promoted \relative x {} [where x is
Marc Hohl writes:
> Am 06.03.2013 21:24, schrieb David Kastrup:
>> Marc Hohl writes:
>>
>>> I am a bit disappointed that the discussion about \bar ":|."
>>> rises half a year after the patch went through the revision
>>> process.
>>
Thomas Morley writes:
> 2013/3/6 David Kastrup :
>> Marc Hohl writes:
> [...]
>>> The basic idea behind the bar line interface based on Harm's
>>> work, and I like the idea of having a 1:1 representation of the
>>> bar line stringwise.
>>
>&g
t at first.
> I hope that this extension will find its way into the official
> lilypond releases...
What needs to be done for this?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Janek Warchoł writes:
> On Thu, Mar 7, 2013 at 10:06 AM, David Kastrup wrote:
>> [snip snip]
>> Ok, here is the deal: I promise to give real thought about a way to
>> _define_ repeat structures in such a straightforward manner that a user
>> would understand how to
ocess.
>
> I am sorry. But in this case it was triggered by a user (me) who did
> not take part in the revision process. But it is still the development
> version.
Yup. And if one aim is to avoid a flurry of users complaining about
\bar "|:" having stopped working, we are stil
Marc Hohl writes:
> Am 07.03.2013 10:06, schrieb David Kastrup:
>> [...]
>> Ok, here is the deal: I promise to give real thought about a way to
>> _define_ repeat structures in such a straightforward manner that a user
>> would understand how to create repeat stru
Noeck writes:
>> We use "|." for the end bar not because of its _visual_ properties,
> If that is the case, I would say \bar "." is more logical.
Zounds. Tell you what: I'd consider that an actual improvement. Never
though
Marc Hohl writes:
> Am 07.03.2013 18:36, schrieb David Kastrup:
>> Noeck writes:
>>
>>>> We use "|." for the end bar not because of its _visual_ properties,
>>> If that is the case, I would say \bar "." is more logical.
>> Zounds.
Marc Hohl writes:
> Am 07.03.2013 18:45, schrieb David Kastrup:
>> Marc Hohl writes:
>>
>>> Am 07.03.2013 18:36, schrieb David Kastrup:
>>>> Noeck writes:
>>>>
>>>>>> We use "|." for the end bar not because of its
an autogenerated one on
\relative c' { c c } ?
Do we want one on
\relative c' { \partial 4 c | c c c } ?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Marc Hohl writes:
> Am 07.03.2013 18:56, schrieb David Kastrup:
>
>> A piece has one final bar line. A music theory text has thousands of
>> fragments without final bar line.
> Ok, but this depends on what you write more often – from my rather
> selfish point of view,
ntless if it's not enough of an improvement to actually change the
documentation extensively and recommend this use.
How do people feel about this?
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
David Kastrup writes:
> Please take a look at
>
> Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
> an absolute one
>
> http://code.google.com/p/lilypond/issues/detail?id=3229>
>
> It's clear that this change will require quite a bit more wo
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 af
Janek Warchoł writes:
> On Thu, Mar 7, 2013 at 8:06 PM, David Kastrup wrote:
>> 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 b
reimplemented outside of the parser.
But at any rate: the change only concerns the choice of reference pitch,
so nothing _inside_ of \relative really changes.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
he only thing that works reliably for copy/paste is absolute pitch.
Relative pitch is always prone to octave errors.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Graham Percival writes:
> On Thu, Mar 07, 2013 at 08:06:24PM +0100, David Kastrup wrote:
>>
>> 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 t
Colin Hall writes:
> David Kastrup writes:
>
>> Please take a look at
>>
>> Issue 3229: Patch: Make \relative { ... } interpret the first pitch as
>> an absolute one
>>
>> http://code.google.com/p/lilypond/issues/detail?id=3229>
>>
>>
ative to the previous
pitch. The first written pitch after @code{\relative} is in absolute
pitch. If @code{\relative} is @emph{immediately} followed by a pitch,
this pitch is @emph{only} used as the reference pitch for the following
music and not interpreted otherwise."
That's
501 - 600 of 7563 matches
Mail list logo
