Re: New repeat type
Original message
From: Dan Eble
Date: 8/29/17 5:33 PM (GMT-07:00)
To: Carl Sorensen
Cc: LilyPond Development Team
Subject: Re: New repeat type
> On Aug 29, 2017, at 19:14, Carl Sorensen wrote:
>
> I wouldnt, because it is not a repeat.
Not even as
\alternative {
\new Lyrics { \stanzaI }
\new Lyrics { \stanzaII }
}
to be treated as simultaneous during engraving but unfolded before performing?
—
Dan
Repeats result in sequential music, regardless of whether they are volta,
unfold, or tremolo, right?
There are no repeats named by that structure that I am aware of in the music
literature that create simultaneous music.
If we want to do something like this I think we should call it a lyricrepeat,
or a stanzarepeat.
But the most common stanza repeat stuctire in my experience is a verse-chorus
structure:
\stanzarepeat \stanzas { \new lyrics {\stanza1}{\stanza2}{\stanza3}} {\chorus}
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New repeat type
> On Aug 29, 2017, at 19:14, Carl Sorensen wrote:
>
> I wouldnt, because it is not a repeat.
Not even as
\alternative {
\new Lyrics { \stanzaI }
\new Lyrics { \stanzaII }
}
to be treated as simultaneous during engraving but unfolded before performing?
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New repeat type
I wouldnt, because it is not a repeat.
Sent via the Samsung Galaxy S®6 active, an AT&T 4G LTE smartphone
Original message
From: Dan Eble
Date: 8/29/17 5:01 PM (GMT-07:00)
To: LilyPond Development Team
Subject: New repeat type
Consider: \repeat XX \A \alternative { \B \C }
If “unfold” is effectively
{
{ \A \B }
{ \A \C }
}
what type would you call this, if it existed?
<<
{ \A \B }
{ \A \C }
>>
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
New repeat type
Consider: \repeat XX \A \alternative { \B \C }
If “unfold” is effectively
{
{ \A \B }
{ \A \C }
}
what type would you call this, if it existed?
<<
{ \A \B }
{ \A \C }
>>
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let Merge_rests_engraver deal with dotted rests (issue 324310043 by thomasmorle...@gmail.com)
On 2017/08/29 07:55:06, dak wrote: https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10 Documentation/notation/simultaneous.itely:10: @c \version "2.19.29" On 2017/08/29 07:39:45, thomasmorley651 wrote: > On 2017/08/29 07:31:20, dak wrote: > > Version warrants changing to the version where the engraver got register. At > > least once you actually make use of the registration... > > Not sure to which version I should change it, 2.21.0? Excellent question, actually. I think that the dot merge functionality is too new and untested for 2.20.0 but the Merge_rest_engraver itself has been around unregistered for months and that seems like a bad idea for 2.20. So I'd propose that you split the registration (and its use in docs and old(!) regtest) into a separate commit and use version 2.20.0 on that. I can cherry-pick that into the stable branch then. The rest is for 2.21 then. It's either that or back out (namely revert) all of the Merge_rest_engraver for 2.20. But that would necessitate tampering with both documentation and translation a lot more, so it's not my preferred option. Holler if you need Git assistance. I now splitted the patch. Obviously Rietveld merges the two patches for review, though. Is it possible to see them separated somewhere? https://codereview.appspot.com/324310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let Merge_rests_engraver deal with dotted rests (issue 324310043 by thomasmorle...@gmail.com)
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10 Documentation/notation/simultaneous.itely:10: @c \version "2.19.29" On 2017/08/29 07:39:45, thomasmorley651 wrote: On 2017/08/29 07:31:20, dak wrote: > Version warrants changing to the version where the engraver got register. At > least once you actually make use of the registration... Not sure to which version I should change it, 2.21.0? Excellent question, actually. I think that the dot merge functionality is too new and untested for 2.20.0 but the Merge_rest_engraver itself has been around unregistered for months and that seems like a bad idea for 2.20. So I'd propose that you split the registration (and its use in docs and old(!) regtest) into a separate commit and use version 2.20.0 on that. I can cherry-pick that into the stable branch then. The rest is for 2.21 then. It's either that or back out (namely revert) all of the Merge_rest_engraver for 2.20. But that would necessitate tampering with both documentation and translation a lot more, so it's not my preferred option. Holler if you need Git assistance. https://codereview.appspot.com/324310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let Merge_rests_engraver deal with dotted rests (issue 324310043 by thomasmorle...@gmail.com)
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10 Documentation/notation/simultaneous.itely:10: @c \version "2.19.29" On 2017/08/29 07:31:20, dak wrote: Version warrants changing to the version where the engraver got register. At least once you actually make use of the registration... Not sure to which version I should change it, 2.21.0? https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode933 Documentation/notation/simultaneous.itely:933: \consists \Merge_rests_engraver On 2017/08/29 07:31:20, dak wrote: Uh, what? You could have written _this_ without registering the engraver. The point of registering the engraver is that you can write \consists Merge_rests_engraver or (I think that's the convention we usually use) \consists "Merge_rests_engraver" like with C++-defined engravers. Silly me. Will change, in the reg-test as well https://codereview.appspot.com/324310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: change translations?
2017-08-29 8:53 GMT+02:00 David Kastrup : > Thomas Morley writes: > >> Hi, >> >> my last patch-set for >> https://sourceforge.net/p/testlilyissues/issues/5179/ >> registers the Merge_rests_engraver. >> Obviously the docs/regtests should be changed from \consists >> #Merge_rests_engraver to \consists \Merge_rests_engraver. >> >> >> What is our policy for translations in this regard? >> Should I change it there as well or leave it to the translators? Up to >> now the french translation is the only one mentioning >> Merge_rests_engraver at all. > > Usually leaving stuff to the translators is fine unless convert-ly > already does the job. I don't think that this warrants a convert-ly > rule though: the Merge_rests_engraver hasn't been around long enough. > Thanks, new patch's up, only changing the english docs. Cheers, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Let Merge_rests_engraver deal with dotted rests (issue 324310043 by thomasmorle...@gmail.com)
https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely File Documentation/notation/simultaneous.itely (right): https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode10 Documentation/notation/simultaneous.itely:10: @c \version "2.19.29" Version warrants changing to the version where the engraver got register. At least once you actually make use of the registration... https://codereview.appspot.com/324310043/diff/40001/Documentation/notation/simultaneous.itely#newcode933 Documentation/notation/simultaneous.itely:933: \consists \Merge_rests_engraver Uh, what? You could have written _this_ without registering the engraver. The point of registering the engraver is that you can write \consists Merge_rests_engraver or (I think that's the convention we usually use) \consists "Merge_rests_engraver" like with C++-defined engravers. https://codereview.appspot.com/324310043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
