lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: divisi parts and another general question


From: Sarah k Alawami
Subject: Re: divisi parts and another general question
Date: Sun, 3 Mar 2013 11:12:00 -0800

Ok. it looks like the viola part  needs to be device as these double stops are 
not fun. here it is with the notes and cords with out taking the divisi  in to 
consideration.

{ c aes,  g  ees |
ees f <des ees> <c ees> | }

Just the first 2 measures

so would I have to imply the double less then sign at the top  to indicate the 
divisi and the double back slash method for this? so it would be something like

<<
{ c aes,  g  ees |
ees f {des ees} {c ees} | \\} single note safer that? Actually I won't be 
getting out of that divisi for a while it looks like. so would I have to switch 
to then voice 1 and voice 2? if so that will be annoying. lol!


On Mar 3, 2013, at 8:13 AM, David Kastrup <address@hidden> wrote:

> Kieren MacMillan <address@hidden> writes:
> 
>> Hi David,
>> 
>>> Here is one difference: #{ ... #} creates copies of music
>>> identifiers referenced via \... inside.
>>> 
>>> That's not relevant for anything you mentioned explicitly, but it
>>> _would_ have triggered issue 2263 in case you were using _chord_
>>> _repetition_ in connection with \relative.
>> 
>> 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
>> the first note in the music expression]. (I am slowly updating my old
>> code to fix this.)
> 
> I do not remember that we promoted \relative x, actually.  What I wanted
> to promote at one point of time was having \relative { ... } be
> equivalent to \relative f { ... } since then the first note inside can
> _always_ be specified as if it was absolute:
> 
> \relative c' { f' } -> f''
> \relative c' { g' } -> g'
> \relative f { f' } -> f'
> \relative f { g' } -> g'
> 
> Since \relative f looks contrived (it's not easy to explain what makes f
> special), being able to leave off the pitch and have it secretly
> replaced by f would make sense.
> 
> Of course, it would appear that enough legacy code with \relative {
> ... } is around to make that change somewhat painful.
> 
>> Furthermore, I can report with total confidence that the bug I
>> encountered was an octave displacement problem — I remember that
>> vividly, since it was so irritating (and inexplicable).
>> 
>> So it seems that
>> 
>>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2263>,
>>> previously
>>> <URL:http://code.google.com/p/lilypond/issues/detail?id=1110>.
>> 
>> were/was almost certainly the problem(s).
>> 
>> Can you say with 100% certainty that this issue is now solved, and
>> hence that I will get identical results the my function and the
>> simpler function (which I prefer)?
> 
> Yes.  I completely reimplemented the whole of chord repetition after the
> EventChord changes (issue 2240) made it possible to distinguish chords
> and single notes in music expressions (rather than just in the parser).
> That was not just further touchup work on a flawed implementation.  I
> don't know of any remaining code in LilyPond that gets confused by
> copying nowadays (as of 2.16).
> 
> Independently, you can by now (not sure about the version) write #music1
> and #music2 inside of sequential music in #{ ... #} and in that manner
> avoid the copying that takes place when writing $music1 and $music2.  It
> is not really all that important, and since LilyPond often works
> destructively on music expressions, copying more than necessary is to be
> preferred over copying less than necessary.  One difference, however, is
> that point-and-click for $xxx expressions points to the call of the
> music function whereas point-and-click for #xxx expressions points to
> the original music expression.
> 
>> p.s. I'm relieved to have proven to myself that my memory was to be
>> trusted on this after all!  =)
> 
> The repeatchord debacle could not just be triggered by music functions.
> Even just sticking something in a music variable before doing \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 original implementation on the developer list, it is
> somewhat embarrassing that I did not make the connection here.
> 
> -- 
> David Kastrup
> 
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user




reply via email to

[Prev in Thread] Current Thread [Next in Thread]