Re: Repeat alternative count
On Sun, Aug 30, 2020 at 10:34 PM Werner LEMBERG wrote:
>
>
> >> > \alternative {
> >> > { c1 }
> >> > 1
> >> > { d1 }
> >> > 1
> >> >}
> >> >
> >> > Which would be interpretted as: the 1st, 2nd, and 4th endings are c,
> >> > and the 3nd ending is d.
> >>
> >> That is already valid syntax and makes the first and second
> >> alternative c1 and the third and fourth alternative d1 .
> >
> > If Lilypond already does this, it ought to be documented. (It isn't,
> > not on the website anyway.)
>
> Nothing to be documented IMHO: Since 2.20 you can use '1' to
> repeat the same pitch with the given rhythm.
>
> Werner
Ah. I heard about this feature, but didn't know whether it got added
officially yet.
So maybe what we need is something like a new macro like "\redo"
\alternative {
{ c1 }
\redo 1
{ d1 }
\redo 1
\redo 3
}
... although I'm starting to wonder whether the number should refer to
the index of the music sequence, and not the iteration at which it
appears. (You'd have "\redo 2" instead of "\redo 3" in the example
above.) Otherwise you could conceivably have constructions like
\alternative { { c1 } \redo 1 \redo 1 ... \redo 1 { d1 } \redo 1 \redo x }
and you have to count the \redo's to figure out what x is. Whereas, if
the items in \alternatiave's argument that are \redo's are removed,
you get the list
{ { c1 } { d1 } }
and you would know that x = 2 (instead of something like x = 8).
--- Christopher Heckman
Re: Repeat alternative count
>> > \alternative {
>> > { c1 }
>> > 1
>> > { d1 }
>> > 1
>> >}
>> >
>> > Which would be interpretted as: the 1st, 2nd, and 4th endings are c,
>> > and the 3nd ending is d.
>>
>> That is already valid syntax and makes the first and second
>> alternative c1 and the third and fourth alternative d1 .
>
> If Lilypond already does this, it ought to be documented. (It isn't,
> not on the website anyway.)
Nothing to be documented IMHO: Since 2.20 you can use '1' to
repeat the same pitch with the given rythm.
Werner
Re: Repeat alternative count
On Sun, Aug 30, 2020 at 11:59 AM David Kastrup wrote:
>
> Christopher Heckman writes:
>
> > How about allowing modifying the syntax of \alternative to include the
> > possibility of a number, which means to repeat that ending? This would
> > look like
> >
> > \alternative {
> > { c1 }
> > 1
> > { d1 }
> > 1
> >}
> >
> > Which would be interpretted as: the 1st, 2nd, and 4th endings are c,
> > and the 3nd ending is d.
>
> That is already valid syntax and makes the first and second alternative
> c1 and the third and fourth alternative d1 .
>
> Extending LilyPond syntax is not really a matter of arbitrarily
> inventing something: a lot of stuff is already taken.
>
> --
> David Kastrup
If Lilypond already does this, it ought to be documented. (It isn't,
not on the website anyway.)
--- Christopher Heckman
Re: ancient convert rules
Am Sonntag, den 30.08.2020, 22:12 +0200 schrieb Jean Abou Samra: > > What if we kept a legacy convert.ly that went from the origin to, say > > 2.12.0 that was still Python 2 based? And then had the new, Python 3-based > > convert.ly start from 2.12.0? > > > > This would provide a way for anybody who needed to get old source code up > > to the current standard to do so, and would eliminate the burden of > > converting the whole file to Python 3. > > > > Thanks, > > > > Carl > > Maybe the solution is just to mention somewhere in the documentation of > convert-ly that if the user wants to upgrade from older that 2.12 or > whatever, they can use the convert-ly from LilyPond 2.18? If we want to maintain all old rules, I think it's better to have them stay one script. Python 2 will hopefully go away at some point, if the rules are needed they should be fixed. > > I definitely overlooked how often there are*too many* backslashes in > > the code. So there are a lot more changes requried than what is in merge > > request 363: > > Also, you fixed invalid escape sequences -- thanks for that! --, but > pylint can't > spot cases where there aren't many actual backslash characters in the > resulting string > to escape backslashes in the regular expression (the second level of > escaping), like in Jonas' > original example. This is why it seems all ancient rules would require a > decent > amount of work to be made to work with Python 3, if I understand correctly. I think it's not that bad, I went through 24 instances of this. What's giving me more headaches right now is the rule for 2.5.13 to remove \encoding. As far as I understand, it tries to re-encode the whole file which won't work easily because the content is already read in UTF-8 mode. As far as I understand, \encoding "latin1" basically meant binary mode in LilyPond? I guess I have to look this up in git. Jonas signature.asc Description: This is a digitally signed message part
Re: ancient convert rules
Am Sonntag, den 30.08.2020, 21:36 +0200 schrieb Joram Noeck:
> Hi Jonas,
>
> some comments to that:
>
> 1. I (hopefully) fixed all the escaping issues like #6024 in my merge
> request: https://gitlab.com/lilypond/lilypond/-/merge_requests/363
>
> The python re syntax is clear, it just requires the right amout of
> backslashes or r-prefixes;
>
> re.sub(r'\\command', r'\command', s) or
> re.sub('command', '\\command', s)
You need two backslashes in the replacement string, or you get
re.error: bad escape \c at position 0
re.sub(r'\\commandA', r'\\commandB', r'\command')
works correctly.
> I definitely overlooked how often there are *too many* backslashes in
> the code. So there are a lot more changes requried than what is in merge
> request 363:
There is no such thing as too many backslashes due to how re processes
the expressions and replacements, and there are many missing.
> tl;dr: I would not drop conversion rules unless we know that they fail.
All right, this means we need to fix all rules then.
Jonas
signature.asc
Description: This is a digitally signed message part
Re: ancient convert rules
Greetings everybody,
Le 30/08/2020 à 21:06, David Kastrup a écrit :
Jonas Hahnfeld writes:
For https://gitlab.com/lilypond/lilypond/-/issues/6024, I've been
looking at python/convertrules.py and wonder if we really need all
ancient rules starting from version 0.1.9. Right now, a majority of
these won't even apply because Python 3 is much pickier about bad
escape codes in the regular expressions. Example:
re.sub('\\musicalpitch', '\\pitch', s)
is wrong because \\ only escapes for the string and neither \m nor \p
are correct escapes in a regular expression. For this case, it's easy
to fix with raw strings and I think I was able to resolve most errors
so that all rules are able to run, but I've no way to guarantee that my
edits are correct.
To make the story short: Can we maybe instead drop any rules older than
2.12.0? Its last minor release 2.12.3 is more than 10 years ago.
Music tends to stick around really really long once entered. Admittedly
old convert-ly rules tended to be a lot less thorough than what we tend
to do now.
Doing
dak@lola:/usr/local/tmp/The-Mutopia-Project$ git grep -h '\\version'|sort
-u|less
gives me something starting with
\version "1.9.8"
For the record, I finally figured out why we had different results: I
had been
searching only the ftp/ directory. Naturally, what you did is more accurate.
What if we kept a legacy convert.ly that went from the origin to, say
2.12.0 that was still Python 2 based? And then had the new, Python 3-based
convert.ly start from 2.12.0?
This would provide a way for anybody who needed to get old source code up
to the current standard to do so, and would eliminate the burden of
converting the whole file to Python 3.
Thanks,
Carl
Maybe the solution is just to mention somewhere in the documentation of
convert-ly that if the user wants to upgrade from older that 2.12 or
whatever,
they can use the convert-ly from LilyPond 2.18?
I definitely overlooked how often there are*too many* backslashes in
the code. So there are a lot more changes requried than what is in merge
request 363:
Also, you fixed invalid escape sequences -- thanks for that! --, but
pylint can't
spot cases where there aren't many actual backslash characters in the
resulting string
to escape backslashes in the regular expression (the second level of
escaping), like in Jonas'
original example. This is why it seems all ancient rules would require a
decent
amount of work to be made to work with Python 3, if I understand correctly.
Cheers,
Jean
PATCHES - Countdown for August 30th
Hello, Here is the current patch countdown list. The next countdown will be on September 1st. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !353 Fix input/regression/page-label.ly - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/353 !352 web: Remove links to missing binary packages - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/352 !351 NR: document peculiar 'Nr.' ligature in URW fonts - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/351 !348 lilypond-book: replace reduce() call with list concatenation - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/348 Countdown: !360 Remove remnants of defunct `interscoreline` paper variable - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/360 !359 NR: remove overfull lines in PDF output - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/359 !358 Remove RepeatedMusic - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/358 !357 Simultaneous music implicitly creates a Score - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/357 !356 Merge duplicate numbers on multi-measure rests - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/356 !354 doc: exempt web from .xref-map dependency - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/354 !347 doc: qualify snippet paths - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/347 Review: !361 NR: Fix broken Cyrillic output in PDFs. - Werner Lemberg https://gitlab.com/lilypond/lilypond/-/merge_requests/361 !341 Revise gittxt generation - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/341 New: !363 Resolve "convert-ly rule for tocItem" - Joram https://gitlab.com/lilypond/lilypond/-/merge_requests/363 !362 Fix opening files in Python - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/362 Waiting: !344 WIP: fully qualify doc includes. - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/344 !204 Move parallel processing to lilypond-book - Han-Wen Nienhuys https://gitlab.com/lilypond/lilypond/-/merge_requests/204 *** Regards, James
Re: ancient convert rules
> The python re syntax is clear, it just requires the right amout of > backslashes or r-prefixes I definitely overlooked how often there are *too many* backslashes in the code. So there are a lot more changes requried than what is in merge request 363: https://gitlab.com/lilypond/lilypond/-/merge_requests/363 Cheers, Joram
Re: ancient convert rules
Hi Jonas,
some comments to that:
1. I (hopefully) fixed all the escaping issues like #6024 in my merge
request: https://gitlab.com/lilypond/lilypond/-/merge_requests/363
The python re syntax is clear, it just requires the right amout of
backslashes or r-prefixes;
re.sub(r'\\command', r'\command', s) or
re.sub('command', '\\command', s)
2. pylint spots the clearly wrong ones (e.g. \m) but not the valid ones
(e.g. \n in \numbers or \t in \times). I would gladly compare your fixes
to mine.
3. We might want to cleanup convertrules.py. And I doubt that all
conversions work flawlessly for ancient versions all the way to 2.21.
But IMHO this issue is not the right excuse to drop possibly working
functionality.
4. Mutopia uses very old versions. There was an effort in 2014 - 2015 to
update all Mutopia scores to a version > 2.0.0. So version 0 or 1 should
not be used any more (one exception). But 2.2.0 is also very old.
Details for Mutopia:
Update Mutopia pieces with LilyPond versions < 2.0
https://github.com/MutopiaProject/MutopiaProject/milestone/5
Apparently, one work (KV487) is missing from that effort.
2.16 and 2.18 are the most frequent versions in Mutopia:
766 \version "2.16.0"
736 \version "2.18.0"
553 \version "2.18.2"
519 \version "2.16.1"
300 \version "2.14.2"
186 \version "2.10.33"
184 \version "2.12.2"
176 \version "2.10.3"
156 \version "2.6.0"!!!
Besides KV487 with version 1.9.8, the oldest versions are (with number
of occurances):
1 \version "2.2.0"
41 \version "2.4.0"
1 \version "2.4.1"
7 \version "2.4.2"
1 \version "2.4.6"
4 \version "2.5.21"
156 \version "2.6.0"
12 \version "2.6.2"
9 \version "2.6.3"
51 \version "2.6.4"
4 \version "2.6.4.3"
5 \version "2.6.5"
1 \version "2.7.13"
1 \version "2.7.24"
37 \version "2.7.29"
1 \version "2.7.30"
3 \version "2.7.38"
1 \version "2.7.39"
58 \version "2.7.40"
46 \version "2.8.0"
23 \version "2.8.1"
5 \version "2.8.2"
1 \version "2.8.3"
11 \version "2.8.4"
58 \version "2.8.5"
2 \version "2.8.6"
2 \version "2.8.7"
4 \version "2.8.8"
1 \version "2.9.16"
1 \version "2.9.18"
4 \version "2.9.2"
9 \version "2.9.9"
tl;dr: I would not drop conversion rules unless we know that they fail.
Cheers,
Joram
Re: ancient convert rules
Jonas Hahnfeld writes:
> For https://gitlab.com/lilypond/lilypond/-/issues/6024, I've been
> looking at python/convertrules.py and wonder if we really need all
> ancient rules starting from version 0.1.9. Right now, a majority of
> these won't even apply because Python 3 is much pickier about bad
> escape codes in the regular expressions. Example:
> re.sub('\\musicalpitch', '\\pitch', s)
> is wrong because \\ only escapes for the string and neither \m nor \p
> are correct escapes in a regular expression. For this case, it's easy
> to fix with raw strings and I think I was able to resolve most errors
> so that all rules are able to run, but I've no way to guarantee that my
> edits are correct.
>
> To make the story short: Can we maybe instead drop any rules older than
> 2.12.0? Its last minor release 2.12.3 is more than 10 years ago.
Music tends to stick around really really long once entered. Admittedly
old convert-ly rules tended to be a lot less thorough than what we tend
to do now.
Doing
dak@lola:/usr/local/tmp/The-Mutopia-Project$ git grep -h '\\version'|sort
-u|less
gives me something starting with
\version "1.9.8"
\version "2.10"
\version "2.10"
\version "2.10.0"
\version "2.10.0"
\version "2.10.0"
\version "2.10.10"
%\version "2.10.10"
\version "2.10.10"
\version "2.10.12"
\version "2.10.14"
\version "2.10.14"
and also containing
\version "2.2.0"
\version "2.4.0"
\version "2.4.1"
\version "2.4.2"
\version "2.4.2"
\version "2.4.6"
\version "2.5.21"
\version "2.6.0"
\version "2.6.0"
\version "2.6.0"
\version "2.6.2"
\version "2.6.3"
\version "2.6.3"
\version "2.6.3" % necessary for upgrading to future LilyPond versions.
\version "2.6.4"
\version "2.6.4"
\version "2.6.4"
and so on. Stuff like that will not likely convert nicely, but at least
having a start seems like common courtesy.
--
David Kastrup
Re: Repeat alternative count
Christopher Heckman writes:
> How about allowing modifying the syntax of \alternative to include the
> possibility of a number, which means to repeat that ending? This would
> look like
>
> \alternative {
> { c1 }
> 1
> { d1 }
> 1
>}
>
> Which would be interpretted as: the 1st, 2nd, and 4th endings are c,
> and the 3nd ending is d.
That is already valid syntax and makes the first and second alternative
c1 and the third and fourth alternative d1 .
Extending LilyPond syntax is not really a matter of arbitrarily
inventing something: a lot of stuff is already taken.
--
David Kastrup
Re: Repeat alternative count
Dan Eble writes:
> After further thought, I believe we can do this, but using \volta
> where you have \alternative. These are my current thoughts (some
> informed by experiment).
>
> \volta i,j,k can be used anywhere and is semantically similar to tags.
> During unfolding, music is kept which is either marked for the current
> volta or is unmarked. An important difference from tags is that
> unfolding will avoid processing nested repeats before their time.
>
> If you write { \volta 6,12 {…} … \volta 12,13,5 {…} }, LilyPond will
> give you what you seem to be asking for, in repeat layout, unfolded
> layout, and in midi, and not try to make more sense of it than is
> necessary.
>
> \alternative remains (but at some point is renamed \alternatives) for
> these reasons at least:
>
> a. backward compatibility: the legacy syntax produces the same data
> structures as if \volta had been used
>
> b. it provides a scope in which LilyPond can derive implied volta
> numbers as previously discussed in this thread
>
> c. like (b), it might be helpful for producing brackets (but I haven't
> thought much about it yet)
The reason I want to lose it is that most constructs of the form
\prefix ... { ... }
do not require further lookahead to resolve. That's important in
several respect, such like writing
music = \prefix ... { ... }
\music
\alternative is one ugly wart in that respect. \addlyrics is another.
Either cause a fair share of headaches whenever there is a change in the
parser.
Also, \alternative is basically the only construct I know that has
{ sequence of music expressions } mean something different from, well, a
sequential music expression. There have been several cases of people
getting tripped up when forgetting to add inner braces.
Also when the included expressions become longer, the readability for
humans goes down the drain since the individual alternatives are not
separated by anything other than } { or similar.
\volta (?) would be able to take an _optional_ number list if we are
reasonably sure that this is all we need.
Usually prettier alternatives can come with a backward compatibility
hook (though their lifetime tends to be semi-eternal). But in this case
the ugliness does not just extend to the input, but also to the input
processing.
--
David Kastrup
Re: Repeat alternative count
On Aug 29, 2020, at 15:50, Dan Eble wrote:
>
> On Aug 29, 2020, at 14:52, David Kastrup wrote:
>>
>> \repeat volta 40 {
>> ...
>> \alternative { ... }
>> \alternative { ... }
>> \alternative { ... }
>> }
>>
>> since that would avoid several syntactical problems and would allow to
>> produce alternatives by music functions.
>
> I agree, but that's a little too far into fantasy land for me to attempt
> right now.
After further thought, I believe we can do this, but using \volta where you
have \alternative. These are my current thoughts (some informed by experiment).
\volta i,j,k can be used anywhere and is semantically similar to tags. During
unfolding, music is kept which is either marked for the current volta or is
unmarked. An important difference from tags is that unfolding will avoid
processing nested repeats before their time.
If you write { \volta 6,12 {…} … \volta 12,13,5 {…} }, LilyPond will give you
what you seem to be asking for, in repeat layout, unfolded layout, and in midi,
and not try to make more sense of it than is necessary.
\alternative remains (but at some point is renamed \alternatives) for these
reasons at least:
a. backward compatibility: the legacy syntax produces the same data structures
as if \volta had been used
b. it provides a scope in which LilyPond can derive implied volta numbers as
previously discussed in this thread
c. like (b), it might be helpful for producing brackets (but I haven't thought
much about it yet)
—
Dan
Re: ancient convert rules
Hi Jonas,
Le 30/08/2020 à 15:38, Jonas Hahnfeld a écrit :
For https://gitlab.com/lilypond/lilypond/-/issues/6024, I've been
looking at python/convertrules.py and wonder if we really need all
ancient rules starting from version 0.1.9. Right now, a majority of
these won't even apply because Python 3 is much pickier about bad
escape codes in the regular expressions. Example:
re.sub('\\musicalpitch', '\\pitch', s)
is wrong because \\ only escapes for the string and neither \m nor \p
are correct escapes in a regular expression. For this case, it's easy
to fix with raw strings and I think I was able to resolve most errors
so that all rules are able to run, but I've no way to guarantee that my
edits are correct.
Ah, we were doing overlapping work, thanks for letting us know! I'll let
you go ahead.
On 30/08/2020 14:38, Jonas Hahnfeld wrote:
To make the story short: Can we maybe instead drop any rules older than
2.12.0? Its last minor release 2.12.3 is more than 10 years ago.
I don't know.
While it is more than 10 years ago, I seem to recall a lot of stuff on
Mutopia where there are LP files to use are from much older than 2010.
A quick searchin Mutopia's repository reveals that the oldest \version
statement
there is 2.4.0. That release dates back to 2004. I think it would be
fine to drop
rules prior to that version, or maybe 2.0.
I think at the very least we should perhaps 'flag' anything (either as
a warning or as an error) for users that might have needed to convert
something that we have removed because of backward compatibility if
they tried to use such a convert-ly file. Rather than look like it has
worked until they try to compile it with the later code and then get
an error and open a bug report (if you see what I mean).
It should be made to error out when conversion from a version older that
2.4.0 or
whatever is attempted, I guess. Does that address your concern?
Best,
Jean
Re: ancient convert rules
On Sun, Aug 30, 2020 at 9:02 AM Jonas Hahnfeld wrote:
> For https://gitlab.com/lilypond/lilypond/-/issues/6024, I've been
> looking at python/convertrules.py and wonder if we really need all
> ancient rules starting from version 0.1.9. Right now, a majority of
> these won't even apply because Python 3 is much pickier about bad
> escape codes in the regular expressions. Example:
> re.sub('\\musicalpitch', '\\pitch', s)
> is wrong because \\ only escapes for the string and neither \m nor \p
> are correct escapes in a regular expression. For this case, it's easy
> to fix with raw strings and I think I was able to resolve most errors
> so that all rules are able to run, but I've no way to guarantee that my
> edits are correct.
>
> To make the story short: Can we maybe instead drop any rules older than
> 2.12.0? Its last minor release 2.12.3 is more than 10 years ago.
>
What if we kept a legacy convert.ly that went from the origin to, say
2.12.0 that was still Python 2 based? And then had the new, Python 3-based
convert.ly start from 2.12.0?
This would provide a way for anybody who needed to get old source code up
to the current standard to do so, and would eliminate the burden of
converting the whole file to Python 3.
Thanks,
Carl
Re: ancient convert rules
FWIW, I ran a grep on my files, and the oldest version is 2.4.4; there are also several 2.9, 2.10 and 2.11 ones. I admit I rarely touch old files, but sometimes that happens. James Lowe ezt írta (időpont: 2020. aug. 30., V, 16:32): > > On 30/08/2020 14:38, Jonas Hahnfeld wrote: > > To make the story short: Can we maybe instead drop any rules older than > > 2.12.0? Its last minor release 2.12.3 is more than 10 years ago. > > I don't know. > > While it is more than 10 years ago, I seem to recall a lot of stuff on > Mutopia where there are LP files to use are from much older than 2010. > > I think at the very least we should perhaps 'flag' anything (either as a > warning or as an error) for users that might have needed to convert > something that we have removed because of backward compatibility if they > tried to use such a convert-ly file. Rather than look like it has worked > until they try to compile it with the later code and then get an error > and open a bug report (if you see what I mean). > > James > >
Re: ancient convert rules
On 30/08/2020 14:38, Jonas Hahnfeld wrote: To make the story short: Can we maybe instead drop any rules older than 2.12.0? Its last minor release 2.12.3 is more than 10 years ago. I don't know. While it is more than 10 years ago, I seem to recall a lot of stuff on Mutopia where there are LP files to use are from much older than 2010. I think at the very least we should perhaps 'flag' anything (either as a warning or as an error) for users that might have needed to convert something that we have removed because of backward compatibility if they tried to use such a convert-ly file. Rather than look like it has worked until they try to compile it with the later code and then get an error and open a bug report (if you see what I mean). James
ancient convert rules
For https://gitlab.com/lilypond/lilypond/-/issues/6024, I've been
looking at python/convertrules.py and wonder if we really need all
ancient rules starting from version 0.1.9. Right now, a majority of
these won't even apply because Python 3 is much pickier about bad
escape codes in the regular expressions. Example:
re.sub('\\musicalpitch', '\\pitch', s)
is wrong because \\ only escapes for the string and neither \m nor \p
are correct escapes in a regular expression. For this case, it's easy
to fix with raw strings and I think I was able to resolve most errors
so that all rules are able to run, but I've no way to guarantee that my
edits are correct.
To make the story short: Can we maybe instead drop any rules older than
2.12.0? Its last minor release 2.12.3 is more than 10 years ago.
Jonas
signature.asc
Description: This is a digitally signed message part
