Re: Issue 1265 in lilypond: Avoid compilation and run-time deprecation warnings from Guile V2
Comment #3 on issue 1265 by Carl.D.Sorensen: Avoid compilation and run-time deprecation warnings from Guile V2 http://code.google.com/p/lilypond/issues/detail?id=1265 As far as I recall, we already got the go-ahead to remove all of the Guile 1.6 compatibility code. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 694 in lilypond: Enhancement: arrowed heads for microtone accidentals
Comment #10 on issue 694 by joseph.wakeling: Enhancement: arrowed heads for microtone accidentals http://code.google.com/p/lilypond/issues/detail?id=694 Looking at the patches, they don't address the fundamental problem. I don't know whether they really matter at this stage. The problem is not the support for arbitrary fractional alterations of a pitch per se. The problem is that Lilypond permits only one possible accidental for any given alteration of a pitch, whereas some microtonal notations (like the arrowed notation) can have two different accidentals for the same pitch alteration. I'll try and write up an adequate description of the problems/concerns for the -devel list. I did try and do this some time ago at: http://lists.gnu.org/archive/html/lilypond-user/2009-04/msg00139.html ... but the discussion/feedback at the time didn't lead to an adequate solution. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1265 in lilypond: Avoid compilation and run-time deprecation warnings from Guile V2
Updates: Summary: Avoid compilation and run-time deprecation warnings from Guile V2 Labels: Patch Comment #2 on issue 1265 by ianhuli...@gmail.com: Avoid compilation and run-time deprecation warnings from Guile V2 http://code.google.com/p/lilypond/issues/detail?id=1265 I have a patch available, builds and runs OK and runs reg-tests with Guile V1.8.7. With Guile 1.9.12 compiles without deprecation warnings and runs up as far as it gets without the patch, but this time without the run-time deprecation warnings from libguile. The patch is available for review at http://codereview.appspot.com/2247041 One issue - there's a flower/include/guile-compatibility.hh with stuff in it to translate the new guile names back to the deprecated guile names. This is intended for Guile 1.6, which we don't support any more. Should I hack out the conditional compilation block as part of this change? This thing is included by lily/include/lily-guile.hh. Cheers, Ian ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 694 in lilypond: Enhancement: arrowed heads for microtone accidentals
Comment #9 on issue 694 by percival.music.ca: Enhancement: arrowed heads for microtone accidentals http://code.google.com/p/lilypond/issues/detail?id=694 What's not clear... - there's some patch(s), but it's not clear if it applies to current git, or is waiting for revision from the author, or waiting for review. - lilypond already supports arbitrary fractional tones. Notation 1.1.1 Non-Western note names and accidentals, in the 2.13 docs. So what's missing? Just the graphical pointed arrow? - to reduce confusion from developers and bug squad people, we only want "item" per issue. This one claims to be about documentation, but the original reporter (Valentin) didn't know about our arbitrary-fraction-microtones, and there's this patch, and now you're talking about "code solution first"... We need somebody who cares about microtonal support (you?) to divide this up. - if anything is wrong with our fundamental support for arbitrary fractional microtones, make a minimal bug report and send it to bug-lilypond. The Bug Squad should add a SEPARATE issue for that one. - if the fundamental definitions of microtones are fine, but you want a different display mechanism (which is probably true; the Turkish notation doesn't look familiar to me), then make a minimal bug report and send it to bug-lilypond. The bug squad should add a separate issue for that graphical enhancement request. - if the patch is still good, then send it to lilypond-devel, and if nobody replies, the patch manager will add a separate issue blah blah. - if there's anything else, then send a separate minimal bug report, and blah blah. Finally, close this issue because it's way too confusing for me. Yes, I may be an idiot, but given that it's an old issue and nobody else has looked into it, I think you need to deal with the idiot. I know this makes extra administrative work (maybe 30 minutes in total?) for people who care about microtonal stuff, but IMHO that's the best chance to move forward with this. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 694 in lilypond: Enhancement: arrowed heads for microtone accidentals
Comment #8 on issue 694 by joseph.wakeling: Enhancement: arrowed heads for microtone accidentals http://code.google.com/p/lilypond/issues/detail?id=694 Can you clarify which points you feel are not clear? My feeling is that it is principally a code issue, not a doc one. Lilypond simply does not support effectively one of the ways of writing microtones -- which is to successively "shade" pitches by adding extra symbols to the accidentals (up/down arrows, +/-, whatever). The _reason_ it does not support this notation for microtones is because of Lilypond's internal way of representing pitch -- as staff position + alteration. That clashes with a notation like e.g. the arrow notation for quarter-tones, where the same alteration (+1/4) can be notated with two different accidentals: natural-with-arrow-up or sharp-with-arrow-down. I developed a 'cheat' solution that used subtly different alterations to correspond to these different accidentals, but it's far from ideal. A better approach would likely be to have a notation like \qUp c \qDown cs ... which modifies the accidental contextually. Anyway, bottom line is, this needs code solution first and then documentation one. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Mark Polesky wrote Sunday, September 19, 2010 3:54 PM Trevor Daniels wrote: But a quick look through some of my music shows dynamics are more commonly placed above the staff, so I wonder why placing them below is the default? But I don't have any instrumental parts to hand - where are the dynamics in these usually placed? Vocal dynamics are usually placed above the staff so they don't interfere with the lyrics. Otherwise, dynamics are usually placed below the staff for monophonic staves, and for polyphonic staves when the dynamics are the same. OK, and as the dynamics _are_ usually the same, and as dynamics are usually placed in voice one for polyphonic music, they should be placed, by default, below the staff for voice one. And, I would argue, for all voices. But as Kurt Stone, Ted Ross, and Gardner Read *all* agree, polyphonic staves with different simultaneous dynamics require upstem and downstem dynamics to be placed above *and* below the staff respectively. Why are we arguing when the authorities are clear on this? I'm not arguing with that. I'm arguing that this occurs rarely and there is a perfectly good command for doing it when it happens. So the default should not be changed. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1043 in lilypond: Cross-staff beams confuse skyline calculations
Comment #10 on issue 1043 by k-ohara5...@oco.net: Cross-staff beams confuse skyline calculations http://code.google.com/p/lilypond/issues/detail?id=1043 Using Carl's way of categorizing the sub-issues, (1) could be summarized "collision automatic beams near staff changes." (2) is already in this tracker as issue 439, and issue 36. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 389 in lilypond: \t -> tab in LSR snippets
Updates: Status: Fixed Labels: fixed_2_13_34 Comment #14 on issue 389 by percival.music.ca: \t -> tab in LSR snippets http://code.google.com/p/lilypond/issues/detail?id=389 pushed as f8fd9c211e9ab17859841aa9ec98af731ab253c3 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 389 in lilypond: \t -> tab in LSR snippets
Comment #13 on issue 389 by percival.music.ca: \t -> tab in LSR snippets http://code.google.com/p/lilypond/issues/detail?id=389 ok, I've discovered that the LSR export is perfectly fine; it's just snippets in D/s/n/ and many of the translate texidoc strings. I've got an auto-backslash-escape function for makelsr.py now, which I'm just doing a final doc-compile test before pushing. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1202 in lilypond: git cl is hidden in CG 9.8.9 ?
Updates: Status: Started Owner: percival.music.ca Comment #1 on issue 1202 by percival.music.ca: git cl is hidden in CG 9.8.9 ? http://code.google.com/p/lilypond/issues/detail?id=1202 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 965 in lilypond: making a score-following DVD with lilypond
Updates: Labels: -Priority-Postponed Priority-Low Comment #1 on issue 965 by percival.music.ca: making a score-following DVD with lilypond http://code.google.com/p/lilypond/issues/detail?id=965 This is a valid request, and more important than other Postponed items. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1199 in lilypond: lilypond telnet server
Updates: Labels: -Priority-Postponed Priority-Low Comment #2 on issue 1199 by percival.music.ca: lilypond telnet server http://code.google.com/p/lilypond/issues/detail?id=1199 More important than Postponed. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Trevor Daniels wrote:
> But a quick look through some of my music shows dynamics
> are more commonly placed above the staff, so I wonder why
> placing them below is the default? But I don't have any
> instrumental parts to hand - where are the dynamics in
> these usually placed?
Vocal dynamics are usually placed above the staff so they
don't interfere with the lyrics. Otherwise, dynamics are
usually placed below the staff for monophonic staves, and
for polyphonic staves when the dynamics are the same. But as
Kurt Stone, Ted Ross, and Gardner Read *all* agree,
polyphonic staves with different simultaneous dynamics
require upstem and downstem dynamics to be placed above
*and* below the staff respectively. Why are we arguing when
the authorities are clear on this?
http://lists.gnu.org/archive/html/bug-lilypond/2010-09/msg00259.html
Phil Holmes wrote:
> Why should voiceOne dynamics go above the staff?
So they're not mistaken for voiceTwo dynamics!
> I frequently set music only putting the dynamics in one
> voice, and I don't expect that to determine where the
> dynamic goes.
I do expect it to.
> If you want it above the staff, you can use c2^\f.
If you're going to use single-staff polyphony and put your
dynamics in an odd-numbered voice, I think the burden should
be on you to use \dynamicDown. The way I see it, it's far
easier to ask a user in your situation to do this once...
\layout {
\context {
\Score
\override DynamicText #'direction = #DOWN
\override DynamicLineSpanner #'direction = #DOWN
}
}
...than to make a user like me have to keep doing this
every time I have polyphonic dynamics:
<< { \dynamicUp c4\p\< c c c\f } \\ { a1\mf } >>
David Kastrup wrote:
>> So why doesn't it also imply \dynamicUp ?
> Because that will be startling for basically homophonic
> voicing with only short
> not-actually-a-voice-but-we-need-to-write-it-such
> passages.
Hmm.
> As I said: the right thing to me seems to put the dynamics
> in every voice (and let the performers work from that),
> and give the dynamics engraver options to funnel them off
> to a common place as long as they can be unified (like in
> the middle of a piano stuff).
I do agree with you on this point -- from a semantics view,
every voice intended to be associated with a dynamic should
be given one, and this musical information should be
independent of the "style" in which it is displayed (think
HTML and CSS). And if "dynamic contamination" is to be
assumed, it should be formalized somewhere. Also, be
careful with the word "performers"; I assume you mean
Dynamic_performer?
>> ...what legitimate code would possibly break by changing
>> this?
>
> \relative c'' { << { c2\f } \\ { a2 } >> }
>
> Namely code that makes use of the fact that a dynamic
> specification in a single voice contaminates all other
> voices (and the Midi) by default.
>
> If all other dynamic specifitions end up below the staff,
> you'll be surprised at this one.
>
> I consider it bad style to write like this, but there have
> not been convincing alternatives yet, have they?
Eloquently stated.
I'm starting to think that this is a bigger problem than I
initially thought. You've said the LilyPond has "no clean
concept of dynamics related to voices rather than merely to
current time." Is there a solution?
- Mark
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1241 in lilypond: old .bib files contain latex-accents
Updates: Status: Fixed Labels: fixed_2_13_34 Comment #2 on issue 1241 by percival.music.ca: old .bib files contain latex-accents http://code.google.com/p/lilypond/issues/detail?id=1241 Second one pushed as 64e20e277b363c54afe92322f51a328bfb78caae ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 694 in lilypond: Enhancement: arrowed heads for microtone accidentals
Updates: Labels: -Priority-Medium Priority-Postponed Comment #7 on issue 694 by percival.music.ca: Enhancement: arrowed heads for microtone accidentals http://code.google.com/p/lilypond/issues/detail?id=694 At some point in GOP, we might assign a new doc person to work on this and figure out what's actually valid or not. As far as I'm concerned, the entire report is invalid, but I'll leave it here until somebody spends half an hour decyphering everything. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
On 2010-09-19 13:18, Trevor Daniels wrote: [...] This argues for making the default dynamic placement independent of voice, leaving the rarer case to be treated as an exception. But a quick look through some of my music shows dynamics are more commonly placed above the staff, so I wonder why placing them below is the default? But I don't have any instrumental parts to hand - where are the dynamics in these usually placed? In choir parts (french scores) with individual staves per voice, I can't remember any professional edition where the dynamics are written below the staff when there's enough space to have a choice. Mainly, I guess, because the distance to the staff gets too far for either dynamics or lyrics, and one of those could be mixed up with the previous or next voice. Instead, they the publishers try to keep everything close to the notes, and that means above the staff (or, even better, with the baseline extenders slightly inside the staff and the dynamics just a little bit _before_ the corresponding note). Only hairpins sometimes are between lyrics and staff, but it's not uncommon the other way around, too. [*] I'm not sure about instrumental parts, though, where IIRC the distance between staves often is larger, and there are no lyrics. And while I often want dynamics placed closer than LilyPond, I don't think it's sensible to allow them inside the staff per default. [*] But IMHO that's rarely good for LilyPond right now, since we have only a simple bounding box around hairpins, and often the lyrics get pushed too far downwards. Also, the same often happens with large slurs above extender lines or hyphens, by the way. Cheers, Alexander ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Help, please --- can not mode dot down .(
Hi! Here lilypond puts dots "in betweens noteheads", i need both of them (all of them) would be in spaces below noteheads: \version "2.13.33" % 2.12 does the same [...] It looks to me as if this strange behaviour is caused by the \voiceTwo-command. It also happens with \voiceFour. For now you could use \stemDown instead of \voiceTwo or: in 2.12.3 the result is incorrect no matter if you put \voiceX or nothing at all. \dotsDown also affects only one dot in the chord looks like a bug to me... greetings, Vicente ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Mark Polesky wrote Sunday, September 19, 2010 9:23 AM
Trevor Daniels wrote:
We have to be careful to interpret this correctly. None
of these writers were familiar with the use of "voice" in
the computer engraving sense. By "voice" these writers
mean parts that are on one staff but are to be played or
sung by independent musicians. With that meaning
separating the dynamics is sensible.
Trevor, I couldn't (respectfully) disagree more. The
computer engraving sense of the word "voice" changes nothing
here. A 5-voice fugue by Bach (such as BWV 849) has 5
voices on 2 staves, computer or no computer.
I think it does. When writing for polyphonic instruments
several voices are often required for differing rhythms.
But the dynamics are usually the same. You would want
the placement of a dynamic marking to be dependent on
the voice only if these were musically separate phrases
with differing dynamics, which is rarer than just
rhythmically differing parts. This argues for making
the default dynamic placement independent of voice,
leaving the rarer case to be treated as an exception.
But a quick look through some of my music shows dynamics
are more commonly placed above the staff, so I wonder
why placing them below is the default? But I don't
have any instrumental parts to hand - where are the
dynamics in these usually placed?
But it makes no sense to separate the dynamics of
individual voices in music that is intended to be played
by a single musician, such as guitar or piano music[1].
Indeed, in piano music LilyPond provides facilities for
combining the dynamics from two staves.
[1] Unless two overlapping sequences of notes are to be
played with different dynamics...
Are you saying that, in a 2-voice 1-staff setting, it makes
no sense to separate the dynamics when they both voices are
at the same dynamic? Like this:
\relative c'' {
<< { c2\p } \\ { a2\p } >>
}
Yes; unless the dynamics engraver were to be enhanced
in the way David suggests - so it were clever enough
to recognise they should be combined. That's maybe
desirable, but it doesn't sound an easy or imminent
change.
Trevor
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
"Mark Polesky" wrote in message
news:500436.44248...@web83404.mail.sp1.yahoo.com...
voiceOne Dynamics end up in the worst possible place...
- Mark
* * * * * * * * * *
\version "2.13.34"
\relative c'' {
<<
% "f" should go above the staff; but appears
% below the staff, below the "p" (!)
{ c2\f c }
\\
{ a2\p a }
>>
}
Why should voiceOne dynamics go above the staff? I frequently set music
only putting the dynamics in one voice, and I don't expect that to determine
where the dynamic goes. If you want it above the staff, you can use c2^\f.
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 687 in lilypond: Enhancement: inequal MIDI quantization of equal durations (swing, rubato)
Comment #25 on issue 687 by arvidgr: Enhancement: inequal MIDI quantization
of equal durations (swing, rubato)
http://code.google.com/p/lilypond/issues/detail?id=687
I took the liberty of fixing the two TODOs commenting in swingIt (so that
e.g. a 4. would be scaled right) and trying it on a real-world example.
The example is in copyright, so I can't post it here, but here's a few
observations:
It looks swingIt must be called on a beat. If I'm on an upbeat, I have to
compress that note manually. No surprise really.
Also, SimultaneousMusic isn't handled well. From what I observed, one
voice will be swung and the other left straight. In some (or even most)
cases, this will make the rythm go out of whack, giving barcheck errors and
unreadable scores.
So as it is, it can't be used on all the music of a staff if that staff
splits up into temporary voices. (Which is exactly what the piece of real
music I was applying this to did all the time.) Workaround:
\swingIt { a8 a 4. a8 a }
<< { a8*2/3 | % as I said, manually.
\swingIt { a8 a a a % ...
}} >>
<< { b8*2/3 | \swingIt { b8 b b b % ...
}} >>
;; ...etc.
And with that somewhat tedious workaround, it works!
Simultaneous music (temporary voices) could probably be handled by calling
the working part of swingIt recursively.
Cheers,
-- Arvid
Attachments:
swing.ly 2.8 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1043 in lilypond: Cross-staff beams confuse skyline calculations
Comment #9 on issue 1043 by Carl.D.Sorensen: Cross-staff beams confuse skyline calculations http://code.google.com/p/lilypond/issues/detail?id=1043 So what would be a good summary for this bug? It seems there are two issues, and maybe the bug should be split: 1) The beam created by autobeaming belongs to the staff of the note *after* the autobeam ends. The workaround here is to use manual beams instead of autobeams. 2) Dynamics are misplaced with cross-staff beams See measure 4 of the revised example. Attachments: cross-staff-beam-test.ly 1004 bytes cross-staff-beam-test.png 33.0 KB ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Mark Polesky writes:
> Are you saying that, in a 2-voice 1-staff setting, it makes
> no sense to separate the dynamics when they both voices are
> at the same dynamic? Like this:
>
> \relative c'' {
> << { c2\p } \\ { a2\p } >>
> }
>
> Okay, I suppose I might be able to agree with that. The
> first note of Beethoven's 2nd symphony has 5 such instances
> of a combined dynamic, though that's not what you're
> referring to since those instances are not each played by
> single musicians. Besides, compile that fragment --
> LilyPond prints 2 p's anyway.
>
> And it makes *every* sense to separate the dynamics for a
> single player when the dynamics are different. And please
> don't make me place all of these manually, or you might as
> well ask me to manually place every articulation, slur, tie,
> etc. IIUC, \voiceOne already implies the following:
>
> \dotsUp
> \phrasingSlurUp
> \slurUp
> \stemUp
> \tieUp
> \tupletUp
> [... also articulations, fermatas, etc. go up]
>
> So why doesn't it also imply \dynamicUp ?
Because that will be startling for basically homophonic voicing with
only short not-actually-a-voice-but-we-need-to-write-it-such passages.
As I said: the right thing to me seems to put the dynamics in every
voice (and let the performers work from that), and give the dynamics
engraver options to funnel them off to a common place as long as they
can be unified (like in the middle of a piano stuff).
> \relative c'' {
> << { c2\f } \\ { a2\p } >>
> }
>
> In my mind, this is so obviously a bug, I'm surprised by all
> this resistance. I mean, what legitimate code would
> possibly break by changing this?
\relative c'' {
<< { c2\f } \\ { a2 } >>
}
Namely code that makes use of the fact that a dynamic specification in a
single voice contaminates all other voices (and the Midi) by default.
If all other dynamic specifitions end up below the staff, you'll be
surprised at this one.
I consider it bad style to write like this, but there have not been
convincing alternatives yet, have they?
--
David Kastrup
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Oh no, not one of these threads...
Trevor Daniels wrote:
> We have to be careful to interpret this correctly. None
> of these writers were familiar with the use of "voice" in
> the computer engraving sense. By "voice" these writers
> mean parts that are on one staff but are to be played or
> sung by independent musicians. With that meaning
> separating the dynamics is sensible.
Trevor, I couldn't (respectfully) disagree more. The
computer engraving sense of the word "voice" changes nothing
here. A 5-voice fugue by Bach (such as BWV 849) has 5
voices on 2 staves, computer or no computer.
> But it makes no sense to separate the dynamics of
> individual voices in music that is intended to be played
> by a single musician, such as guitar or piano music[1].
> Indeed, in piano music LilyPond provides facilities for
> combining the dynamics from two staves.
>
> [1] Unless two overlapping sequences of notes are to be
> played with different dynamics...
Are you saying that, in a 2-voice 1-staff setting, it makes
no sense to separate the dynamics when they both voices are
at the same dynamic? Like this:
\relative c'' {
<< { c2\p } \\ { a2\p } >>
}
Okay, I suppose I might be able to agree with that. The
first note of Beethoven's 2nd symphony has 5 such instances
of a combined dynamic, though that's not what you're
referring to since those instances are not each played by
single musicians. Besides, compile that fragment --
LilyPond prints 2 p's anyway.
And it makes *every* sense to separate the dynamics for a
single player when the dynamics are different. And please
don't make me place all of these manually, or you might as
well ask me to manually place every articulation, slur, tie,
etc. IIUC, \voiceOne already implies the following:
\dotsUp
\phrasingSlurUp
\slurUp
\stemUp
\tieUp
\tupletUp
[... also articulations, fermatas, etc. go up]
So why doesn't it also imply \dynamicUp ?
> ...but then the positioning depends on the particular
> locations of the notes on the staff and is better done
> manually.
??!! Which notation manual states this? This goes against
everything, I think! A \voiceOne slur always goes up, no
matter how low the note. Where is it stated that a dynamic
should follow a different rule?
And when would the current (ridiculous) default positioning
in the following construct *ever* be appropriate?
\relative c'' {
<< { c2\f } \\ { a2\p } >>
}
In my mind, this is so obviously a bug, I'm surprised by all
this resistance. I mean, what legitimate code would
possibly break by changing this?
- Mark
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
"Trevor Daniels" writes: > Mark Polesky wrote Sunday, September 19, 2010 2:37 AM > >> Gardner Read, ch.14, "NOTATIONAL PRACTICES", p.253: >> "The general rule is, of course, altered should there be >> inadequate room because of elements [...] related to the >> staff just below, or when different dynamic markings >> affect two voices written on one staff..." > > We have to be careful to interpret this correctly. > None of these writers were familiar with the use of > "voice" in the computer engraving sense. By "voice" > these writers mean parts that are on one staff but > are to be played or sung by independent musicians. I disagree. Baroque polyphony is commonly executed on single instruments, as composed. The principal selling point of the pianoforte (hammer piano) was that it allowed playing several dynamics at once without being confined to working with registers. More than a single dynamic is even needed for executing Bach violin solo pieces, for multiple voices executed sequentially (via multi-string bowing patterns) or in parallel (via skewed bow pressure on multiple strings). And of course, the principal polyphonic string instrument, the lute, was also employed with voices differentiated in articulation and dynamics. > But it makes no sense to separate the dynamics of individual voices in > music that is intended to be played by a single musician, such as > guitar or piano music[1]. You can even differentiate dynamics of different voices on an accordion (where every reed sounds off the same bellow, the principal control of dynamics) by working with articulation, variations of button depression, psychoacoustical masking (a loud onset masks volume variations of a continued note) and using registration (where available, to differentiate between left and right hand). > Indeed, in piano music LilyPond provides facilities for combining the > dynamics from two staves. Not necessarily desired. In pieces or passages where common dynamics are desired, it might be convenient to enter them just in one voice (and have them propagate across all voices, also in Midi). But the dynamics would then not be specified in varying locations. In general, I think that dynamics should be present in every voice entry, just like articulations. And it would usually be the task of the engraver to merge the dynamics when identical. One result of the current mishmash is that the dynamics performer just fiddles with global volume rather than key velocity, propagating dynamics across voices in that manner. More or less accidentally, like we currently do visually. This bug report is just one more outcome of Lilypond having no clean concept of dynamics related to voices rather than merely to current time. -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Mark Polesky wrote Sunday, September 19, 2010 2:37 AM -Eluze wrote: i'm not sure i would like the dynamics of one voice above the staff in a polyphonic guitar piece - but you can use \dynamicUp to do so! The authorities are unanimous on this point. Kurt Stone, ch.1, "Placement of Dynamics...", p.31: "A. Dynamics 1. INSTRUMENTAL MUSIC (SCORES AND/OR PARTS) Single staves with two or more polyphonic parts: at the stem side of the up- and downstemmed parts." Ted Ross, ch.4, "SHARING A STAFF", p.205: "If [the voices] move independently of each other, each part may require its own dynamics, above and below the staff." Gardner Read, ch.14, "NOTATIONAL PRACTICES", p.253: "The general rule is, of course, altered should there be inadequate room because of elements [...] related to the staff just below, or when different dynamic markings affect two voices written on one staff..." We have to be careful to interpret this correctly. None of these writers were familiar with the use of "voice" in the computer engraving sense. By "voice" these writers mean parts that are on one staff but are to be played or sung by independent musicians. With that meaning separating the dynamics is sensible. But it makes no sense to separate the dynamics of individual voices in music that is intended to be played by a single musician, such as guitar or piano music[1]. Indeed, in piano music LilyPond provides facilities for combining the dynamics from two staves. [1] Unless two overlapping sequences of notes are to be played with different dynamics, but then the positioning depends on the particular locations of the notes on the staff and is better done manually. Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: voiceOne dynamics should go above the staff
Mark Polesky wrote: > > -Eluze wrote: >> i'm not sure i would like the dynamics of one voice above >> the staff in a polyphonic guitar piece - but you can use >> \dynamicUp to do so! > > The authorities are unanimous on this point. > > Kurt Stone, ch.1, "Placement of Dynamics...", p.31: > "A. Dynamics > 1. INSTRUMENTAL MUSIC (SCORES AND/OR PARTS) > Single staves with two or more polyphonic parts: > at the stem side of the up- and downstemmed parts." > > Ted Ross, ch.4, "SHARING A STAFF", p.205: > "If [the voices] move independently of each other, each > part may require its own dynamics, above and below the > staff." > > Gardner Read, ch.14, "NOTATIONAL PRACTICES", p.253: > "The general rule is, of course, altered should there be > inadequate room because of elements [...] related to the > staff just below, or when different dynamic markings > affect two voices written on one staff..." > i go with Ross:"If [the voices] move independently of each other, each part may require its own dynamics, above and below the staff." (emphasized by me) he is pointing out that the voices are moving independently - which in many guitar pieces is not the case. therefore i am grateful that Lilypond does not automatically imply \dynamicUp or \dynamicDown with \voiceOne or \voiceTwo. in your example there is a conflict since both voices require a (different) dynamic mark at the same time - maybe Lilypond should detect this and - if not automatically correct it - issue a warning!? finally - what would/could you do with pieces having three or more voices? -Eluze -- View this message in context: http://old.nabble.com/voiceOne-dynamics-should-go-above-the-staff-tp29747634p29750401.html Sent from the Gnu - Lilypond - Bugs mailing list archive at Nabble.com. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
